Clojure/EPL and the GPL

[Tassilo Horn]

Hi all,

I have a licensing question. Am I allowed to include clojure.jar in a
GPL project?

On the net I've found out that the EPL is not GPL compliant, and there's
an explicit statement by the FSF that it's not possible to include GPL
code inside an EPL licensed project, or to create an EPL licensed
derived work from GPL works. But how about the other way round?

The reason is that we are thinking about (re)writing some components of
our GPL java project in clojure. Some of them might be core components,
and so we would like to bundle the clojure.jar with the project.

Bye,
Tassilo

[Matthias Benkard]

On 28 Aug., 13:42, Tassilo Horn <tass...@member.fsf.org> wrote:
> I have a licensing question.  Am I allowed to include clojure.jar in a
> GPL project?

IANAL, but if I understand the GPL correctly, it prohibits you from
distributing a GPL-covered programme that is based on Clojure, because
it would need to be linked to the EPL'd Clojure library code and so
would make the combination have to be distributed under the GPL, which
is impossible.

> The reason is that we are thinking about (re)writing some components of
> our GPL java project in clojure.  Some of them might be core components,
> and so we would like to bundle the clojure.jar with the project.

Well, if it's _your_ project, obviously no one can stop you from
violating your own license. Nobody else will be able to redistribute
your work, however.

What you can do to improve the situation in this case is to add an
exception to the license. See http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLIncompatibleLibs
for details.

If you don't own all of the GPL'd code, I think you're out of luck,
though.

Bye,
Matthias

[Tassilo Horn]

Matthias Benkard <mulki...@gmail.com> writes:

Hi Matthias,

> On 28 Aug., 13:42, Tassilo Horn <tass...@member.fsf.org> wrote:
>> I have a licensing question. Am I allowed to include clojure.jar in a
>> GPL project?
>
> IANAL, but if I understand the GPL correctly, it prohibits you from
> distributing a GPL-covered programme that is based on Clojure, because
> it would need to be linked to the EPL'd Clojure library code and so
> would make the combination have to be distributed under the GPL, which
> is impossible.

Yes, that's my impression, too. Does it make a difference not to
distribute the clojure.jar with the GPL project, but to add "you have to
dowload clojure.jar and place it in the lib/ dir" to the README?

> What you can do to improve the situation in this case is to add an
> exception to the license. See
> http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLIncompatibleLibs
> for details.

That looks practical.

> If you don't own all of the GPL'd code, I think you're out of luck,
> though.

Well, the exception would only to be added to the code that requires
clojure. IMHO, this is only the code written in clojure itself, and
that would all be written from scratch. So here the copyright holders
are available.

Bye,
Tassilo

[Daniel Renfer]

perhaps this link in the FAQ for the EPL will clear things up.

http://www.eclipse.org/legal/eplfaq.php#USEINANOTHER

[Meikel Brandmeyer]

Hi,

Am 29.08.2009 um 00:58 schrieb Daniel Renfer:

> perhaps this link in the FAQ for the EPL will clear things up.
>
> http://www.eclipse.org/legal/eplfaq.php#USEINANOTHER

Wow! All but one of my Clojure projects are illegal! (They are all MIT
licensed...)

But I hope, that this link doesn't apply. I barely know the situation
in Germany. Let alone somewhere else in the world. For example in
Germany:
* public domain *meeep* you can't give up your copyright (in
particular you can't sell it to a company)
* no warranty *meeep* not here, you let it out in the wild, you can be
held liable for it in certain situations, especially distributors
(read: SuSE) should be very careful [1]

But IANAL. so, how do I have interpret the contents of the FAQ link?
Does this refer to eg. ripping out Clojure's STM, modifying it and
using it in another program? Or does this refer to use an unmodified
Clojure as a library?

Sincerely
Meikel

[1]: http://www.ifross.de/ifross_html/art3.html

[Laurent PETIT]

Meikel, the situation is certainly not as bad as you think.

What the "USEINANOTHER" url link states (as far as I understand) is for people for take the source coce, and RELICENSE it, changing the header and pretending that from the fork point it can be handled by another license. This indeed seems like the violation of the copyright where you would then act as the original author which is the sole person allowed to change the license (and I think it is true for almost any license that includes a copyright, not just for the EPL).

So when you just use clojure as a lib to which you link code, there's no problem (as far as the EPL is concerned, maybe its' a problem for the GPL, that I don't know for sure, but it seems it is).

But maybe I'm wrong, and it is not possible to say that different parts of a project can have different licenses, ...

HT(a little bit)H,

--
Laurent

2009/8/29 Meikel Brandmeyer <m...@kotka.de>

[Tassilo Horn]

Meikel Brandmeyer <m...@kotka.de> writes:

Hi!

>> perhaps this link in the FAQ for the EPL will clear things up.
>>
>> http://www.eclipse.org/legal/eplfaq.php#USEINANOTHER
>
> Wow! All but one of my Clojure projects are illegal! (They are all MIT
> licensed...)

Yep, but I think this doesn't apply. We wouldn't include clojure's
source code, only the binary jar file, as it's a prerequisite for
compiling the project.

