GPL licensing prevents BSD applications from using Pandoc

[GoogleCodeExporter]

The BSD license is probably the most popular license for Haskell
applications and libraries.  A primary reason for this is that GHC has not
historically supported dynamic linking, and the legality of static linking
is a bit murky in the GPL and LGPL.

In xmonad, we recently decided to generate our manpage using the pandoc
library rather than the assortment of regular expressions that we currently
use.  However, xmonad is licensed under BSD meaning we'd have to relicense
our manpage script to GPL.  We would also need to be very careful about how
we use the code in xmonad, as it is not possible to relicense all of xmonad.

Has a linking exception ever been considered for Pandoc [1]?  This would
allow BSD Haskell applications and libraries to use Pandoc without fear.

[1] http://en.wikipedia.org/wiki/GPL_linking_exception

Original issue reported on code.google.com by SpencerJ...@gmail.com on 29 Oct 2009 at 11:41

[GoogleCodeExporter]

From a quick look through this mirror of hackage, it seems that there already 
exist
several packages that violate pandoc's license.

http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/pandoc-1.2.
1

Original comment by SpencerJ...@gmail.com on 29 Oct 2009 at 11:43

[GoogleCodeExporter]

Thanks for bringing this up.  I've been thinking about it, but I'm not very
enthusiastic at this point about making the change.  One reason to use GPL is to
ensure that if someone uses pandoc as the basis for a new, improved, document
converter (perhaps with additional output or input formats), the code gets
contributed back to the community (and back to pandoc).  I worry that the static
linking exception would undermine this goal.  What's to stop someone from 
writing
five additional writer modules and a replacement for pandoc.hs, linking in the 
rest
of pandoc statically, and distributing the result as a new improved pandoc, 
without
contributing the code for the new writers back to the community?  Nothing, as 
far as
I can see.

I don't yet see why pandoc's GPL license should pose a problem for you at 
xmonad.
From what I understand, you're using a script that uses pandoc as part of the 
build
process.  Many projects with BSD licenses use GNU Make, which is GPL licensed. 
Why
should it be any more problematic for you to use pandoc, or a custom script that
links in pandoc, and that is licensed under GPL?

Note also that pandoc has two dependencies that are GPL licensed: zip-archive 
and
(optionally) highlighting-kate.  I'd be willing to change the license of 
zip-archive
to BSD3...I think that would make sense, actually.  But I don't know if I can 
change
the license on highlighting-kate.  It derives the highlighters from Kate XML 
syntax
descriptions, which have a variety of licenses -- but some, if I recall, are 
GPL.  As
I understand the license, if highlighting-kate is derived from even one 
GPL-licensed
syntax description, it must have GPL license.

Original comment by fiddloso...@gmail.com on 1 Nov 2009 at 12:52

[GoogleCodeExporter]

PS.  The title of this bug report could just as easily be "BSD licensing 
prevents BSD
applications from using Pandoc."  :)

Original comment by fiddloso...@gmail.com on 1 Nov 2009 at 12:53

• Added labels: Type-Other
• Removed labels: Type-Defect

[GoogleCodeExporter]

What about LGPL?

Original comment by LightGua...@gmail.com on 12 May 2010 at 9:50

[GoogleCodeExporter]

My understanding is that the difference between LGPL and GPL is insignificant 
as long
as the libraries are being linked statically, which is still the norm for 
Haskell.
(That may change soon, though.)

Original comment by fiddloso...@gmail.com on 13 May 2010 at 1:26

[GoogleCodeExporter]

Re: Comment 2.

Conversely I can argue that it's easy to work around use of the GPL in any 
library by writing GPL'd executable wrapper around the library and then calling 
it from any non-GPL code.  As far as pandoc goes, you've already done that for 
us.  It seems to me that this points out a subtle problem with your wording.  
You say, "One reason to use GPL is to ensure that if someone uses pandoc as the 
basis for a new, improved, document converter...".  I think the more correct 
idea is "One reason to use GPL is to ensure that if someone uses the pandoc 
*code* as the basis...".  Code is different from an API, and when you release a 
library (open-source or otherwise) the API is the equivalent of a UI for 
standalone programs.  Adding the linking exception acknowledges that the API is 
public, and it's use of the underlying code that you want people to contribute 
back to the community.

At any rate, you significantly reduce the impact of your code by using the GPL 
in a community that has decided on BSD as its defacto license.

Original comment by mightyb...@gmail.com on 15 Dec 2010 at 5:04

[GoogleCodeExporter]

Regarding #2,

I release all my code as BSD3. Here is my thoughts on the concerns.

The core argument is:

 "a company might build a closed-source application based on my code and not release the code back, but they can not do that if it is GPL."

Let's say a company does build a closed-source app using by BSD3 code. How am I 
worse off than before? I'm not really. But by not releasing their changes back, 
they are causing more work for themselves. They are now responsible for merging 
a bunch of upstream changes into their code base. And they don't get to 
interact with the community and see the changes they want made upstream. So, 
really they lose.

