GPL License of H-Matrix and prelude numeric

newer
3GB allocation, 75% CPU usage from...

gutti

25 Jan 2011 25 Jan '11

4:32 p.m.

Hi all, I realised that haskell in the base libraries tries to consistently stick to the permissive BSD license to also give the language traction in the commercial world. The H-Matrix and the prelude numeric packages however, which in my mind cover really important ground work, are issued under the resprictive GPL. Is that only because they link into other external GNU - libaries with GPL license ? -- If yes would be repackaging the haskell-native bits in an extra BSD package an option ? Cheers Phil -- View this message in context: http://haskell.1045720.n5.nabble.com/GPL-License-of-H-Matrix-and-prelude-num... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

Show replies by date

Ivan Lazar Miljenovic

25 Jan 25 Jan

5:18 p.m.

On 26 January 2011 07:32, gutti wrote:

...

The H-Matrix and the prelude numeric packages however, which in my mind cover really important ground work, are issued under the resprictive GPL.

I think your description of "restrictive" is contentious...

...

Is that only because they link into other external GNU - libaries with GPL license ? -- If yes would be repackaging the haskell-native bits in an extra BSD package an option ?

Or else because the developers _wanted_ to license it under the GPL. Some people do, you know. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Chris Smith

5:24 p.m.

On Wed, 2011-01-26 at 08:18 +1000, Ivan Lazar Miljenovic wrote:

...

Or else because the developers _wanted_ to license it under the GPL. Some people do, you know.

Sure, but I agree it would be nice to know whether the authors chose the GPL, or applied it because of linking with GPLed native libraries and might be open to relicensing the native stuff. Seems like a good question to me. -- Chris Smith

gutti

5:51 p.m.

Hi Ivan, thanks for making me aware that this is a potentialy controverse topic. -- I have highest respect of people writing open source and I totally respect their decision. -- View this message in context: http://haskell.1045720.n5.nabble.com/GPL-License-of-H-Matrix-and-prelude-num... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

Richard O'Keefe

9:16 p.m.

On 26/01/2011, at 11:18 AM, Ivan Lazar Miljenovic wrote:

...

On 26 January 2011 07:32, gutti wrote:

...
The H-Matrix and the prelude numeric packages however, which in my mind cover really important ground work, are issued under the restrictive GPL.

I think your description of "restrictive" is contentious...

You say "restrictive" like it's a bad thing. The GPL is *meant* to restrict certain behaviours, some of which some other open source licences do not.

Chris Smith

9:55 p.m.

On Wed, 2011-01-26 at 15:16 +1300, Richard O'Keefe wrote:

...

You say "restrictive" like it's a bad thing. The GPL is *meant* to restrict certain behaviours, some of which some other open source licences do not.

There's really no need to start a debate over licensing here. Clearly, the best license is the one that allows the things the author wanted to allow, and doesn't allow the things the author didn't want to allow. Still, it would be nice to get an answer to the original question. Licensing with the GPL has definite consequences; for example, that the great majority of Haskell libraries, which are BSD3 licensed, may not legitimately declare dependencies on it. We can all agree that it's good for people to understand those restrictions on what they can do with hmatrix; and if the author didn't intend to place those restrictions on the pure Haskell bits and just did so in respect for other libraries' licensing, it would be reasonable to suggest splitting it up to better express the intent. If the author did intend those restrictions, then of course they will remain. -- Chris Smith

Ivan Lazar Miljenovic

10:22 p.m.

On 26 January 2011 12:55, Chris Smith wrote:

...

Still, it would be nice to get an answer to the original question. Licensing with the GPL has definite consequences; for example, that the great majority of Haskell libraries, which are BSD3 licensed, may not legitimately declare dependencies on it. We can all agree that it's good for people to understand those restrictions on what they can do with hmatrix; and if the author didn't intend to place those restrictions on the pure Haskell bits and just did so in respect for other libraries' licensing, it would be reasonable to suggest splitting it up to better express the intent. If the author did intend those restrictions, then of course they will remain.

In which case, why not ask the author(s) directly rather than blindly asking the mailing list? -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

John Lask

10:37 p.m.

On 26/01/2011 1:52 PM, Ivan Lazar Miljenovic wrote:

...

In which case, why not ask the author(s) directly rather than blindly asking the mailing list?

others, such as I, may be interested in the answer.

Ivan Lazar Miljenovic

10:43 p.m.

On 26 January 2011 13:37, John Lask wrote:

...

On 26/01/2011 1:52 PM, Ivan Lazar Miljenovic wrote:

...
In which case, why not ask the author(s) directly rather than blindly asking the mailing list?

others, such as I, may be interested in the answer.

Yes, but this way you're assuming the author(s) is going to be reading this thread. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

John Millikin

11:53 p.m.

On Tue, Jan 25, 2011 at 18:55, Chris Smith wrote:

...

Licensing with the GPL has definite consequences; for example, that the great majority of Haskell libraries, which are BSD3 licensed, may not legitimately declare dependencies on it.

What are you talking about? Of course BSD3 libraries/applications can depend on GPL'd code. The only license Cabal allows that conflicts with the GPL is BSD4, which (to my knowledge) is not used by any software on Hackage.

David Leimbach

26 Jan 26 Jan

12:11 a.m.

On Tue, Jan 25, 2011 at 8:53 PM, John Millikin wrote:

...

On Tue, Jan 25, 2011 at 18:55, Chris Smith wrote:

...
Licensing with the GPL has definite consequences; for example, that the great majority of Haskell libraries, which are BSD3 licensed, may not legitimately declare dependencies on it.

What are you talking about? Of course BSD3 libraries/applications can depend on GPL'd code.

