Trusting companies with your code…

Mark Reinhold announced JDK 7 Milestone 5 which is derived from OpenJDK7. Lots of people contributed to that. But sadly Sun decided they weren’t going to release this as Free Software. I wanted to research this JDK7 M5 and compare it to the work we did on OpenJDK and IcedTea, but apparently I am not allowed to…

Sun might have the right to do this given they only use contributions granted to them under their SCA terms. But the following clauses from the JDK7 license seem somewhat unfair given that we all contributed parts to OpenJDK.

  • “Licensed Software is “Confidential Information”. Licensee may not disclose or use Confidential Information”
  • “Licensee may not modify or create derivative works of the Licensed Software, or reverse engineer, disassemble or decompile binary portions of the Licensed Software, or otherwise attempt to derive the source code from such portions.”
  • “Licensee shall have no right to use the Licensed Software for productive or commercial use.”
  • “LICENSEE DUTIES Licensee agrees to evaluate and test the Software for use in Licensee’s software environment and provide feedback to Sun in a manner reasonably requested by Sun. Any and all test results, error data, reports or other information, feedback or materials made or provided by Licensee relating to Software (collectively, “Feedback”) are the exclusive property of Sun and Licensee here by assigns all Feedback to Sun at no cost to Sun.”
  • “This Agreement will commence on the date on which Licensee receives Licensed Software (the “Effective Date”) and will expire ninety (90) days from the Effective Date, unless terminated earlier as provided herein.”
  • “Upon termination or expiration of this Agreement, Licensee will immediately cease use of and destroy Licensed Software, any copies thereof.”
  • “It is understood and agreed that, notwithstanding any other provision of this Agreement, Licensee’s breach of this Agreement will cause Sun irreparable damage for which recovery of money damages would be inadequate…”

There is no reason for Sun to act in this anti-social way. There are free replacements for the previously encumbered binary blobs (thanks IcedTea!). So anybody that wants to can distribute a completely free version. And redistributing other peoples contributions under such draconian one-sided terms is totally unnecessary (and rude!). If someone wants to add the previously proprietary binary blobs one can do that under the terms of the OpenJDK Assembly Exception to the GPL that was specially drafted to allow this. So there is no need to not redistribute the free parts under the GPL as everybody else is doing.

Come on Sun, tear down this proprietary legal wall that divides users from the developers that contributed all this code to be free and open.