The next question is, "Are there companies that would use my BSD3 code and not 
send patches, but would still consider using my code if it was GPL?"

I figure any company that is going to send me patches because it is GPL, will 
also send them if it is BSD3 (because it is easier than trying to maintain a 
fork). If sending patches is an issue then GPL will affect whether or not they 
use my code at all. But making it GPL does not seem likely to result in 
receiving more patches than I would otherwise. I would instead expect fewer, 
since my potential commercial user base will be smaller.

And the final question is, "Will using the GPL result is less patches to my 
code?"

Since the GPL is not compatible with many popular licenses like BSD3, it means 
that many BSD3 projects will not be able to use my code. Since BSD3 using 
developers are likely to contribute patches, I would be missing out on patches 
from them.

So, in summary, my feeling is that using GPL is not going to increase the 
number of commercial developers sending me patches, but is going to reduce the 
number of open-source developers that will.

But if you are set on GPL, that is fine with me. I currently just shell out to 
markdown instead of using pandoc. It is far less powerful and is written in 
perl, but is BSD3 licensed. At some point in time I will probably implement a 
BSD licensed markdown parser. Though I would prefer not to -- as you know, 
parsing markdown is a pain.

Original comment by jashaw...@gmail.com on 15 Dec 2010 at 5:54

[GoogleCodeExporter]

Thank you for your input.  I continue to consider this issue, but I'm not 
decided.  It's not just my decision, either. Some modules are partly 
copyrighted by others.  In addition, there is the issue mentioned above about 
highlighting-kate.

I should point out that there is little reason for you to "shell out to 
markdown instead of using pandoc."  You might as well shell out to pandoc, 
which you could distribute, together with its source code.  This way of using 
pandoc would not require you to GPL license your code.  Also, you might try my 
peg-markdown, which is dual MIT and GPL licensed, and much better than 
Markdown.pl.

Original comment by fiddloso...@gmail.com on 15 Dec 2010 at 6:16

[GoogleCodeExporter]

I do not wish to express any opinion on the issue, however I would like to 
correct a couple misconceptions:

In comment #3 above:

> My understanding is that the difference between LGPL and GPL is insignificant 
as long as the libraries are being linked statically.

This is not the case. It is possible to ship proprietary applications using 
LGPL components and static linking. In this case one also has to provide (or 
promise to provide) the application binary in a "relinkable" form, e.g. as a 
big main.o file.

In comment #7 above:

> Since the GPL is not compatible with many popular licenses like BSD3

This is not correct. It is entirely possible to have a program where the 
distributor has to comply with both GPL and BSD licenses, and it is possible to 
simultaneously comply with both.

Perhaps what the commentator meant was that if you expect the *set* of licenses 
that a distributor must comply with to be the set [BSD], then of course [BSD, 
AnythingElse] is not compatible with the upper bounding set [BSD]. This 
property is of course not unique to the GPL, it applies to anything other than 
the BSD.

Original comment by duncan.c...@googlemail.com on 15 Dec 2010 at 6:45

[GoogleCodeExporter]

FWIW, this community member hasn't decided on BSD as my defacto license, and is 
glad that pandoc's default license is a strong one that provides maximum 
protection for the project and its creator against patent trolls, exploitation 
and so on. Perhaps license exceptions for certain projects or classes of 
project are also a good idea, I'm exploring this myself.

Original comment by simon@joyful.com on 15 Dec 2010 at 7:00

[GoogleCodeExporter]

@jashaw251
Don't rewrite a lot of code, just use GPL license !
Your FUD about GNU GPL is so dated... Oh yes it's true, Intel, IBM, HP and so, 
are so afraid by the GPL that Linux is a dead kernel.
And what about BSD/OS ??

Original comment by fgalla...@gmail.com on 6 Jan 2011 at 2:22

[GoogleCodeExporter]

It's not FUD if its the truth; a large number of companies outright ban GPL 
programs because of its overly-infectious nature. That's not out of date 
either, I personally know plenty of people who work for companies *right now* 
that are banned from GPL-software usage because of concerns from Legal.

As for your jab at BSD OS', they're doing just fine. The BSDs are alive and 
kicking. Rackspace is adding support for FreeBSD this year in fact.

Original comment by joshua.c...@gmail.com on 28 Jun 2012 at 5:51

[GoogleCodeExporter]

GPL instead of BSD or just GPL with a linking exception is preventing me from 
using Pandoc, which is a shame, because it's one of my favorite libraries.

Linux is a good example of GPL working, but it's also not a library. Users 
aren't subject to the redistribution requirements when they do things on Linux, 
only if they modify it. GPL prevents a lot of companies from using libraries 
like Pandoc at all, even if they intend to release any modifications to the 
source code.

The best I can do at the moment is to spawn pandoc as a process instead of 
linking against the library, which seems really, really silly.

Original comment by patr...@patrickmn.com on 21 Dec 2013 at 1:58