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: servlet 3.0 (JSR-315)
Date Mon, 02 Jul 2007 17:54:10 GMT

On Jul 2, 2007, at 12:52 PM, Sam Ruby wrote:

> On 7/2/07, Geir Magnusson Jr. <geir@pobox.com> wrote:
>>
>> On Jul 2, 2007, at 7:08 AM, Sam Ruby wrote:
>>
>> > On 7/2/07, Geir Magnusson Jr. <geirm@apache.org> wrote:
>> >> Bill Shannon, spec lead for the new JSR-315 (servlet 3.0),  
>> confirmed
>> >> that there will be no FOU restrictions for the TCK for this JSR.
>> >>
>> >> Unless there are any objections, I intend to vote "yes" on  
>> behalf of
>> >> Apache for this JSR. (today)
>> >
>> > Will NDAs be required to access to TCK?  Will development of  
>> this JSR
>> > require a private mailing list?
>> >
>> > If the answer to either of the above two is either 'yes' or  
>> 'unknown',
>> > then I VEHEMENTLY object, and call for others on this mailing  
>> list to
>> > do so too.
>>
>> I've pondered this for a few more minutes, and I think it's
>> unreasonable to expect that the JCP EGs can work w/o any private
>> list, when our own projects don't work without a private list.
>>
>> Clearly, if we're going to drive "the Apache Way" (whatever the hell
>> that is...) into the JCP EGs working behavior, this can't be by vague
>> fiat.
>>
>> The servlet JSR has a public list, and a private list.  I think that
>> the real question is how that private list will be used.
>>
>> I think that we should :
>>
>> 1) note our support for working in the open (it's like "the Apache  
>> Way")
>> 2) in our vote, also note that we expect them to do technical work in
>> public
>> 3) we will have people on that EG -> let *them* report back to us if
>> the EG is doing technical development in public (and see if the EG is
>> reacting to ASF representation urging them to do the tech work in
>> public).
>> 4) If they don't - if they do things in secret - we vote "no" on
>> future votes for that JSR.
>>
>> This don't solve the NDA for TCK issue of course.
>
> First, I believe that we should limit our comment to exactly what
> Niall posted, nothing more, nothing less.  Well, something less: I
> still strongly feel that a YES vote is highly inappropriate at this
> point.
>
> Second, upon reading http://jcp.org/en/jsr/detail?id=315 more closely:
>
> "We will leverage the collaborative tools provided by the java.net
> infrastructure. We have established the "servlet-spec-public" project
> on java.net. Therein, we will have a public issue tracker for tracking
> most issues. Any issues that absolutely must be EG private will be
> handled with a separate EG-private issue tracker. We will have an
> EG-private mailing list. The reference implementation will be
> developed entirely in the public GlassFish project on java.net. The
> TCK will be developed privately by Sun. We will leverage the Early
> Draft feature of JCP 2.6 to allow the public to see the spec in
> progress."
>
> A few things to note.  First, Apache Tomcat will no longer be the
> reference implementation.  Does that cause anybody here any concerns?

Nope.  Once they did glassfish, it was game-over for Tomcat as the  
RI.  Maybe you missed that whole brouhaha? :)

>
> Second, this proposal indicates that they will operate mostly in the
> public, except for the TCK.  So that isn't the biggest concern.

Right - they are going to write the TCK themselves.  If they wrote it  
in public with community help, they couldn't whine how expensive it  
us to be the Java EE spec lead, and therefore justify the license fees.

>
> Our biggest concern should be over TCKs, both in terms of FOU and NDA.

Agreed, which is why I pushed back.  We can hold them to the implicit  
commitment of transparency :

"Any issues that absolutely must be EG private will be handled with a  
separate EG-private issue tracker. We will have an EG-private mailing  
list."

where our representatives get to be the judge of "must".

We have the commitment for no FOU.  The remaining thing is the NDA  
for the TCK, which - despite my opinion and our agreement of what the  
ASF should do re them - I do have reservations in us trying to tell  
them how to license.  Why?  Our messaging around the Java SE TCK  
debate has been that we're sticking to the letter of the agreement -  
we're not asking for anything that we haven't already agreed to, and  
that Sun hasn't agreed to.  For example, people tried to confuse the  
issue w/ us asking for the TCK as open source, which has nothing to  
do w/ the Java SE TCK.  We're not - we're asking that Sun stick to  
the deal.

Now, we've worked long to support open-ness in how EGs operate, so  
encouraging transparency and voting based on transparency is easily  
defendable as part of our work over the years.  But no NDA for TCK?   
That's out of the blue.

I'd be happy to make it clear in our vote comment that we believe  
that TCKs should be available w/o NDA, and will consider this a major  
factor in the final vote for the JSR.

geir




Mime
View raw message