You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Pier Fumagalli <pi...@betaversion.org> on 2003/01/26 20:58:28 UTC
Why not LGPL? (Was: Re: ChartTransformer 0.0.4 urge a commiter!)
Nicola Ken Barozzi wrote:
> Steven Noels wrote:
>> Nicola Ken Barozzi wrote:
>>
>>> I'm not going to put another jar in our dependencies that is LGPL also.
>>
>> You are not _allowed_ to do so.
>
> Actually, we can. It depends on whom you ask ;-)
Both wrong? :-) :-)
Ok, let me try to explain the rationale behind GPL/LGPL for inclusion in
the ASF codebases.
I believe that everyone will know why GPL is "no-no" for us: it's a
"viral" license, every modification to some GPL code, and everything
linked against some GPL code _needs_ to be re-released as GPL.
Now, the folks at GNU one day, seeing the drawbacks imposed by this
licensing scheme (not many wanted to release software using a GPL
licensed library) decided to come out with a "Lesser" GPL (LGPL).
LPGL has one small caveat in it: you can LINK against that library and
not be forced to re-release your code as GPL (however, if you modify the
library itself, your modifications will have to be licensed under LGPL
again, it is still "viral" on that part).
Legally there is nothing preventing us (Apache) to base some of our work
on a LGPL licensed library, then, for real, you can link against, put it
in CVS, do whatever you want. But there is one tricky little detail:
If (for example) we, the ASF, decided to get the library and make some
modifications to it, or, scarier though, we _had_ to "fork" the library
for our own needs (imagine, the orignal author changes from LGPL to
something else, full GPL for example -as happened lately to the MySQL
JDBC drivers- or even worse, decides the library will only be
distributed as "commercial software"), then we would be utterly f***ed.
Ethically the ASF does not develops software under a "viral" license,
therefore, given the "partial virality" of LGPL, we wouldn't be able to
"fork" and maintain such a library. We wouldn't even be able to change
the license, all modifications would have to be LGPL, so, we either
would have to rewrite the whole thing, or get rid of the offending bits
and bobs...
Soooo, I'd say, if you see the word GPL somewhere (with or without the
leading L) my answer is usually no, because now or in the future it
could/will create problems...
My 2c...
Pier
BTW, this whole argument about Charts is getting _so_ tedious! :-) :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Why not LGPL? (Was: Re: ChartTransformer 0.0.4 urge a commiter!)
Posted by Pier Fumagalli <pi...@betaversion.org>.
Jeff Turner wrote:
>
> Not at Apache, but is there anything stopping a few developers forking
> the last LGPL'ed version on Sourceforge?
Nope, not AFAIK...
> If so, then using LGPL code could be an acceptable risk. The
> alternatives (rewrite, or convince the world to adopt BSD/ASL) aren't fun
> at all..
Maybe from your point of view, from mine (and don't take it personally,
please, it's just an example) there's no difference between Jeff Turner
of the Cocoon fame and Mark Matthews of the MySQL-MM JDBC driver...
I had some chats in the past with Mark, and he understood our vision and
why whe used the BSD/ASL instead of GPL/LGPL, but look at how version
3.0 of his codebase is now distributed! :-)
IIRC (long time have passed) at that time we were even "in the talks"
for bringing the driver under Jakarta...
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Why not LGPL? (Was: Re: ChartTransformer 0.0.4 urge a commiter!)
Posted by Jeff Turner <je...@apache.org>.
On Sun, Jan 26, 2003 at 07:58:28PM +0000, Pier Fumagalli wrote:
> Nicola Ken Barozzi wrote:
> >Steven Noels wrote:
> >>Nicola Ken Barozzi wrote:
> >>
> >>>I'm not going to put another jar in our dependencies that is LGPL also.
> >>
> >>You are not _allowed_ to do so.
> >
> >Actually, we can. It depends on whom you ask ;-)
>
> Both wrong? :-) :-)
>
> Ok, let me try to explain the rationale behind GPL/LGPL for inclusion in
> the ASF codebases.
>
> I believe that everyone will know why GPL is "no-no" for us: it's a
> "viral" license, every modification to some GPL code, and everything
> linked against some GPL code _needs_ to be re-released as GPL.
>
> Now, the folks at GNU one day, seeing the drawbacks imposed by this
> licensing scheme (not many wanted to release software using a GPL
> licensed library) decided to come out with a "Lesser" GPL (LGPL).
>
> LPGL has one small caveat in it: you can LINK against that library and
> not be forced to re-release your code as GPL (however, if you modify the
> library itself, your modifications will have to be licensed under LGPL
> again, it is still "viral" on that part).
>
> Legally there is nothing preventing us (Apache) to base some of our work
> on a LGPL licensed library, then, for real, you can link against, put it
> in CVS, do whatever you want.
Well that's interesting.
> But there is one tricky little detail:
>
> If (for example) we, the ASF, decided to get the library and make some
> modifications to it, or, scarier though, we _had_ to "fork" the library
> for our own needs (imagine, the orignal author changes from LGPL to
> something else, full GPL for example -as happened lately to the MySQL
> JDBC drivers- or even worse, decides the library will only be
> distributed as "commercial software"), then we would be utterly f***ed.
>
> Ethically the ASF does not develops software under a "viral" license,
> therefore, given the "partial virality" of LGPL, we wouldn't be able to
> "fork" and maintain such a library.
Not at Apache, but is there anything stopping a few developers forking
the last LGPL'ed version on Sourceforge?
If so, then using LGPL code could be an acceptable risk. The
alternatives (rewrite, or convince the world to adopt BSD/ASL) aren't fun
at all..
--Jeff
> We wouldn't even be able to change the license, all modifications would
> have to be LGPL, so, we either would have to rewrite the whole thing,
> or get rid of the offending bits and bobs...
>
> Soooo, I'd say, if you see the word GPL somewhere (with or without the
> leading L) my answer is usually no, because now or in the future it
> could/will create problems...
>
> My 2c...
>
> Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Why not LGPL? (Was: Re: ChartTransformer 0.0.4 urge a commiter!)
Posted by Pier Fumagalli <pi...@betaversion.org>.
Luca Morandini wrote:
>
> I mean, Cocoon already has some components relying on non-ASL
> libraries (like the SAP ones or the JDBC drivers); had these
> libraries to change, ASF wouldn't be able to fork them, hence
> resorting to change the Cocoon components, which is what was
> to be avoided in the first place.
>
> This underlines, I fear, a more general problem: to make Cocoon
> more powerful it has to interface to as many software packages
> as possible, which means it will, in some ways, come to depend
> on them.
>
> As a long-time Cocoon user, I dare to say: the gain is worth the
> risk !
As an old Apache fart, I'd say nope... Look at HTTPd land, modules
relyng on something over which we have some kind of legal troubles with
are not included in the distro, not included in the "core", not on our
CVS... mod_auth_mysql, for example). I don't think they ever will...
> Getting back to the point: in the case of JFreeChartTransformer
> the idea would be to treat it like the SAP components: put the
> transformer in the codebase and leave the non-ASL library out.
>
> Does it sound too risky a strategy ?
This community should not rely on my only judgement to evaluate the
possible risks of a strategy... (I'm the one who put all those nasty
bugs two years ago, and you had to work for 2 years, in more than 30 to
get rid of them! :-) :-) :-)
And please note that already many raised the same issue with the SAPv3
components (I can't find them in CVS, so, I assume they're not going to
be "in" until those problems are solved)...
Steven said:
> If license issues do not allow these components to be added to ASF
> CVS, we could look and see whether they could be hosted at
> cocoondev.org (since yes, they would be a valuable addition to
> Cocoon).
And I share Sylvain's point here:
> we voted a cocoon-apps module to host Cocoon-related developments
> that don't belong to the core. And this ultra-specific component
> typically falls in this category.
Well, in the past, our fellow colleagues on HTTPd created
<http://modules.apache.org>. I believe that most people would prefer to
see a similar solution for Cocoon rather than adding, and adding, and
adding stuff to the main CVS tree. And indeed it would solve the
"legalities" as well, relegating the problem to the end user...
<ashamed>
AxKIT solved all this mess even before starting... They use CPAN, we
don't even have that... :-( :-( :-( :-(
</ashamed>
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Why not LGPL? (Was: Re: ChartTransformer 0.0.4 urge a commiter!)
Posted by Luca Morandini <lu...@tin.it>.
> -----Original Message-----
> From: Pier Fumagalli [mailto:pier@betaversion.org]
> Sent: Sunday, January 26, 2003 8:58 PM
> To: cocoon-dev@xml.apache.org
> Subject: Why not LGPL? (Was: Re: ChartTransformer 0.0.4 urge a
> commiter!)
> Soooo, I'd say, if you see the word GPL somewhere (with or without the
> leading L) my answer is usually no, because now or in the future it
> could/will create problems...
>
Pier,
your point is very clear and I cannot agree more... but it begs the question: does this precaution extend to libraries that are not
included in the codebase ?
I mean, Cocoon already has some components relying on non-ASL libraries (like the SAP ones or the JDBC drivers); had these libraries
to change, ASF wouldn't be able to fork them, hence resorting to change the Cocoon components, which is what was to be avoided in
the first place.
This underlines, I fear, a more general problem: to make Cocoon more powerful it has to interface to as many software packages as
possible, which means it will, in some ways, come to depend on them.
As a long-time Cocoon user, I dare to say: the gain is worth the risk !
Getting back to the point: in the case of JFreeChartTransformer the idea would be to treat it like the SAP components: put the
transformer in the codebase and leave the non-ASL library out.
Does it sound too risky a strategy ?
My 1.2c (after tax)
Regards,
---------------------------------------------
Luca Morandini
GIS Consultant
lmorandini@ieee.org
http://utenti.tripod.it/lmorandini/index.html
---------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Why not LGPL? (Was: Re: ChartTransformer 0.0.4 urge a commiter!)
Posted by Stefano Mazzocchi <st...@apache.org>.
Ovidiu Predescu wrote:
> Rewriting the code to conform to a license is a poor choice IMO.
Agreed and respected.
Although, there is a real problem: the LGPL says that you are forced to
put changes back into the LGPL license only if you modify the library,
but not the code that links to it.
Now, what is a java library?
The real issue with LGPL is with its imprecision: there potentially no
limit about where the 'gpl infection' can get thru in your code.
Personally, I don't want to give the FSF the possibility to come after
us because of that.
I designed the blocks concept also to get around legal problems because
the xGPL works with 'redistribution', not 'installation'.
You can even install a GPL cocoon block on top of Cocoon and as long as
we don't ship any of that inside Cocoon, we are fine and the user who
does is fine as well.
The block concept will work as a condom around GPL virality (yes, RMS, I
don't like your imposed freedom, I want 'metafreedom' the freedom to
choose my flavor of it and to dislike yours, thank you)
Today, even moch classes are unsafe sex for us, because moch classes
rewrite parts that are *included* in the library so they are part of the
library itself, so they have to be LGPL-ed.
At the end, do not worry, we are not trying to paint the world with
Apache licenses (like the FSF does) so we'll work to make it possible to
make the software interoperate.
But we need blocks for that and we need a serious avalon container for
that and we need a serious community around it... or we simply screw
them and build our own container.
oh well...
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Why not LGPL? (Was: Re: ChartTransformer 0.0.4 urge a
commiter!)
Posted by Pier Fumagalli <pi...@betaversion.org>.
<note>
This discussion should be better if continued on community@apache.org.
I'm sending it here because of the last few lines pertinent to Cocoon
specifically.
Also, I'm not on community@apache.org, as I trust my peers over there to
do a great job and have not much time to contribute to the discussuin.
If you think it's appropriate, feel free to CC me as well...
</note>
"Ovidiu Predescu" <ov...@apache.org> wrote:
> Pier,
>
> On Sunday, Jan 26, 2003, at 11:58 US/Pacific, Pier Fumagalli wrote:
>
>> If (for example) we, the ASF, decided to get the library and make some
>> modifications to it, or, scarier though, we _had_ to "fork" the
>> library for our own needs (imagine, the orignal author changes from
>> LGPL to something else, full GPL for example -as happened lately to
>> the MySQL JDBC drivers- or even worse, decides the library will only
>> be distributed as "commercial software"), then we would be utterly
>> f***ed.
>
> Under the same logic, nothing prevents somebody to take any project
> from Apache and release it under their own commercial license, without
> releasing any source code at all for any change. The Apache Software
> License is of no use either in such a situation, since there is no
> provision that prevents such forks to happen.
That is correct. And we have several of those examples. Example prime being
IBM WebSphere, based entirely on Apache-HTTPd, re-stretched and re-wrote to
new extents, but distributed under a purely commercial license (or at least
that was at the beginning, I don't know if now they distribute it using the
IBM Public-Source License).
> I think the real issue is not the _license_, but the _copyright_. If
> you're the copyright holder, you can change the license at will or you
> can release the same code under different licenses. That's why a
> license change was possible in the case of MySQL's JDBC driver. It was
> not LGPL that was viral, it was the copyright holder.
Well, yes: indeed the copyright holder of any particular body of work is
allowed to change the license anytime, but, if you get back to our original
example (forking a LGPL-based library), to be able to change the library's
license, each single line of the library should have to be rewritten (with
copyright of each modified part assigned to the modifier).
Only at that point, when the copyright is entirely owned by the modifier
(and therefore every single line of code has been rewritten), the modifier
is allowed to change from LGPL.
> That's why Apache and FSF require their contributors to assign the copyrights
> to the respective foundations.
Indeed (and also for protection to each individual contributor, I want to
add). One of the ASF main tasks is also to LEGALLY PROTECT each individual
contributor... It's somewhere in our charter, but better outlined in the
Foundation FAQ: <http://www.apache.org/foundation/faq.html>
2.b) provide a means for individual volunteers to be sheltered from legal
suits directed at the Foundation's projects
In layman's terms, if you mess about, you won't be directly sued, the
foundation will (goes back to the discussion on the dues and rights of being
a committer to any project).
> [One nice thing about FSF is that once you
> transfer your copyright to them, they even give you the right to
> continue distributing your original code under a restrictive license.]
You are legally allowed to do that (if I was able to scavenge the three
classes of Cocoon 2 I wrote before posting them on CVS, I can still claim
them as "mine" and fork myself, hehehehe)...
Plus, the ASF doesn't "need" to do that... Our license says "go ahead and do
whatever you want" :-) That's the beauty of it... (or how I persolanny call
it, real "freedom", you're even free to change my license!)
>> Ethically the ASF does not develops software under a "viral" license,
>> therefore, given the "partial virality" of LGPL, we wouldn't be able
>> to "fork" and maintain such a library. We wouldn't even be able to
>> change the license, all modifications would have to be LGPL, so, we
>> either would have to rewrite the whole thing, or get rid of the
>> offending bits and bobs...
>
> This is FUD! What is the problem with your changes being LGPL? If what
> matters is the software continuing to be free software, it should be
> fine with you. The changes you make are copyrighted by you, so the
> original developer will not be able to take your improvements and
> release them under a commercial, more restrictive license without your
> consent.
Well, as you say "if what matters is the software continuing to be free
software".... You see, that doesn't matter for me... I do not care if the
software I wrote continues to be free or not :-) You want it? Get it, use
it, turn'n'twist it, and then sell it "Microsoft way" :-)
All I want is my ego to be satisfied (ASF license point #3, say that we
wrote it! :-) and be a part of a community that shares my concerns...
> Linux worked just fine on exactly these principles, using GPL, an even
> more restrictive license than LGPL. Sure you may not like that Linux is
> not copyrighted by your favorite foundation, but is that a good reason
> to rewrite the whole thing?
Well, ask Brian Behlendorf on why we are using FreeBSD on the Apache
infrastructure! :-) :-)
>> Soooo, I'd say, if you see the word GPL somewhere (with or without
>> the leading L) my answer is usually no, because now or in the future
>> it could/will create problems...
>
> I don't think LGPL is a problem. Informed commercial companies (big
> ones too) are routinely using LGPL code with no problems, even in
> commercial products, without encountering any legal issues. It's a
> shame open source developers stumble on such issues, rather than
> discussing the technical merits of the code and collaborating on
> software that solves the problem. Rewriting the code to conform to a
> license is a poor choice IMO.
I agree entirely, but it's not my fault if the GNU foundation wants to
LEGALLY enforce one vision over another (basically imposing their license to
all software they touch basically forever)...
I believe that one piece of software doesn't have to legally require its
"free" status. The power is only on the community: if the community is
strong enough, and focused on one vision of collaboration and cooperation,
then the software BY ITSELF will remain free because of its evolution.
Do you think that if someone forked Cocoon and went off doing its
"commercial thing" the "derivate" would have more success? Do you think that
if Cocoon was protected to be "always free" by its license it would be more
"effective"?
I don't think so... Cocoon is free, and will remain free, because of its
community.
Each one of you IS Cocoon, and you all TOGETHER are Cocoon. Cocoon is not a
code-base, Cocoon is not a license, Cocoon is this community, Cocoon is
Andy, Bernhard, Bertrand, Carsten, Christian, Dims, Geoff, Giacomo, Gianugo,
Ivelin, Jeff, Jeremy, Michael, Niclas, Nicola, Ovidiu, Stefano, Stephan,
Steven, Sylvain, Torsten, Vadim and all the others I forgot...
Without _THIS_ Cocoon, Cocoon 2.x would only be Stefano's initial idea, and
4 classes full of bugs I wrote back in 2000.
And you only realize this when you go away for some time and realize that
what you wrote is just a drop in an ocean of talented kids! :-) :-)
Power to the people, not to the lawyers! :-) :-) :-)
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Why not LGPL? (Was: Re: ChartTransformer 0.0.4 urge a commiter!)
Posted by Ovidiu Predescu <ov...@apache.org>.
Pier,
On Sunday, Jan 26, 2003, at 11:58 US/Pacific, Pier Fumagalli wrote:
> If (for example) we, the ASF, decided to get the library and make some
> modifications to it, or, scarier though, we _had_ to "fork" the
> library for our own needs (imagine, the orignal author changes from
> LGPL to something else, full GPL for example -as happened lately to
> the MySQL JDBC drivers- or even worse, decides the library will only
> be distributed as "commercial software"), then we would be utterly
> f***ed.
Under the same logic, nothing prevents somebody to take any project
from Apache and release it under their own commercial license, without
releasing any source code at all for any change. The Apache Software
License is of no use either in such a situation, since there is no
provision that prevents such forks to happen.
I think the real issue is not the _license_, but the _copyright_. If
you're the copyright holder, you can change the license at will or you
can release the same code under different licenses. That's why a
license change was possible in the case of MySQL's JDBC driver. It was
not LGPL that was viral, it was the copyright holder. That's why Apache
and FSF require their contributors to assign the copyrights to the
respective foundations. [One nice thing about FSF is that once you
transfer your copyright to them, they even give you the right to
continue distributing your original code under a restrictive license.]
> Ethically the ASF does not develops software under a "viral" license,
> therefore, given the "partial virality" of LGPL, we wouldn't be able
> to "fork" and maintain such a library. We wouldn't even be able to
> change the license, all modifications would have to be LGPL, so, we
> either would have to rewrite the whole thing, or get rid of the
> offending bits and bobs...
This is FUD! What is the problem with your changes being LGPL? If what
matters is the software continuing to be free software, it should be
fine with you. The changes you make are copyrighted by you, so the
original developer will not be able to take your improvements and
release them under a commercial, more restrictive license without your
consent.
Linux worked just fine on exactly these principles, using GPL, an even
more restrictive license than LGPL. Sure you may not like that Linux is
not copyrighted by your favorite foundation, but is that a good reason
to rewrite the whole thing?
> Soooo, I'd say, if you see the word GPL somewhere (with or without
> the leading L) my answer is usually no, because now or in the future
> it could/will create problems...
I don't think LGPL is a problem. Informed commercial companies (big
ones too) are routinely using LGPL code with no problems, even in
commercial products, without encountering any legal issues. It's a
shame open source developers stumble on such issues, rather than
discussing the technical merits of the code and collaborating on
software that solves the problem. Rewriting the code to conform to a
license is a poor choice IMO.
Regards,
--
Ovidiu Predescu <ov...@apache.org>
http://www.google.com/search?btnI=&q=ovidiu (I'm feeling lucky)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org