Perils of GPL'ed java

[Jim Yingst]

[EFH]: Duke is a penguin?

I believe they prefer the term "Native Antarctican".

[Gregg Bolinger]

Duke could also be a tear drop. You know, like when the first time all the Java creaters wrote their first java program, deployed it to Linux, then deployed the same unaltered code to windows, and it ran without a hitch, everyone shed a tear of joy.

[Paul Clapham]

Originally posted by Jim Yingst:
[EFH]: Duke is a penguin?

I believe they prefer the term "Native Antarctican".

This is simply Antarctic species imperialism and completely disrespects the rights of penguins living in Africa and South America and Australia and New Zealand.

[Abhinav Srivastava]

Q: 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?
A: Yes, because the program as it is actually run includes the library.
*Does it mean the all java programs in the world would have to be GPL'ed before they can be distributed? This is
of course assuming the Java class libraries are open sourced. If only JVM and Compiler is opened, this doesn't apply.

[Jeroen T Wenting]

Originally posted by Marcus Green:
No I am referring to the revenue generated by Java applications by 3rd parties. Are you suggesting that Sun is to undermine the entire commercial Java market, i.e. require that every Java application be free under the GPL to save the cost of salaries of the Java developers.

So that the Oracle Java tools must be GPL, including the JVM at the heart of the database system, Oracle JDeveloper, the Borland Developer Tools, the WebLogic and WebSphere tools, the Sybase tools, etc etc. Are we going to be able to get the source code and redistribute those tools under the terms of the GPL in the near future?.

I'm suggesting Sun doesn't care one way or another about third parties as long as those 3rd parties don't generate income for Sun.
They're not in there for altruism after all.

