Okay, You're right. I will change the license info as soon as possible. Kind regards, Jasper Van der Jeugt On Dec 8, 2009 6:30 AM, "Tom Tobin" wrote: On Sat, Dec 5, 2009 at 6:35 AM, Jasper van der Jeugt wrote: > Hakyll is a simp... I hate to say this, but it looks like you're violating the GPL by not releasing Hakyll under the GPL, since Pandoc is GPL'd. I don't think you're alone in this — IIRC I've seen several Hackage libraries doing the same thing. I *really* wish Pandoc would switch to a non-copyleft license. (Pretty please, with sugar and cherries on top?) I know that GPL authors are trying to enforce contributions, but the opposite can very well happen: if you have an "essential" copyleft library, someone's eventually going to write a non-copyleft replacement for it (e.g., witness the replacements for Readline) rather than continue to allow it to restrict the licensing options of the community. Great libraries should be able to be embraced without reservations. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Tom Tobin wrote:

The 3 clause BSD license is officially a GPL compatible license. See:

http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses

It is within the terms of the GPL to link GPL code to a bunch of BSD3 code as long as you abide by both the GPL and the BSD3 license.

That really just means that BSD3 code can be used in GPL code; you still have to release your own code as GPL if you are including any GPL code. Having said that...

...

I *really* wish Pandoc would switch to a non-copyleft license.

The LGPL is still a copyleft license. Do you still have a problem with that?

If Pandoc is LGPL, then I think that means we are dealing with an entirely different situation, one in which the library user can choose whatever license he or she likes for his or her own code as long as any modifications to the LGPL'd library itself are released under the LGPL. Cheers, Greg

Gregory Crosswhite wrote:

...

Tom Tobin wrote:

The 3 clause BSD license is officially a GPL compatible license. See:

http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses

It is within the terms of the GPL to link GPL code to a bunch of BSD3 code as long as you abide by both the GPL and the BSD3 license.

That really just means that BSD3 code can be used in GPL code; you still have to release your own code as GPL if you are including any GPL code.

The main licence of darcs is GPL, but I've licensed all my contributions to it as BSD3. My view of this is that while darcs as a whole is obviously still GPL, any of my contributions that can be extracted independently can be used in other projects under BSD3. I'd say that with hakyll, the library itself can be under BSD3 but any executable you produce from it at the moment will necessarily be GPL. Not sure if there's any good way to communicate this fact in the metadata, though. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

Gregory Crosswhite writes:

That really just means that BSD3 code can be used in GPL code; you still have to release your own code as GPL if you are including any GPL code.

Not quite true: it means that any code your BSD3 library gets used in has to have a GPL-compatible license: http://www.fsf.org/licensing/licenses/gpl-faq.html#IfLibraryIsGPL (this is the approach I've used for Graphalyze since I use Pandoc as a default library for document generation; later on I'm planning on re-doing the document part in which case it will _have_ to use Pandoc and thus I'll re-license the library). -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

minh thu writes:

I wonder how APIs are covered.

I don't think an API would be covered. The API is the standard way to use something, if copyright licenses cover usage like this, any executable will be a derivative of the operating system and (possibly) the compiler.

Why should your code be licensed under GPL?

I think your code is covered by whatever license you wish. An aggregate work, on the other hand, would need to be covered by the GPL, and all source code would have to be available under GPL terms. So if you distribute your code linked to or incorporating the GPL library, the whole must conform to the GPL license (source availability and redistributatbility, etc). Your contributions could still be licensed under a different license (e.g. BSD), as long as the licensing doesn't prevent somebody else to pick it up and relicense it under GPL. At least, that's how I understand things. -k -- If I haven't seen further, it is by standing in the footprints of giants

On Tue, Dec 8, 2009 at 3:30 PM, Ben Franksen wrote:

Ketil Malde wrote:

...

Your contributions could still be licensed under a different license (e.g. BSD), as long as the licensing doesn't prevent somebody else to pick it up and relicense it under GPL.

