www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: Looks like Sun responded to the Open Letter
Date Sun, 12 Aug 2007 23:00:46 GMT

On Aug 12, 2007, at 5:56 PM, Dalibor Topic wrote:

> Chris Gray <chris.gray@...> writes:
>
>>
>> On Sunday 12 August 2007 05:30, Geir Magnusson Jr. wrote:
>>
>>> No - we have no standing in any "rift" related to the GPL TCK, since
>>> we don't distribute software under the GPL.  Dalibor may have a
>>> problem, if he tries to get a license to certify Kaffe + GNU
>>> Classpath, but I can't predict what will happen there.
>>
>> IIRC Dalibor has been trying for years to get a TCK license for  
>> Kaffe under
>> the "scholarship" programme, without success - where success is  
>> defined as
>> meaning "under conditions which make sense for the open source  
>> project in
>> question". Rich's blog seems confirm what some of us had long  
>> suspected -
>> that the whole scholarship thing was a sham, and Sun never  
>> intended to give
>> TCK access to an independent free implementation.
>>
>
> In a project like Kaffe, that doesn't have a corporate sponsor, it  
> makes sense
> to reuse as much code as possible from other projects.

Same with Harmony.  Less is more.

>
> Almost all TCK licenses I've seen or heard of, including the  
> current OpenJDK TCK
> license, have NDA-like restrictions on communication. Such  
> provisions make it
> very hard to deal with potentially tons of issues raised by the TCK  
> effectively
> in a federated project, like Kaffe, where I have to talk to GNU  
> Classpath and
> other independent projects about fixing them. For projects like Kaffe,
> certification can not possibly work under NDAs, unless the expected  
> amount of
> issues raised by the TCK is minimal.
>
> So yeah, the JCP has always been discriminatory. The NDA  
> requirements draw a
> sharp line between those playing within the system and those  
> outside it.
>
> I understand the business advantage for those playing within the  
> NDA system:
> privileged access to the secret sauces during the making of JSRs  
> lets them
> exploit that informational advantage financially by being first to  
> market, etc.
> That sort of discrimination is system-endemic, i.e. the JCP works  
> that way
> because the last round of EC members deciding on it designed it  
> that way.

I'm not so sure.  The primary intent is to let companies "open the  
kimono" when it comes to their technologies and products to a small  
group (the EC) such that if their ideas or technology is rejected,  
they can "take it back".

I think that there are many cases where EGs work openly and "first  
mover" advantage is quite weak.  EJB3 was one such example.

>
> That, unfortunately, is not a problem one can really fix from  
> outside the JCP.
> It's not a problem anyone except the EC could really fix. And I  
> don't think it
> will, as there is no current EC member that is going to fight  
> against NDAs, or
> fight against tying in proprietary software into JSRs, be it RIs,  
> or TCKs.

But you're confusing things here - your theory about NDAs giving  
advantage to the signatories is reasonable, but having a proprietary  
RI or TCK doesn't give anyone an advantage because of the license.

>
> It's clearly not in the interest of all the proprietary software  
> vendors on the
> EC, and the independents on it all probably have their own good  
> reasons why they
> didn't pick up such a fight so far (for example because they'd  
> likely lose it
> given the current distribution of seats between independents and  
> proprietary
> software vendors).

Again, I don't understand your argument here.   I think that EG  
activities are trending towards the totally open.  One counter- 
example is Java SE 7, which seems to be happening outside of the JCP,  
entirely inside Sun.

>
>> Best thing is for all concerned - ASF, FSF, the various Classpath- 
>> based
>> projects - to keep hammering at Sun to live up to their promises  
>> and actually
>> make the Java language as free as most of the alternatives are.
>>
>
> JCP's fundamental problem is that it is heavily rigged in favor of  
> proprietary
> software vendors, and those within the system, at the expense of  
> those outside
> the system, who end up having to deal with the results of business  
> models based
> on keeping vital parts of the secret sauce proprietary. All the  
> other problems
> follow from that.

Maybe.  I think the JCPs fundamental problem is that it's a set of  
contracts with one single commercial organization, Sun, as party to  
each of those contracts.  The JCP *used* to be rigged in favor of  
proprietary software vendors, since open source wasn't possible (the  
ASF fixed that), and if we don't get Sun to do the right thing wrt  
the Java SE TCK, it will *still* be rigged.  But I have hope we'll  
fix that.

>
> Unfortunately, turning around Sun only changes one vote on the EC.  
> That's not
> sufficient in order to fix the JCP.

Well, right now, they are the only member of the EC that is trying to  
rig the game for themselves by trying to dictate control of *any*  
implementation of the JAva SE runtime, so I think if you fixed that,  
you'd have a decent environment to work in.

>
> There are two long term strategies I'd use to fix that problem: a  
> soft one and a
> hard one.
>
> The soft one is to create advantages for free software  
> implementations of JSRs
> over proprietary ones, so that the value of proprietary JSR  
> implementations
> decreases over time, and therefore the companies behind them lose  
> the incentive
> to rig the system in their favor. No money, no problem.

That wouldn't be an open standard, and actually contrary to the  
notion of freedom, isn't it?  Let others distribute their IP as they  
choose....

>
> The hard one is to use elections to gradually replace those members  
> of the EC
> who don't vote against JSRs with NDAs, or proprietary TCKs or  
> proprietary RIs by
> those that would do that, until a sufficient majority on the JCP EC  
> exists to
> ensure that no such JSR can pass through ever again. Then, codify  
> that as a
> change to the JCP and make it permanent, to make sure that we don't  
> have to keep
> that majority all the time. Problem fixed for good.

I think that could be useful, but first lets see what the current EC  
does to solve the "rogue member" problem that we have now.

>
> I don't know if the ASF is the right place for pushing through  
> either strategy.
> I think there is some value in a two pronged approach, where the  
> ASF gets to be
> all 'pragmatic', and others get to be all 'radical'.

Color me pragmatic.

geir

>
> cheers,
> dalibor topic
>


Mime
View raw message