Skip to main content

End-user java applications

16 replies [Last post]
sfortin
Offline
Joined: 2006-08-16
Points: 0

Hi there, I thought I'd post our usage scenario although I'm sure it is very common.

We're a small company that sells a mass market game that is written in Java (Poker Academy if you are interested). We bundle the entire JRE with our game and use that so we have control over exactly what VM users are running and since we cannot rely on a VM being present at all.

Absolutely critical for us in open source java is that we don't have to release the source code for our game--although that seems so obvious it goes without saying.

Cooler would be the idea that we could make a custom VM and bundle that instead of the JDK. We wouldn't want or need to call it Java or indeed have it used for any app but our own. I can imagine us wanting to do things like app-specific optimizations, stripping out portions we don't use, embedding copy protection/encryption at a lower level, etc.

The question is if and how we'd have to release source for our changes to the VM? We're not a large company and having a lot of licensing requirements would make VM hacking a non-starter for us. It'd be better from our point of view if that was up to our discretion.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
robilad
Offline
Joined: 2004-05-05
Points: 0

@webmink: +100.

A lot of us developers fall into the trap of thinking of law and its application as a binary, black or white, right or wrong thing. I'm happy to hear that you're getting legal advice from many sources, that's certainly the best way to obtain different perspectives on the pros and cons of various licensing choices.

webmink
Offline
Joined: 2003-06-06
Points: 0

> S'o we're back to the usual problem: the lawyers :)
> Specifically, the ones who might not read the GPL
> that way. They might say "but what if you looked at
> the JDK hashCode() source, and so your code is
> probably 'based' on that".'

It's not the lawyers who are a problem. All the lawyers I speak to inside & outside Sun (including ones who favour use of the GPL) neither engage in the sort of angels-on-pinheads debating needed to make those sorts of conclusions nor assert that the GPL is "transmitted" in the way you describe. The problem is the weekend-lawyer types who behave as if law was executable code and find entertaining corner cases that support their prejudices.

atripp
Offline
Joined: 2003-07-15
Points: 0

> All the
> lawyers I speak to inside & outside Sun (including
> ones who favour use of the GPL) neither engage in the
> sort of angels-on-pinheads debating needed to make
> those sorts of conclusions nor assert that the GPL is
> "transmitted" in the way you describe.

Can you be more explicit about "all the lawyers" you've talked to? How many have you talked to? What sort of companies did they work for? Where they familiar with the GPL and copyleft? Did they really say that they thought copyleft wasn't "transimitted" / "viral"? What specifically did the Sun lawyer(s) that you talked to say?

jwenting
Offline
Joined: 2003-12-02
Points: 0

> S'o we're back to the usual problem: the lawyers :)
> Specifically, the ones who might not read the GPL
> that way. They might say "but what if you looked at
> the JDK hashCode() source, and so your code is
> probably 'based' on that".'
>
Correct. And not just that, under GPL implementation any code written against the standard APIs would count as a derived work and therefore be forced to be released under the GPL as well.
That means all Java code because everything extends from Object one way or another.

> Geesh, that's a troubling idea. At what point is
> something not derived from another piece of source.
> If I read some GPLed Java code and 2 weeks later
> r create code that is very similiar to that is my
> code GPLed? It seems like paranoia almost, but if Im

yes, they could claim that. Therefore you won't find any GPL'd source on my system, and no or hardly any binaries.

> doing a version of the code from memory isn't this
> still a derivative work? Maybe I shouldn't ever read
> any GPL code... :D
>
That's correct. You should stay far away from GPL source, it's no use getting involved in it.

gkulewski
Offline
Joined: 2006-08-17
Points: 0

Well, GPL has its problems. And it wasn't invented for object oriented programming too.

But GPL is simply not for Java. While it would be good if Java used GPL compatible license GPL itself isn't woth considering in my opinion.

Especially standard Java library has to be at least LGPL licensed or way better BSD licensed (like many UNIX code in history, and many reference implentations).

As to the virual machine - since it will be probably linked (dynamicaly) with GPL code (to embeded JVM in something) it would be good for it to be GPL compatible. But to keep (not only) BSD people happy it would be good to have it BSD licesed too. It is also a reference implementation.

GK

robilad
Offline
Joined: 2004-05-05
Points: 0

Let me see if I can help.

Your source code is not a derived work, as long as it's using the standard interfaces. Your bytecode is not a derived work, as per specs, nothing copyrightable from the standard libraries ends up in your class file.

