Slashdot Mirror
J2SE 5.0 Source Code Bundles Now Available
madcowbrit writes "J2SE 5.0 Source code bundles are now available
with SCSL and the new and exciting Java
Research license!
Coders have been asking for Java J2SE source code
access under new terms. The new Java Research
license gives people more access and options to
work with the Java J2SE source code."
This is just SUN throwing a bone to the free software community who has been asking for a free Java. What they want is the four software freedoms. SUN, by allowing this "shared source" access to take quick, careful peeks at the source code and hope SUN won't go SCO on your behind, want to be able to say "we're meeting you half-way, you stupid hippies!" This move is guaranteed to get them excellent scores in the press, which thinks they've listened and acted. At the same time, the free software community won't be able to complain any more, since they'll just look like arrogant whiners.
"Oppression and harassment is a small price to pay to live in the land of the free." -- Montgomery Burns.
Yes, you can download the J2SE 5.0 source code. But once you do, you will be bound by Sun's source code license agreements. Some companies and open source projects interpret those license agreements in such a way that you will not be able to work on projects covering anything that overlaps with functionality in the Java distribution.
I'd recommend you read Sun's licenses carefully in their entirety and think about its implications carefully before you download the source code and look at it.
Furthermore, you should carefully think about what you are getting out of agreeing to the license and what Sun is getting out of it (I find Sun's licenses inequitable).
If you want to find out how Java-like compilers and runtimes are developed and built, there are truly open source systems you might look at that don't saddle you with the kinds of restrictions Sun wants to impose on you (and they are likely better systems to learn from anyway).
7. Does this license require a click-through acceptance of terms?
... useful to me.
Yes. For enforceability, Sun requires a click-through license.
This should tell you something - only a license that plans to restrict your rights in some unpleasant way requires a clickthrough. Seriously - I always get the willies from having to clickthrough to accept anything.
14. Can I share my modifications with other researchers?
Yes, provided that the other researchers have accepted the JRL.
Cool, even my patches are subject to the license. I knew some doozy was coming that was going to restrict my usual rights. Thus the clickthrough love.
8. When do I need to get a commercial license?
This research license is only for initial research and development projects. If you decide to use your project internally for a productive use, and/or distribute your product to others, you must sign a commercial agreement and meet the java compatibility requirements.
Uhhh... so let's see, I can use the Sun JRE free for any use. I can download the SCSL Java SDK source code, and while I can't redistribute it or do other Open Source style things with it, I can at least play with it and use it for internal things if I want (I think). But I can't even do that with the Java Research License, if it consists of 'productive use'? That sounds really
And rightfully so. Don't forget Sun has invested a lot of both time and money into java. Frankly, I am surprised they go as far as they do now. From the license faq:
12. Am I required to keep my research "java compatible?"
No. The license encourages you to innovate and experiment using the java technology core. It is expected that research implementations will not be compatible with the Reference Implementation from Sun. This is ok.
13. Can I publish my source code at a conference, and in white papers?
Yes, you may publish your work in the usually accepted academic manner as long as you reference the Java Research License and include the correct copyright information.
14. Can I share my modifications with other researchers?
Yes, provided that the other researchers have accepted the JRL.
I might not be your regular open source hippy, but I feel that anyone that has taken the time to create software or whatever has the right to define the terms upon how it is used. Sure, the community has given a lot back. Some (can't find the link, but it was mentioned on slashdot some time ago) even argue that if it weren't for this Sun would be out of business by now. So it's a bit of giving and a bit of taking. This seems like a great gesture from Sun.
Please login to access my lawn
And that is why that license stinks.
It is "viral" in that if you get that code and
learn from it, you can not use it to improve
any open source software.
I would very much like to see how Sun has
implemented certain optimizations for Java and
bring those over to Mono (or to other open source
Java VMs, VMs in general, JIT engines, compilers
or scripting languages).
The problem is that the license explicitly
forbids the use of it for this purpose `direct
or indirect commecial (including strategic) gain
or advantage'.
Still falls short of usable for the free software/
open source community.
Miguel.
Sun isn't ashamed to admit that Java is not open source, and likely won't be for the foreseeable future. In fact, they seem to get a little angry at the question pointing out that Sun has spent millions developing Java and now the community expects them to make it GPL or something. I'm not sure how keeping the development burden of Java internal to Sun really makes them money, though. Open sourcing would be the ultimate outsoursing... hundreds (or thousands) of developers all contributing to Java for free.
The biggest argument against this I heard is that Sun would have to halt new features of Java for 9-12mos and concentrate on getting the source ready to be released. I don't get this at all... just throw it in CVS and do it with the help of the open source community.
P.S. The Colorado Software Sumit is awesome!
Quoting Danese Cooper, Sun's open source diva:
h tml
.net, Microsoft, IBM, Bea, or whatever the scare-of-the-day is, that prevents Sun from licensing their code under an OSI certified license.
"IMHO (and IANAL) the JRL doesn't actually represent much of a change of terms from what the research and academic community could do under SCSL (there are some small changes around export), but it does clear away all the language in SCSL that is confusing, if you are only planning to engage in research."
from http://today.java.net/pub/a/today/2003/06/24/jrl.
On a first look, there is not much difference between the JRL and the research provisions in the SCSL. The language got a bit clearer, and a few of the most hillarious provisions have been dropped.
Research projects like JikesRVM, ORP, OVM and others seem to prefer to use GNU Classpath, rather than have their hands tied by proprietary, non-permissive licenses. I'd expect more research projects to join into the GNU Classpath pool, which is free software, in the future.
It's definitely a step ahead for Sun. Good luck on the rest of the road to freedom without fear[1].
cheers,
dalibor topic
[1] Fear of forking, incompatibility,
It is only possible to have a direct self-compiling system when the target is native code. The standard Java build process only generates native code internally and temporarily, so that isn't really possible.
As for machine-level abstraction, all of the recent x86 processors are actually RISC-style processors running optimized x86 emulators. Even RISC processors these days are run with microcode running on different and newer RISC architectures. Pretty much only microcontrollers actually implement the processor you're using in hardware.
Java is "open" (documented, can be reimplemented)
The Java platform cannot be legally reimplemented without meeting Sun's compatibility requirements and without obtaining licenses for several of Sun's patents (Sun has refrained to enforce that against open source, but as Unisys and SCO show you, you can cause trouble many years after some infringement has taken place). As a result, the Java platform is not open (i.e., an "open standard") in the long-established meaning of the term.
the computer industry (Sun specifically) has used the word "open" for many years
The computer industry has used the term "open standard" for many years. The term "open source", however, used to refer to publicly available intelligence sources before the open source movement applied it to software. And, whether you believe me on the the history or not, most people will understand it to mean what opensource.org says it means; any attempt by Sun or anybody else to play semantic games and pretend that their software "is open source" for some unusual meaning of "is", "open", or "source" is just being deceptive.
Be careful,
Or what? The Schwartz is going to destroy me?
Miguel, you are wrong. The license says "You may use any information in intangible form that you remember after accessing the Technology, except when such use violates Sun's copyrights or patent rights." In other words, you can read the code to learn how it works and use that knowledge. You just can't cut-and-paste Sun's code into another project.
They cannot stop you from learning from what you observe, nor can they stop you from exploiting that knowledge, even for commercial advantage.
All they can ultimately do is come down against you if you actually _copied_their_code_ into a resulting work. If they try to stop you from producing something that may happen to have cosmetic similarity to their own code merely by virtue of it performing the same function, they would have to try to claim a patent over the portions of the code being copied first, which isn't the case here.
Oh... and they can also stop you from using the Java trademark.
File under 'M' for 'Manic ranting'
Stay very well clear of it:
"agreeing to this license (e.g. by downloading source covered by the SCSL) will make it impossible for you to contribute to free software clean-room implementations."
I'm certanly not going to touch it, the pre-compiled stuff will do fine.
I have yet to see a valid argument for why SUN doesnt release J2SE under an OSI complient licence.
The argument that they want to be able to use the code in their own closed things, well they can do what OpenOffice.Org does and dual licence.
There are clearly no arguments that can be made about "other peoples code", if there was anyone elses code in there, we wouldnt get to see it at all.
As for the oft-pushed argument about forking, I said it before and I will say it again.
What they need to do is to release the source code.
Plus a testsuite.
If you want to use the JAVA name on your particular binaries, those binaries must pass the testsuite.
Releasing under a string copyleft like GPL that requires all source changes to be made public would also help stop forking because anything that is used can be added to the official sun tree.
That way, anyone can use the source for whatever they like. But if you want to call something (be it modified from the SUN code or otherwise) JAVA, you have to pass the testsuite. That way, anything that has the JAVA logo on it (or whatever) is gauranteed not to be incompatible with SUNs VM.
A good cpoyleft licence would also prevent what happened with Microsoft from happening again (since any additions could be added to the SUN VM)
I don't think anyone is trying to force Sun to open source the Java reference implementation. Rather, what are being highlighted are the practical deficiencies of its licence. There are undeniable business risks associated with using software whose future direction is so heavily under the control of a single company, whose priorities may conflict with the interests of your own business at some point in the future. Especially when there are viable, mature alternatives which are genuine free, open source software.
In contrast, Sun's LGPL licensing of OpenOffice.org, a much larger body of code than the Java reference implementation, is the single most important reason why OOo looks set to be the de-facto office standard in the long term.
perl -e 'fork||print for split//,"hahahaha"'
IBM has called on Sun to open source Java, so the obstacle is Sun, not IBM. The fact that IBM has contributed so much to J2SE is probably a thorn in IBM's side because they did a lot of work and Sun effectively gets to control what happens with it.