At least, that's how I understand things.

Right. So hakyll is absolutely fine with a BSD3 license, AFAICS.

Seriously, no, this is *totally* wrong reading of the GPL, probably fostered by a misunderstanding of the term "GPL-compatible license". GPL-compatible means the compatibly-licensed work can be incorporated into the GPL'd work (the whole of which is GPL'd), *not the other way around*. If you are forming a derivative work based on the GPL'd work, and thus you have to release that derivative work under the GPL. If you don't believe me, ask the people at the Software Freedom Law Center: help@softwarefreedom.org They've answered legal questions for me before. Please note that I'm not raising this issue because I like the GPL (I don't); I'm raising it because I don't think many people understand the consequences of using a GPL'd library. I think there would be more pressure on library authors to not GPL their works if everyone understood how restrictive the GPL was.

Ganesh Sittampalam wrote:

On Tue, 8 Dec 2009, Tom Tobin wrote:

...

On Tue, Dec 8, 2009 at 3:30 PM, Ben Franksen wrote:

...

Ketil Malde wrote:

...

Your contributions could still be licensed under a different license (e.g. BSD), as long as the licensing doesn't prevent somebody else to pick it up and relicense it under GPL.

At least, that's how I understand things.

Right. So hakyll is absolutely fine with a BSD3 license, AFAICS.

Seriously, no, this is *totally* wrong reading of the GPL, probably fostered by a misunderstanding of the term "GPL-compatible license". GPL-compatible means the compatibly-licensed work can be incorporated into the GPL'd work (the whole of which is GPL'd), *not the other way around*.

No. See http://www.fsf.org/licensing/licenses/gpl-faq.html#WhatIsCompatible Quote: "What does it mean to say that two licenses are compatible? In order to combine two programs (or substantial parts of them) into a larger work, you need to have permission to use both programs in this way. If the two programs' licenses permit this, they are compatible. If there is no way to satisfy both licenses at once, they are incompatible.[...]" and http://www.fsf.org/licensing/licenses/gpl-faq.html#WhatDoesCompatMean "What does it mean to say a license is compatible with the GPL? It means that the other license and the GNU GPL are compatible; you can combine code released under the other license with code released under the GNU GPL in one larger program."

...

If you are forming a derivative work based on the GPL'd work, and thus you have to release that derivative work under the GPL.

Maybe, but I doubt very much that publishing a library that merely calls functions from some other (GPL'ed) library makes your library a "derivative work" of the former. It is something different if you /combine/ those two libraries into e.g. an application.

The combination of haykll and pandoc clearly must be GPL. I don't think it automatically follows from that that hakyll taken alone must be GPL.

Right that was the point I wanted to make. It is the responsibility of the programmer who uses hakyll (and thus, presumably, pandoc) in order to produce a complete program to make sure that his work complies with /both/ licenses. This is possible if the two licences are compatible, see quotes above.

One might argue that the hakyll itself must be a derivative work as it builds on pandoc,

If this were so, then /all/ of Linux (including all the thousands of programs found on linux distributions) would have to be licensed under GPL, which is clearly not the case. It would also mean that MS could require fees from people who program against the windows API. Cheers Ben

On Tue, Dec 8, 2009 at 3:46 PM, Tom Tobin wrote:

If you are forming a derivative work based on the GPL'd work, and thus you have to release that derivative work under the GPL.

Wow, I mangled the syntax on that last sentence. That should read: "If you are forming a derivative work based on the GPL'd work, you thus have to release that derivative work under the GPL."

Am I the only one who finds this stuff confusing as hell? On Tue, Dec 8, 2009 at 2:13 PM, Robert Greayer wrote:

The crux here is that the source code of hakyll, released on hackage, is not a derivative of Pandoc (it contains, as far as I understand it, no Pandoc source code).  A compiled executable *is* a derivative of Pandoc, so anyone who *distributes* a compiled executable would need to make *all* the source available under the GPL (including the hakyll source).  Since the hakyll package is released under BSD3, this would be allowed (AIUI, IANAL).

On Tue, Dec 8, 2009 at 4:13 PM, Robert Greayer wrote:

On Tue, Dec 8, 2009 at 4:46 PM, Tom Tobin wrote:

...

On Tue, Dec 8, 2009 at 3:30 PM, Ben Franksen wrote:

...

Ketil Malde wrote:

...

Your contributions could still be licensed under a different license (e.g. BSD), as long as the licensing doesn't prevent somebody else to pick it up and relicense it under GPL.

At least, that's how I understand things.

Right. So hakyll is absolutely fine with a BSD3 license, AFAICS.

Seriously, no, this is *totally* wrong reading of the GPL, probably fostered by a misunderstanding of the term "GPL-compatible license". GPL-compatible means the compatibly-licensed work can be incorporated into the GPL'd work (the whole of which is GPL'd), *not the other way around*.  If you are forming a derivative work based on the GPL'd work, and thus you have to release that derivative work under the GPL.

