Re: (Re)Licensing question

2006-01-11 Thread Pier Fumagalli

On 10 Jan 2006, at 17:22, Andrew Stevens wrote:


From: Helma van der Linden [EMAIL PROTECTED]
Date: Tue, 10 Jan 2006 17:31:25 +0100

Guys,

I usually keep away from licensing issues, but this time I'd like  
to know if it is done correctly. I'm looking at a project that is  
made up of several other open source projects, cocoon is one of  
them, another (sub)project is licensed under BSD.


This project is licensed under GPL. It doesn't say that only their  
part is GPL and others are licensed differently. Looks like they  
included the entire Cocoon source tree with licensing files for  
all external jars used and they also left in the ASF license  
headers in the various files.


Is this correct?


Given that GNU [1] list the Apache licenses as GPL-Incompatible,  
Free Software Licenses, I've always interpreted that to mean that  
you can't link to (i.e. make use of) Apache-licensed libraries  
(jars) in a project that you're releasing under the GPL.  They  
don't appear to have an equivalent list for LGPL compatibility,  
unfortunately.
I do recall that previous discussions on this list have stated that  
Apache-hosted projects aren't allowed to [L]GPL libraries in their  
CVS repositories.


If I've got this all backwards, someone please let me know; I've a  
project of my own [2] that I would have licensed under GPL if not  
for the fact that I made use of libraries that were released under  
Apache and BSD licenses.  Instead I went for LGPL on the grounds  
that I can find a lot of other LGPL'd projects that use the same  
libraries, so it looks like that's okay...


I personally think you've got it upside down... You can write a piece  
of software distributed with a (L)GPL license and using ASL licensed  
software...


The main problem for us (the ASF) is to incorporate software based  
on GPL/LGPL licenses (not the other way around).


