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: [Draft] New ASF/JCP Policies
Date Fri, 29 Jun 2007 12:40:18 GMT

On Jun 27, 2007, at 8:12 PM, Jeff Genender wrote:

> My concern here is where we are going with this.  I apologize in  
> advance
> if I missed something regarding the JCK vs TCK with respect to  
> Harmony.
>  If I did, please point it out.
>
> I asked in a previous email about the open letter to Sun about if  
> anyone
> has made direct contact with those folks instead of expecting a public
> response to the open letter.

yes.  They aren't responding.  I had a conversation at JavaOne with a  
few people, and at that time, they were holding their ground.

I expect it will soften over time.

> Calling a company out publicly may be a
> bit much to expect a public response.  I just hope that we have  
> followed
> through with the personal side before being heavy handed.  Again, I  
> may
> have not been privy to past discussions so it possible I am not seeing
> this with full view.

Yes, we did.  For months.

>
> I think the issue of JCK vs TCK and our stance is a difficult one.  I
> would hope we do not cut off our nose to spite our face.  As I
> understand it, the JCK is a different testing animal than the TCKs.
> They test different things AFAICT.

Nope.  It's just a TCK.  it tests a different JSR, but it's just a  
TCK.  It's conceptually no different than the J2EE TCK.


>
> The TCKs allow our products to compete in the market place with
> commercial and other open source offerings (non-Apache).  I think our
> ability to pass these TCKs allows us to have people in the community
> want to adopt our products, and ultimately helps us build even more
> community and followers.  It allows folks to take us really seriously.
> But stopping or hindering our ability to obtain and use newer TCKs  
> will
> likely have the effect of people not wanting to adopt some of our
> products because they are not "certified" or do not pass certification
> tests.

>
> I believe this is a large risk to take because Sun will not bend to a
> JCK license or has not responded publicly to the open letter.  I think
> risking several projects' ability to continue adoption due to
> certification with respect to an issue with Harmony is something we
> should really examine carefully and weigh the risk vs reward on  
> what we
> are about to do.
>
> I would ask that we see if we have exhausted all efforts to
> communication with Sun on this issue and do a risk/reward analysis on
> steps moving forward.
>
> Thoughts?  Can I help with this somewhere?
>
> Jeff
>
> Joe Schaefer wrote:
>> Matt Hogstrom <matt@hogstrom.org> writes:
>>
>> [...]
>>
>>> One question I have on the FOU restriction for the Java TCK is what
>>> would happen if we did certify Harmony with the TCK under its  
>>> current
>>> terms?
>>
>> Then we've broken a covenant with our users, that stuff downloadable
>> from apache.org is licensed at least as liberally as the Apache  
>> License
>> allows.  A click-through agreement on the installer would probably be
>> required to faithfully implement the FOU restrictions.  Yuck to that.
>>
>> The real question would be: who else besides Apache would actually
>> distribute it, if harmony+FOU doesn't even qualify as open source
>> software?
>>
>>> I would assume that this means that people that download a certified
>>> binary would have to be shot if they used it in a Kiosk.  But  
>>> what if
>>> someone grabbed the code from a particular release and built it
>>> themselves.
>>
>> Then I think whatever patent and trademark claims Sun has on the  
>> software
>> remain intact, although Geir's opinion is probably what you need to
>> be hearing.  We don't know what the explicit patent claims are,  
>> because
>> Sun won't disclose them, but it's reasonable to assume that any
>> implementation of Java infringes on patents owned by or licensed  
>> to Sun.
>>
>>> Are they under the terms of the license?  I would think  
>>> presumably not
>>> as the certification is on a binary and not an svn rev number.   
>>> IANAL
>>> so I don't know the ramifications of this scenario.
>>
>> Our license only covers IP contributed to Apache, which Sun has not
>> done in the case of harmony.  As I understand the JSPA, we rely on
>> passing the TCK to get the "necessary IP" from the spec lead, so we
>> can distribute TCK-passing software under the Apache License alone.
>> I don't know if a source-code distribution would fall under that IP
>> grant if the corresponding binary passed the TCK.  If it doesn't,
>> then that's probably another defect in the JSPA we should try to get
>> addressed.
>>
>>> I guess my point is we should evaluate what TCKs and projects we
>>> participate in based on their individual merits and not do a  
>>> sweeping
>>> non-NDA position going forward.
>>
>> That would undercut the ability of Apache to speak on the issue
>> with one voice.  If we're just a federation of projects and  
>> there's no
>> reason for spec leads to deal with Apache projects uniformly, then
>> they won't.  That's the lesson I'd take away from harmony to date.
>>
>> IMO we need to stop trafficing in NDAs if we're really producing
>> software for the benefit of the public.  The public needs to be
>> able to inspect those third-party IP agreements on the software
>> they are downloading directly from us.
>>
>>> I think the license is freedom of expression and if folks have
>>> limitations in them we don't like we don't have to work with the IP.
>>
>> Part of the problem here is that an NDA limits freedom of
>> expression.  The other part of the problem is that we can't
>> just walk away from J2SE now that we've put so much time
>> and energy into it.  Maybe walking away from 1.5 is the right
>> thing to do, but there's no guarantee 1.6 or 1.7 will be any
>> better, and allowing Sun to shift our goal posts like that
>> is simply unfair.
>>


Mime
View raw message