The crux here is that the source code of hakyll, released on hackage, is not a derivative of Pandoc (it contains, as far as I understand it, no Pandoc source code).  A compiled executable *is* a derivative of Pandoc, so anyone who *distributes* a compiled executable would need to make *all* the source available under the GPL (including the hakyll source).  Since the hakyll package is released under BSD3, this would be allowed (AIUI, IANAL).

IANAL either, but my understanding is that judges take a very dim view of attempts like this to evade the requirements of a license. If a piece of software is built on another piece of software, it doesn't matter if you're looking at source code or a binary. I can write the SFLC and pose a hypothetical situation that captures the gist of what we're talking about, and post the response here, if anyone is interested.

Tom Tobin wrote:

IANAL either,

Ditto!

but my understanding is that judges take a very dim view of attempts like this to evade the requirements of a license.

I can't see how any judge could possibly come to that conclusion in this case. Studying the terms of the GPL and the BSD3 a lawyer would come to the conclusion that the terms of the GPL are narrower than the terms of the BSD3 but that independently developed code under the BSD3 license can be linked to GPL code as long as the terms of the GPL are followed. For instance, there are many BSD licensed drivers in the GPL licensed Linux kernel.

If a piece of software is built on another piece of software, it doesn't matter if you're looking at source code or a binary.

The GPL makes this distinction. The GPL says if you distribute a binary from GPL sources you must release the sources as well. It does not however say that if you release sources you must also release binaries.

I can write the SFLC and pose a hypothetical situation that captures the gist of what we're talking about, and post the response here, if anyone is interested.

I suggest that you put together a question, post it here for comments and when there is some form of concensus pass the question on the the SFLC. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

Tom Tobin writes:

1) Is there any scenario where Y can be distributed under a non-GPL license (e.g., the BSD)?

2) If so, what would Y's author need to do (or *not* do)?

3) If Y must be released under the GPL under the above scenario, and someone subsequently wrote library Z, an API compatible replacement for X, and released it under the BSD license, would Y's author now be permitted to release Y under the BSD?

I wonder: if *using* an API makes a work derived, wouldn't replicating it be equally problematic? (The question stands anyhow, since 'someone' might be the author of the original library, who is clearly not limited by his licensing...) -k -- If I haven't seen further, it is by standing in the footprints of giants

On Tue, Dec 8, 2009 at 6:10 PM, Erik de Castro Lopo wrote:

Tom Tobin wrote:

...

The background situation: X is a library distributed under the GPL.  Y is another library that uses that library and requires it in order to compile and function.

You probably also need to bring in application Z which uses library X via library Y, because library Y is not usable by itself.

I think this is implicit in calling something a library; are there any questions where it would come up?

...

1) Is there any scenario where Y can be distributed under a non-GPL license (e.g., the BSD)?

