Stefan Monnier wrote:

...

Note that this is a safety measure for the submitter: If the code is, indeed, released to the public, it is (dual licesed) GPL, anyway, even if that might not have been the intent.

No. If the submitter did not explicitly release his code under the GPL, then it is not licensed under the GPL, even if is a derivative of GPL code. Instead, it is a breach of the GPL license and the submitter is exposing himself to a civil suit.

...I think for the majority of non-commercial developers (and even a lot of companies), the net result is the same. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

The next question that comes to mind is thus: What if a new library X' released under BSD or MIT license implements the X API (making possible to compile Y against it)? Can such a new library X' be licensed under something else than the GPL (we guess Yes because we don't think it is possible to license the API itself)?

Yes.

Why should the existence of X' make any difference for the author of Y?

Because the existence of X' makes it possible to use Y without using X. The order in which X and X' come to exist doesn't matter. This exact scenario took place for the GMP library, whose API was reimplemented as fgmp, specifically so that a user of the GMP library could release their code under a different library than the GPL. Stefan

The thing is that the new X' library can provide the same API while not being very useful (bug, performance, whatever). And in this case, it is trivial to make that new X'. So I don't understand why the answer was no in the first place.

The law is not a set of mathematical rules. It all needs to be interpreted, compared to the underlying intentions etc... So while you can say that it's pointless if you push the idea to its limit, that doesn't mean that it's meaningless in the context of the law. All it might mean is that in some cases, the interpretation is not clear. It's those cqases where a court needs to decide which interpretation should be favored. Stefan

Stefan Monnier writes:

...

What if a new library X' released under BSD or MIT license implements the X API (making possible to compile Y against it)? Can such a new library X' be licensed under something else than the GPL (we guess Yes because we don't think it is possible to license the API itself)?

Yes.

So it's okay to reimplement the GPL'd API with a different license -- this is apparently not a derived work -- but making use of it is not allowed?

...

Why should the existence of X' make any difference for the author of Y?

Because the existence of X' makes it possible to use Y without using X. The order in which X and X' come to exist doesn't matter.

So the ability to *use* is what is crucial here? This is very surprising to me in the context of copyright law. At any rate you'd be able to use the source code of Y for teaching, bedtime reading, or whatever. Normally, I'd expect to write some text and publish it under any license I wish, the exeption being if I incorporate somebody elses work. I also thought merely conforming to an API didn't count as such incorporation, since this would mean glibc would be GPL (using the kernel API), which in turn would make GHC GPL (linking to glibc).

This exact scenario took place for the GMP library, whose API was reimplemented as fgmp, specifically so that a user of the GMP library could release their code under a different library than the GPL

This sounds very interesting, but unfortunately, I am unable to google any details. Links? -k -- If I haven't seen further, it is by standing in the footprints of giants

Am Donnerstag, 4. März 2010 18:57:03 schrieb MightyByte:

Interesting. It seems to me that the only solution for the BSD-oriented haskell community is to practically boycott GPL'd libraries. From what I understand, this is exactly what the LGPL is for. I've known the basic idea behind the GPL/LGPL distinction for quite awhile, but I didn't realize that mistaking the two had such far-ranging consequences. Since GPL seems to be the big elephant in the room, it seems very easy to make this mistake. At the very least we should try to educate the community about this.

To my knowledge, the LGPL only allows *linking* with non-(L)GPL software. But GHC doesn’t just link but performs massive cross-module inlining. So in my opinion, LGPL is not a solution, too. Use BSD3! Best wishes, Wolfgang

2010/3/5 Maurí­cio CA

...

To my knowledge, the LGPL only allows *linking* with non-(L)GPL software. But GHC doesn't just link but performs massive cross-module inlining. So in my opinion, LGPL is not a solution, too. Use BSD3!

But that massive cross-module inlining happens at your computer, where the rights allowed by GPL for private use applies.

Not if I ship you a statically linked binary. You assume everyone compiles my Haskell source code :-).

So, as long as you distribute the GPL/LGPL code separate from your BSD/proprietary code, no restrictions should apply. (I believe this applies even with GPL, as all you'll be using in your code is the API which, as far as I know, can't be copyrighted, like any kind of interface -- even hardware interface. But I can't find a source on that.)

This is not suitable for everyone.

Best,

Maurício

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

Am Samstag, 6. März 2010 03:45:02 schrieb Maciej Piechotka:

PS. There is also GPL-with-linking-exception which allows linking etc. but does not require relinking capability. I'd believe that in such case the cross-module inlining is not a problem since it is 'linking' for compiler.

The term “linking” is quite well-defined in computer science. You seem to redefine it and assume that copyright holders will accept your redefinition. Best wishes, Wolfgang

On Thu, Mar 4, 2010 at 18:05, Stephen Tetley wrote:

Hi Tom

Hmm, its seems I'm due to eat my hat...

To me though, the judgement makes that insistence that using an API is making a derivative work. I can't see how that squares up.

That has, AFAIU, been the intention of the GPL all along. See e.g. http://www.fsf.org/licensing/licenses/why-not-lgpl.html It also explains why there has been a discussion in the Linux kernel community about closed source drivers (e.g. nvidia). The LGPL was, AFAIU, written to explicitly allow a shift of license at the API level. Without the insistence you point out, GPL and LGPL would be pretty much the same license. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

On Fri, Mar 5, 2010 at 08:55, minh thu wrote:

2010/3/5 Magnus Therning :

...

On Thu, Mar 4, 2010 at 18:05, Stephen Tetley wrote:

...

Hi Tom

Hmm, its seems I'm due to eat my hat...

To me though, the judgement makes that insistence that using an API is making a derivative work. I can't see how that squares up.

That has, AFAIU, been the intention of the GPL all along.  See e.g. http://www.fsf.org/licensing/licenses/why-not-lgpl.html

It also explains why there has been a discussion in the Linux kernel community about closed source drivers (e.g. nvidia).

The LGPL was, AFAIU, written to explicitly allow a shift of license at the API level.  Without the insistence you point out, GPL and LGPL would be pretty much the same license.

I don't see how what you say is related by the link you provide.

They say there is an advantage to make a library GPL when there is no alternative so program using the library is required to be GPL too. As an example,  they licensed the C library LGPL because they were already other available C library, so making their one GPL licensed could not really drive more programs to be GPL.

Indeed the boundary of a library is its API but that hardly translates to say that the GPL covers the API.

Ah, I might have misunderstood the whole thread then. I thought the discussion was about using the API of a GPLd library. While your comment suggests it's actually about re-implementing a GPLd library, making it API compatible, and releasing the re-implementation under another license. In that case wouldn't a project like Harmony (http://en.wikipedia.org/wiki/Harmony_toolkit) be problematic? So would editline's mode for compatibility with readline, right? (GNU TLS would probably not get in trouble for providing an OpenSSL compatibility layer though.) /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

On 5 March 2010 09:38, Stephen Tetley wrote:

Similar BSD3 is a GPL compatible library, so this dependency chain would be legal:

[2] App --> libGPL --> libBSD

Typo above - should be Similar BSD3 is a GPL compatible __license__, so this dependency chain would be legal: [2] App --> libGPL --> libBSD Apologies all

On 5 March 2010 09:53, Magnus Therning wrote:

Now I'm even more confused. How is hosting on Hackage an issue in [1]?

Hi Magnus The issue arouse when Tom Tobin spotted Hackage was hosting hakyll (libBSD3) that depends in pandoc (libGPL). Hakyll's author is allowed to privately write any code he wants that uses GPL code, Hackage come into it as he published on Hackage. Best wishes Stephen

As always I'm still not a lawyer, so this is not legal advice... but here's how I think it works. If you need to talk to a lawyer to get this cleared up, do it. On Fri, Mar 5, 2010 at 2:30 AM, Malcolm Wallace < malcolm.wallace@cs.york.ac.uk> wrote:

On 5 March 2010 09:53, Magnus Therning wrote:

...

Now I'm even more confused. How is hosting on Hackage an issue in [1]?

...

The GPL specifically (and only) applies when code is "distributed" to others outside the originating authors' organisation.

I'm pretty sure it says nothing about organizations. If I threw a flash stick with a binary of a program I wrote over my cubicle wall to say, my coworker, Steve, and I tried to tell him he couldn't have the source to my binary that I created based on a GPL'd program on that stick, he could say I've infringed on his rights under the GPL.

Hackage is a means of distributing such code. Because Hackage has received the code from the author, it therefore has the same obligations (under the GPL, or BSD, or whatever) as any other recipient.

Hackage has no obligations unless it's an intelligent entity. Hackage does not have to enforce the GPL, the author responsible for the perceived violation of the GPL must resolve it with the person claiming the violation, either by settling it inside or outside of court, by either making their code the GPL, or dealing with someone potentially bringing them in front of a judge. In fact the people running Hackage have now become the same as the person I threw my flash drive over the cube wall to, and have the same rights as Steve.

To be clear, like any recipient, one treats the donor in good faith. That is, one believes the license granted by the author (or upstream distributor) is valid until notified otherwise. It is the author's responsibility to check, not Hackage's.

EXACTLY :-) Now for a bit of personal reflection that you can ignore if you wish... Wouldn't it be excellent if Google could tell us just how many times innocent mailing lists like haskell-cafe have to put up with confusion over the GPL? Every single open source project I've ever been on has had a mailing list that has had this problem in the last 15 years I've been active in open source communities, and it just keeps rearing it's ugly head. It's really irritating and distracts people who'd rather be sharing their work with one another from doing so, completely thwarting the point of the FSF to begin with. As such I've long since abandoned any love for any form of the GPL, and much prefer licenses like the BSD license.

Regards, Malcolm

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

On Fri, Mar 5, 2010 at 4:16 AM, Malcolm Wallace < malcolm.wallace@cs.york.ac.uk> wrote:

...

The GPL specifically (and only) applies when code is "distributed" to others outside the originating authors' organisation.

I'm pretty sure it says nothing about organizations.

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

This is not the GPL license, this is an FAQ written by someone at the FSF presumably about how they interpret the license. Since anyone can technically interpret this license in any way, and argue before a judge with their belief about their rights, I don't feel any better about this text. I think key to this is whether or not individuals within an organization own their own work or not. Sometimes people do retain ownership, though it's very very rare. In that case my handing software to someone I'm cooperating with could still claim their rights are being infringed under the GPL if I don't provide source code.

Is making and using multiple copies within one organization or company “distribution”? No, in that case the organization is just making the copies for itself. As a consequence, a company or other organization can develop a modified version and install that version through its own facilities, without giving the staff permission to release that modified version to outsiders.

However, when the organization transfers copies to other organizations or individuals, that is distribution. In particular, providing copies to contractors for use off-site is distribution.

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

David Leimbach wrote:

Yes the author can privately license code to himself under any license he wants, but when he distributes code based on GPL'd code, it has to be GPL'd. That's why people hate this license, or love this license. For all the freedom it talks about it's awfully restrictive.

It has to be lincensed under GPL, but GPL doesn't have to be the only license. Consider, for example, releasing an app that depends on readline (GPL) under GPL/BSD: People may use+distribute it under GPL, they may hack it to remove the readline dependency and use and distribute it under either GPL, BSD, or both, or someone could come along and re-implement readline (guess what has happened) and everybody will be able to choose between GPL, BSD, or both, again. The GPL is viral, but it doesn't (and can't) prevent you from releasing _your_ code under -- additionally -- any bleeding license you wish[1]. It could also be argued that, as BSD explicitely allows re-lincensing, that any grant of a BSD-license implies a dual-license under GPL, as everyone and everybody can just re-license the code as such. BSD also does not claim that the lincensed code is not allowed to be used under GPL, and it does not guarantee FITNESS FOR ANY PURPOSE, which includes, but is not limited to, being distributable under violation of GPL. This, admittedly, isn't a bullet-proof argument. I'd be surpised, though, if any court would see _intent_ of closing up GPL'ed code if you release it under terms _that allow, but not by themselves enforce,_ GPL distribution. However, (apart from IANAL and whether or not above argument holds), not mentioning that your code depends on GPL and thus can't be distributed in violation of it is clearly a mean, aweful breach of the principle of least surprise and is therefore to be fought with any static means we have at our disposal: % cabal sdist foo.cabal: Error: Depends on a GPL library but only mentions "BSD3" as license. Either change License: to include GPL or remove the offending dependency. Please, please don't make this a mere warning. It's easy and painless enough to fix and will result in way less confusion about what terms some random piece of hackage code can be used under. [1] I strongly advice dual-licensing any BSD code under the Beer License, regardless of GPL involvement. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

Pending an explicit response from the SFLC, I decided to ask the FSF themselves what they thought of the Hackage/cabal situation. Specifically, I asked this:

There is a website, 'Hackage' (http://hackage.haskell.org) that hosts source code packages for Haskell libraries and programs. The site hosts *only* source code, along with (text) descriptions of the packages. Each package hosted by the site is either source code for a library, for a program, or for both.

In the package description, a package author specifies what license applies to the source code, the common choices being LGPL, GPL, or BSD3. The package author also specifies what other packages in the repository the package may require to compile successfully.

The controversy in the community of users who use Hackage is whether or not it is a violation of the GPL for a package to be uploaded to Hackage specifying (for example) a BSD3 license for the code in the package, but also specifying that another package is a requirement for compilation, where that other package has been uploaded specifying (a version of) the GPL as its license.

The opinion of many in the community is that since Hackage hosts only source code, and does not in any way combine packages (any combination of packages is created when a user chooses to download and compile and link the individual packages) there is no problem: there are no 'derived works' combining GPL and non-GPL being distributed on the site.

Others believe that having a non-GPL package have as a dependency a GPL package is a problem for both the package author and for Hackage; that this in some way violates the GPL.

I don't believe this sort of situation is clearly addressed in your FAQ (at least not to the satisfaction of the Hackage user community). There's a certain amount of fear, uncertainty and doubt being spread about usage of the GPL on Hackage, which it would be great to dispel (or, confirm, as necessary).

Someone from the FSF responded as follows:

A work which extends or requires a GPL work will generally also need to be released under the GPL, unless the GPL work provides a specific exception for that case. You are already familiar with the FAQ; however, please note http://www.fsf.org/licensing/licenses/gpl-faq.html#OOPLang and http://www.fsf.org/licensing/licenses/gpl-faq.html#MereAggregation . There is no magic to the act of linking, compiling, or a function invocation; these are not defining moments. It is the level of integration and dependency which will define whether one work is a derivative of another.

Ultimately, the decision that one work is a derivative of another is a legal one which a court may have to decide for a particular case; a lawyer can give you a legal opinion. However, a good rule of thumb would be: if P is a GPL work, and Q is a work that would not function without P, then Q is probably a derivative of P and should only be conveyed to a third party or the public under a GPL license, in compliance with the license for P.

I hope that helps.

Thank you for your interest in free software! I am not a lawyer and the above is not legal advice. The opinions expressed above do not constitute an official position of the Free Software Foundation.

Luigi Bai FSF Associate Member Volunteer, licensing@gnu.org

Of course, given the disclaimer at the bottom, this opinion is officially no better than any of our opinions on the matter. Nevertheless, I would at least believe based on the above that this is what the FSF *wants* the GPL to mean, and, by extension, would assume, barring other evidence that this is what someone who chooses the GPL *wants* it to mean, and in licensing any software that I write that depends on someone else's GPL'd software, I'd respect those desires (without at all suggesting that this has any bearing on how the GPL would actually be interpreted in court). There's still a lot of gray area here -- the mere existence of a dependency doesn't imply that a software package is useless without the dependency, so there are many situations in which P could depend on Q and not be a derivative of Q, because the dependency can be disabled in some way and the software would still function. As an example -- pandoc can be built with or without highlighting-kate, and is useful either way. They're both GPL and by the same author, so there's no issue, but were that not the case it would seem obvious that pandoc isn't derivative of -kate, and thus could (by this reasoning) be released independently under different terms. The same may not be true of the hakyll / pandoc situation which sparked this controversy. Cheers, Rob

On Fri, Mar 5, 2010 at 2:59 PM, Job Vranish wrote:

This seems really confusing.

It would imply that if I write a library that is designed to talk to some part of the linux kernel API (which is GPL'd) then I'd have to release my library under the GPL. And anything that used my libraries API would need to be GPL'd too, etc... Which would mean that everything run in linux would need to be GPL'd, which is just silly.

Linux license specifically single that case out of the license restrictions. From the COPYING file in linux's source: NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the Linux kernel) is copyrighted by me and others who actually wrote it. Also note that the only valid version of the GPL as far as the kernel is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated.

Robert Greayer wrote:

There's still a lot of gray area here -- the mere existence of a dependency doesn't imply that a software package is useless without the dependency, so there are many situations in which P could depend on Q and not be a derivative of Q, because the dependency can be disabled in some way and the software would still function. As an example -- pandoc can be built with or without highlighting-kate, and is useful either way. They're both GPL and by the same author, so there's no issue, but were that not the case it would seem obvious that pandoc isn't derivative of -kate, and thus could (by this reasoning) be released independently under different terms. The same may not be true of the hakyll / pandoc situation which sparked this controversy.

From what I gather, Hakyll is helper program / library for generating static websites. It uses pandoc to offer a default markdown -> html converter, which means that it's also useful without it.

Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

Hi, On Fri, Mar 05, 2010 at 01:16:18AM +0300, Bulat Ziganshin wrote:

...

...

[...] The SFLC holds that a library that depends on a GPL'd library must in turn be GPL'd, even if the library is only distributed as source and not in binary form.

...

Was this a general statement

yes. it's soul of GPL idea, and it's why BG called GPL a virus :)

Oh, BSD3 or ISC licensed code is viral as well, but only on the source code level ;-) (if you redistribute the sources, you have to leave the license and the copyright marker intact) Anyway, I really think the SFLC people are telling lies here (or, as someone else wrote in this thread, are telling what they whish the GPL to imply). Applying some common sense tells me: If you write some code (library or program) that depends on some GPL licensed library, you can still redistribute your *source code* under whatever license you want, as long as your source code distribution does not contain copies (original or modified) from the GPL'd stuff it depends on. For binary products created from such a library combo, you have to apply the GPL, which should be fine if *your* code is BSD3 or ISC or something similar. But nobody can force you to apply a specific license to your *source code*, even if the binary (links against/calls functions provided by) a GPL'd library. Oh, and for the discussion about wether APIs may be license-worth, which also popped up in this thread; /* * Copyright (c) 2010 Matthias Kilian * * All rights reserverd. */ extern int foo(double bar); If you ever dare to write some C function `foo' that takes a double and returns an int, I'll sue you to death ;-) Yes, there are APIs more inventive than that example above, but they're just *interfaces*. There has to be a lot of brain used on some interface to make it a creative work. (Oh, monads jump to mind) Ciao, Kili

On Fri, Mar 05, 2010 at 12:29:15PM +0000, Malcolm Wallace wrote:

...

...

Background: X is a library distributed under the terms of the GPL. Y is another library which calls external functions in the API of X, and requires X to compile. X and Y have different authors.

1) Can the author of Y legally distribute the *source* of Y under a non-GPL license, such as the 3-clause BSD license or the MIT license?

I believe the answer you got from SFLC ("no") contradicts what the authors of the GPL say about this case. viz:

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

Yes, to my knowledge what the SFLC said is also incorrect. Perhaps they just erred on the side of 'just GPL it'. In any case, I wouldn't want cabal/hackage to worry about such things for random uploaded packages, it can't know if the GPL licenses have special exceptions or whatnot. Unless of course someone where to write a formal combinator language for expressing legal contracts.. :). John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/