Open GoogleCodeExporter opened 9 years ago
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
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
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
What about LGPL?
Original comment by LightGua...@gmail.com
on 12 May 2010 at 9:50
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
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
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
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
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
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
@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
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
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
Original issue reported on code.google.com by
SpencerJ...@gmail.com
on 29 Oct 2009 at 11:41