I am not an IP lawyer, but this is my understanding of the GPL and it's transitive relationship with bodies of work that aren't GPL'd. BSD3 doesn't really state anything about what it links with, but the GPL injects itself into the tree of stuff it's linked with via the derivative works clause. The consequence is that the entire derivative work becomes GPL'd as well, and those distributing the derivative work must adhere to the terms of the GPL for distribution and provide source. This is somewhat in the tradition of commercial middleware requiring a royalty fee or some per-installation licensing when a work is distributed that uses a particular library with such terms. In other words transitive licensing properties are NOT unique to the GPL. At least that's always been my understanding. A BSD3 library in isolation may still remain BSD3, but if it's not useful without being linked to a GPL'd library, then the point is kind of moot, except that someone is free to implement a replacement for the GPL'd part to avoid the transitive properties in the derivative work, in much the same way you could implement a free version of a commercial library (barring patent or other violations) to avoid transitive properties of the commercial license. Dave

...

The only license Cabal allows that conflicts with the GPL is BSD4, which (to my knowledge) is not used by any software on Hackage.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

John Millikin

12:41 a.m.

On Tue, Jan 25, 2011 at 21:11, David Leimbach wrote:

...

I am not an IP lawyer, but this is my understanding of the GPL and it's transitive relationship with bodies of work that aren't GPL'd. BSD3 doesn't really state anything about what it links with, but the GPL injects itself into the tree of stuff it's linked with via the derivative works clause. The consequence is that the entire derivative work becomes GPL'd as well, and those distributing the derivative work must adhere to the terms of the GPL for distribution and provide source.

This is correct. If you create a derivative work of BSD3 and GPL code (eg, a binary), it's covered by both the BSD3 and GPL. The GPL requires you to provide source code for that binary.

...

This is somewhat in the tradition of commercial middleware requiring a royalty fee or some per-installation licensing when a work is distributed that uses a particular library with such terms. In other words transitive licensing properties are NOT unique to the GPL.

EVERY license propagates down the dependency chain. If a PublicDomain application depends on a BSD3 library, then compiled versions of that application must obey the BSD license's copyright, endorsement, and warranty clauses. It's disingenuous to suggest this only matters to GPL code.

...

At least that's always been my understanding. A BSD3 library in isolation may still remain BSD3, but if it's not useful without being linked to a GPL'd library, then the point is kind of moot, except that someone is free to implement a replacement for the GPL'd part to avoid the transitive properties in the derivative work, in much the same way you could implement a free version of a commercial library (barring patent or other violations) to avoid transitive properties of the commercial license.

Licensing is a property of the code, not the package; Cabal's licensing field is only a useful shorthand for "most of the code here is covered by...". Many people write BSD3 code that depends on GPL libraries, because they believe 1) their code is not important enough to protect (eg, one-off libs) or 2) want to encourage commercial forks (eg, during exploratory design). Sorry to sound so pedantic about this, but I often field emails along the lines of: Hi! I really like <some library> and want to use it for a program I'm writing. But because its GPL I can't (the program is BSD). Can you please relicense your library so BSD code can use it? And then I have to email them back, and explain, and reassure them that the GPL is not actually the green-eyed bogeyman portrayed by some tabloids. At one point, I actually had to offer to sign/mail a physical letter just to convince some guy I wasn't trying to trick him.

Chris Smith

12:51 a.m.

On Tue, 2011-01-25 at 21:41 -0800, John Millikin wrote:

...

Licensing is a property of the code, not the package; Cabal's licensing field is only a useful shorthand for "most of the code here is covered by...".

That would be a very dangerous position to take. When the Cabal license field informs someone that something is licensed under the BSD, I think any reasonable person would assume that means ALL of the code is licensed under the BSD, and without added restrictions. We're being extremely unhelpful if developers have to read through every source file in every library they use, and all of its indirect dependencies, to make sure there's not an additional restriction in there somewhere. -- Chris Smith

John Millikin

1:01 a.m.

On Tue, Jan 25, 2011 at 21:51, Chris Smith wrote:

...

On Tue, 2011-01-25 at 21:41 -0800, John Millikin wrote:

...
Licensing is a property of the code, not the package; Cabal's licensing field is only a useful shorthand for "most of the code here is covered by...".

That would be a very dangerous position to take. When the Cabal license field informs someone that something is licensed under the BSD, I think any reasonable person would assume that means ALL of the code is licensed under the BSD, and without added restrictions. We're being extremely unhelpful if developers have to read through every source file in every library they use, and all of its indirect dependencies, to make sure there's not an additional restriction in there somewhere.

I don't think a reasonable person would assume that. Based on the almost universal habit of noting the license in source file comment headers, a reasonable programmer would know to check the status of any code he wants to copy into his own works. For example, if I copy some BSD3 code into one of my GPL'd libraries, that code remains BSD3 (and owned by the original author). The Cabal field will still say GPL, because most of the code is GPL, but some of it is not. Alternatively, I could bundle a GPL'd test script with BSD3 code. The code itself (and hence Cabal file) is BSD3, but not everything in the archive is. The package's dependencies are irrelevant, unless the package's code was itself copied from one of its deps.

Maciej Piechotka

6:06 a.m.

On Tue, 2011-01-25 at 22:01 -0800, John Millikin wrote:

...

On Tue, Jan 25, 2011 at 21:51, Chris Smith wrote:

...
On Tue, 2011-01-25 at 21:41 -0800, John Millikin wrote:

...
Licensing is a property of the code, not the package; Cabal's licensing field is only a useful shorthand for "most of the code here is covered by...".

That would be a very dangerous position to take. When the Cabal license field informs someone that something is licensed under the BSD, I think any reasonable person would assume that means ALL of the code is licensed under the BSD, and without added restrictions. We're being extremely unhelpful if developers have to read through every source file in every library they use, and all of its indirect dependencies, to make sure there's not an additional restriction in there somewhere.

I don't think a reasonable person would assume that. Based on the almost universal habit of noting the license in source file comment headers, a reasonable programmer would know to check the status of any code he wants to copy into his own works.

For example, if I copy some BSD3 code into one of my GPL'd libraries, that code remains BSD3 (and owned by the original author). The Cabal field will still say GPL, because most of the code is GPL, but some of it is not.

Alternatively, I could bundle a GPL'd test script with BSD3 code. The code itself (and hence Cabal file) is BSD3, but not everything in the archive is.

