The LGPL only obliges you to release derived works under a compatible license. The issue really hinges on what is really considered a derived work. With executables, if you link your application against LGPL code statically, it is considered derived, but if you link it dynamically, it is not. If you make changes to the library, it is very obviously derived and must also be released under a compatible license. This is pretty clear cut and dry.
With javascript development, things get a little murkier. Let's use jQuery as an example (I know it's MIT and not LGPL, but for the sake of discussion...) If you pull in jQuery, your code can still be separated from jQuery and would not need to be released. If you used some tool to concatenate and minimize all your code with the jQuery code, your code cannot be separated from the jQuery code and would need to be released with a compatible license. Dynamic linking vs static -- essentially the same concept. With qooxdoo and its necessary build process, you are essentially always static linking. With careful planning and use of the Parts Loader (http://demo.qooxdoo.org/current/apiviewer/#qx.io.PartLoader) you can effectively separate your code, and only release the linking code. (Just the code that does the loading.) HOWEVER: "As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and **reverse engineering** for debugging such modifications." -- emphasis mine http://www.gnu.org/licenses/lgpl-2.1.html <-- See section 6 It *could* be argued that even concatenated and minimized javascript code can be reverse engineered (no matter now tedious,) so a "statically linked" javascript application is also excluded as a non-derived work. This gets a little hairy, no?? Of course, there is the caveat that I'm not a lawyer, and others may interpret the LGPL differently. Since I'm not doing anything externally, not selling or distributing anything outside of this organization (with the exception of a number of non-employee users accessing our applications,) the LGPL is perfectly acceptable in our use-case. The GPL is not. We are most definitely not releasing our server side stuff! :) At the end of the day, if our non-employee users really *want* to see our client side code, we have no major reservations against it -- it's never been an issue regardless... On 2014-11-07 14:58, Reggaeny wrote: > Wow...! > What an eloquent and complete answer. > > I'm just analyzing several Javascript Frameworks in order to examine > the > feasibility of developing a commercially used/sold technology platform > consisting of a java backend and a javascript/HTML5 framework as a > frontend. > > The type-system of qooxdoo, you mentioned, is a very strong argument as > it > perfectly fits to the strong typing of Java making it easier to > maintain a > concise and comparable programming philosophy for both the front- and > the > backend. > > There is but one question left. You say that the qooxdoo license is OK > for > corporate applications. As far as I can see the LPGL/EPL License > obliges me > to publish the applications developed with qooxdoo under the same > license. > As most of the business logic and the components deserving protection > are > part of the server and the middleware (message-broker) I'm just > developing, > I suppose the LPGL/EPL license would be OK for me. > > > > -- > View this message in context: > http://qooxdoo.678.n2.nabble.com/Coming-from-Sencha-ExtJs-tp7586356p7586363.html > Sent from the qooxdoo mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > _______________________________________________ > qooxdoo-devel mailing list > qooxdoo-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel ------------------------------------------------------------------------------ _______________________________________________ qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