And if the GPL starts infecting the standard API soon we will indeed start to see people demanding that everything written in Java is released under GPL because it is all a derived work from Object.java which will be GPL.
Commercial partners it seems may be offered a chance to BUY a JDK/JRE released under another license, making the scheme complete (in a similar fashion to mySQL demanding payment from people who don't want to release every bit of code talking to it under GPL).

[Ernest Friedman-Hill]

Jeroen:

Why are you ignoring theclasspath exception, the provision, invented for the GNU Classpath project but also being adopted by Sun? It's an explicit exception to the GPL's provisions which states that if you run your program using an unmodified version of the licensed code (i.e., the GPL'd Java APIs) then your code does not have to be open-sourced.

The "classpath exception" is the key to understanding this whole thing, but even though it's been mentioned already in this thread, you seem to be willfully ignoring its existence.

[Jim Yingst]

"Jack" (Abhinav), where are you quoting from? The license that they're releasing Java stuff under includes the classpath exception. It sounds like the thing you're quoting from does not include the classpath exception - in which case, it doesn't apply here.

While we're at it, it looks like you need to check out our display name policy and then edit your display name to something not obviously fictitious. Thank you.

[Jim Yingst]

[Paul Clapham]: This is simply Antarctic species imperialism and completely disrespects the rights of penguins living in Africa and South America and Australia and New Zealand.

Good point. I'm pretty sure Duke lives in Silicon Valley nowadays, so the proper term here would be Antarctic-American.

[Tim LeMaster]

From the Java open source FAQ: Sun Java Open Source FAQ

Q:
Will Sun continue distributing its commercial implementation of the JDK?
A:
Yes. For people who want the benefits of commercial support, and predictability, they may choose to use Sun's commercial distribution of the JDK or JRE. The free commercial implementation of the JDK may be found at http://java.sun.com/javase/downloads/index.jsp. Similarly, Sun's free JRE may be downloaded from http://java.com. To learn more about development and deployment support options, visit http://sun.com/javasupport.

So make their "EVIL" scheme complete and continue downloading the JDK from free from sun.com and ignore all the GPLness.

[Abhishek Misra]

It seems like what we needed was a LGPL rather then a GPL to make java really the defacto choice and compete. If it would have been LGPL'ed we could have stripped out stuff we didn't need from JRE and made our product compact. It doesn't make sense for many to use java for downloadable apps as JRE is freaking insanely huge.

[Abhinav Srivastava]

Apart from the Classpath Exception, here is a snippet from Sun FAQ :

Q:
Will Sun continue to offer the JDK and Java ME source code under a commercial license, along with GPL v2?
A:
Yes. Indeed, some of Sun's existing licensees will continue to prefer a commercial license over an open-source license for a variety of reasons.
Back to top

Q:
Why will Sun continue to offer the JDK and Java ME sources under a commercial license?
A:
Sun has commercial obligations towards its licensees which of course we will continue to satisfy after the code base is open sourced. Sun will continue to work with licensees who want to distribute derivatives of Sun's implementations without the requirement in the GPL to contribute modifications back to the community. Sun's commercial Java technology distribution licenses require licensees to distribute only compatible implementations as determined by the TCK for relevant Java technologies.

Also, its Sun's implementation of Java which is GPL'ed, theoritcally IBM/BEA/Oracle... can have their own non-open source Java.

JY: It took you years!
[ November 16, 2006: Message edited by: Jack Ryan ]

[Phil Rhodes]

You'd have to be nuts to think that IBM is going to intentionally release an incompatible Java fork. And if they do, they can't call it Java, so the net effect would be the same as if IBM rolled out a brand new language tomorrow and had to start trying to get people to adopt it. Basically, it would be like MS rolling out C#.

But IBM is not in the business - for the most part - of selling proprietary programming languages and tools. They make money off hardware, middleware, services, integration and consulting. They're part of a huge ecosystem built up around Java... and you want me to believe they would intentionally try to destroy that ecosystem? No freaking way...

[Jim Yingst]

[Abhinav]: JY: It took you years!

Ah, I see by your edit that you belatedly figured out that EFH and I are not the same person. Congratulations. I guess this means we really shouldn't allow any further delays then. So I've taken the liberty of helping you along a bit. Feel free to choose a more appropriate last name; I just picked one that sounded fairly common.

Since you didn't answer my other question, I will assume you now agree that the Q/A you quoted earlier is not relevant, is that right?

[Abhinav Srivastava]

Originally posted by Jim Yingst:
Since you didn't answer my other question, I will assume you now agree that the Q/A you quoted earlier is not relevant, is that right?

That QA was from GPL faq, apparently that clause is overridden by Classpath Exp.

And about misquoting your name.. that was not intentional... just not good with names! Also, on a side note, if it takes years for you to know... how can it be 'obviously' fictional!

[Abhinav Srivastava]

Originally posted by Phil Rhodes:
You'd have to be nuts to think that IBM is going to intentionally release an incompatible Java fork.

It is clear that the Java Spec is not GPLed, it would still be controlled by JCP so forking should not be an issue. Even today, BEA releases its own JVM which works with Sun's java runtime. I am not sure what else is different in JRockit SDK.

So ultimately what is really different in open-source java world?
It benefits the Big Corps (the way Eclipse worked out for IBM). Do you think an open source version would survive unless promoted by the Big 3/4/-5..

[Jim Yingst]

[Abhinav]: And about misquoting your name.. that was not intentional... just not good with names!

No problem; I was just irritable there.

[Abhinav]: Also, on a side note, if it takes years for you to know... how can it be 'obviously' fictional!

Well, "obviously fictional" is usually a subjective call anyway... some things are more obvious after you notice them than before. But consider - how do you suppose I knew your name was Abhinav? That's what took you from "maybe fictional" to "obviously fictional".
[ November 16, 2006: Message edited by: Jim Yingst ]

[Phil Rhodes]

Originally posted by Abhinav Srivastava:



So ultimately what is really different in open-source java world?
It benefits the Big Corps (the way Eclipse worked out for IBM). Do you think an open source version would survive unless promoted by the Big 3/4/-5..

1. Linux / BSD distros can now ship a "real" JDK with their OS's.
2. Java loses something of it's "red headed stepchild" status in the F/OSS world.
3. possibly faster bug-fixes if the GPL license encourages more
F/OSS hacker types to get involved with Java

For probably 99.9% of Java developers this GPL'ing means absolutely nothing.

[Jeroen T Wenting]

Originally posted by Ernest Friedman-Hill:
Jeroen:

Why are you ignoring theclasspath exception, the provision, invented for the GNU Classpath project but also being adopted by Sun? It's an explicit exception to the GPL's provisions which states that if you run your program using an unmodified version of the licensed code (i.e., the GPL'd Java APIs) then your code does not have to be open-sourced.

The "classpath exception" is the key to understanding this whole thing, but even though it's been mentioned already in this thread, you seem to be willfully ignoring its existence.

The classpath exception MAY not apply to Java code!
Strictly speaking every Java class is a derived work of a class in the standard API at source level and therefore would fall outside the scope of the classpath exception which only relates to calling functions inside binary libraries.

As long as that's not been tested in court and rejected, that's the sword hanging over everyone's neck.

[Marcus Green]

"I'm suggesting Sun doesn't care one way or another about third parties as long as those 3rd parties don't generate income for Sun.They're not in there for altruism after all."

You are the first to mention altruism here. You seem to be implying that Sun would for example be ignoring any impact on companies such as Oracle, a very significant source of hardware revenues. I have not seen anyone writing articles about how Oracle is going to have to release its Java tools under the GPL.

[Jim Yingst]

[Jeroen]: The classpath exception MAY not apply to Java code!

Um, OK. And you MAY be a child molester. Or I MAY be a serial killer. Speaking for myself, I know I have never defended myself in court against such a charge. Don't know about you. Let's assume you haven't. Should other people avoid associating with us because we haven't had to go to court to prove our innocence? I would suggest that pehaps the correct answer here is OF COURSE NOT.

Aside from this, um, minor flaw in your argument, I would also point out that Sun hasn't GPL'ed the API or any of its implementations, yet. (Have they?) So what are we talking about here?

[Jeanne Boyarsky]

Originally posted by Jeroen T Wenting:


The classpath exception MAY not apply to Java code!
Strictly speaking every Java class is a derived work of a class in the standard API at source level and therefore would fall outside the scope of the classpath exception which only relates to calling functions inside binary libraries.

As long as that's not been tested in court and rejected, that's the sword hanging over everyone's neck.

What's the problem with deriving work by extending a class at the source code level? If I extend a Struts class by writing my own classes, they don't become part of Struts. (Let's assume Struts was under this license, my class isn't in an org.apache package and I don't redistribute Struts to others.)

[Ernest Friedman-Hill]

Originally posted by Jeanne Boyarsky:

What's the problem with deriving work by extending a class at the source code level?

Well, to be fair, strict GPL constructionists would tell you that if Struts were licensed under GPL without the classpath exception, then extending a Struts class would, in fact, mean that your code must be GPL'd. This is a legitimate concern for businesses, and is the reason that there isn't a whole lot of widely-used GPL Java code.

Struts is, of course, licensed under the (very different) Apache license, where there's no such concern.

[Tim LeMaster]

every Java class is a derived work of a class in the standard API at source level and therefore would fall outside the scope of the classpath exception which only relates to calling functions inside binary libraries.

Really at the source level huh? You can and often do, extend a class (Object is a good example) without the source. Its just like a dynamic linked library. You need it a compile time (javac) and you need it at runtime.

Now if the Standard API was GPLd without the classpath exception that would require your code to be GPLd. However the developers of the classpath exception make the intent clear here:

http://www.gnu.org/software/classpath/license.html
"As such, it can be used to run, create and distribute a large class of applications and applets. When GNU Classpath is used unmodified as the core class library for a virtual machine, compiler for the java language, or for a program written in the java programming language it does not affect the licensing for distributing those programs directly."

[Jeanne Boyarsky]

Originally posted by Ernest Friedman-Hill:
Well, to be fair, strict GPL constructionists would tell you that if Struts were licensed under GPL without the classpath exception, then extending a Struts class would, in fact, mean that your code must be GPL'd. This is a legitimate concern for businesses, and is the reason that there isn't a whole lot of widely-used GPL Java code.

So this means that extending a GPL'd class is not ok without the classpath exception but ok with it? Would calling a GPL class have the same problem as extending one?

Struts is, of course, licensed under the (very different) Apache license, where there's no such concern.

Right. That's why I said "Let's assume Struts was under this license". I understand there is no concern for Struts.