[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 LGPL@jakarta 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.
-

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 LGPL@jakarta 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

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 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 LGPL@jakarta 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: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>

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 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 LGPL@jakarta 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: general-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: general-help@jakarta.apache.org
>>
>>
>>
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>