The package's dependencies are irrelevant, unless the package's code was itself copied from one of its deps.

Most reasonable people have limited time to read through the source code and some of it does not include the header. I think it is reasonable that the License include most compatible ("restrictive") license of library i.e. if one is using GPL-2+, GPL-3+ and BSD-3 in single project it should include GPL-3+ even if most of it is covered by BSD-3. There is smaller problem with program as hardly anyone links with program. Regards

Ketil Malde

2:11 a.m.

David Leimbach writes:

...

BSD3 doesn't really state anything about what it links with, but the GPL injects itself into the tree of stuff it's linked with via the derivative works clause.

I'm not an IP lawyer either (thank God), but merely using a published interface does not make it a derivative work. So IMO there's no problem with a GPL library making use of a BSD library, nor vice versa - just like I can write a BSD program and run it on (GPL'ed) Linux and libc.

...

The consequence is that the entire derivative work becomes GPL'd as well,

Only if you incorporate GPL code - and it doesn't have to be GPL, only a license that is GPL compatible (prevents any redistributer from preventing recipients from modifying the code). -k -- If I haven't seen further, it is by standing in the footprints of giants

Chris Smith

2:23 a.m.

On Wed, 2011-01-26 at 08:11 +0100, Ketil Malde wrote:

...

I'm not an IP lawyer either (thank God), but merely using a published interface does not make it a derivative work. So IMO there's no problem with a GPL library making use of a BSD library, nor vice versa - just like I can write a BSD program and run it on (GPL'ed) Linux and libc.

As mentioned elsewhere, this is true for the individual bits of source code, but not for the combined eventual program. That will be subject to the terms of the GPL, if there is any GPLed bits included (and that includes a GPLed library informing a linker about symbol resolution and relocation stuff). -- Chris Smith

Maciej Piechotka

5:57 a.m.

On Wed, 2011-01-26 at 08:11 +0100, Ketil Malde wrote:

...

David Leimbach writes:

...
BSD3 doesn't really state anything about what it links with, but the GPL injects itself into the tree of stuff it's linked with via the derivative works clause.

I'm not an IP lawyer either (thank God), but merely using a published interface does not make it a derivative work. So IMO there's no problem with a GPL library making use of a BSD library, nor vice versa - just like I can write a BSD program and run it on (GPL'ed) Linux and libc.

In addition to Chris Smith reply please note that system interfaces (to which Linux syscalls and libc belongs according to FSF) are explicitly excluded IIRC. Regards

Chris Smith

12:39 a.m.

On Tue, 2011-01-25 at 20:53 -0800, John Millikin wrote:

...

What are you talking about? Of course BSD3 libraries/applications can depend on GPL'd code.

Not being a lawyer, I'll avoid claiming any definitive answers, and just mention that that's definitely a minority opinion, and at odds with the interpretation given by the FSF.

...

The only license Cabal allows that conflicts with the GPL is BSD4, which (to my knowledge) is not used by any software on Hackage.

This is true if you "conflicts" means "cannot be combined with GPLed code in a GPLed derivative work." However, it's generally considered untrue if "conflicts" means "cannot be combined with GPLed code in a BSD licensed derivative work." While there might be a legitimate debate over whether linking constitutes making a derivative work, the author of the GPL license certainly believes that it does. Hence my comment. Not trying to start a license war here; as I said earlier, it's completely up to a library author how they license their own code. But we do have to understand the consequences and be careful to abide by the licenses those authors choose. -- Chris

John Millikin

12:48 a.m.

On Tue, Jan 25, 2011 at 21:39, Chris Smith wrote:

...

On Tue, 2011-01-25 at 20:53 -0800, John Millikin wrote:

...
What are you talking about? Of course BSD3 libraries/applications can depend on GPL'd code.

Not being a lawyer, I'll avoid claiming any definitive answers, and just mention that that's definitely a minority opinion, and at odds with the interpretation given by the FSF.

Please cite where the FSF claims the GPL applies to unrelated works just because they can compile against GPL'd code. Keep in mind that if your claim is correct, then every significant Linux and BSD distro is committing massive copyright infringement.

Ivan Lazar Miljenovic

1:07 a.m.

On 26 January 2011 15:48, John Millikin wrote:

...

On Tue, Jan 25, 2011 at 21:39, Chris Smith wrote:

...
On Tue, 2011-01-25 at 20:53 -0800, John Millikin wrote:

...
What are you talking about? Of course BSD3 libraries/applications can depend on GPL'd code.

Not being a lawyer, I'll avoid claiming any definitive answers, and just mention that that's definitely a minority opinion, and at odds with the interpretation given by the FSF.

Please cite where the FSF claims the GPL applies to unrelated works just because they can compile against GPL'd code. Keep in mind that if your claim is correct, then every significant Linux and BSD distro is committing massive copyright infringement.

Voila: http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL (Note: in the past they said otherwise.) -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

John Millikin

1:10 a.m.

On Tue, Jan 25, 2011 at 22:07, Ivan Lazar Miljenovic wrote:

...

Voila: http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL

(Note: in the past they said otherwise.)

Important: "or a GPL-compatible license" BSD3, MIT, PublicDomain, Apache, etc, are all GPL-compatible. The only GPL-incompatible licenses Cabal supports are BSD4 and AllRightsReserved, which are not used by anything on Hackage.

Ivan Lazar Miljenovic

1:14 a.m.

On 26 January 2011 16:10, John Millikin wrote:

...

On Tue, Jan 25, 2011 at 22:07, Ivan Lazar Miljenovic wrote:

...
Voila: http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL

(Note: in the past they said otherwise.)

Important: "or a GPL-compatible license"

You're right; they seem to have changed it again to add that phrase since last I (properly) read it. However, my understanding that this property is then transitive: if Foo is GPL, Bar depends on Foo and Baz depends on Bar, then Baz must also be released under a GPL-compatible license. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

John Millikin

1:21 a.m.

On Tue, Jan 25, 2011 at 22:14, Ivan Lazar Miljenovic wrote:

...

However, my understanding that this property is then transitive: if Foo is GPL, Bar depends on Foo and Baz depends on Bar, then Baz must also be released under a GPL-compatible license.

It's not really a "must", just a matter of practicality. If you compile/link together code with incompatible licenses (BSD4 + GPL, GPL2-only + GPL3-only) then the resulting binary can't be legally distributed for any reason (because doing so would violate at least one of the licenses). You can still license the source code however you want, and distribute it; the problem is only for binaries.

Maciej Piechotka

5:51 a.m.

On Tue, 2011-01-25 at 22:21 -0800, John Millikin wrote:

...

On Tue, Jan 25, 2011 at 22:14, Ivan Lazar Miljenovic wrote:

...
However, my understanding that this property is then transitive: if Foo is GPL, Bar depends on Foo and Baz depends on Bar, then Baz must also be released under a GPL-compatible license.

It's not really a "must", just a matter of practicality.

If you compile/link together code with incompatible licenses (BSD4 + GPL, GPL2-only + GPL3-only) then the resulting binary can't be legally distributed for any reason (because doing so would violate at least one of the licenses). You can still license the source code however you want, and distribute it; the problem is only for binaries.

The text of GPL-2 and GPL-3 at least have note about upgrading so GPL-2 program can be relicensed into GPL-3. ANAL but I think the legal framework of US makes it relatively safe (status of FSF prevents it from 'being evil'). Some projects (like Linux) remove this clause and I'm not sure how many projects are marked on hackage as GPL2 being GPL2-only. Regards PS. I may be wrong but on the first sight GPLx and GPLx-only seems to be noncompatible.

wren ng thornton

27 Jan 27 Jan

12:45 a.m.

On 1/26/11 5:51 AM, Maciej Piechotka wrote:

...

Some projects (like Linux) remove this clause and I'm not sure how many projects are marked on hackage as GPL2 being GPL2-only.

Technically GPLx and GPLy are incompatible for all x and y such that x /= y. The problem is that *technically* the phrasing of the viral clause prohibits dual licensing, despite the obvious intention. This is why the recommended verbiage states that that the work is "licensed under GPLx or any later version". That disjunction isn't saying that you're allowing for revisions of refinements to the license, it's a disjunction of licenses so that others can choose the license that's compatible with their needs. Which is also why, if the "or any later version" part is omitted then the GPLx code can't be combined with GPLy (for y > x). Aka, "GPL2-only" stuff cannot depend on "GPL3(or later)" stuff. The only time this really matters is when dealing with the linux kernel (and few other projects) since they have specific objections to the GPL3 and intentionally sought to disallow licensing of kernel code under it. -- Live well, ~wren

Maciej Piechotka

2:21 p.m.

On Thu, 2011-01-27 at 00:45 -0500, wren ng thornton wrote:

...

On 1/26/11 5:51 AM, Maciej Piechotka wrote:

...
Some projects (like Linux) remove this clause and I'm not sure how many projects are marked on hackage as GPL2 being GPL2-only.

Technically GPLx and GPLy are incompatible for all x and y such that x /= y.The problem is that *technically* the phrasing of the viral clause prohibits dual licensing, despite the obvious intention.

Could you elaborate? I cannot see any problem why author, having all rights, cannot publish code under GPL-2 and MPL. Sure GPL-2 allows someone to fork it into single-licence fork.

...

This is why the recommended verbiage states that that the work is "licensed under GPLx or any later version". That disjunction isn't saying that you're allowing for revisions of refinements to the license, it's a disjunction of licenses so that others can choose the license that's compatible with their needs. Which is also why, if the "or any later version" part is omitted then the GPLx code can't be combined with GPLy (for y > x).

Aka, "GPL2-only" stuff cannot depend on "GPL3(or later)" stuff. The only time this really matters is when dealing with the linux kernel (and few other projects) since they have specific objections to the GPL3 and intentionally sought to disallow licensing of kernel code under it.

Hmm. By GPL I understend FSF version which allows relicensing. I'm not sure about the interpretation (and IANAL) but I'm not entirely sure if GPLx+ and GPLx-only are compatible at all. Regards

wren ng thornton

7:36 p.m.

On 1/27/11 2:21 PM, Maciej Piechotka wrote:

...

On Thu, 2011-01-27 at 00:45 -0500, wren ng thornton wrote:

...
On 1/26/11 5:51 AM, Maciej Piechotka wrote:

...
Some projects (like Linux) remove this clause and I'm not sure how many projects are marked on hackage as GPL2 being GPL2-only.

Technically GPLx and GPLy are incompatible for all x and y such that x /= y.The problem is that *technically* the phrasing of the viral clause prohibits dual licensing, despite the obvious intention.

Could you elaborate? I cannot see any problem why author, having all rights, cannot publish code under GPL-2 and MPL. Sure GPL-2 allows someone to fork it into single-licence fork.

IANAL, but that is the synopsis that was given to me by and old friend who was. ISTR that the FSF may have a page on the matter too (circa "how to upgrade to GPL3" pages), though I'm loo lazy to look for it now. The problem is in the exact wording of how the viral clause is phrased, which is somewhat at odds with the intention. Basically, if you license your work under GPL2, and someone else wants to use it in a derivative work, then they must distribute the composite work under GPL2. All well and good, since this is the intention of the viral clause. However, copyright law doesn't have any built-in notion of "versioning". So if you distribute your work as GPL2 and someone does some derivative work that they want to distribute as GPL3, then technically they must distribute the composite work under the *joint* license (GPL2 && GPL3); however, since parts of the GPL3 were specifically written as "bugfixes" to the GPL2, this means the joint license is inconsistent and so noone can simultaneously adhere to both of them, so the composite work cannot be (non-vacuously) distributed. Conversely, if your work was distributed as GPL2+ then you are providing a disjunction of licenses for users to choose from. The person making their derivative work would be free to choose the GPL3 (or GPL3+) license(s) for their use of your work, and this is clearly compatible with their own GPL3 (or GPL3+) license, so the composite work can be released under GPL3 && GPL3 == GPL3 (or GPL3+ && GPL3+ == GPL3+, or GPL3+ && GPL3 == GPL3,...) If you're familiar with linear logic, this is basically the same kind of differentiation between multiplicative and additive conjunction.

...

Hmm. By GPL I understend FSF version which allows relicensing.

I'm not sure exactly what you're meaning by "relicensing"...

...

I'm not sure about the interpretation (and IANAL) but I'm not entirely sure if GPLx+ and GPLx-only are compatible at all.

If one project is released under "GPL version x (or, at your option, any later version)" and the other is released under "GPL version x" (only), then the composite work can satisfy both by being released under "GPL version x" (only), since they have the option to choose "GPL version x" as their license for the first project. It's only a problem when x-only is not in the range of y+. -- Live well, ~wren

Maciej Piechotka

28 Jan 28 Jan

7:25 a.m.

On Thu, 2011-01-27 at 19:36 -0500, wren ng thornton wrote:

...

On 1/27/11 2:21 PM, Maciej Piechotka wrote:

...
On Thu, 2011-01-27 at 00:45 -0500, wren ng thornton wrote:

...
On 1/26/11 5:51 AM, Maciej Piechotka wrote:

...
Some projects (like Linux) remove this clause and I'm not sure how many projects are marked on hackage as GPL2 being GPL2-only.

Technically GPLx and GPLy are incompatible for all x and y such that x /= y.The problem is that *technically* the phrasing of the viral clause prohibits dual licensing, despite the obvious intention.

Could you elaborate? I cannot see any problem why author, having all rights, cannot publish code under GPL-2 and MPL. Sure GPL-2 allows someone to fork it into single-licence fork.

IANAL, but that is the synopsis that was given to me by and old friend who was. ISTR that the FSF may have a page on the matter too (circa "how to upgrade to GPL3" pages), though I'm loo lazy to look for it now.

The problem is in the exact wording of how the viral clause is phrased, which is somewhat at odds with the intention. Basically, if you license your work under GPL2, and someone else wants to use it in a derivative work, then they must distribute the composite work under GPL2. All well and good, since this is the intention of the viral clause. However, copyright law doesn't have any built-in notion of "versioning". So if you distribute your work as GPL2 and someone does some derivative work that they want to distribute as GPL3, then technically they must distribute the composite work under the *joint* license (GPL2 && GPL3); however, since parts of the GPL3 were specifically written as "bugfixes" to the GPL2, this means the joint license is inconsistent and so noone can simultaneously adhere to both of them, so the composite work cannot be (non-vacuously) distributed.

Conversely, if your work was distributed as GPL2+ then you are providing a disjunction of licenses for users to choose from. The person making their derivative work would be free to choose the GPL3 (or GPL3+) license(s) for their use of your work, and this is clearly compatible with their own GPL3 (or GPL3+) license, so the composite work can be released under GPL3 && GPL3 == GPL3 (or GPL3+ && GPL3+ == GPL3+, or GPL3+ && GPL3 == GPL3,...)

If you're familiar with linear logic, this is basically the same kind of differentiation between multiplicative and additive conjunction.

Sorry - I misunderstood you. Dual licensing corresponds in my mind to || not &&. I.e. program dual-licensed on MPL and GPL-2 is (MPL || GPL-2) and user can choose to which license he wants to adhere. I believe similar nomenclature is used on Wikipedia. The problem you are describing corresponds to compatibility and, of course, GPL-2 and GPL-3 are not compatible (I believe that GPL-2+ && GPL-3+ == GPL-3+).

...

...
I'm not sure about the interpretation (and IANAL) but I'm not entirely sure if GPLx+ and GPLx-only are compatible at all.

If one project is released under "GPL version x (or, at your option, any later version)" and the other is released under "GPL version x" (only), then the composite work can satisfy both by being released under "GPL version x" (only), since they have the option to choose "GPL version x" as their license for the first project.

It's only a problem when x-only is not in the range of y+.

Sorry - my concerns were unbased. I reread licences and found answer in point 9 (GPL-2) and 14 (GPL-3). Regards

wren ng thornton

10:22 p.m.

On 1/28/11 7:25 AM, Maciej Piechotka wrote:

...

On Thu, 2011-01-27 at 19:36 -0500, wren ng thornton wrote:

...
you distribute your work as GPL2 and someone does some derivative work that they want to distribute as GPL3, then technically they must distribute the composite work under the *joint* license (GPL2&& GPL3); however, since parts of the GPL3 were specifically written as "bugfixes" to the GPL2, this means the joint license is inconsistent and so noone can simultaneously adhere to both of them, so the composite work cannot be (non-vacuously) distributed.

Conversely, if your work was distributed as GPL2+ then you are providing a disjunction of licenses for users to choose from. The person making their derivative work would be free to choose the GPL3 (or GPL3+) license(s) for their use of your work, and this is clearly compatible with their own GPL3 (or GPL3+) license, so the composite work can be released under GPL3&& GPL3 == GPL3 (or GPL3+ && GPL3+ == GPL3+, or GPL3+ && GPL3 == GPL3,...)

Sorry - I misunderstood you. Dual licensing corresponds in my mind to || not&&. I.e. program dual-licensed on MPL and GPL-2 is (MPL || GPL-2) and user can choose to which license he wants to adhere. I believe similar nomenclature is used on Wikipedia.

Yes, "dual licensing" is disjunctive in the sense that clients are free to choose. However, the issue about GPL versions has to do with *joint* licensing, which is more like an intersection between the licenses since both must be satisfied simultaneously. Elsewhere on the thread I brought up the example of joint licenses arising from multiple versions of the BSD3 (namely the person named by the third clause varies). We can form the join of many BSD3 licenses by just concatenating them together, which is exactly what Apple does for all the licenses of the code they build off of. It's just that the join of GPL2 and GPL3 is inconsistent, so technically they aren't "GPL-compatible" with one another (until you get around the issue by dual licensing as GPLx+).

...

The problem you are describing corresponds to compatibility and, of course, GPL-2 and GPL-3 are not compatible (I believe that GPL-2+&& GPL-3+ == GPL-3+).

Yes, GPL2+ && GPL3+ == GPL3+. -- Live well, ~wren

Chris Smith

26 Jan 26 Jan

1:24 a.m.

On Wed, 2011-01-26 at 16:14 +1000, Ivan Lazar Miljenovic wrote:

...

You're right; they seem to have changed it again to add that phrase since last I (properly) read it.

I don't believe it's been changed recently. While you may license the specific source code you've written under a GPL-compatible license, the total program will remain licensed under the GPL. So someone could conceivably take your source code and copy it into a BSD3 project; but the issue when Hackage is involved seems to be what can be done with the program that Cabal has now compiled and built for you, and that's certainly subject to the GPL. That's not explicitly stated in that answer, but it is made clear through the rest of the FAQ. -- Chris Smith

Chris Smith

1:20 a.m.

On Tue, 2011-01-25 at 21:48 -0800, John Millikin wrote:

...

Please cite where the FSF claims the GPL applies to unrelated works just because they can compile against GPL'd code. Keep in mind that if your claim is correct, then every significant Linux and BSD distro is committing massive copyright infringement.

I'm not sure what you're doing here. You yourself just wrote in another email: "If you create a derivative work of BSD3 and GPL code (eg, a binary), it's covered by both the BSD3 and GPL." In practice, since the BSD3 contains no terms that aren't also contained in the GPL, that means it's covered by the GPL. If you're actually confused, I'd be happy to compose a longer response with more details. But since you've just said yourself the same thing I was saying, I feel rather as though running off to collect quotations from the FSF web site would be a wild goose chase and not much worth the time. What part of this do you think needs support? Is it the definition of "derived work" to include linking? Something else? -- Chris Smith

John Millikin

1:34 a.m.

On Tue, Jan 25, 2011 at 22:20, Chris Smith wrote:

...

On Tue, 2011-01-25 at 21:48 -0800, John Millikin wrote:

...
Please cite where the FSF claims the GPL applies to unrelated works just because they can compile against GPL'd code. Keep in mind that if your claim is correct, then every significant Linux and BSD distro is committing massive copyright infringement.

I'm not sure what you're doing here. You yourself just wrote in another email: "If you create a derivative work of BSD3 and GPL code (eg, a binary), it's covered by both the BSD3 and GPL." In practice, since the BSD3 contains no terms that aren't also contained in the GPL, that means it's covered by the GPL.

The specific claim I'm refuting is that if some library or application depends on GPL'd code, that library/application must itself be GPL-licensed. This claim is simply not true. The GPL only applies to derived works, such as binaries or copied code.

...

If you're actually confused, I'd be happy to compose a longer response with more details. But since you've just said yourself the same thing I was saying, I feel rather as though running off to collect quotations from the FSF web site would be a wild goose chase and not much worth the time. What part of this do you think needs support? Is it the definition of "derived work" to include linking? Something else?

I think you're getting mixed up between a derived work and dependent library/application. Using the following code as a guide, the library "hmatrix" is BSD3, the dependent library "matrixTools" is X11, the dependent application "matrixCalc" is BSD3, and the derived work ("binary") is all three. Just because some of the packages depend on a GPL'd library, doesn't mean *they* are GPL'd. They can be under whatever license the creator wants them to be. -------------------------------------------------------------------------------- import Data.List data License = GPL | BSD3 | X11 | PublicDomain deriving (Show, Eq) data Library = Library String License [Library] -- name, license, deps deriving (Show, Eq) data Application = Application String License [Library] -- name, license, deps deriving (Show, Eq) data Binary = Binary String [License] -- name, licenses deriving (Show, Eq) compile :: Application -> Binary compile (Application name license deps) = Binary ("bin-" ++ name) allLicenses where allLicenses = nub (license : concatMap libLicenses deps) libLicenses (Library _ l libdeps) = l : concatMap libLicenses libdeps main = do let base = Library "base" BSD3 [] -- hmatrix depends on base hmatrix = Library "hmatrix" GPL [base] -- matrixTools depends on hmatrix matrixTools = Library "matrix-tools" X11 [hmatrix] -- matrixCalc depends on base, hmatrix, and matrixTools matrixCalc = Application "matrix-calc" BSD3 [matrixTools, hmatrix, base] -- the compiled binary is a derived work of all four binary = compile matrixCalc print binary --------------------------------------------------------------------------------

Chris Smith

1:52 a.m.

On Tue, 2011-01-25 at 22:34 -0800, John Millikin wrote:

...

The specific claim I'm refuting is that if some library or application depends on GPL'd code, that library/application must itself be GPL-licensed. This claim is simply not true. The GPL only applies to derived works, such as binaries or copied code.

Well, binaries (among other things) are pretty much exactly what's at issue here. I don't think anyone disputes that you can copy and paste sections of BSD3 licensed source code into a new project, but that wasn't the point brought up. If you actually install the thing from Hackage, you build a binary, which links in code from the GPLed library, and distributing the result is covered by the terms of the GPL. I definitely interpret the license field in Cabal to refer to the terms and conditions that govern distribution of the entire program or library as a unit, including binaries. If the people to whom I distribute that program are not free to further distribute it without offering source code, then I'm not giving it to them under the terms of the BSD3 license; so the license field in Cabal should note that.

...

I think you're getting mixed up between a derived work and dependent library/application.

I'm fairly sure I'm not mixed up. I think it may have caused some confusion that I'm talking about the entire program, and you seem to be (sometimes, at least) talking about individual pieces of source code. -- Chris Smith

John Millikin

2:03 a.m.

On Tue, Jan 25, 2011 at 22:52, Chris Smith wrote:

...

On Tue, 2011-01-25 at 22:34 -0800, John Millikin wrote:

...
The specific claim I'm refuting is that if some library or application depends on GPL'd code, that library/application must itself be GPL-licensed. This claim is simply not true. The GPL only applies to derived works, such as binaries or copied code.

Well, binaries (among other things) are pretty much exactly what's at issue here. I don't think anyone disputes that you can copy and paste sections of BSD3 licensed source code into a new project, but that wasn't the point brought up. If you actually install the thing from Hackage, you build a binary, which links in code from the GPLed library, and distributing the result is covered by the terms of the GPL.

It's not possible for a .cabal file to specify which license the final binaries will use -- it depends on what libraries are locally installed, what flags the build uses, and what the executables themselves link. The best Cabal could do is, after finishing "cabal build" on an executable, printing out which licenses apply: $ cabal build some-pkg --flags=enable-some-exc ... Executable 'some-exc' has licenses: BSD3 GPL3 PublicDomain Executable 'some-other-exc' has licenses: BSD3 GPL3 ** Note: 'some-other-exc' links against external system libraries. Additional libraries may apply. Executable 'another-exc' has licenses: MIT PublicDomain ... $ Since it's impossible for Cabal/Hackage to work as you describe, it's only sensible to interpret the "license" field as applying to the source code archive.

Chris Smith

2:27 a.m.

On Tue, 2011-01-25 at 23:03 -0800, John Millikin wrote:

...

It's not possible for a .cabal file to specify which license the final binaries will use -- it depends on what libraries are locally installed, what flags the build uses, and what the executables themselves link.

It's certainly possible for library authors to indicate in their Cabal files the licensing restrictions that use of the library will place on the end result. The library author knows about all of this stuff. Sure, it may not be a perfect system -- but in practice, flags should probably not change licensing anyway, and there will nearly always be some license that is the most restrictive of all that apply and so can be said to govern the end result by itself. Of course the final executable would need to collect the licensing restrictions of all of its dependencies. But it then would not need to recursively check their dependencies, and so on.

...

Since it's impossible for Cabal/Hackage to work as you describe, it's only sensible to interpret the "license" field as applying to the source code archive.

As mentioned earlier, though, this leaves others in the position of hunting through the source code of all the direct and indirect dependencies of their project, looking for additional restrictions that might be hiding there. That's a pretty ridiculous requirement, and makes it unreasonably difficult to comply with the wishes of library authors. -- Chris Smith

Antoine Latter

3:13 a.m.

On Wed, Jan 26, 2011 at 1:27 AM, Chris Smith wrote:

...

On Tue, 2011-01-25 at 23:03 -0800, John Millikin wrote:

...
It's not possible for a .cabal file to specify which license the final binaries will use -- it depends on what libraries are locally installed, what flags the build uses, and what the executables themselves link.

It's certainly possible for library authors to indicate in their Cabal files the licensing restrictions that use of the library will place on the end result. The library author knows about all of this stuff. Sure, it may not be a perfect system -- but in practice, flags should probably not change licensing anyway, and there will nearly always be some license that is the most restrictive of all that apply and so can be said to govern the end result by itself.

Of course the final executable would need to collect the licensing restrictions of all of its dependencies. But it then would not need to recursively check their dependencies, and so on.

I state the license of what is being distributed - and what is being distributed is the source code as I wrote it. For me it is conceptually the easiest to understand, as I don't know in what environment the code will be compiled. Taken to an extreme, I don't want to have to list my library as GPL because it will be linked against the stock GHC runtime by almost all of its users. I also don't want my package description to be wrong when my transitive dependencies change - either by re-licensing or by their adding new dependencies. Antoine

wren ng thornton

27 Jan 27 Jan

12:52 a.m.

On 1/26/11 2:27 AM, Chris Smith wrote:

...

and there will nearly always be some license that is the most restrictive of all that apply and so can be said to govern the end result by itself.

All BSD3 licenses from different authors are "at the same level". To get the join of the licenses you must create a new license which incorporates all the different 3rd clauses. So while a most-restrictive license may exist, it will not be any of the source licenses. (Comparatively) trivial for humans; tricky for automated tools (which attempt to do better than collocating all source licenses). -- Live well, ~wren

Ketil Malde

26 Jan 26 Jan

6:08 a.m.

Chris Smith writes:

...

I definitely interpret the license field in Cabal to refer to the terms and conditions that govern distribution of the entire program or library as a unit, including binaries.

I disagree, I've always interpreted the license to cover the text in that particular package. At any rate we need a different way to deal with this, since the license for the resulting binary can vary depending on build flags, different binaries from the same package can end up having different licensing, licensing can change if the licencing of a dependency changes, and so on. Perhaps cabal should look over the licenses involved, and inform the user after building? : Installing executable(s) in /home/ketil/.cabal/bin Executable 'foo' incorporates components with the following licenses: GPL BSD3 LGPL Executable 'bar' ... -k -- If I haven't seen further, it is by standing in the footprints of giants

Chris Smith

12:19 p.m.

On Wed, 2011-01-26 at 12:08 +0100, Ketil Malde wrote:

...

I disagree, I've always interpreted the license to cover the text in that particular package.

There seems to be a difference in focus here that's confusing to me. When I write a library, my primary concern is generally with helping others use that library by linking it in their programs. As such, I generally consider that the most important set of licensing restrictions attached to my library are the ones that will apply to people linking the library in their programs. While I'm happy that people have the legal right to copy and paste my source code into their own projects, I also hope to prevent them from needing to do so. The licensing restrictions covering this last-ditch work-around for my failure to adequately package my code are a minor concern. As a result, if I were to write a package that depends on someone else's GPLed library, I don't see it being anywhere near worth the conceptual weight to apply a different license to the source code in the current package; since ultimately, the terms of the GPL are going to apply to anyone who builds a program with the library anyway. Sure, that occasionally creates questions like the one that was asked about hmatrix. So what? It's not a bad thing if people occasionally ask about relicensing.

...

At any rate we need a different way to deal with this, since the license for the resulting binary can vary depending on build flags, different binaries from the same package can end up having different licensing,

The other (somewhat obvious, in my mind) possibility is to consider this a poor use of build flags and packagine binaries together. One would then remain aware of the problem, and strive to avoid it by splitting up packaging better in the future.

...

licensing can change if the licencing of a dependency changes, and so on.

I suppose this is another reason to specify upper bounds on dependencies. :) In this case, it's a matter of legal compatibility rather than technical compatibility, but it amounts to the same thing.

...

Perhaps cabal should look over the licenses involved, and inform the user after building?

: Installing executable(s) in /home/ketil/.cabal/bin Executable 'foo' incorporates components with the following licenses: GPL BSD3 LGPL Executable 'bar' ...

That certainly seems like overkill. First of all, as mentioned above, it's confusing and unnecessary to package things in such a way that different licenses will apply to different pieces or build options. Furthermore, the example above could be greatly shortened by just saying "GPL". Complying with the terms of the GPL automatically implies complying with the terms of both the BSD3 and LGPL licenses. In practice, either this happens, or the licenses are incompatible... or the third option is that they may as well be incompatible because it's kinder to users to just consider the licenses incompatible and find different libraries to depend on, rather than dumping lists of multiple licenses on them. -- Chris Smith

malcolm.wallace

12:51 p.m.

...

Installing executable(s) in /home/ketil/.cabal/bin Executable 'foo' incorporates components with the following licenses: GPL BSD3 LGPL Executable 'bar' ...

Furthermore, the example above could be greatly shortened by just saying "GPL". Complying with the terms of the GPL automatically implies complying with the terms of both the BSD3 and LGPL licenses. IANAL, but I think this statement is factually incorrect, on a plain reading of the BSD licence itself. If you distribute an artifact that contains BSD-licensed code, you cannot simply delete or ignore the BSD licence on the grounds that it is subsumed into the terms of some other licence. BSD states quite clearly: "redistributions ... must reproduce ... this list of conditions". If you fail to do so, then you are breaking the terms of the licence, and since nothing else gives you permission to redistribute source or binary, you could technically be sued by the copyright holder. BSD is just as "viral" as the GPL. Its terms may be less onerous, but they still apply. Regards, Malcolm

Ketil Malde

27 Jan 27 Jan

3:23 a.m.

Chris Smith writes:

...

...
I disagree, I've always interpreted the license to cover the text in that particular package.

...

There seems to be a difference in focus here that's confusing to me. When I write a library, my primary concern is generally with helping others use that library

I'm not saying it's a bad idea to echo the licensing of dependencies, say for a library that wraps an underlying C-library. But there could be valid reasons for not doing it.

...

As a result, if I were to write a package that depends on someone else's GPLed library, I don't see it being anywhere near worth the conceptual weight to apply a different license to the source code in the current package; since ultimately, the terms of the GPL are going to apply to anyone who builds a program with the library anyway.

What if the library depends on proprietary code? Maybe you want to make the code available for educational purposes, or porting to non-proprietary alternatives? What if you write a database access library which links against various backends - just because one of the backends has restriction (GPL, say), you may want to use a liberal license so that people can still use it in their proprietary project with (say) BSD-licensed back ends.

...

...
At any rate we need a different way to deal with this, since the license for the resulting binary can vary depending on build flags, different binaries from the same package can end up having different licensing,

...

The other (somewhat obvious, in my mind) possibility is to consider this a poor use of build flags

Well, I disagree - it's nice to be able to ./configure --without-readline (or whatever) precisely to avoid licensing conditions that are unacceptable to your project. The alternative is more duplication of code.

...

I suppose this is another reason to specify upper bounds on dependencies. :) In this case, it's a matter of legal compatibility rather than technical compatibility, but it amounts to the same thing.

For most of us, technical compatibility is what's relevant, since we typically download from Hackage and build everything from scratch, we don't often redistribute binaries. Linux distributions will have to audit packages a bit more carefully.

...

That certainly seems like overkill. First of all, as mentioned above, it's confusing and unnecessary to package things in such a way that different licenses will apply to different pieces or build options.

We have lots of itty bitty packages with a variety of licenses, so I'm not sure this is so easy for non-trivial projects.

...

Furthermore, the example above could be greatly shortened by just saying "GPL".

I'd be wary of automatically interpreting licensing issues for users. Better to just provide the information, and let them decide whether they have redistribution rights or not. -k -- If I haven't seen further, it is by standing in the footprints of giants

Edward Kmett

26 Jan 26 Jan

10:11 p.m.

On Tue, Jan 25, 2011 at 5:18 PM, Ivan Lazar Miljenovic < ivan.miljenovic@gmail.com> wrote:

...

On 26 January 2011 07:32, gutti wrote:

...
The H-Matrix and the prelude numeric packages however, which in my mind cover really important ground work, are issued under the resprictive GPL.

I think your description of "restrictive" is contentious...

Perhaps, but its true. ;)

