It’s just data

Inconceivable

Dalibor Topic: I think you simply landed in a corner their business plan didn’t foresee

This is an important topic.


Yeah Right Dalibor!!! That is the WHOLE plan! Not a corner/edge case. You will see this pop up more and more, this is just the beginning.

Posted by Davanum Srinivas at

I prefer to approach such politically interesting topics from a naive position. I’ve tried being cynical for a couple of years, and as much fun as it is, it doesn’t work as well as giving people enough benefit of doubt to allow for them to (eventually) do the right thing.

Posted by Dalibor Topic at

I should add what I believe the right thing to be: mandating free software TCKs and RIs for every JSR passing through the JCP.

Posted by Dalibor Topic at

Dims: there are five stages of grief.  The sooner you can get to stage 5, the better off you will be.

Dalibor: you can certainly chose to be naïve, but it took me mere seconds to find that Sun was aware of, and actively “working” this precise issue, months ago.  In any case, a JCP requirement that TCKs and RIs are either truly free, or simply free of FOU restrictions, would simply mean that we will never see a JSR for Java™ SE 7 Release Contents.

Posted by Sam Ruby at

We may see one that comes with a non-free TCK, but I don’t think it should pass the final ballot stage (or any other JSR with a non-free component).

Achieving the necessary majority for that is a project that could take some three to four years, but that’s the nature of the thing: creating the environment in which Java made sense as Free Software to a lot of people took a couple of years, too. Creating an environment in which all components of a JSR make sense as Free Software to those leading such JSRs will take a couple of years of selective pressure, nudging along, etc.

If the JCP ends up being the wrong environment for that, the community will route around it.

Posted by Dalibor Topic at

Achieving the necessary majority for that is a project that could take some three to four years

Your estimate is too conservative.  This has already been achieved.  The outcome is already so obvious that no spec lead would be so foolish as to propose such a JSR in the first place.

If the JCP ends up being the wrong environment for that, the community will route around it.

There is no question in my mind that this community will simply route around the JCP.

P.S.  Those who register get some relief from some of my spam throttle.

Posted by Sam Ruby at

I’m not so sure about a pro-free software JCP majority being achieved yet.

Looking at JCP.org I see a couple of ‘focussed’ JSRs. One of them, 319, says that its TCK will be open source in one paragraph, but then claims in the next that “The TCK will be licensed under a standard Community Source License.”, which reads to me like the useless SCSL, or some pointless Microsoft shared source license. I have never heard of a standard community source license from the JCP, never mind an open source one. The spec lead is Ericsson.

JSR 249, led by Open Cloud, comes with the following explanation: “The TCK is licensed by Open Cloud, this license will be a standard Open Cloud Community Source License.” Looking at the OpenCloud license, it’s rather obviously not open source in any form or shape. This JSR has made it to the proposed final draft stage - without anyone on the SE JCP EC objecting to a non-free TCK license.

JSR 284, also managed to get to the proposed final draft stage, without anyone on the SE EC taking notice of its proprietary TCK. It’s spec lead is Google. Maybe Google should start a summer of TCKs for its spec leads ... ;)

JSR 254, and JSR 264, both have something to do with something called OSS/J, which has some strange licensing scheme called the OSS/J Harmonized Licensing and Certification Model, which prohibits modifying the classes in the javax.oss name space. Clearly not open source, yet no objection from the SE EC to the spec leads Nokia and Nakina Systems, so the proposals have sailed smoothly to the proposed final draft stage.

I could go on and on, afaict.

I doubt that this year’s JCP ECs will be much different from last year, as Red Hat, ASF and Nortel have all been re-ratified, so I don’t think the ECs will be more inclined to put an end to the current practice of tying in proprietary software into ‘community’ standards, than they were in the past couple of years.

It will take a new EC membership to clean up with the past.

Posted by Dalibor Topic at

I stand by my prediction that there will not be a JSR for Java™ SE 7 Release Contents, that the PhoneMe “community” will simply route around the JCP, and that therefore the constitution of the JCP EC is moot.

Posted by Sam Ruby at

Sam, You are right!

Posted by Davanum Srinivas at

Hi Sam

Having problems viewing your August archive (badly formed xml I believe):

XML Parsing Error: not well-formed
Location: [link]
Line Number 310, Column 15:</svg></div>J<<wbr/>del title="Community"><wbr/>C</<wbr/>del><wbr/>P</a>
--------------^

regards
Al

Posted by Al at