In the meantime, I got a reply from the GNU licensing guys. It seems we
have to add a "special exception" to our GPL, which permits Clojure's
usage. And it doesn't matter if we include clojure or not, the usage is
what matters.

BTW: What's the reason that Clojure is licensed under the EPL and the
contrib stuff under CPL? Since clojure is not really eclipse-related, I
don't see a good rationale. IMHO, the Lesser GPL would be a much better
fit. Then you can use clojure also in commercial apps (I guess that was
the rationale behind EPL), but still you can use it in projects with any
other free-software license, may it be EPL, GPL or whatever...

Bye,
Tassilo

[Garth Sheldon-Coulson]

Another option Rich could consider for Clojure is the Mozilla tri-license (GPL/LGPL/MPL).

http://www-archive.mozilla.org/MPL/relicensing-faq.html

The tri-license would remove any lingering ambiguity about building GPLed Clojure projects.

But actually I believe the status quo is already quite permissive. The fact that Clojure is EPLed doesn't mean you can't write GPLed apps using it.* The EPL-GPL incompatibility bites you only when you try to GPL something that is a "derivative work" of Clojure. Doing so would be illegal in the status quo. Simple apps built with Clojure don't create a derivative work. Libraries probably don't either. Packaging Clojure with your application doesn't. A modification of Clojure itself does. Anything in between is iffy. The EPL FAQ covers most of this stuff. See:

http://www.eclipse.org/legal/eplfaq.php#GPLCOMPATIBLE
and
http://www.eclipse.org/legal/eplfaq.php#EXAMPLE

* All of this is my understanding only, not legal advice!

[Tassilo Horn]

Garth Sheldon-Coulson <ga...@mit.edu> writes:

Hi Garth,

> Another option Rich could consider for Clojure is the Mozilla
> tri-license (GPL/LGPL/MPL).
>
> http://www-archive.mozilla.org/MPL/relicensing-faq.html
>
> The tri-license would remove any lingering ambiguity about building
> GPLed Clojure projects.

What's the point of licensing something under GPL and LGPL? AFAIK, you
can always take a LGPL project and relicense it as GPL.

> But actually I believe the status quo is already quite permissive.
> The fact that Clojure is EPLed doesn't mean you can't write GPLed apps
> using it.* The EPL-GPL incompatibility bites you only when you try to
> GPL something that is a "derivative work" of Clojure.

Exactly, but everything that goes beyond communication over pipes /
fifos / command line invocation is derivative work according to the FSF.
So compiling the clojure sources we've written with the EPL clojure
compiler is ok, but since our code calls functions in clojure.core and
clojure.contrib it is derivative work, and thus the GPL incompatibility
bites us.

Well, but we can use the GPL with some special "we allow the usage of
clojure" exception. That's a bit of inconvenience, but at least we
don't have to exclude clojure only because of licensing issues.

Bye,
Tassilo

[Daniel]

On Sat, Aug 29, 2009 at 3:52 PM, Garth Sheldon-Coulson<ga...@mit.edu> wrote:
> Another option Rich could consider for Clojure is the Mozilla tri-license
> (GPL/LGPL/MPL).
>
> http://www-archive.mozilla.org/MPL/relicensing-faq.html
>
> The tri-license would remove any lingering ambiguity about building GPLed
> Clojure projects.
>
> But actually I believe the status quo is already quite permissive. The fact
> that Clojure is EPLed doesn't mean you can't write GPLed apps using it.* The
> EPL-GPL incompatibility bites you only when you try to GPL something that is
> a "derivative work" of Clojure. Doing so would be illegal in the status quo.
> Simple apps built with Clojure don't create a derivative work. Libraries
> probably don't either. Packaging Clojure with your application doesn't. A
> modification of Clojure itself does. Anything in between is iffy. The EPL
> FAQ covers most of this stuff. See:
>
> http://www.eclipse.org/legal/eplfaq.php#GPLCOMPATIBLE
> and
> http://www.eclipse.org/legal/eplfaq.php#EXAMPLE
>

I found this link also pretty interesting:

http://www.dwheeler.com/essays/floss-license-slide.html

Doesn't cover the EPL though.

(... but also IANAL, and can't/won't advise on legal matters).

Cheers,
Daniel

[rb]

On Aug 28, 4:18 pm, Matthias Benkard <mulkiat...@gmail.com> wrote:
> On 28 Aug., 13:42, Tassilo Horn <tass...@member.fsf.org> wrote:
>
> > I have a licensing question.  Am I allowed to include clojure.jar in a
> > GPL project?
>
> IANAL, but if I understand the GPL correctly, it prohibits you from
> distributing a GPL-covered programme that is based on Clojure, because
> it would need to be linked to the EPL'd Clojure library code and so
> would make the combination have to be distributed under the GPL, which
> is impossible.

Note that the GPL has this requirement only for derivative works!
In the case you write clojure code, clojure wouldn't be a derivative
work of your program and so clojure doesn't need to be licensed under
the GPL....
There are GPL software that run on windows and use windows libraries,
this doesn't require windows to be licensed under the GPL.....