You need to make sure they know that your are talking about the 3 clause BSD license, the one the FSF calls the Modified BSD license.

Good point.

...

3) If Y must be released under the GPL under the above scenario, and someone subsequently wrote library Z, an API compatible replacement for X, and released it under the BSD license, would Y's author now be permitted to release Y under the BSD?

The author is always allowed to relicense their own work under whatever license they choose.

Well I think that's actually what we're wondering here — under what circumstances is Y's author permitted to choose his license at will?

For instance there are libraries released under the GPL which are also available under a commercial use license for use in closed source products. The requirement here is that the library is soley written by the person doing the dual licensing and/or all other contributors have assigned their rights.

But those libraries don't, in turn, depend on GPL'd libraries written by different authors. I think the answer to the "can Y's author choose the BSD3 for Y" question will also answer this for cases where there's a further, different-author GPL dependency involved.

Tom Tobin wrote:

I'm thinking something along these lines:

The background situation: X is a library distributed under the GPL. Y is another library that uses that library and requires it in order to compile and function.

1) Is there any scenario where Y can be distributed under a non-GPL license (e.g., the BSD)?

2) If so, what would Y's author need to do (or *not* do)?

3) If Y must be released under the GPL under the above scenario, and someone subsequently wrote library Z, an API compatible replacement for X, and released it under the BSD license, would Y's author now be permitted to release Y under the BSD?

(Feel free to add more questions, and/or suggest tweaks.)

Based on the discussion so far, I think you need to distinguish between distributing source and distributing binaries. For example: Background: X is a library distributed under GPL. Y is another library which calls external functions in the API of X. Assume X and Y have different authors. 1. Can the author of Y legally distribute the *source* of Y under a non-GPL licence (BSD3, Modified BSD, etc), assuming such source is distributed without any binaries, and is distributed separately from X? 2. etc. Question 1 covers the situation at hand, and keeps the initial line of questioning simple and specific.

On Tue, Dec 8, 2009 at 6:31 PM, Tom Tobin wrote:

Question 2 can be "If the answer to 1 is no, is there *any* circumstance under which the author of Y can distribute the source of Y under a non-GPL license?"

I'd like to get these questions out to the SFLC so we can satisfy our curiosity; at the moment, here's what I'd be asking: 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? 2) If the answer to 1 is "no", is there *any* circumstance under which the author of Y can distribute the source of Y under a non-GPL license? 3) If the answer to 1 is "yes", what specifically would trigger the redistribution of a work in this scenario under the GPL? Is it the distribution of X+Y *together* (whether in source or binary form)? 4) If the answer to 1 is "yes", does this mean that a "BSD-licensed" library does not necessarily mean that closed-source software can be distributed which is based upon such a library (if it so happens that the library in turn depends on a copylefted library)? By the way, apologies to the author of Hakyll — I'm sure this isn't what you had in mind when you announced your library! I'm just hoping that we can figure out what our obligations are based upon the GPL, since I'm not so sure myself anymore.

2009/12/12 Stephen Tetley :

2009/12/12 Tom Tobin :

...

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?

Hello Tom

If the answer to this isn't yes, I'll buy a hat and eat it...

As source, Y (the BSD3 library) can surely be distributed as the author sees fit. The author could even distribute Y as source under a non-GPL _compatible_ license. This would hamper the utility Y, neither the author of Y nor anyone else could distribute an executable that agglomerates X and Y, but I honestly can't see how the existence of library X (GPL) can make it illegal to distribute other distinct works (my emphasis on _distinct_).

Now, author X could choose to sue author Y for copyright infringement. If such a case happened it might set the precedent for what a 'derived work' is - vis-a-vis GPL and libraries - from my cursory web searching, such a case hasn't happened. From the 'Linking and derived works' bit in the Wikipedia page, the judgement on copyright law notes "the infringing work must incorporate a portion of the copyrighted work in some form", surely the judges would have to decide whether or not calling API's and reusing datatypes is incorporation.

