Skip to main content

Copyleft, GPL, and Java

18 replies [Last post]
atripp
Offline
Joined: 2003-07-15

In a previous thread (http://forums.java.net/jive/thread.jspa?threadID=17590&tstart=0) the issue of copyleft came up. Specifically, it's a question of the meaning of "derived work" and "based on" in section 2 of the GPL.

For example, if I have:
class MyClass extends Object {
MyClass() {
System.out.println(hashCode());
}
}

I have a class that extends the GPL'ed Object class, and references some functionality in that class. Is this class considered "based on" Object, so my work is now considered a "derived work"?

Some possible answers:
a) No. You're simply using a standard API (as rolibad explains in that previous thread)
b) Yes. According to a strict reading of GPL section 2, your MyClass could be considered "based on " Object.
c) Maybe. All depends on how things might turn out in court.

Obviously, this is not just one example. Because everything extends Object, the answer here should apply to everything: Either your entire app (assuming it uses the standard API only) is covered by the copyleft, or its not.

Sun's lawyers must have looked into this issue. What do they say about it? Would all runtime apps be automatically covered by a GPL copyleft?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
atripp
Offline
Joined: 2003-07-15

vsizikov,
Thanks for the link! I agree that according to that explanation, the GPL certainly would be viral - a GPL class library would infect Java user programs.

dalibor,
As for the "Java is designed so that your app can run on any JVM", we've discussed that before. That may be a goal to some extent, but I don't think it's nearly perfect in practice. System.out.println(this.hashCode()) probably isn't identical across various VMs, and DateFormat.equals() probably isn't either.

WORA is about code running the same on various ports of a single JVM, not various alternative implementations of the specs.

I do consider my code to be dependant on Sun's JVM, I doubt that it works on Kaffee. java.lang.Object may (or may not) compile to exactly the same bytecode on both kaffee and javac, but I seriously doubt that's true for the entire class library.

Good luck on getting Classpath to compile so that "There is not a single bit in the resulting bytecode that would imply that the class is derived from a particular implementation".

Until then, I've just changed my view 180 degrees. Although, who knows? The GPL seems to be saying one thing, and David Turner seems to be saying another in that link.

robilad
Offline
Joined: 2004-05-05

@leouser: I think it may also help to if I pointed out that the current way of doing things (BCL/JRL/DLJ) is not going away, for all I can see. The open source licenses covering the JDK could simply be an additional licensing option, like SCSL, JDL and JIUL are, to cover additional situations that are not covered under the current licensing arrangements.

So, people who don't need or can't use Java under a particular open source license for one reason or another, would be able to use it under the same rules that worked so far for them, without having to care about the other 5-6 licensing options the JDK is available under today. I don't think that many Java developers know the effects of the JIUL, for example, and I don't think that they have to know them, as many other licensing options are available.

In my opinion, a large part of the angst about open source, licensing and all that is based on the assumption that the JDK licensing is going to switch to open source and the current licensing options removed. Afaict, from the way opening of the other crown jewel, Solaris, worked, that's not going to happen: a free version, and a non-free version will happilly coexist for different target groups, and you simply pick what works for you.

leouser
Offline
Joined: 2005-12-12

hmm, an interesting perspective. Ive been thinking about this under the assumption that this is going to be some "global shift" for the license and to date I haven't heard anything saying that the previous licensing is going to be dropped.

leouser

robilad
Offline
Joined: 2004-05-05

@leouser: Right. I think Simon's comment on http://www.businessreviewonline.com/os/archives/2006/08/open_source_jav.... makes that a bit clearer:

"There's a scale of benefit. At the one end it won't make the slightest bit of difference to some people," he admitted, noting that for the vast majority of Java users, the fact that the implementation ships with an open source license will be of little or no interest. "I actually think that the end user impact will actually be quite small."

And I tend to agree with that: the implementation already ships under half a dozen different licenses, and the impact on the end user (i.e. the average Java developer) is minimal.

Adding the DLJ as an option, for example, helped make Java deployment easier for many circumstances, but didn't matter to many Java developers who're happily using Java on Windows. Adding this new licensing option has not taken anything away from the rights of users of deveopers, and I don't see Sun doing that with an open source license for the JDK, either, whichever license they pick.