Having problems viewing your August archive (badly formed xml I believe)

Fixed.  Thanks!

Posted by Sam Ruby at

Dalibor, let me be cynical and, after so many discussions and JCP conflicts going on, I think I deserve my right to be cynical. Your sentence looks exactly like what Sun would say if willing to keep us frozen and silent behind NDA curtains. It could be further rephrased from Sun as:

I prefer you to approach such politically interesting topics from a naive position.

I’m already tired of Sun’s FUD, and looking to only use free computer languages like python, ruby, perl, PHP  or erlang if I can avoid doing otherwise.

My position, and my vote in case anybody asked for it, is to completely ignore Sun and proceed releasing $independent_codebase without access to any JCK or (hypothetical)IP, to see if Sun wants to shut down open java publicly or if they just want to keep us quiet for another year. In other words, call their bluff. Eeven if this is not enough for commercial users in, say, the embedded space, it is enough for keeping the technical ball rolling and allow for “self-assembly” kits for some platforms.

Posted by Santiago Gala at

Santiago, if you are against NDA curtains, please make sure that Geir votes for the ASF against all JSRs for review at the EC he’s been voted back that come with NDA-like restrictions. If I was on the JCP EC or a member of the ASF, I’d be doing that.

I’ve also listed a couple of focused JSRs that would warrant a NO vote from people who don’t like to see proprietary TCKs pass through with ASF’s implicit approval. I’d suggest kicking off a discussion on jcp-open about how the ASF is going to vote on those.

The list has been pretty dead over the past months, and the re-ratification of the ASF should provide some incentive to see how the next term ASF has been granted by the JCP membership can be used to drag the JCP kicking and screaming away from its desire to be subservient to proprietary software companies interests, rather than promoting the union of open source and open standards.

The hard route in the JCP, organizing the resistance to the corporate interests, will require a new membership of the JCP, though, or at least the existing EC members to replace their current strategy of complicit acceptance of the proprietary-by-default status quo with something else, and new presumably new heads, to be plausible.

It’d be very short-sighted to paint Sun, or ASF as the exclusive bad guy in this conflict, like people on both sides have tried to, as fundamentally the problem is that all of the JCP EC membership in the past 5 (five) years, including Sun and ASF, has not been doing enough to think about how the JCP should function in a world where open source everything is the default way of doing things, and act on that. I’ve been talking about how to do it since 2002, and I’ll tell it again:

The JCP must require that all software components of a JSR to be open source.

It’s that simple. And the fastest way to get there without wasting time on changing the JSPA is to vote accordingly in the EC when JSRs come up for vote.

But that’s not a position the ASF can manage to get behind, as discussions on jcp-open have shown so far, so ... it’ll be up to individuals to get voted onto the EC starting from this year, to start cleaning up the mess the current and former EC members have created by letting everyone get away over the past years with tying their proprietary code as necessary parts of open standards.

If the JCP feels as powerless as the US congress, that’s because its elected members chose to be powerless.

Posted by Dalibor Topic at

I stand by my prediction that there will not be a JSR for Java™ SE 7 Release Contents, that the PhoneMe “community” will simply route around the JCP, and that therefore the constitution of the JCP EC is moot.

Posted by Sam Ruby at

I don’t quite understand, do you suggest doing nothing, and waiting to see if your prediction comes true or not?

Posted by Dalibor Topic at

I am suggesting that if people who are members of the OpenJDK Governance Board want the JCP to become relevant again, they should suggest that at some point the code for development of Java 7 features should be based on some sort of specification.

Posted by Sam Ruby at

I’d assume that much would be obvious, no? I guess the fun questions are when, and how the JSR feedback loop works with an open source RI, but the JCP offers a broad set of good and bad examples to follow on that.

Posted by Dalibor Topic at

I’d assume that much would be obvious, no?

It would be obvious if any members of the OpenJDK Governance Board actually called for such publicly.  Conversely, it would be equally as obvious if none such has chosen to do so.

I guess a third possibility would be that the OpenJDK prefers to operate in a closed and secretive manner.

At the present time, I see the third as unlikely, the first as clearly lacking evidence, so my bets are on #2.

Posted by Sam Ruby at

Per popular demand, then: [link]

Posted by Dalibor Topic at

Thanks!

As a request: try not to let item #2 ("constitution") complete without something that guarantees that item #11 ("J7 JSR") will also complete.  Something along the lines of a requirement that all runtime code in the OpenJDK be constitutionally limited to implementing code that implements a JSR.