http://en.wikipedia.org/wiki/GNU_General_Public_License

...

3) If the answer to 1 is "yes", what specifically would trigger the redistribution of a work in this scenario under the GPL? Is it the distribution of X+Y *together* (whether in source or binary form)?

Don't know.

In the case of Hakyll and other packages on Hackage, the distribution is in source form. If someone wanted to repackage the code from Hackage as a binary distro they would have different obligations.

...

4) If the answer to 1 is "yes", does this mean that a "BSD-licensed" library does not necessarily mean that closed-source software can be distributed which is based upon such a library (if it so happens that the library in turn depends on a copylefted library)?

The 'closed-source' software here still depends on a 'copyleft' library - if the library is GPL then the terms of the GPL apply. Whether there is an intermediary BSD licensed library is surely immaterial.

I'd like to point out a possible situation, that makes the questions even more interesting. Say the author of Y (the BSD licensed code) is used to install its code, Y, along of its requisite X (under GPL) to customer locations. Note that Y and X are not (re)distributed in compiled form. In fact, the client could have the internal resource to install and configure Y and its requisite himself (if Y was made available to him). Is it ok in regard of the GPL ? Cheers, Thu

Hello Stephen, Saturday, December 12, 2009, 3:32:09 PM, you wrote:

the GPL would apply. Distribution being the key point, as at that your mileage may vary, etcetera. Similar the limits on 'client' would need some definition vis-a-vis distribution, one person would surely be fine, extrapolating up to multi-national companies I'm not sure.

afaik, it's still ok while inside one company -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Tom Tobin writes:

...

...

...

...

Your contributions could still be licensed under a different license (e.g. BSD), as long as the licensing doesn't prevent somebody else to pick it up and relicense it under GPL.

...

...

...

Right. So hakyll is absolutely fine with a BSD3 license, AFAICS.

...

...

Seriously, no, this is *totally* wrong reading of the GPL, probably fostered by a misunderstanding of the term "GPL-compatible license". GPL-compatible means the compatibly-licensed work can be incorporated into the GPL'd work

You can incorporate all you want, as long as you don't distribute the result.

...

...

If you are forming a derivative work based on the GPL'd work, and thus you have to release that derivative work under the GPL.