At least given their handling of the open source transition so far, I don't think the assumption that Sun would have an interest in dropping licensing choices that work well for their current ecosystem is very plausible, when they can simply extend them like they have done over the past years with the SCSL, JRL, JDL, JIUL, and the DLJ.

In that light, I'd see adding the GPL to the licensing options for the JDK as just another licensing choice for specific circumstances and target groups, in the same sense how the JIUL is not ultimately intresting for every end user.

atripp
Offline
Joined: 2003-07-15

Dalibor,

Have you spoken to a lawyer about this issue? I mean your explanation makes a lot of sense to me, but then IANAL, and you know how differently you and I can interpret the same words in a license. Is the explanation you gave just from informal conversations you've had, or is there maybe a FSF lawyer or something behind that interpretation?

It may all be a mute point if Sun doesn't choose a copyleft license, but I'd hate to have them choose the GPL and start a huge storm of uninformed blathering about the "viral" issue, when just a few sentences from a real lawyer or two (Sun, FSF, or other) could clear it up right now.

Thanks and have a good weekend,
Andy

robilad
Offline
Joined: 2004-05-05

Hi Andy,

I have spoken with David Turner about that issue at FISL 2005, who was FSF's GPL compliance engineer at the time. David was also involved in drafting of the GPLv3, and helped get some improvements into the GPLv3 drafts that came from our work in Kaffe & GNU Classpath projects.

At that time, Kaffe was heavily in the process of switching over its GPL licensed class library to GNU Classpath completely. That meant its class library would switch licenses from GPL to GPL+linking exception. So, while David followed my reasoning, he correctly pointed out that the switch to GNU Classpath with its more liberal license made such issues moot.

If Sun decided to go with the GPL, I have no doubt that Sun's legal staff would accompany the license with an FAQ that explains the exact effects of the license on their implementation. In particular, I think they'd want to make sure people understand that no derivative works of a particular implementation are created by writing or compiling code against the standard APIs. That approach has worked well when Sun published the JRE under the DLJ this spring, where potential misunderstandings were quickly dealt with in an extensive FAQ, thanks to webmink, tmarble, robogeek & others on Sun's side.

Don't take me wrong, though, I'm not arguing for a pure GPL licensing approach. I'm just saying that GPL's 'virality' wouldn't necessarily be an issue for most end users even if Sun went with the GPL. ;)

From my experience with both having a GPLd and a GPL+linking exception licensed class library in my VM over time, if Sun choses the GPL, I would suggest using an explicit exception construct like GNU Classpath does over using the pure GPL. Besides making a whole class of potential misunderstandings about the effects of the license disappear, it also makes it easier to combine the class library with GPL-incompatible libraries, something Sun may have a need for, as long as proprietary code remains inside the class library.

jwenting
Offline
Joined: 2003-12-02

" I'm just saying that GPL's 'virality' wouldn't necessarily be an issue for most end users even if Sun went with the GPL. "

It would be because your FAQ doesn't nullify the license clause which makes all code written against the standard library a derived work and therefore forces all Java code into the GPL.

That's the consequence of using the GPL, and the reason LGPL was invented in the first place (which is better but certainly not perfect).

atripp
Offline
Joined: 2003-07-15

...and, of course, the silence from Sun is deafening.

Here's a related article on the GPL: http://www.itmanagersjournal.com/article.pl?sid=06/08/21/1659203
In particular, see item 1 on virality.

jwenting
Offline
Joined: 2003-12-02

So? Anything compiled against the standard libraries is a derived work from the standard libraries under a strict interpretation and therefore would fall under the GPL.
That's the consequence of the way Java is constructed. If the standard library was not a set of Java classes but something like the VB runtime the problem might not arise to the degree it does with Java.

We're not talking about an image created by a GPL image editor here.

Remains the fact that any access to GPL code puts anything a programmer creates after that at risk of being called a derivative work by the zealots.

atripp
Offline
Joined: 2003-07-15

> So? Anything compiled against the standard libraries
> is a derived work from the standard libraries under a
> strict interpretation and therefore would fall under
> the GPL.

OK, I'm all ears, let's hear how that strict interpretation goes.

