Since you're asking opinions, here's mine. I think that we should NOT include any LGPL'd projects, or any possibility of people inadvertently getting them included during build time, no matter how great these projects are.
If for some very special reason we want to provide support for an LGPL'd project (like in the case for neo4j), then we could provide code for the module separately, but require that the user of the module include any dependency on it manually herself in her own POM (kind of like the equivalent of an explicit click on the "I agree" button). That way, no mistakes, or at least none caused by confusion due to ops4j. Cheers, David > -----Original Message----- > From: [email protected] > [mailto:[email protected]]on Behalf Of Niclas Hedhman > Sent: 20 December 2008 16:29 > To: Qi4j Dev > Subject: [qi4j-dev] Licensing > > > Gang, > > Another case of licensing has emerged in our internal discussions; LGPL. > > LGPL is essentially a response from Free Software Foundation to > compete in 'commerce friendly' licensing. It is not nearly as > 'liberal' as the BSD, MIT and Apache licenses, but a hell lot better > than GPL and, God forbid, Affero GPL. > > Now, The Apache Software Foundation has practically ruled out Apache > projects to use LGPL codebase, not even as a binary dependency. See > http://www.apache.org/legal/3party.html. The main reason being that > LGPL imposes restrictions on larger works. For instance, for a > closed-source product to use LGPL code its license must allow > reverse-engineering. > > So, what does this got to do with Qi4j? > > We already have the entitystore-neo4j module, which in itself is > Apache licensed, but whomever downloads the AGPLv3 licensed Neo4j > which it depends on, is not allowed to combine Neo4j, > entitystore-neo4j and Qi4j application for use by anyone by > him/herself (excl web apps for instances), without violating the AGPL. > (For clarity, said person can purchase a commercial license with other > terms.) In fact, one could argue that running the entity-store > testcases is already a violation, since Maven will do the download and > there is combined work that is not AGPL licensed. > > So, you can see that this case is somewhat complicated already. If we > are to allow this, and hence similar licensing scenarios, we may > create a complicated mess for downstream users. On the other hand, by > excluding such possibilities we will limit our options and some things > that we might want to do becomes too hard and won't be done at all. > > > What I would like to hear is the views and opinions of all the lurkers > on this list. There is >100 of you, so I hope to get some constructive > feedback on how to balance this. Should we disallow it? Should we > separate legally entangled stuff onto a SourceForge project? Should we > just document it and put up a big sign of warnig, if so how is that > 'sign' going to work? Are there other solutions? > > > Cheers > Niclas > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev > _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
