[Jakarta Wiki] Update of Using LGPL'd code by HenriYandell
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta Wiki for change notification. The following page has been changed by HenriYandell: http://wiki.apache.org/jakarta/Using_LGPL'd_code The comment on the change is: Removing this page and replacing with a link to the 3rd party draft. -- == Can I use an LGPL'd licensed work at Apache? == - No. + See: [http://www.apache.org/legal/3party.html] - == Please? == - - Nope. - - == Why not? == - - Basically, LGPL is a license written for the C programming language. - While we all agree that its intent is to allow people to freely use - the library, its wording means that the actual application to a - language other than C is up for debate. A lot of this comes down to - whether the term 'linking' means 'import' in Java or not. Early vs - Late linking languages etc. - - Anyways, legal advice given to the ASF is to not to be tied to an LGPL - license as the LGPL is feasibly as viral as GPL. This isn't just some - NIH view the ASF have. Lawrence Rosen's latest book ''Open Source Licensing'' - seems to repeat the view. This means: - - * we cannot have LGPL'd jars in the CVS repository - * that we cannot modify previously LGPL'd code - * that we cannot import LGPL'd code in our import statements. - - The same applies for GPL. - - The only solutions are: - - * Ask the library to dual-license LGPL with something like BSD or ASF 2.0. - * Make the LGPL-usage a plugin, and host the plugin outside of the ASF. - - The latter does mean that you are personally taking on the liability for the code; ie) you're now in the situation that the lawyers warn against. - - == This sucks == - - Yep. - - == Will this ever be resolved? == - - I'm hoping that as the months go by next year (2005) the board will have a method by which - we'll be able to import LGPL'd code in our code. GPL will still be out of the question, as - would LGPL in CVS or modifying LGPL; but use of Dumbster, JFreeCharts, Hibernate - and other libraries would be possible. - - - = Latest [EMAIL PROTECTED] informations (2006) = - - Lately we discussed that it might be possible that the PMC is able to vote to add LGPL stuff to a project as long as the following rule will be fulfilled. - - We still need the ok from legal@ before we start with this procedure. - - At least the jakarta PMC voted that these rules are acceptable. - - == Rules== - - * ask the original library author to change its license or provide a double licensing model - * look for an alternative implementation with an ASF friendly license - * the build script BY DEFAULT excludes java classes depending on LGPL - * a special parameter will enable building these classes - * its not allowed to bundle the LGPL library with any distribution\\(nightly, release) - * the function the library gains from the LGPL stuff is fully optional - * a bridging api (which can reside within the same project - so can be hosted at apache) will be used to access these LGPL stuff to clearly show its optional behaviour - * a vote for adding a LGPL dependency to a project on pmc@ - - The technical stuff how to setup the build has to be figured out. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Update of Using LGPL'd code by HenriYandell
Hi! The following page has been changed by HenriYandell: http://wiki.apache.org/jakarta/Using_LGPL'd_code Does this mean the door to have LGPL dependencies as described below has been closed again? - = Latest [EMAIL PROTECTED] informations (2006) = - - Lately we discussed that it might be possible that the PMC is able to vote to add LGPL stuff to a project as long as the following rule will be fulfilled. - - We still need the ok from legal@ before we start with this procedure. - - At least the jakarta PMC voted that these rules are acceptable. - - == Rules== - - * ask the original library author to change its license or provide a double licensing model - * look for an alternative implementation with an ASF friendly license - * the build script BY DEFAULT excludes java classes depending on LGPL - * a special parameter will enable building these classes - * its not allowed to bundle the LGPL library with any distribution\\(nightly, release) - * the function the library gains from the LGPL stuff is fully optional - * a bridging api (which can reside within the same project - so can be hosted at apache) will be used to access these LGPL stuff to clearly show its optional behaviour - * a vote for adding a LGPL dependency to a project on pmc@ - - The technical stuff how to setup the build has to be figured out. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Update of Using LGPL'd code by HenriYandell
Ah - now I see. Must be the Optional Add-ons section. Thanks! Ciao, Mario I don't think so - the 3rd party draft I link to says pretty much the same thing. On 10/4/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! The following page has been changed by HenriYandell: http://wiki.apache.org/jakarta/Using_LGPL'd_code Does this mean the door to have LGPL dependencies as described below has been closed again? - = Latest [EMAIL PROTECTED] informations (2006) = - - Lately we discussed that it might be possible that the PMC is able to vote to add LGPL stuff to a project as long as the following rule will be fulfilled. - - We still need the ok from legal@ before we start with this procedure. - - At least the jakarta PMC voted that these rules are acceptable. - - == Rules== - - * ask the original library author to change its license or provide a double licensing model - * look for an alternative implementation with an ASF friendly license - * the build script BY DEFAULT excludes java classes depending on LGPL - * a special parameter will enable building these classes - * its not allowed to bundle the LGPL library with any distribution\\(nightly, release) - * the function the library gains from the LGPL stuff is fully optional - * a bridging api (which can reside within the same project - so can be hosted at apache) will be used to access these LGPL stuff to clearly show its optional behaviour - * a vote for adding a LGPL dependency to a project on pmc@ - - The technical stuff how to setup the build has to be figured out. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Wiki] Update of Using LGPL'd code by HenriYandell
I don't think so - the 3rd party draft I link to says pretty much the same thing. On 10/4/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! The following page has been changed by HenriYandell: http://wiki.apache.org/jakarta/Using_LGPL'd_code Does this mean the door to have LGPL dependencies as described below has been closed again? - = Latest [EMAIL PROTECTED] informations (2006) = - - Lately we discussed that it might be possible that the PMC is able to vote to add LGPL stuff to a project as long as the following rule will be fulfilled. - - We still need the ok from legal@ before we start with this procedure. - - At least the jakarta PMC voted that these rules are acceptable. - - == Rules== - - * ask the original library author to change its license or provide a double licensing model - * look for an alternative implementation with an ASF friendly license - * the build script BY DEFAULT excludes java classes depending on LGPL - * a special parameter will enable building these classes - * its not allowed to bundle the LGPL library with any distribution\\(nightly, release) - * the function the library gains from the LGPL stuff is fully optional - * a bridging api (which can reside within the same project - so can be hosted at apache) will be used to access these LGPL stuff to clearly show its optional behaviour - * a vote for adding a LGPL dependency to a project on pmc@ - - The technical stuff how to setup the build has to be figured out. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