Specifically, how do you interpret this wording: "If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves" as meaning that by simply "extending Object", I am creating a "derived work"?

vsizikov
Offline
Joined: 2004-11-16

> OK, I'm all ears, let's hear how that strict
> interpretation goes.
>
> Specifically, how do you interpret this wording: "If
> identifiable sections of that work are not derived
> from the Program, and can be reasonably considered
> independent and separate works in themselves" as
> meaning that by simply "extending Object", I am
> creating a "derived work"?

How about this (right from FSF):
http://www.gnu.org/licenses/lgpl-java.html

More specifically:

1. "It has always been the FSF's position that dynamically linking applications to libraries creates a single work derived from both the library code and the application code. The GPL requires that all derivative works be licensed under the GPL, an effect which can be described as "hereditary." So, if an application links to a library licensed under the GPL, the application too must be licensed under the GPL."

2. "The typical arrangement for Java is that each library an application uses is distributed as a separate JAR (Java Archive) file. Applications use Java's "import" functionality to access classes from these libraries. When the application is compiled, function signatures are checked against the library, creating a link. The application is a then generally a derivative work of the library. So, the copyright holder for the library must authorize distribution of the work."

3. "Inheritance creates derivative works in the same way as traditional linking"

So, indeed, it looks lake the intent is clearly expressed, and GPL is viral.

robilad
Offline
Joined: 2004-05-05

You've apparently missed the word 'generally' in there.

In the general case, your work can not be reasonably considered independant and separable, since it needs the particular library it links to in order to work/be built/etc.

In the particular case of the core class library, that's not the case, by design. The whole point of Java is that you can take programs that run on one VM and run them unmodified on another in a different environment, as long as the programs use the standard class library. So each Java program that uses the standard class libraries is, reasonably an independent and separate work in itself from a particular implementation of those standard class libraries.

That holds trivially for the source code form of the program, and equally trivially for the bytecode form of the program. Compiling against a GPLd java.lang.Object implementation results in bit-for-bit, exactly the same class file as does compiling against a non-GPLd one, independent of the details of their implementations. There is not a single bit in the resulting bytecode that would imply that the class is derivative of a particular implementation of that standard, and as such be obliged to follow its licensing conditions.

vsizikov
Offline
Joined: 2004-11-16

> You've apparently missed the word 'generally' in
> there.

Dalibor, I understand what are you saying.

Still, I'm not sure that "the judge" would appreciate references to "the whole idea of Java" and Java design.

Another interesting issue - so, let's say there is an error in GPL'ed java implementation, somebody decided to add calculatePrime method right to the Object, and you've built your application against this, not testing against other java implementations. Suddenly, your entire code must be GPL.