Basically, as we (ASF) don't impose any restriction on our software  
(it's a kind of do-whatever-you-want-with-it), if we were to include  
(L)GPL software we would force you (end user of Cocoon) to  
redistribute your project under a (L)GPL license: the ASF doesn't  
permit it, so that's why you won't find any reliance or use of (L)GPL  
software in ASL licensed projects.


The other way around, is, on the other hand (and in my very personal  
non-lawyer idea), totally possible (Mr. Stallman still says it's not,  
but I don't believe he's right on this one).


As your software is going to be (L)GPLed, yours is the choice of how  
to re-license the changes you make to OUR (cocoon's) classes: if you  
choose to distribute the changes you make to the Cocoon classes under  
the (L)GPL, then we (as the ASF) won't be able to redistribute them  
and you'll have to maintain your changes yourself. If you re-license  
your chages under the Apache Software License and we (as the ASF) are  
able to include them, we'll integrate them and ship them in our next  
release (hopefully).


I know that in the past there were some issues dealing with the  
advertising clause in the Apache license 1.1 that Mr. Stallman didn't  
particularly like (and claimed were uncompatible), and now he's  
claiming that the version 2.0 of the Apache license is incompatible  
because of some patenting issue: those are subjective issues that  
were never tried in a court of law.


Personally, not being a lawyer, I think the GNU approach (Mr.  
Stallman's) is over-zealous onto those issues, but, at the end-of-the- 
day, it's your gut-feeling that will have to tell you whether you can  
combine the two licenses or not. As far as my personal instinct goes,  
I wouldn't release anything under the (L)GPL, go straight to the ASL  
(or even better, BSD) and not care about it...


Try to Google up ASL LGPL GPL: you'll find links to a number of  
blogs on this subject, especially by those who are on the licensing  
committee in the ASF (they might explain you in more legal terms  
what my gut feeling is all about!!!) :-P :-P


Pier

smime.p7s
Description: S/MIME cryptographic signature


Re: (Re)Licensing question

2006-01-11 Thread Geoff Howard
On 1/10/06, David Crossley [EMAIL PROTECTED] wrote:
 This plain language FAQ is helpful:
 http://www.apache.org/foundation/licence-FAQ.html#WhatDoesItMEAN
 and follow through to the preFAQ which has a good overview,

Any idea why this is stated in the pre-FAQ?

quote
9.  You have questions specifically about the Apache XML projects.

If you have sent us mail about one of the Apache XML software projects
(Xerces, FOP, Cocoon, et cetera), please use the following contact
instead:

URL:http://xml.apache.org/mail.html
/quote

I imagine they can remove Cocoon from that list?

Geoff


RE: (Re)Licensing question

2006-01-10 Thread Andrew Stevens

From: Helma van der Linden [EMAIL PROTECTED]
Date: Tue, 10 Jan 2006 17:31:25 +0100

Guys,

I usually keep away from licensing issues, but this time I'd like to know 
if it is done correctly. I'm looking at a project that is made up of 
several other open source projects, cocoon is one of them, another 
(sub)project is licensed under BSD.


This project is licensed under GPL. It doesn't say that only their part is 
GPL and others are licensed differently. Looks like they included the 
entire Cocoon source tree with licensing files for all external jars used 
and they also left in the ASF license headers in the various files.


Is this correct?


Given that GNU [1] list the Apache licenses as GPL-Incompatible, Free 
Software Licenses, I've always interpreted that to mean that you can't link 
to (i.e. make use of) Apache-licensed libraries (jars) in a project that 
you're releasing under the GPL.  They don't appear to have an equivalent 
list for LGPL compatibility, unfortunately.
I do recall that previous discussions on this list have stated that 
Apache-hosted projects aren't allowed to [L]GPL libraries in their CVS 
repositories.


If I've got this all backwards, someone please let me know; I've a project 
of my own [2] that I would have licensed under GPL if not for the fact that 
I made use of libraries that were released under Apache and BSD licenses.  
Instead I went for LGPL on the grounds that I can find a lot of other LGPL'd 
projects that use the same libraries, so it looks like that's okay...



Andrew.

[1] http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses
[2] http://pseudoq.sourceforge.net/




Re: (Re)Licensing question

2006-01-10 Thread Pier Fumagalli

On 10 Jan 2006, at 16:31, Helma van der Linden wrote:


Guys,

I usually keep away from licensing issues, but this time I'd like  
to know if it is done correctly. I'm looking at a project that is  
made up of several other open source projects, cocoon is one of  
them, another (sub)project is licensed under BSD.


This project is licensed under GPL. It doesn't say that only their  
part is GPL and others are licensed differently. Looks like they  
included the entire Cocoon source tree with licensing files for all  
external jars used and they also left in the ASF license headers in  
the various files.


Is this correct?


It definitely is... The ASF doesn't pose any whatsoever restriction  
when its code is being re-distributed by a third party (you could  
virtually sell the ASF sources, and noone would be able to stop you).


In this particular case, the entire project you methion is GPL  
licensed, thus, any modifications made to it will be (as well) have  
to be GPLed. This will guarantee that whoever inherits any of the  
files from that project will have to redistribute them using the same  
license (in case of any modification).


The problem might arise for those willing to modify code based on  
that project and re-publish those changes:


If they submit changes to (let's say) Cocoon's sources back to the  
project you're mentioning. The person modifying those sources can  
either choose to submit them back to us (the real source) or to the  
project they downloaded (the distributor).


In the first case, we'll accept those modifications only if we can  
make them our own (copyright is assigned and transfered to the ASF)  
and   will include them (hopefully) in our next release.


In the second, those changes will be in the hands of the distributor  
(and thus GPLed). There are two options, either the copyright of  
those changes is transfered to the ASF by the distributor (and then  
we'll follows what's described above) or they'll have to maintain  
those patches themselves as we're not going to include GPL licensed  
code in our repository...


I hope this clears it a little bit...

Pier



smime.p7s
Description: S/MIME cryptographic signature


Re: (Re)Licensing question

2006-01-10 Thread hepabolu

Pier Fumagalli wrote:
In the second, those changes will be in the hands of the distributor  
(and thus GPLed). There are two options, either the copyright of  those 
changes is transfered to the ASF by the distributor (and then  we'll 
follows what's described above) or they'll have to maintain  those 
patches themselves as we're not going to include GPL licensed  code in 
our repository...


So this means it could become a Cocoon fork and there's nothing we can 
do about it?



I hope this clears it a little bit...


a bit yes. ;-)

Bye, Helma


Re: (Re)Licensing question

2006-01-10 Thread Stefano Mazzocchi

Helma van der Linden wrote:

Guys,

I usually keep away from licensing issues, but this time I'd like to 
know if it is done correctly. I'm looking at a project that is made up 
of several other open source projects, cocoon is one of them, another 
(sub)project is licensed under BSD.


This project is licensed under GPL. It doesn't say that only their part 
is GPL and others are licensed differently. Looks like they included the 
entire Cocoon source tree with licensing files for all external jars 
used and they also left in the ASF license headers in the various files.


Is this correct?


According to both the FSF and the ASF legal counselors, the GPL2.0 is 
not compatible with the AL2.0 because of the patent termination clause 
of the apache license.


More information can be found here:

http://www.apache.org/licenses/GPL-compatibility.html

There *IS* a way, however, to license your software as GPL and have it 
link to apache licensed software (or other GPL-incompatible free 
software licenses): you have to 'extend' the GPL by saying explicitly 
that only the part of the software that you own is covered by the GPL 
and not the entire bundle. Each part is covered by its own license and 
the GPL does not apply to that.


As an example of such a thing see

http://www.mysql.com/company/legal/licensing/foss-exception.html

NOTE: there is legal debate to whether or not such an exception would 
stand if tested in court, but this is true for almost anything in the 
legal world anyway, but if you put such a GPL extension in place both 
sides of the open source and free software world would be happy and 
won't come after you.


Others might, though, (see SCO), and the GPL2.0 does *NOT* have any sort 
of IP protection mechanisms in place when that happens but that's a risk 
that you take by just writing software these days.


HTH

--
Stefano.



Re: (Re)Licensing question

2006-01-10 Thread Stefano Mazzocchi

Andrew Stevens wrote:

From: Helma van der Linden [EMAIL PROTECTED]
Date: Tue, 10 Jan 2006 17:31:25 +0100

Guys,

I usually keep away from licensing issues, but this time I'd like to 
know if it is done correctly. I'm looking at a project that is made up 
of several other open source projects, cocoon is one of them, another 
(sub)project is licensed under BSD.


This project is licensed under GPL. It doesn't say that only their 
part is GPL and others are licensed differently. Looks like they 
included the entire Cocoon source tree with licensing files for all 
external jars used and they also left in the ASF license headers in 
the various files.


Is this correct?


Given that GNU [1] list the Apache licenses as GPL-Incompatible, Free 
Software Licenses, I've always interpreted that to mean that you can't 
link to (i.e. make use of) Apache-licensed libraries (jars) in a project 
that you're releasing under the GPL.  They don't appear to have an 
equivalent list for LGPL compatibility, unfortunately.
I do recall that previous discussions on this list have stated that 
Apache-hosted projects aren't allowed to [L]GPL libraries in their CVS 
repositories.


If I've got this all backwards, someone please let me know; I've a 
project of my own [2] that I would have licensed under GPL if not for 
the fact that I made use of libraries that were released under Apache 
and BSD licenses.  Instead I went for LGPL on the grounds that I can 
find a lot of other LGPL'd projects that use the same libraries, so it 
looks like that's okay...


FYI, LGPL is incompatible with the Apache License as much as the GPL, so 
the exact same reasoning applies.


--
Stefano.



Re: (Re)Licensing question

2006-01-10 Thread Stefano Mazzocchi

Pier Fumagalli wrote:

On 10 Jan 2006, at 16:31, Helma van der Linden wrote:


Guys,

I usually keep away from licensing issues, but this time I'd like to 
know if it is done correctly. I'm looking at a project that is made up 
of several other open source projects, cocoon is one of them, another 
(sub)project is licensed under BSD.


This project is licensed under GPL. It doesn't say that only their 
part is GPL and others are licensed differently. Looks like they 
included the entire Cocoon source tree with licensing files for all 
external jars used and they also left in the ASF license headers in 
the various files.


Is this correct?


It definitely is... The ASF doesn't pose any whatsoever restriction when 
its code is being re-distributed by a third party (you could virtually 
sell the ASF sources, and noone would be able to stop you).


In this particular case, the entire project you methion is GPL licensed, 
thus, any modifications made to it will be (as well) have to be GPLed. 
This will guarantee that whoever inherits any of the files from that 
project will have to redistribute them using the same license (in case 
of any modification).


The problem might arise for those willing to modify code based on that 
project and re-publish those changes:


If they submit changes to (let's say) Cocoon's sources back to the 
project you're mentioning. The person modifying those sources can either 
choose to submit them back to us (the real source) or to the project 
they downloaded (the distributor).


In the first case, we'll accept those modifications only if we can make 
them our own (copyright is assigned and transfered to the ASF) and   
will include them (hopefully) in our next release.


In the second, those changes will be in the hands of the distributor 
(and thus GPLed). There are two options, either the copyright of those 
changes is transfered to the ASF by the distributor (and then we'll 
follows what's described above) or they'll have to maintain those 
patches themselves as we're not going to include GPL licensed code in 
our repository...


I hope this clears it a little bit...


Hmmm

In the real world, the ASF will *NEVER* come after you if you link 
apache licensed material from a GPL-ed project, neither would the FSF.


But the matter of fact is that the apache license has a patent bomb 
built into it that the GPL doesn't like because it's considered a 
*further restriction* and the GPL has a very well defined set of 
'freedoms' that it gives you and, unfortunately, it also gives people 
the freedom to sue your ass over IP infringement without any side 
effects on the licensing part of the software.


The ASF is a innovator in this space (and the FSF is going to catch up 
with the GPL3, hopefully) because it first introduced this you sue my 
friend, I screw you clause.


So, if EvilCocoonCorp sues GoodCocoonCorp over IP infringement of some 
patent they have and that Cocoon happens to implements, then 
EvilCocoonCorp can no longer distribute Cocoon's code!


It's not a solution to the software patent problem, but given the wild 
availability of our software, it creates a pretty complicated deadlock 
scheme (because the counter-lawsuits for illegal AL2.0 distribution 
would rain like in a tropical forest!)


There is nothing like that in the GPLv2.

Mixing the two and undergoing an IP lawsuit is going to create all sort 
of issues, because nowhere in the GPL there is something that says that 
parts of it are allowed to be licensed under some other license with 
more strict terms, therefore EvilCocoonCorp could claim that the GPL 
*shielded* them against that ASF patent bomb.


It's a mess, I know, but it's better be safe than sorry in these matters 
(even if Europe is, so far, a place where the IP problem doesn't count 
that much so it's a much safer bet)


--
Stefano.



Re: (Re)Licensing question

2006-01-10 Thread Stefano Mazzocchi

hepabolu wrote:

Pier Fumagalli wrote:
In the second, those changes will be in the hands of the distributor  
(and thus GPLed). There are two options, either the copyright of  
those changes is transfered to the ASF by the distributor (and then  
we'll follows what's described above) or they'll have to maintain  
those patches themselves as we're not going to include GPL licensed  
code in our repository...


So this means it could become a Cocoon fork and there's nothing we can 
do about it?


We can't take code that we don't own and that is licensed by some other 
license and relicense it under different terms.


But the apache license states that *if* you contribute anything back, 
then this would be apache licensed if you don't say anything else.


But this has very little to do with the license incompatibility problem.


I hope this clears it a little bit...


a bit yes. ;-)

Bye, Helma



--
Stefano.



Re: (Re)Licensing question

2006-01-10 Thread David Crossley
Pier Fumagalli wrote:
 Helma van der Linden wrote:
 
 Guys,
 
 I usually keep away from licensing issues, but this time I'd like  
 to know if it is done correctly. I'm looking at a project that is  
 made up of several other open source projects, cocoon is one of  
 them, another (sub)project is licensed under BSD.
 
 This project is licensed under GPL. It doesn't say that only their  
 part is GPL and others are licensed differently. Looks like they  
 included the entire Cocoon source tree with licensing files for all  
 external jars used and they also left in the ASF license headers in  
 the various files.
 
 Is this correct?
 
 It definitely is... The ASF doesn't pose any whatsoever restriction  
 when its code is being re-distributed by a third party (you could  
 virtually sell the ASF sources, and noone would be able to stop you).

This plain language FAQ is helpful:
http://www.apache.org/foundation/licence-FAQ.html#WhatDoesItMEAN
and follow through to the preFAQ which has a good overview,
and of course the main page:
http://www.apache.org/licenses/

It worth being familiar with the principles and aims.

 In this particular case, the entire project you methion is GPL  
 licensed, thus, any modifications made to it will be (as well) have  
 to be GPLed. This will guarantee that whoever inherits any of the  
 files from that project will have to redistribute them using the same  
 license (in case of any modification).
 
 The problem might arise for those willing to modify code based on  
 that project and re-publish those changes:
 
 If they submit changes to (let's say) Cocoon's sources back to the  
 project you're mentioning. The person modifying those sources can  
 either choose to submit them back to us (the real source) or to the  
 project they downloaded (the distributor).
 
 In the first case, we'll accept those modifications only if we can  
 make them our own (copyright is assigned and transfered to the ASF)  
 and   will include them (hopefully) in our next release.

Thanks for the excellent description. However, that
copyright part is not correct. This point is so important
that i am goingg to quote it directly:
http://www.apache.org/licenses/ at second paragraph:

These licenses help us achieve our goal of providing reliable
and long-lived software products through collaborative open source
software development. In all cases, contributors retain full rights
to use their original contributions for any other purpose outside
of Apache while providing the ASF and its projects the right to
distribute and build upon their work within Apache.


 In the second, those changes will be in the hands of the distributor  
 (and thus GPLed). There are two options, either the copyright of  
 those changes is transfered to the ASF by the distributor (and then  
 we'll follows what's described above) or they'll have to maintain  
 those patches themselves as we're not going to include GPL licensed  
 code in our repository...
 
 I hope this clears it a little bit...
 
   Pier