You can create a derived work by taking GPLd code from the standard class library and copying it modified or verbatim, into your own code, of course, but that's the same regardless of the license.

For a trivial analogy, consider the shell script

echo "Hi Andy"

which will work the same in a BSD licensed shell, or in a GPL licensed one, or a shell under any other license, as long as it implements the POSIX-y echo command in its library of builtins.

Using echo does not create a derived work of a GPLd shell, if you happen to write or run a shell script on GNU/Linux using bash, for example, as Sun did with the JDK for a few years.

A similar rationale applies to your hashCode invocation: it's part of a standard, so your source code using the standard interfaces isn't a derived work of a particular implementation of the standard.

I didn't say that all implementations of hashCode are the same. I said that the interface names and constants are the same accross all implementations of the standard, and as such are not copyrightable by a particular implementation, whatever its license is.

atripp
Offline
Joined: 2003-07-15
Points: 0

Thanks, Dalibor!
I understand now, and on rereading GPL section 2, what you said makes sense. (Errr..at least I can't find a contradiction, though the wording obviously doesn't spell things out as neatly as you just did).

So we're back to the usual problem: the lawyers :) Specifically, the ones who might not read the GPL that way. They might say "but what if you looked at the JDK hashCode() source, and so your code is probably 'based' on that".

Or what if you did look at the hashCode() source, found some "magic key" constant, and used that in your code? That's a contrived example, I know. I'm just trying to point out that there is always a gray area between just using the API and actually hijacking chunks of code.

Anyway, thanks for the explanation. I wonder if Sun's lawyers have come to the same understanding.

leouser
Offline
Joined: 2005-12-12
Points: 0

S'o we're back to the usual problem: the lawyers :) Specifically, the ones who might not read the GPL that way. They might say "but what if you looked at the JDK hashCode() source, and so your code is probably 'based' on that".'

Geesh, that's a troubling idea. At what point is something not derived from another piece of source. If I read some GPLed Java code and 2 weeks later create code that is very similiar to that is my code GPLed? It seems like paranoia almost, but if Im doing a version of the code from memory isn't this still a derivative work? Maybe I shouldn't ever read any GPL code... :D

leouser

atripp
Offline
Joined: 2003-07-15
Points: 0

> S'o we're back to the usual problem: the lawyers :)
> Specifically, the ones who might not read the GPL
> that way. They might say "but what if you looked at
> the JDK hashCode() source, and so your code is
> probably 'based' on that".'
>
> Geesh, that's a troubling idea. At what point is
> something not derived from another piece of source.
> If I read some GPLed Java code and 2 weeks later
> r create code that is very similiar to that is my
> code GPLed? It seems like paranoia almost, but if Im
> doing a version of the code from memory isn't this
> still a derivative work? Maybe I shouldn't ever read
> any GPL code... :D
>
> leouser

Yes, Dalibor and I have debated that before at Javalobby, in the context of Sun's licenses, not the GPL. My personal view is that I'll just use common sense. I'm comfortable looking at GPL code and then writing related non-GPL code. I feel like I know when I'm "reusing" something and when I'm not. Some open source projects are more cautious, not wanting to even look at Sun's source code before writing competing code, for fear of "tainting" themselves. I guess it's up to each individual and their particular level of paranoia.

jwenting
Offline
Joined: 2003-12-02
Points: 0

> Absolutely critical for us in open source java is
> that we don't have to release the source code for our
> game--although that seems so obvious it goes without
> saying.
>

As long as Sun chooses a decent license (so not the GPL) that should not be a problem.

> Cooler would be the idea that we could make a custom
> VM and bundle that instead of the JDK. We wouldn't
> want or need to call it Java or indeed have it used
> for any app but our own. I can imagine us wanting to
> do things like app-specific optimizations, stripping
> out portions we don't use, embedding copy
> protection/encryption at a lower level, etc.
>

And there's one of the core reasons for NOT letting Java go open source.

Here's someone who wants to fork the platform for his own personal reasons, with the best intentions it seems, in a way that would prevent other than his own applications from running on systems that have it installed.

That's exactly the kind of thing that has me worried greatly, as it will create a plethora of mutually incompatible JVMs installed on customer machines, and thus a massive amount of complaints and queries from customers who see your applications crashing (or failing to run at all) despite them having "Java installed".
The only way to prevent that would be for everyone to ship a complete JVM with every application he distributes, even if it's a few hundred lines of code.