Yes, but I understood the situation to be that Hakyll is using Pandoc as a library, accessing its API. If this makes Hakyll a derivative of Pandoc, then anything running on your Linux box must be GPL, as it uses system calls (the API of the GPL'ed kernel).

...

available under the GPL (including the hakyll source).  Since the hakyll package is released under BSD3, this would be allowed (AIUI, IANAL).

IANAL either, but my understanding is that judges take a very dim view of attempts like this to evade the requirements of a license.

I don't consider it an attempt to evade requirements. For all I know, the author of Hakyll wrote it using public documentation, and never even had Pandoc in his possession. Why should he be bound by its copyright license? I've used public specs to write software to parse files generated by proprietary software. My code is GPL, and I think it would be incredibly unreasonable to force me to abide by whatever license the generating software uses.

If a piece of software is built on another piece of software, it doesn't matter if you're looking at source code or a binary.

The question is if using an API is sufficient to make it a derived work.

I can write the SFLC and pose a hypothetical situation that captures the gist of what we're talking about, and post the response here, if anyone is interested.

I'm curious, at least. If nobody else wants it, feel free to email me privately. -k -- If I haven't seen further, it is by standing in the footprints of giants

On Tue, Dec 8, 2009 at 4:38 PM, Robert Greayer wrote:

Not to belabor the point (I hope), but consider the following situation -- if the current version of Pandoc, 1.2.1, were released under BSD3, not GPL, it would be obvious that the current version of hakyll could be released as BSD3 as well.  After said hakyll release, the Pandoc maintainer would be perfectly within his rights to release an API compatible 1.2.2 version of Pandoc, this time licensed under the GPL.  People installing hakyll with cabal might now be building a version of hakyll containing both GPL and BSD3 code.  This is not under either author's control, and is perfectly allowable.  If the person downloading chooses to redistribute the hakyll executable he's built, he must be aware of and comply with his responsibilities under the GPL, but those would be his responsibilities, not those of the original author of hakyll.  (AIUI -- IANAL).

The compatible-API issue is very murky — it does indeed seem weird that creating an API-compatible BSD'd library would magically "release" users. I've seen other discussions regarding this, and about the sanest conclusion I've drawn is "ask your lawyer". :-/

On Tue, Dec 8, 2009 at 5:15 PM, Gregory Crosswhite wrote:

On Tue, Dec 8, 2009 at 4:46 PM, Tom Tobin wrote:

The crux here is that the source code of hakyll, released on hackage, is not a derivative of Pandoc (it contains, as far as I understand it, no Pandoc source code).  A compiled executable *is* a derivative of Pandoc, so anyone who *distributes* a compiled executable would need to make *all* the source available under the GPL (including the hakyll source).  Since the hakyll package is released under BSD3, this would be allowed (AIUI, IANAL).

Hm, I didn't write that; I think your quoting is off. ^_^

On Tue, Dec 8, 2009 at 7:38 PM, Ivan Lazar Miljenovic < ivan.miljenovic@gmail.com> wrote:

Apologies, Robert, for you getting this twice: I forgot to CC the list as well.

...

The crux here is that the source code of hakyll, released on hackage, is not a derivative of Pandoc (it contains, as far as I understand it, no Pandoc source code). A compiled executable *is* a derivative of Pandoc, so anyone who *distributes* a compiled executable would need to make *all* the

Robert Greayer writes: source

...

available under the GPL (including the hakyll source). Since the hakyll package is released under BSD3, this would be allowed (AIUI, IANAL).

That is my understanding as well:

http://www.fsf.org/licensing/licenses/gpl-faq.html#IfLibraryIsGPL

,---- | If a library is released under the GPL (not the LGPL), does that mean | that any program which uses it has to be under the GPL or a | GPL-compatible license? | | Yes, because the program as it is actually run includes the library. `----

Thus, it means your program using Pandoc can be BSD3; but it can never be used in a proprietary program.

There's another FAQ on GNU site that, I think, addresses the Pandoc/Hakyll situation directly: http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL "You have a GPL'ed program that I'd like to link with my code to build a proprietary program. Does the fact that I link with your program mean I have to GPL my program? Not exactly. It means you must release your program under a license compatible with the GPL (more precisely, compatible with one or more GPL versions accepted by all the rest of the code in the combination that you link). The combination itself is then available under those GPL versions. "

On Tue, Dec 8, 2009 at 11:19 PM, Tom Tobin wrote:

 In temporary lieu of posing questions explicitly to the SFLC, I dug up a copy of _Intellectual Property and Open Source_ by Foobar

::facepalm:: I wrote "Foobar" as a placeholder as I was typing, and never replaced it. The author's name is Van Lindberg.

On Wed, Dec 9, 2009 at 4:59 AM, Ketil Malde wrote:

Tom Tobin writes:

...

If it turns out that Hakyll *is* okay to be BSD3 licensed so long as neither any binary nor the GPL'd work's source is distributed under non-GPL terms, well ... I'll say that the meaning of "BSD licensed" will have become much less reliable, since it means you actually have to trace the genealogy of the libraries you use *all* the way back in order to understand the situation for certain.

How so?  To me it's the exact converse: if the author of Hakyll may *not* distribute his work under the BSD license, just because it is intended to be linked with some GPL code, this complicates issues tremendously.

For instance, it would mean that businesses which may be writing proprietary software can't assume they can freely use a liberally licensed (e.g., BSD3) library — which would *completely* go against the prevailing understanding of liberally licensed software. Tainting your software with a GPL dependency without realizing it is a terrifying prospect (and certainly one of the questions I'd now like to pose to the SFLC).