Posted by Sam Ruby at

The constitution of a project should describe its governance structure, not limit the scope of what people can do with the free software code within the project.

Posted by Dalibor Topic at

It would see odd to me if the OpenJDK project were to develop and release software that is known to be incompatible with the relevant TCKs.  So while the software produced should remain Free (or, at the very least, Open), I would suggest that the governance model of the the OpenJDK and the specs that define the very scope for this project are very much linked.

My fear is that a long list like the one you provided leaves open the possibility that a year from now that claims that “around 90%” of these items will have been addressed, and that “real progress” is being made on the rest, whereas the actual truth will be that amongst the unaddressed 10% will be some important topics.

Posted by Sam Ruby at

I expect that there will always be important topics on the table, so there will always be some club to whack OpenJDK over the head, if one feels like it, as with any other project of the scope and size. If IBM joined in and started contributing, they could make sure that the topics dear to their heart are addressed in a timely fashion, though, as the OpenJDK membership will always have the opportunity to modify the constitution to suit their desired mode of governance better.

Just because I think that OpenJDK and JCP are two orthogonal issues, for many reasons, doesn’t mean that in the future the prevalent opinion wouldn’t be a different one. And that’s a good thing, as communities change as they grow, and they need to be able to make sure that they are not hindered by the ‘one true way’ of governance being set in stone.

For research projects related to OpenJDK, for example, I think that hosting them within OpenJDK would be a good idea, as it would make it easier it integrate their work if it bears fruit. On the other hand, constitutionally forcing researchers to become JCP members, and find enough people interested in what they do who are also JCP members, and run a JSR, and so on, before they start working on their research project, would be a silly requirement, in my opinion.

Posted by Dalibor Topic at

I stand by my prediction that there will not be a JSR for Java™ SE 7 Release Contents, that the PhoneMe “community” will simply route around the JCP, and that therefore the constitution of the JCP EC is moot.

Posted by Sam Ruby at

Repeating that over and over again does not make it more or less true, or a response to what I’ve said.

Any chance of switching to plain English for the sake of having a conversation?

Posted by Dalibor Topic at

Plain English: I don’t think we have much to talk about at this time.  What I want to talk about is a JSR for J7 in a predictable time frame.  You want to talk about hypothetical research projects.  I’m not particularly interested in the latter, at least not at this time.  Whenever I want to talk about the former, you bring up other JSRs that again may be relevant to you, but again aren’t relevant to me.

Seeing the one thing I care about tossed into a lengthy list  of things that might or might not be accomplished in 2008, coupled with statements that “there will always be important topics on the table”; well frankly, I’m even more pessimistic than I was before, if that is indeed possible.  Which is quite a feat as I’ve seen five years of broken promises.

Perhaps we should pick up this conversation again when we have common interests that we both want to talk about.  Meanwhile, I have other areas that I wish to poke and prod.  This Android thing seems interesting.

Posted by Sam Ruby at

Thank you for being frank.

I don’t think that starting J7 before we have removed the remaining proprietary encumbrancies makes sense, and that’s something IBM could help fix faster.

In what time frame do you think IBM could manage to run through the red tape with Sun, and actively work on fixing the encumbrancies?

Posted by Dalibor Topic at

Dalibor, have you clicked on the Disclaimer link on the right?  IBM is a fairly big place and I have virtually nothing to do with IBM’s involvement with the JCP.  Until fairly recently, I could have said absolutely nothing, but a few months ago, I had two meetings with them where I shared the same prediction that I have repeated often here.  (I also have had numerous meetings over a long period of with other areas of IBM that intersect with the ASF in many ways, primarily on the development sides, and some of them are undoubtedly work with people who are in contact with the people that represent IBM on the JCP EC).

I do, however, have a direct and continuous relationship with the Apache representative on the JCP; and try to maintain a firewall of sorts between my IBM and Apache activities.  For example, I read and commented on early drafts of the Apache Open letter, but left it to others to work with the other EC members on this issue.

More personally, I undoubtedly could make it my business to get in touch with the people on the EC (as could you), but I have little interest in doing so.  You see, I don’t believe that the key issue is encumbrances, but integrity.  From my perspective, you don’t fix an agreement with a party that is unwilling to hold up their end of the bargain by forging another agreement.

Posted by Sam Ruby at

Thanks for the pointers, Sam, I’ll try to get in touch with the right people.

Posted by Dalibor Topic at

Add your comment