Customers shouldn't have to worry about having the correct runtime installed. At the moment all they need is a single place to get it, and every Java application in existence should work.
In the future they'll have to install a new JVM every time they install a Java application, and if those JVM installers are poorly written (as most free installers are) that installation will cripple existing JVMs (even some Sun and IBM JVM installers did that in the past) so previously installed Java applications suddenly no longer work.

sfortin
Offline
Joined: 2006-08-16
Points: 0

I think you misunderstand this type of commercial deployment. I should have said JRE and not JDK.

Bundling a JRE and not clobbering or effecting in any way the Java users have installed (in fact them not knowing that you are using/have installed Java at all) is literally trivial. The JRE ia not a seperate install and does not touch system folders but instead lives quietly in the application's install folder.

I can see no reason why that would not continue to be the case with an open-sourced JVM.

Perhaps it would be better if companies did not deploy this way but for commercial mass market game development I don't see much of a downside.

robilad
Offline
Joined: 2004-05-05
Points: 0

FWIW, a GPL'd VM would not require you to redistribute the source code of your application ... any more than distributing Java on the GPLd Linux Kernel in their Java Linux Desktop requires Sun to redistribute the source code for all the applications running on top of it, like their JVM.

That's not how the GPL works, despite Microsoft's Get-the-Facts campaign. ;)

jwenting
Offline
Joined: 2003-12-02
Points: 0

no, that's exactly how it works in this case.
Your program is an extension of the standard libraries (after all, every class extends Object which is part of the standard library).
Under the GPL any extension or modification of GPL code MUST be under GPL as well, so any class extending Object (or extending a class that at some point extends Object which is every class) MUST be GPL if Object is GPL.

For C and C++ and the like that's no problem as there is no actual library containing the source of their grandfather language structures as such.

robilad
Offline
Joined: 2004-05-05
Points: 0

@jwenting: I've been the maintainer of a GPLd JVM for almost five years. Which GPLd JVM have you been maintaining? ;)

I know a fair bit about the usage of GPL, and its effect in this scenario, since I had to deal with licensing FUD earlier, and had ample opportunities to discuss it with David Turner and others from the FSF.

The GPL doesn't require that bytecode classes using a GPLd java.lang.Object be licensed under the GPL as well. That's because neither the bytecode nor the source code using it are derivative works of java.lang.Object, as all that ever ends up in them are interface names and constants, and those remain the same, regardless of the license of the java.lang.Object class. Those symbols are standardised through the JCP, and published as specifications. They are necessary for interoperability.

Therefore, the symbol names and constant values can not be claimed as original works by a GPLd java.lang.Object, and accordingly don't meet the bar for copyrightability.

The GPL can only work through copyrightable elements of a work, and in a normal bytecode class file using java.lang.Object, there is no such thing stemming from java.lang.Object in it.

Per design of the bytecode format, I might add.

atripp
Offline
Joined: 2003-07-15
Points: 0

> That's because neither the bytecode nor the
> source code using it are derivative works of
> java.lang.Object, as all that ever ends up in them
> are interface names and constants, and those remain
> the same, regardless of the license of the
> java.lang.Object class.

Dalibor,
OK, I guess I do deserve a "you don't understand" label here, even after reading the above about 5 times :) You're saying that my Whatever class, which relies on the GPLed Object.hashCode() method, is not a "derived work" (as defined by GPL section 2), because hashCode() is just an "interface name"?

I don't know what you mean by "just an interface name", but regardless, there is some underlying implementation to hashCode(). And if my Whatever class is based on that implementation, then my Whatever class is "based on" Object. No?

And what does it matter whether the various implementations of hashCode are "the same"? That seems irrelevant (as well as probably untrue).

Andy

leouser
Offline
Joined: 2005-12-12
Points: 0

In terms of extending from Object, I find it hard to believe that this would mean your code is now GPLed. What if I compile from Sun's javac today and run the bytecode under a GPLed JVM which has a GPLed Object? Surely my code is not GPLed at this point. But what if I take the source from that GPLed Object and reuse it in a different class? What if the GPLed Object has a nifty equals formula that I want to reuse?
It seems to me that my source is now GPLed. darn Object.

Id guess by 'interface name' he means the spec. For Object the spec would be:
hashCode()
toString()
equals()
etc...

If I write code against that, just the interface to the Object shouldn't I expect myself not to be tainted by the GPL? Its already established in the world independent of the GPL.

leouser