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/27 16:25:00 UTC

Re: Why not LGPL? (Was: Re: ChartTransformer 0.0.4 urge a commiter!)

<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