Another possibility - an error in compiler that puts non-public-API references into your class files (something like sun.misc or, I don't know, org.gnu.*). Again, if we closely follow the quotes from my original message, and your clarifications, we should agree that this error exposes the whole application to GPL.

In a sense, it's kinda cool - if you use incompatible Java, your code is immediately in GPL! :) But I doubt many would appreciate that.

robilad
Offline
Joined: 2004-05-05

> Still, I'm not sure that "the judge" would appreciate
> references to "the whole idea of Java" and Java
> design.

Only Sun is able to enforce any interpretation of any license covering their code in the JDK, be it GPL, Apache license, or something else.

I'm not sure why one would assume Sun would attempt to enforce a contradictory interpretation of any license in court. The implied 'bait and switch' scenario is not warranted given Sun's behavior in the Java community over the past 10 years.

Given that you have to trust Sun to interpret their current licenses in a reasonable fashion when you use Java, I don't see what makes the GPL stand out as a particular attractor for that sort of speculation. A malicious copyright holder could take any free or non-free software license, even the Apache license, and claim that it doesn't say what it says, and haul you to court.

> Another interesting issue - so, let's say there is an
> error in GPL'ed java implementation, somebody decided
> to add calculatePrime method right to the Object, and
> you've built your application against this, not
> testing against other java implementations. Suddenly,
> your entire code must be GPL.

Your code doesn't become subject to the GPL by error. In the case of a mistake, you fix the error and everyone moves on.

There were different times when someone checked in something GPLd into various Apache CVS repositories, and it was subsequently fixed when that mistake was discovered, without the necessity to relicense the entire Apache code base under the GPL meanwhile.

> Another possibility - an error in compiler that puts
> non-public-API references into your class files
> (something like sun.misc or, I don't know,
> org.gnu.*). Again, if we closely follow the quotes
> from my original message, and your clarifications, we
> should agree that this error exposes the whole
> application to GPL.

As above, you don't catch the GPL by mistake, you fix the mistake, and move on.

Let's hypothetically say that your iPod has the Hofbräuhaus song on it, and when you connect it to your Windows XP box, due to a very obscure bug in Apple's firmware an even more obscure error in the Windows USB driver is triggered, that coincidentally ends up adding some GPL licensed code to your Java projects in Eclipse ... that wouldn't mean your code is now exposed to the GPL.

You clean up the damage, and that's it.

In a lot of respects, the GPL is not different from any other license out there. While it is certainly possible to dig in the rich mythology about the GPL and construct scary hypothetical scenarios, those scenarios in general rely on the assumption that Sun would overnight turn from reasonable stewards of Java into a malicious company bent on suing its users, and use some vagueness in the definition of 'derivative works', or something else in whichever license they chose to drag us to court.

The former is about as likely as Richard Stallman following Steven Ballmer as the CEO of Microsoft. The latter is an issue with *any* free or non-free software license, as the copyright laws don't draw a shiny bright line what constitutes a derivative work, and what doesn't in all possible cases. They effectively can't do such a thing, since new ways to create such works come up all the time. There is no such thing as an unambiguous software license, since the underlying laws themselves are not cast in stone.

So at the end of the day, if in doubt, it boils down to the copyright holder on the code you're using. Sun has over the past years shown no malicious behavior towards people using their open source software, that would justify such speculation, IMHO, and they publish a lot of code under the GPL, among other licenses.

vsizikov
Offline
Joined: 2004-11-16

> Only Sun is able to enforce any interpretation of any
> license covering their code in the JDK, be it GPL,
> Apache license, or something else.

Maybe, and only to some degree. If GPL states that source code must be available, it must be available no matter what is Sun's position on this.

> I'm not sure why one would assume Sun would attempt
> to enforce a contradictory interpretation of any
> license in court.

Oh, I had no intention to say that, sorry.
I'm just uncomfortable a bit with GPL and its "viral" behavior.

> Given that you have to trust Sun to interpret their
> current licenses in a reasonable fashion when you use
> Java, I don't see what makes the GPL stand out as a
> particular attractor for that sort of speculation.

Its "viral" nature. I don't mean viral in a bad sense, just emphasize its property when any derivative work suddenly required to be under the same license.

The problem with it, not only the fact itself which poses additional risks for those who would like to use GPL but
also the fact that I have to think hard about all these corner cases, license interpretations and worry.

Yes, most of the cases I listed are imaginary and in no way about Sun, just about GPL. :)

I'd prefer to have less risks and to think less about these issues. :)

That's why Apache license or CDDL license look like better choice to me.

I mostly agree with you that even GPL with explicit linking exception is good enough, but still, the risks are higher.

leouser
Offline
Joined: 2005-12-12

If Java is Open source with the GPL this issue better be clarified and with examples showing of what happens. If people can't seem to come to a common agreement about this its going to turn off developers who just want to understand.

leouser

dgilbert
Offline
Joined: 2004-05-06

The GPL has worked well for Linux, and I think it can work well for the Java platform too. One of the nice features of the GPL is that it discourages "bad" forking, because forks must be done out in the open (reducing the economic incentives of proprietary forks), and licensing barriers to recombining forked code are eliminated. Sun would have to make a lot of clarifying statements to allay people's GPL fears, but that's something they can handle. I'd be surprised if the GPL is not one of the top-ranked licences on Sun's list right now.

jwenting
Offline
Joined: 2003-12-02

GPL will be a disaster, as it causes every single Java class created to be forced to use GPL as well, which will force almost everyone to abandon Java.
Of course that is just what the GPL advocates want, because they don't like Java and would all of us writing in Perl or some other scripting language.