If you want to modify clojure itself and redistribute it under the
GPL, then this link applies: http://www.eclipse.org/legal/eplfaq.php#USEINANOTHER

Raphaël

[John Harrop]

This is a problem.

The GPL is a very popular open source license. If a language does not permit developers to use the GPL, that language may be severely reducing the number of developers willing to adopt it.

It would be desirable for clojure.lang and clojure.core to use a modified license, something perhaps describable as "EPL with classpath exception", that expressly allows linking with GPL code (with classpath exception or similar to avoid violating the GPL instead).

Alternatively, dual-licensing lang and core under both the GPL and the EPL would be possible. Thanks to the contributor agreements, it wouldn't be necessary to track down all the contributors and get their individual permission for this, unless the agreements had reciprocal clauses limiting how Rich could relicense the code base. (I haven't seen them, so wouldn't know.)

Regardless, this problem bears thinking about and perhaps eventually doing something about.

[Rich Hickey]

This has been discussed as nauseam before:

http://groups.google.com/group/clojure/browse_frm/thread/6e99caafcf2bbedf/b5519cc219a5baeb

Nothing has changed, so let's give it a rest, please.

Rich

[Garth Sheldon-Coulson]

On Sat, Aug 29, 2009 at 12:00 PM, Rich Hickey <richh...@gmail.com> wrote:

This has been discussed as nauseam before:

Ah, so it has. Fair enough.

 

[John Harrop]

On Sat, Aug 29, 2009 at 12:00 PM, Rich Hickey <richh...@gmail.com> wrote:

This has been discussed as nauseam before:

http://groups.google.com/group/clojure/browse_frm/thread/6e99caafcf2bbedf/b5519cc219a5baeb

Nothing has changed, so let's give it a rest, please.

This may be a tempest in a tea-pot, at least where GPLv3 is concerned:

http://www.gnu.org/licenses/quick-guide-gplv3.html

"Both versions of the GPL require you to provide all the source necessary to build the software, including supporting libraries, compilation scripts, and so on. They also draw the line at System Libraries: you're not required to provide the source for certain core components of the operating system, such as the C library.

GPLv3 has adjusted the definition of System Library to include software that may not come directly with the operating system, but that all users of the software can reasonably be expected to have. For example, it now also includes the standard libraries of common programming languages such as Python and Ruby."

If the software is written in Clojure, then clojure.jar is something that "all users of the software can reasonably be expected to have", is it not? That means clojure.jar can be combined with GPLv3 code, if I'm not mistaken, since doing so apparently doesn't violate the GPLv3 or the EPL.

It even apparently allows combining with GPLv2 "or any later version" in that anyone redistributing it can (but must) use GPLv3 or later. :)

[Phil Hagelberg]

Tassilo Horn <tas...@member.fsf.org> writes:

>> But actually I believe the status quo is already quite permissive.
>> The fact that Clojure is EPLed doesn't mean you can't write GPLed apps
>> using it.* The EPL-GPL incompatibility bites you only when you try to
>> GPL something that is a "derivative work" of Clojure.
>
> Exactly, but everything that goes beyond communication over pipes /
> fifos / command line invocation is derivative work according to the FSF.

It should be noted that this definition is a minority opinion and is far
from legally proven. I doubt it would stand up if challenged.

-Phil

[Jan Rychter]

Tassilo Horn <tas...@member.fsf.org> writes:
[...]

> BTW: What's the reason that Clojure is licensed under the EPL and the
> contrib stuff under CPL? Since clojure is not really eclipse-related, I
> don't see a good rationale. IMHO, the Lesser GPL would be a much better
> fit. Then you can use clojure also in commercial apps (I guess that was
> the rationale behind EPL), but still you can use it in projects with any
> other free-software license, may it be EPL, GPL or whatever...

The GPL and LGPL are very restrictive licenses. While most people only
focus on the source code availability issue, the real show-stopper for
most commercial usage is the anti-patent clause that exists in both the
GPL and LGPL. This clause is a potential landmine, even though little
attention is paid to it. It exists in the same form in both the GPL and
LGPL.

--J.

[John Harrop]

Version 3 only, and according to http://news.cnet.com/FSF-rebuts-anti-GPL-3-claims/2100-7344_3-6119987.html

"The Linux programmers also expressed concern that a new patent provision in the draft GPL 3 poses risks to corporations' patent portfolios--a concern shared by Hewlett-Packard. The foundation said that interpretation is incorrect.

The GPL 3 "simply says that if someone has a patent covering XYZ, and distributes a GPL-covered program to do XYZ, he can't sue the program's subsequent users, redistributors and improvers for doing XYZ with their own versions of that program," the foundation said. "This has no effect on other patents which that program does not implement.""

Which means it only affects software patents (which have just been rendered invalid by in re Bilski anyway) and only to the extent of indemnifying users and distributors of a GPL-covered program from infringement claims arising from the use and distribution of that code. If they, say, infringed an HP patent on print head design making a laser printer they'd not be covered; HP could still sue.

It no more affects a company's important patents than any version affects a company's important copyrights. It just stops them extending same to the GPL'd code and making it effectively proprietary.