...

...
Is that only because they link into other external GNU - libaries with GPL license ? -- If yes would be repackaging the haskell-native bits in an extra BSD package an option ?

Or else because the developers _wanted_ to license it under the GPL. Some people do, you know.

Actually, not to quote him out of context, but a short snippet from an email to me from Alberto last year shows this isn't the case here in the author's own words.

...

It is GPL because of ignorance and laziness. For hmatrix I really want the less restrictive license compatible with the fact that it is based on (calls functions from) BLAS/LAPACK (BSD) and GSL (GPL). Can I change the license to something like BSD?

This is from when we were discussing how to integrate hmatrix better with my ad package. He was interested in using 'ad' to compute over vectors, and I had a variation on the ad types that would allow them to compute with larger jacobian fragments, but wasn't able or willing to build on the basic hmatrix package, due to the licensing. He was very open to the idea of BSD licensing and to the idea of potentially factoring it apart into GPL and BSD packages if the GSL dependent portions could not be so licensed. The main reason this didn't happen is that this fell off my critical path and I moved on to other things. -Edward Kmett

5226

Age (days ago)

5230

Last active (days ago)

List overview

Download

42 comments

13 participants

participants (13)

Antoine Latter
Chris Smith
David Leimbach
Edward Kmett
gutti
Ivan Lazar Miljenovic
John Lask
John Millikin
Ketil Malde
Maciej Piechotka
malcolm.wallace
Richard O'Keefe
wren ng thornton