Discussions

News: Apache and Sun row over "Field of Use" restrictions

  1. Apache sent Sun an "Open Letter" after it added new terms to the TCK (the software used to certify compatibility) licensing requiring Apache to enforce "Field Of Use" restrictions on certified software. After, Sun failed to reply, Sam Ruby posted proposed changes to the Apache's current participation policies and a discussion has ensued. Since I summarized the discussion, an alternative proposal has been brought forward. Apache has yet to achieve a consensus as to the way to respond as many members are concerned about their personal position in the JCP or the status of their existing projects. Ultimately, the Apache Board of Directors has the final say, but seems to be allowing this group to develop a consensus and vote on a policy. The "Field of Use" restrictions that Sun has imposed restrict software certified with the TCK to "general computing devices" which would for instance restrict use on kiosks or mobile devices. These restrictions would require Apache to help enforce them against users of their software and thus would likely violate the prohibition against restricting "Fields of Endeavor" in the Open Source Definition. An additional issue is the use of "Non-Disclosure Agreements" in the JCP which restricts what Apache developers can discuss with other members of the community and allows Sun to impose restrictions that may not be conducive to open source within the scope of the negotiation for the TCKs without public scrutiny. Chief Open Source Officer, Simon Phipps has commented on the issue seeming to agree (with Dalibor Topic) that "Proprietary software should not be allowed to be tied in as a fundamental part of an open standard in any form.", but defending the use of NDAs in the process. In a recent vote most of the JCP EE/SE Executive Committee (except JBoss and Sun) voted down or abstained from a vote on the specification until the license issues for it were clarified. What do you think? Should the JCP continue to operate under various NDAs? Should licensing of the specification and TCK be clarified up front? Should "Field of Use" restrictions apply to a supposedly open standard, its TCK or Reference Implementation?

    Threaded Messages (18)

  2. Support and Clarification[ Go to top ]

    Andy, JBoss is totally supportive of Apache in its fight to get a proper license that does not contain any field of use restriction from SUNW. As you can see from our recent votes, we decided to add a comment in support of the issues faced by the ASF - and this independently of the JSR being voted on. Until this is properly addressed by SUNW, our defiance towards SUNW's business practices will be high: what happens to the ASF today could happen to anybody tomorrow. It is really time for SUNW to wake-up. Now, let me clarify something that wasn't really correct in your news entry.
    In a recent vote most of the JCP EE/SE Executive Committee (except JBoss and Sun) voted down or abstained from a vote on the specification until the license issues for it were clarified.
    Andy, that part is not entirely correct, let me clarify. The issue with that first submission of the EE6 JSR was around the notion of profiles and what it meant from a licensing/pricing standpoint. The issue was NOT around any field of use restriction - which had been clarified prior to the vote by SUNW, as indicated in a few of the EC comments. Consequently, while a few EC members (including JBoss) made a comment wrt the field of use restriction, this was strictly in support of the issue the ASF is facing in licensing Java SE, it was not related to EE6 itself.
    Cheers,
    Sacha CTO JBoss, a division of Red Hat.
  3. Hi Sacha, Yes I did not mean to call Red Hat out on that. I intended just to report the vote (Red Hat did indeed comment supportively on the issue). It appears the reason was as you say inaccurate. I'd apologize for that as well however I think it speaks to that this issue goes far beyond Apache and it getting a fair license for its JDK. This goes to the genuineness of OpenJDK (which is presently not technically open source as I mentioned in my blog), and is FOU terms continue to propagate they can affect JBoss and others' ability to distribute under licenses that meet the Open Source Definition or the definition of free software. If I could see into the process (if these were truly open standards developed by an actual COMMUNITY process), I could have reported more accurate information. Instead I have to deduce from the vote/comments and take third party information which isn't always accurate and often self-serving. Moreover the restrictive licensing terms of the TCK/CTS/JCK whatever...combined with the NDAs that govern the process, the TCK, etc prevent JSRs in my view form being considered "open standards". Because the TCK and the RI are considered the authoritative source (more than the actual specification itself) and thus help define the standard, yet are not open, this CANNOT in my view be considered an open standard or the JCP an open standards process. Don't get me wrong, I think TCKs are a fine idea. However if this is an open standard developed by a community process then they should be as open as the specification itself and not re-licensed back to the community separately. I hope that Red Hat continues to support opening of the JCP and goes further to support open licensing of the standards and their artifacts. -Andy
  4. Re: Support and Clarification[ Go to top ]

    I meant to say "if FOU terms" rather than "is FOU terms"
  5. One more reason why "standards" are just a waste of time. Sure, go ahead and explain until you are blue in the face as to why standards are so important, better for your IT strategy, an "ecosystem" of vendors etc. At any rate, there is a *need* for skeptics like me in order to balance out some of this nonsense. About the kind of activity I can see as a user on the mailing list of a certain open source project which I will not mention. Discussions about the design, API and usage happen with both the core committers and users participating, in a matter of hours - sometimes minutes. Decisions are made, and implemented, and checked in right there and then. So maybe the JCP is broken. *shrug*
  6. One more reason why "standards" are just a waste of time. Sure, go ahead and explain until you are blue in the face as to why standards are so important, better for your IT strategy, an "ecosystem" of vendors etc. At any rate, there is a *need* for skeptics like me in order to balance out some of this nonsense.
    What product/technology are you referring to. I bet it is based on, and successful because, of many 'standards'. The JCP may be broken, but that is a separate issue from needing standards.
  7. One more reason why "standards" are just a waste of time.
    Standards the reason you can your printer, and your mouse and use it on your computer because of the USB 2.0 standard...every heard of HTTP standard?..XML standard?.. if i build a function in my software and expose it via Webservices(using SOAP standard)...other's can invoke that function..simply because i built it on an "open architecture", its ok to be a skeptic on some things, because it brings about fresh ideas,etc......but the being a skeptic about something like "standards are a waste of time" doesn't make sense. if JCP is broken, send a comment with a recommended fix to the process to the JCP communmity, instead of saying its broken....
  8. One more reason why "standards" are just a waste of time.
    Standards the reason you can your printer, and your mouse and use it on your computer because of the USB 2.0 standard...every heard of HTTP standard?..XML standard?..
    Thanks for the lecture. Maybe my rant about "design by committee" vs open source was not very clear to you.
    if JCP is broken, send a comment with a recommended fix to the process to the JCP communmity, instead of saying its broken....
    Yeah, like that's going to help when Apache has to resort to sending an "open letter".
  9. Maybe I'm evil[ Go to top ]

    But I believe that Sun has the right to retain exclusive access to certain Java markets in order to make money. It's their product and it's their business under which conditions they choose to open-source it. Demanding that they do something with *their* product is just silly. Yes people are free to whine that this isn't as open-sourced as they'd like but no one has the right to demand anything from Sun. No one owes you anything. Why haven't we heard Apache and JBoss demand the same thing from IBM? Why don't you get IBM to open-source their JVM and operating systems without restrictions? I don't know the full contents of the NDA you are referring to but in my experience most of Sun's NDAs are quite reasonable, much more so than most companies. Again I know this isn't ideal in an open-source world but you need to be reasonable not idealistic. You are dealing with a corporation and corporations tend to be very conservative when dipping their toes in the open-source pond. Sun has gone much further than most others in this field and I for one am quite thankful for all their efforts. I think it is reasonable to expect Sun to open-source more stuff every year at JavaOne. Give it time. When they see that everything is going well and their company make money alongside the open-source community they will open up further. Just my 2 cents.
  10. Re: Maybe I'm evil[ Go to top ]

    Gili, Apache(ASF) is simply asking Sun to honour the agreement it made that any JSR could be implemented by the ASF under the Apache License(AL). This is what Sun owes the ASF for its participation in the JCP - as per the agreement it made with the ASF. http://jcp.org/aboutJava/communityprocess/announce/LetterofIntent.html The ASF isn't asking Sun for their product - just the right to create and release its own Java implementation. Unfortunately the (FOU) conditions Sun placed on the JCK (without which the ASF can't actually call its implementation Java) meant that the ASF's implementation couldn't be released under the Apache License. All the NDA stuff is something else - and I agree with you Sun has made great progress with open source especially OpenJDK (which IMO is a great move) - but this is nothing to do with that - its simply a case of Sun breaking its agreement with the ASF. Theres alot of anger in the ASF by Sun's breach of its agreement - not just that Sun has screwed the efforts of an ASF project - but taking the ASF's Participation and then refusing to give what they owe in return - what would you call that? Its a great shame, since Sun has done so much that they can feel proud of - but this one thing is not worthy of them. They need to sort it out. Niall
  11. Re: Maybe I'm evil[ Go to top ]

    The ASF isn't asking Sun for their product - just the right to create and release its own Java implementation. Unfortunately the (FOU) conditions Sun placed on the JCK (without which the ASF can't actually call its implementation Java) meant that the ASF's implementation couldn't be released under the Apache License.
    IANAL, but the above isn't about implementation, you are still free to implement any JSR - the JCK is about testing the implementation, not anything to do with how the implementation is actually arrived at.
    All the NDA stuff is something else - and I agree with you Sun has made great progress with open source especially OpenJDK (which IMO is a great move) - but this is nothing to do with that - its simply a case of Sun breaking its agreement with the ASF.

    Theres alot of anger in the ASF by Sun's breach of its agreement - not just that Sun has screwed the efforts of an ASF project - but taking the ASF's Participation and then refusing to give what they owe in return - what would you call that?

    Its a great shame, since Sun has done so much that they can feel proud of - but this one thing is not worthy of them.

    They need to sort it out.
    Again, there is an issue of ambiguity here - which you may be able to rectify in succinct detail from the jcp or apache records - but the issue here is not actually about you implementing one, or any number, or JSRs but actually on whether you can 'call' you implementation something through running a test suite on the implementation - isn't this after you've actually implemented the JSRs? Why doesn't Sun offer to run these tests for you and give you the results, or is even that too much of a compromise for the ASF?
  12. Re: Maybe I'm evil[ Go to top ]

    Calum, The problem is not SUN's implementation at all. The problem is much simpler. SUN is leading a JSR, an important at that, and the output of that is a spec, a TCK (to test NEW implementations) and an RI. Fine. Now, if I were to develop my OWN implementation of this spec and test it again the TCK (and let's say it is compatible), then I would expect to be able to market it, right? Well, no it seems: SUN is putting for ADDITIONAL field-of-use restrictions in its license that have nothing to do with the original spec. Another example of a field of use restriction would be to say "you can make an implementation of my JSR but I only allow you to run it on DELL and HP computers". Would you think it is fine? Would you call it an Open Standard? Cheers, Sacha CTO JBoss, a division of Red Hat.
  13. Re: Maybe I'm evil[ Go to top ]

    The standard is open, yes. The implementation may not be approved by sun for certain uses. This means you can't put "approved by sun" or similar label against your product. This is to save the consumer of picking up a product and finding it doesn't work in certain uses. I see this as Sun protecting users. And I find that to be very admirable of Sun. I think apache/jboss are protecting their developers/business - not the users of their products. Also if the TCK doesn't have enough tests for all known types of uses of a JVM, then it seems okay for Sun not to associated with a rogue company passing the TCK and selling their on usage that wasn't tested. Regards, Jitendra
  14. Re: Maybe I'm evil[ Go to top ]

    Jitendra, Sun is not trying "to protect people": if that was the case, they would apply this field-of-use restriction to their own implementation - open source or not - which they don't. Open Standards are supposed to promote equal playing field. Again, you are mixing an implementation and the standard. You might want to read what the JCP is about and how it is supposed to work. Cheers, Sacha CTO JBoss, a division of Red Hat
  15. Re: Maybe I'm evil[ Go to top ]

    I don't have the inclination to read what the JCP is about. However, I do understand that JBoss commercials may not be aligned with Sun's in this instance. But, that business, I think. Regards, Jitendra
  16. Re: Maybe I'm evil[ Go to top ]

    I don't have the inclination to read what the JCP is about.
    Which probably explains the quality of your opinion on a JCP-related matter.
  17. Sacha, I believe your analysis of open standards is naive. Although Sun may cow-tow to this immense pressure being exerted by some of its main colleagues in the JCP, I don't think it will be because of some altruistic 'level the playing field' crap. Open standards are for business purposes, implemented to reduce larger-than-necessary costs for migration; you don't honestly think that Oracle is supporting every software standard in the world because they want to make it easier for would-be competitors? No, its because the market dictates what is a customer-driven exercise in the acquisition of software... Whether or not Sun signed the JSPA, and is legally bound by it is beyond my understanding, I would have to believe that the Sun Legal Relations department wouldn't have done that P.R stunt with Apache in '02 with the purpose of tying their hands in the future open source options around Java...but I could be wrong... Whether or not Sun can risk the support of the vast majority of JCP participants is the real issue, if the legality is not in question, and here I would suspect that it may come down to IP ownership: does IBM have enough invested in the JDK technologies to thwart a Sun move to co-opt the platform? It would go against Sun's history of being inclusive and "fair", which has ultimately served their business purposes, and would usher in a new approach for Java participants, where they know that Sun is trying to take over the distro. of Java, uniquely... Coupled with Glassfish, openJDK could be a major competitive thread that would cause JBoss consternation, right?...So ultimately, as the Sun legal team figures out what their options r, the Sun executive team will have to figure out where, if ever, do they draw a line in the sand, and tell the JCP: thanks for your work, we're done here...I agree with you that is a crazy/frightening proposition, but it is one that is not entirely out of the real of reason...
  18. Douglas, Sun has a lot of power as part of the JCP. However, they gave one real power to the EC - only one but a strong one: a "negative power" i.e. while the EC cannot force a YES vote on a platform JSR, they can force a NO vote on any JSR, including the platform JSRs. Cheers, Sacha
  19. http://jcp.org/en/jsr/results?id=4298 - a few notable comments:
    "IBM votes NO on this JSR because the submission provided by the Specification Lead appears to be inconsistent with the terms of the Java Specification Participation Agreement (JSPA)."
    "Intel Corp. voted No with the following comment: The Spec Leads need to assure the community that the licensing regime for JSR 280 will meet the spirit and the letter of the JSPA. Our preference for accomplishing this would be for the Spec Leads to provide the text of TCK and RI licenses that they commit to offer to any interested party and that meet the requirements of the JSPA. Questions on this JSR from the EC have focused on the RI license. The Spec Leads have distributed to the EC a sample RI license. While we have no objection to the Spec Leads offering that license as one alternative, its restrictions on redistribution make it unacceptable in the role of the fulfilling the Spec Leads obligations for RI licensing as expressed in the JSPA. To avoid any possible confusion, we note that RI licensing is a separate and distinct issue from TCK licensing, which has potentially a more wide-ranging impact than RI licensing, as exemplified by the situation encountered with JSR 176 Java SE 5. The Apache Open Letter on JSR 176 Java SE 5 claimed that field of use restrictions are being imposed on how Independent Implementations of the spec can be used. JCP requirements for licensing compatibility tests must not be used to limit or restrict Independent Implementations of JCP specs. We would be more comfortable if the Spec Lead had supplied a complete sample TCK license, but we are hopeful that, nevertheless, TCK licensing will not be an issue for JSR 280."