20 Comments

  1. TJ says:

    It is a shame, yes. However, one has to understand the financial pressure Sun went into, knowing the Oracle deal. Giving away the JVM is something that L.E. does not want

  2. [...] This post was mentioned on Twitter by Davanum Srinivas, Planet Fedora. Planet Fedora said: Mark J. Wielaard: Trusting companies with your code…: Mark Reinhold announced JDK 7 Milestone 5 which is d.. http://bit.ly/2dC9kl [...]

  3. Rahul Sundaram says:

    This is a potential problem I raised long time back and didn’t seem like people took it seriously. Now I guess they will.

  4. Aaron Luchko says:

    Does this mean that Sun is moving back from open sourcing Java? Or are they doing this because there’s still bits in Java that they can’t open because of their licensing?

  5. Ismael Juma says:

    Aaron,

    Sort of the latter, I assume. The Sun JDK builds still include various bits that are not open-source, many for licensing reasons (which now have less mature/polished open-source versions) and others because Sun has not released them as open-source (webstart/plugin). Given that, it seems like their builds still use the same licensing terms as JDK6.

    This is just an outsider’s view though, maybe someone from Sun can clarify.

    Best,
    Ismael

  6. TJ, Lets hope this isn’t because L.E forced them to.

    Rahul, Yes, you did, and lots of people did warn about the ways Sun could abuse the terms of the SCA. But there was no reason for Sun to actually abuse the trust given to them. Even if the legally could. I must say I am shocked they feel the need to slap such draconian terms on code contributed to them in good faith and that everybody else redistributes under the GPL as intended. Lets hope this does lead to more fair SCA terms. If you have pointers to examples of contributor agreements that prevent corporate “guardians” from doing such things with the public code that would certainly be appreciated.

    Aaron, Thanks for the comment. I added a paragraph explaining what Sun should have done.

    Ismael, Yes, lets hope someone from Sun explains why they felt the need to do this. Maybe it is just laziness (we had these jdk6 terms still around), but that doesn’t really make sense seeing the work that went into the assembly exception.

  7. Rahul Sundaram says:

    “If you have pointers to examples of contributor agreements that prevent corporate “guardians” from doing such things with the public code that would certainly be appreciated.”

    Best policy is to avoid signing over copyright to corporations. You might be shocked but since you basically allowed them to do this to you, they can and probably will ignore you. FSF does have a provision in their license agreement that counter promises not to make the code proprietary.

  8. Clemens Eisserer says:

    If LE forces them, it would be a rather foolish descision.

    The code already available in OpenJDK is too good to no be included by major linux distributions, even if additional functionality is added to the proprietary JDK.
    I guess it would lead to another compatibility desaster, like it has been the case in post Java-1.1 days, when Netscape/MS only shipped 1.1 capable jvms.

  9. Roman Kennke says:

    Hey what is the problem? If you want to look at the code, look at OpenJDK. Ever since its inception its been clear that (closed) JDK will be built in parallel, and it includes OpenJDK code, but it also includes ‘confidential code’, so what? This is not news, is it?

    • Roman, the problem is that there is no way to check that, the license for these binaries explicitly forbid trying to find out that what you say is true. That is just stupid. It fumes the flames that Sun has something to hide.

      The license also threatens users with severe consequences for doing that and learning from our code. This is code we all contributed. That is just nasty. We are cooperating on this code base and now Sun turns around and locks up our code, denies anybody from figuring out it is our code and demands users of this code to work only with Sun as if all this is Sun Confidential and deny working with the community in the open.

      And none if this is necessary. As pointed out thanks to the OpenJDK GPL Assembly Exception Sun can release the free parts as GPL for everybody to collaborate around and only use the restrictions for the previous proprietary blobs. Just like everybody else in the community.

  10. This is nothing new; every build drop of 7 has been released in this manner:

    http://download.java.net/jdk7/binaries/

    with source under the JRL. No different to JDK6 either.

    It’s going to be this way until Sun are happy to ship an equivalent Free binary without any of these proprietary elements (plugin, javaws, the old graphics renderer and sound) to their end users. I don’t get the feeling this is anyone’s goal at the moment – inside or outside of Sun. That’s what we need to be discussing, not getting a binary build from the proprietary JDK7 tree put under multiple licenses just to make things even more confusing.

  11. Roman Kennke says:

    If Sun did as MySQL did before, and sold the same code as non-GPL to paying customers without giving it out for public consumption, would that change things? Do you suggest Sun should release the open parts under GPL and the closed under the closed license, and the user must put together the pieces? Or even worse, require people to examine the header of each source file to figure out if he’s allowed to look at it or not?

    Don’t get me wrong. I would be worried if Sun would discontinue OpenJDK, but I don’t see signs of that…

  12. Andrew, Agreed. We need to get this on the agenda. We really don’t need Sun distributing under different licenses than the rest of the community. And confuse things by using such grossly draconian proprietary terms. Even by proprietary standards, these terms are just totally unfair and reflect badly on the community around free java that we are working on together.

    Roman, Yes, I suggest that Sun does what everybody else does and how things are spelled out under http://openjdk.java.net/legal/. So distribute everything under the same terms as the rest of the community (and definitely not restrict users of their binaries from reporting and communicating with the rest of the community as the terms and conditions they are attaching now do).

    I don’t suggest splitting things up or providing different downloadable parts. I just suggest Sun takes advantage of the Assembly Exception and play by the same rules as the rest of the community. If Sun still has ties to old proprietary modules those can be shipped and distributed together with the free sources under the Assembly Exception (as everybody else can). Yes, it would be sad if there were still parts that are proprietary. But it is much sadder that the free parts are locked up again and users set up against the free community that helped build the code.

  13. Mario Torre says:

    I get it right that with those terms if I find a bug using the closed binary I cannot report it to the OpenJDK people (that is, self as well) and eventually fix it?

    I’m not very good in those legal terms, but if this is the case, it’s a good reason to stay away from those binaries and just use whatever comes from the Linux distributions or directly from the OpenJDK website.

  14. Mario, the binary plugs haven’t been needed by either OpenJDK (6 or 7) for over six months. You can pretty safely not use them, and of course IcedTea doesn’t.

  15. Paul Dodd says:

    I don’t see the problem at all. According to the first sentence quoted, ““Licensed Software is “Confidential Information”. Licensee may not disclose or use Confidential Information” nobody can use the software at all (not even Sun themselves??) so what’s the big deal… > /dev/null

  16. Simon Phipps says:

    Mario: You don’t have it right, no. All the (rather heavy but as Andrew notes not new) closed binary license means is “don’t pass the binary code on”. You are free to pass on all your experiences of it including bug reports and comparisons. Just as it’s always been; no idea why Mark thinks there’s something new happened.

  17. Simon, the license terms explicitly say you are not free to pass on your experiences except to Sun.

    - “Licensed Software” means [...] Feedback [...]
    - Licensed Software is “Confidential Information”.
    - Licensee may not disclose or use Confidential Information
    - Any and all test results, error data, reports or other information, feedback or materials made or provided by Licensee relating to Software (collectively, “Feedback”) are the exclusive property of Sun

    And if that was also true in the past that doesn’t really mean it should be so in the future.

  18. [...] my somewhat cranky post about the JDK 7 M5 binaries being distributed under not very free and social terms. I was really [...]