You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jcp-open@apache.org by Sam Ruby <ru...@apache.org> on 2007/07/05 01:46:46 UTC
Are proprietary TCK's compatible with open standards?
We need to find a way forward, a way that breaks the JCP loose from the
"corrupting"[1] influences that so evidently drive it today. So in the
spirit of brainstorming, I'm forwarding on to this mailing list a notion
expressed by Dalibor Topic[2]:
"Proprietary software should not be allowed to be tied in as a
fundamental part of an open standard in any form."
"It doesn't matter if such software comes from IBM, Sun, Oracle,
BEA, Red Hat, Google, Nokia, or someone else. It doesn't really
matter what the restrictions are, either."
"If the TCK is proprietary, a JSR needs to be voted down, until it
is resubmitted with that bug fixed."
My initial thoughts: is this step necessary? No, not if there are
viable other alternatives. Is this sufficient? Actually, yes. It
would neatly solve both the FOU and NDA issues. It has the added
benefit of addressing the behavior as opposed to the person.
So, given that pretty much every idea is being shot down, I for one
could support a policy built around such this notion.
What do others think?
- Sam Ruby
[1] I'm using the word "corrupt" in precisely the sense that Larry
Lessig used it here:
http://lessig.org/blog/2007/06/required_reading_the_next_10_y.html
[2]
http://blog.buni.org/blog/acoliver/2007/07/03/The-Apache-Conundrum#response-4
Re: Are proprietary TCK's compatible with open standards?
Posted by Ralph Goers <Ra...@dslextreme.com>.
Sam Ruby wrote:
> We need to find a way forward, a way that breaks the JCP loose from
> the "corrupting"[1] influences that so evidently drive it today. So
> in the spirit of brainstorming, I'm forwarding on to this mailing list
> a notion expressed by Dalibor Topic[2]:
>
> "Proprietary software should not be allowed to be tied in as a
> fundamental part of an open standard in any form."
>
> "It doesn't matter if such software comes from IBM, Sun, Oracle,
> BEA, Red Hat, Google, Nokia, or someone else. It doesn't really
> matter what the restrictions are, either."
>
> "If the TCK is proprietary, a JSR needs to be voted down, until it
> is resubmitted with that bug fixed."
>
> My initial thoughts: is this step necessary? No, not if there are
> viable other alternatives. Is this sufficient? Actually, yes. It
> would neatly solve both the FOU and NDA issues. It has the added
> benefit of addressing the behavior as opposed to the person.
>
> So, given that pretty much every idea is being shot down, I for one
> could support a policy built around such this notion.
>
> What do others think?
I totally agree. Whether it will be sufficient to change Sun's (or
anyone else's) behavior remains to be seen. I also don't see how it will
influence anything that Apache is not part of, such as Open XML.
Ralph
Re: Are proprietary TCK's compatible with open standards?
Posted by robert burrell donkin <ro...@gmail.com>.
On 7/7/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
> On Jul 4, 2007, at 7:46 PM, Sam Ruby wrote:
>
> > We need to find a way forward, a way that breaks the JCP loose from
> > the "corrupting"[1] influences that so evidently drive it today.
> > So in the spirit of brainstorming, I'm forwarding on to this
> > mailing list a notion expressed by Dalibor Topic[2]:
> >
> > "Proprietary software should not be allowed to be tied in as a
> > fundamental part of an open standard in any form."
> >
> > "It doesn't matter if such software comes from IBM, Sun, Oracle,
> > BEA, Red Hat, Google, Nokia, or someone else. It doesn't really
> > matter what the restrictions are, either."
> >
> > "If the TCK is proprietary, a JSR needs to be voted down, until it
> > is resubmitted with that bug fixed."
>
> I'm interested in how Dalibor is going to resolve the situation he's
> in as a member Sun's hand-picked OpenJDK Governance Board.
i suspect that the problem will be not how Dalibor will resolve this
situation but how sun will resolve Dalibor...
- robert
Re: Are proprietary TCK's compatible with open standards?
Posted by Jeff Genender <jg...@apache.org>.
Geir Magnusson Jr. wrote:
>
> On Jul 4, 2007, at 7:46 PM, Sam Ruby wrote:
>
>> We need to find a way forward, a way that breaks the JCP loose from
>> the "corrupting"[1] influences that so evidently drive it today. So
>> in the spirit of brainstorming, I'm forwarding on to this mailing list
>> a notion expressed by Dalibor Topic[2]:
>>
>> "Proprietary software should not be allowed to be tied in as a
>> fundamental part of an open standard in any form."
>>
>> "It doesn't matter if such software comes from IBM, Sun, Oracle,
>> BEA, Red Hat, Google, Nokia, or someone else. It doesn't really
>> matter what the restrictions are, either."
>>
>> "If the TCK is proprietary, a JSR needs to be voted down, until it
>> is resubmitted with that bug fixed."
>
> I'm interested in how Dalibor is going to resolve the situation he's in
> as a member Sun's hand-picked OpenJDK Governance Board.
>
> Will the open OpenJDK community not be allowed to use the JCK?
>
> (good luck, my fiend...)
My "fiend"? ;-)
>
> :)
>
> geir
Re: Are proprietary TCK's compatible with open standards?
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jul 4, 2007, at 7:46 PM, Sam Ruby wrote:
> We need to find a way forward, a way that breaks the JCP loose from
> the "corrupting"[1] influences that so evidently drive it today.
> So in the spirit of brainstorming, I'm forwarding on to this
> mailing list a notion expressed by Dalibor Topic[2]:
>
> "Proprietary software should not be allowed to be tied in as a
> fundamental part of an open standard in any form."
>
> "It doesn't matter if such software comes from IBM, Sun, Oracle,
> BEA, Red Hat, Google, Nokia, or someone else. It doesn't really
> matter what the restrictions are, either."
>
> "If the TCK is proprietary, a JSR needs to be voted down, until it
> is resubmitted with that bug fixed."
I'm interested in how Dalibor is going to resolve the situation he's
in as a member Sun's hand-picked OpenJDK Governance Board.
Will the open OpenJDK community not be allowed to use the JCK?
(good luck, my fiend...)
:)
geir
Re: Are proprietary TCK's compatible with open standards?
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jul 5, 2007, at 2:34 AM, Justin Erenkrantz wrote:
> On 7/4/07, Bill Barker <wb...@wilshire.com> wrote:
>> I would like business-as-usual, and to use our position on the EC
>> to change
>> the JCP from the inside. With this type of software development
>> increasingly shifting to the OS model, it might now be possible to
>> get some
>> of the other major players in the JCP to go along.
>
> I'm sorry, but we have been trying to change the JCP from the inside
> for the last nine-plus months and Sun refuses to even give talk to us
> any more (i.e. no response to the letter). In my opinion, time for
> playing 'business-as-usual' expired at the moment we were forced to
> publish the open letter. -- justin
From my POV, we're making headway, but only because I think in spec-
group timescales.
You're right about one thing - "business-as-usual" expired the moment
we published the open letter, but it's Sun that applies to, not us.
We shined light on one of the remaining dark crevices of the JCP.
Sometimes sunlight takes time to have an effect.
I counsel patience.
geir
Re: Are proprietary TCK's compatible with open standards?
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jul 5, 2007, at 4:40 AM, Bill Barker wrote:
>
> "Justin Erenkrantz" <ju...@erenkrantz.com> wrote
> in message
> news:5c902b9e0707042334y17ee06a7n52a1fd3348fbf80e@mail.gmail.com...
>> On 7/4/07, Bill Barker <wb...@wilshire.com>
>> wrote:
>>> I would like business-as-usual, and to use our position on the EC to
>>> change
>>> the JCP from the inside. With this type of software development
>>> increasingly shifting to the OS model, it might now be possible
>>> to get
>>> some
>>> of the other major players in the JCP to go along.
>>
>> I'm sorry, but we have been trying to change the JCP from the inside
>> for the last nine-plus months and Sun refuses to even give talk to us
>> any more (i.e. no response to the letter). In my opinion, time for
>> playing 'business-as-usual' expired at the moment we were forced to
>> publish the open letter. -- justin
>>
> IMHO, publishing the open letter was a mistake. Nobody cares
> anymore about
> an open-source Java 5 implementation, so why bother? It is
> yesterday's
> technology. And as I've pointed out, the ASF already approved the
> JSR with
> flying colors.
it's not about Java 5. It's about Java *. Java 5 was the latest at
the time we started the fight.
>
> But with my sysadm hat on, I would never, ever, authorize
> installing Harmony
> until it can pass the TCK headless w/o a terminal installed.
Nor would I :)
geir
>
>
>
Re: Are proprietary TCK's compatible with open standards?
Posted by Bill Barker <wb...@wilshire.com>.
"Justin Erenkrantz" <ju...@erenkrantz.com> wrote
in message
news:5c902b9e0707042334y17ee06a7n52a1fd3348fbf80e@mail.gmail.com...
> On 7/4/07, Bill Barker <wb...@wilshire.com>
> wrote:
>> I would like business-as-usual, and to use our position on the EC to
>> change
>> the JCP from the inside. With this type of software development
>> increasingly shifting to the OS model, it might now be possible to get
>> some
>> of the other major players in the JCP to go along.
>
> I'm sorry, but we have been trying to change the JCP from the inside
> for the last nine-plus months and Sun refuses to even give talk to us
> any more (i.e. no response to the letter). In my opinion, time for
> playing 'business-as-usual' expired at the moment we were forced to
> publish the open letter. -- justin
>
IMHO, publishing the open letter was a mistake. Nobody cares anymore about
an open-source Java 5 implementation, so why bother? It is yesterday's
technology. And as I've pointed out, the ASF already approved the JSR with
flying colors.
But with my sysadm hat on, I would never, ever, authorize installing Harmony
until it can pass the TCK headless w/o a terminal installed.
Re: Are proprietary TCK's compatible with open standards?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 7/4/07, Bill Barker <wb...@wilshire.com> wrote:
> I would like business-as-usual, and to use our position on the EC to change
> the JCP from the inside. With this type of software development
> increasingly shifting to the OS model, it might now be possible to get some
> of the other major players in the JCP to go along.
I'm sorry, but we have been trying to change the JCP from the inside
for the last nine-plus months and Sun refuses to even give talk to us
any more (i.e. no response to the letter). In my opinion, time for
playing 'business-as-usual' expired at the moment we were forced to
publish the open letter. -- justin
Re: Are proprietary TCK's compatible with open standards?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Sam Ruby wrote:
>> > Non-sequitur. I suppose one counter example would suffice to disprove
>> > this? Here's one:
>> >
>> >
>> http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/200707.mbox/%3c673E8E31-3AA9-4931-ACE8-682D478E8706@gbiv.com%3e
>>
>> A 404 isn't very convicing :).
>
> The link works for me. But try this one: http://tinyurl.com/39gjgb
I dunno. I never trust tinyurl's to survive but a day - but your first
link worked just fine, here.
Bill - maybe your email client wrapped the link?
Re: Are proprietary TCK's compatible with open standards?
Posted by Bill Barker <wb...@wilshire.com>.
"Sam Ruby" <ru...@apache.org> wrote in message
news:3d4032300707042212l5df32d00wd7a66655936b5cab@mail.gmail.com...
> On 7/5/07, Bill Barker <wb...@wilshire.com>
> wrote:
>>
>> "Sam Ruby" <ru...@apache.org> wrote in
>> message
>> news:3d4032300707042158o6c2d69c6ga7beb092bb929c00@mail.gmail.com...
>> > On 7/5/07, Bill Barker
>> > <wb...@wilshire.com>
>> > wrote:
>> >>
>> >> > "If the TCK is proprietary, a JSR needs to be voted down, until
>> >> > it
>> >> > is resubmitted with that bug fixed."
>> >>
>> >> Which translates to that we automatically vote down all JSRs, since
>> >> the
>> >> clear language of the JCPA states that *all* TCKs are proprietary (to
>> >> the
>> >> spec-lead).
>> >
>> > Non-sequitur. I suppose one counter example would suffice to disprove
>> > this? Here's one:
>> >
>> > http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/200707.mbox/%3c673E8E31-3AA9-4931-ACE8-682D478E8706@gbiv.com%3e
>> >
>>
>> A 404 isn't very convicing :).
>
> The link works for me. But try this one: http://tinyurl.com/39gjgb
>
Yes, the spec-lead is free to license under any agreement that they see fit,
subject to the limitations in the JCPA, (so, AL/BSD/GPL/LGPL/MPL are all ok,
assuming that they comply with the IP on the underlying code). However, it
is still the spec-lead that is granting the license (what I meant by
"clear-language"). Personally, I don't see that Apache needs an OS license
on the TCK (yes, no NDAs would be nice, but it isn't an ideal world :). So,
since this thread is for discussion points, the more relevant question is
"what form of a license are we willing to accept?", rather than the
red-herring of "proprietary" or not. It is clear that the spec-lead owns
the IP for the TCK, so in that sense it will always be "proprietary" (until
the JCPA changes).
> - Sam Ruby
>
Re: Are proprietary TCK's compatible with open standards?
Posted by Sam Ruby <ru...@apache.org>.
On 7/5/07, Bill Barker <wb...@wilshire.com> wrote:
>
> "Sam Ruby" <ru...@apache.org> wrote in message
> news:3d4032300707042158o6c2d69c6ga7beb092bb929c00@mail.gmail.com...
> > On 7/5/07, Bill Barker <wb...@wilshire.com>
> > wrote:
> >>
> >> > "If the TCK is proprietary, a JSR needs to be voted down, until it
> >> > is resubmitted with that bug fixed."
> >>
> >> Which translates to that we automatically vote down all JSRs, since the
> >> clear language of the JCPA states that *all* TCKs are proprietary (to the
> >> spec-lead).
> >
> > Non-sequitur. I suppose one counter example would suffice to disprove
> > this? Here's one:
> >
> > http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/200707.mbox/%3c673E8E31-3AA9-4931-ACE8-682D478E8706@gbiv.com%3e
> >
>
> A 404 isn't very convicing :).
The link works for me. But try this one: http://tinyurl.com/39gjgb
- Sam Ruby
Re: Are proprietary TCK's compatible with open standards?
Posted by Bill Barker <wb...@wilshire.com>.
"Sam Ruby" <ru...@apache.org> wrote in message
news:3d4032300707042158o6c2d69c6ga7beb092bb929c00@mail.gmail.com...
> On 7/5/07, Bill Barker <wb...@wilshire.com>
> wrote:
>>
>> > "If the TCK is proprietary, a JSR needs to be voted down, until it
>> > is resubmitted with that bug fixed."
>>
>> Which translates to that we automatically vote down all JSRs, since the
>> clear language of the JCPA states that *all* TCKs are proprietary (to the
>> spec-lead).
>
> Non-sequitur. I suppose one counter example would suffice to disprove
> this? Here's one:
>
> http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/200707.mbox/%3c673E8E31-3AA9-4931-ACE8-682D478E8706@gbiv.com%3e
>
A 404 isn't very convicing :).
> - Sam Ruby
>
Re: Are proprietary TCK's compatible with open standards?
Posted by Sam Ruby <ru...@apache.org>.
On 7/5/07, Bill Barker <wb...@wilshire.com> wrote:
>
> > "If the TCK is proprietary, a JSR needs to be voted down, until it
> > is resubmitted with that bug fixed."
>
> Which translates to that we automatically vote down all JSRs, since the
> clear language of the JCPA states that *all* TCKs are proprietary (to the
> spec-lead).
Non-sequitur. I suppose one counter example would suffice to disprove
this? Here's one:
http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/200707.mbox/%3c673E8E31-3AA9-4931-ACE8-682D478E8706@gbiv.com%3e
- Sam Ruby
Re: Are proprietary TCK's compatible with open standards?
Posted by Matt Hogstrom <ma...@hogstrom.org>.
>
> We've been very successful in working from the inside. Today's JCP
> - even though most of the major players are the same - is very
> different in attitude then the JCP of days of yore.
>
> I'll be happy to detail why if anyone gives a hoot...
>
Hoot
> geir
>
>
Re: Are proprietary TCK's compatible with open standards?
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jul 5, 2007, at 12:49 AM, Bill Barker wrote:
>
>> So, given that pretty much every idea is being shot down, I for
>> one could
>> support a policy built around such this notion.
>>
>> What do others think?
>>
> I would like business-as-usual, and to use our position on the EC
> to change
> the JCP from the inside. With this type of software development
> increasingly shifting to the OS model, it might now be possible to
> get some
> of the other major players in the JCP to go along.
>
We've been very successful in working from the inside. Today's JCP -
even though most of the major players are the same - is very
different in attitude then the JCP of days of yore.
I'll be happy to detail why if anyone gives a hoot...
geir
Re: Are proprietary TCK's compatible with open standards?
Posted by Bill Barker <wb...@wilshire.com>.
"Sam Ruby" <ru...@apache.org> wrote in message
news:468C3166.5020903@apache.org...
> We need to find a way forward, a way that breaks the JCP loose from the
> "corrupting"[1] influences that so evidently drive it today. So in the
> spirit of brainstorming, I'm forwarding on to this mailing list a notion
> expressed by Dalibor Topic[2]:
>
If you actually go and read the JCPA, you will see that the JCP is "corrupt"
(in the sense you used) by design. Discussions are on closed lists between
EGs that have usually agreed to an NDA. The point is to allow the EG to
discuss IP without it getting published in somebody's blog :). It isn't
clear (at least not to me) how you could get the broad participation that
the JCP has if it was structured any other way.
> "Proprietary software should not be allowed to be tied in as a
> fundamental part of an open standard in any form."
>
> "It doesn't matter if such software comes from IBM, Sun, Oracle,
> BEA, Red Hat, Google, Nokia, or someone else. It doesn't really
> matter what the restrictions are, either."
>
> "If the TCK is proprietary, a JSR needs to be voted down, until it
> is resubmitted with that bug fixed."
>
Which translates to that we automatically vote down all JSRs, since the
clear language of the JCPA states that *all* TCKs are proprietary (to the
spec-lead). And, this would be totally impractical in practice, since the
purpose of having proprietary TCKs is to smooth out the IP transfer
required. Apache isn't the FSF (at least not yet :), so with the non-profit
exemption in the JCPA, I see no reason why Apache has an interest in whether
or not the spec-lead can profit from their control of the TCK from other
commercial vendors.
> My initial thoughts: is this step necessary? No, not if there are viable
> other alternatives. Is this sufficient? Actually, yes. It would neatly
> solve both the FOU and NDA issues. It has the added benefit of addressing
> the behavior as opposed to the person.
>
Don't really see a problem here. JSR 313
(http://www.jcp.org/en/jsr/detail?id=313) went down in flames over
licensing. And, while we are whining about Harmony not getting a favorable
licence from 8/2006, you will see from
http://www.jcp.org/en/jsr/detail?id=176 that the ASF gave glowing approval
to this JSR, while IBM had reservations about the licensing from the
beginning. Apache has (or should have) known the licensing issues from late
2003, yet we waited almost three years to complain about it.
The NDAs are a pain, but they are optional on the individual committer.
> So, given that pretty much every idea is being shot down, I for one could
> support a policy built around such this notion.
>
> What do others think?
>
I would like business-as-usual, and to use our position on the EC to change
the JCP from the inside. With this type of software development
increasingly shifting to the OS model, it might now be possible to get some
of the other major players in the JCP to go along.
> - Sam Ruby
>
> [1] I'm using the word "corrupt" in precisely the sense that Larry Lessig
> used it here:
>
> http://lessig.org/blog/2007/06/required_reading_the_next_10_y.html
>
> [2]
> http://blog.buni.org/blog/acoliver/2007/07/03/The-Apache-Conundrum#response-4
>
Re: Are proprietary TCK's compatible with open standards?
Posted by Jeff Genender <jg...@savoirtech.com>.
I am fine with all but the "voted down" part. Let's just not
participate in those.
Jeff
Sent from my iPhone
On Jul 4, 2007, at 7:46 PM, Sam Ruby <ru...@apache.org> wrote:
> We need to find a way forward, a way that breaks the JCP loose from
> the "corrupting"[1] influences that so evidently drive it today. So
> in the spirit of brainstorming, I'm forwarding on to this mailing
> list a notion expressed by Dalibor Topic[2]:
>
> "Proprietary software should not be allowed to be tied in as a
> fundamental part of an open standard in any form."
>
> "It doesn't matter if such software comes from IBM, Sun, Oracle,
> BEA, Red Hat, Google, Nokia, or someone else. It doesn't really
> matter what the restrictions are, either."
>
> "If the TCK is proprietary, a JSR needs to be voted down, until it
> is resubmitted with that bug fixed."
>
> My initial thoughts: is this step necessary? No, not if there are
> viable other alternatives. Is this sufficient? Actually, yes. It
> would neatly solve both the FOU and NDA issues. It has the added
> benefit of addressing the behavior as opposed to the person.
>
> So, given that pretty much every idea is being shot down, I for one
> could support a policy built around such this notion.
>
> What do others think?
>
> - Sam Ruby
>
> [1] I'm using the word "corrupt" in precisely the sense that Larry
> Lessig used it here:
>
> http://lessig.org/blog/2007/06/required_reading_the_next_10_y.html
>
> [2] http://blog.buni.org/blog/acoliver/2007/07/03/The-Apache-Conundrum#response-4
Re: Are proprietary TCK's compatible with open standards?
Posted by robert burrell donkin <ro...@gmail.com>.
On 7/6/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
> On Jul 4, 2007, at 7:46 PM, Sam Ruby wrote:
>
> > We need to find a way forward, a way that breaks the JCP loose from
> > the "corrupting"[1] influences that so evidently drive it today.
> > So in the spirit of brainstorming, I'm forwarding on to this
> > mailing list a notion expressed by Dalibor Topic[2]:
> >
> > "Proprietary software should not be allowed to be tied in as a
> > fundamental part of an open standard in any form."
> >
> > "It doesn't matter if such software comes from IBM, Sun, Oracle,
> > BEA, Red Hat, Google, Nokia, or someone else. It doesn't really
> > matter what the restrictions are, either."
> >
> > "If the TCK is proprietary, a JSR needs to be voted down, until it
> > is resubmitted with that bug fixed."
> >
> > My initial thoughts: is this step necessary? No, not if there are
> > viable other alternatives. Is this sufficient? Actually, yes. It
> > would neatly solve both the FOU and NDA issues. It has the added
> > benefit of addressing the behavior as opposed to the person.
> >
> > So, given that pretty much every idea is being shot down, I for one
> > could support a policy built around such this notion.
>
> That does solve it very neatly. No muss, no fuss. I'd just suggest
> that we announce any such policy publicly before acting on it. We
> will get painted as extremists, though. Just something to deal with,
> I expect.
>
> I look forward to see what company leads the charge there.
the FSF have always been better at politics than the ASF. i hope that
the FSF in general (and Dalibor in particular) will take the lead on
these wider issues.
- robert
Re: Are proprietary TCK's compatible with open standards?
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jul 4, 2007, at 7:46 PM, Sam Ruby wrote:
> We need to find a way forward, a way that breaks the JCP loose from
> the "corrupting"[1] influences that so evidently drive it today.
> So in the spirit of brainstorming, I'm forwarding on to this
> mailing list a notion expressed by Dalibor Topic[2]:
>
> "Proprietary software should not be allowed to be tied in as a
> fundamental part of an open standard in any form."
>
> "It doesn't matter if such software comes from IBM, Sun, Oracle,
> BEA, Red Hat, Google, Nokia, or someone else. It doesn't really
> matter what the restrictions are, either."
>
> "If the TCK is proprietary, a JSR needs to be voted down, until it
> is resubmitted with that bug fixed."
>
> My initial thoughts: is this step necessary? No, not if there are
> viable other alternatives. Is this sufficient? Actually, yes. It
> would neatly solve both the FOU and NDA issues. It has the added
> benefit of addressing the behavior as opposed to the person.
>
> So, given that pretty much every idea is being shot down, I for one
> could support a policy built around such this notion.
That does solve it very neatly. No muss, no fuss. I'd just suggest
that we announce any such policy publicly before acting on it. We
will get painted as extremists, though. Just something to deal with,
I expect.
I look forward to see what company leads the charge there.
geir
>
> What do others think?
>
> - Sam Ruby
>
> [1] I'm using the word "corrupt" in precisely the sense that Larry
> Lessig used it here:
>
> http://lessig.org/blog/2007/06/required_reading_the_next_10_y.html
>
> [2] http://blog.buni.org/blog/acoliver/2007/07/03/The-Apache-
> Conundrum#response-4
Re: Are proprietary TCK's compatible with open standards?
Posted by Sam Ruby <ru...@intertwingly.net>.
On 7/6/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
> We're reacting in anger at the FOU issue by tying the NDA issue.
I am frustrated.
I am against the ASF participating with NDAs. I have always been
against the ASF participating with NDAs. Since long before the FOU
issue. And, on the off chance it ever happens, I will still be
against the ASF participating in NDAs long after the FOU issue is a
distant memory.
Meanwhile, I see our friends at the FSF saying essentially "hey, wait
a minute" and rising in chorus against the same issue.
But I can't bring this up now, because we are in prolonged and
(apparently interminable discussions) on an unrelated issue?
I continue to want us to vote NO on any vote where the JSR in question
will require NDAs for technical participation, including conformance
requirements.
- Sam Ruby
Re: Are proprietary TCK's compatible with open standards?
Posted by "Andrew C. Oliver" <ac...@buni.org>.
Geir Magnusson Jr. wrote:
>
> No, because the FOU issue has nothing to do with the NDA issue. The
> FOU issue is at it's base, a breach of contract. No amount of policy
> or public statements can prevent if from happening in the future. The
> NDA issue is a policy issue for the ASF, based on a belief that such
> limits hinder our communities.
>
> We're reacting in anger at the FOU issue by tying the NDA issue.
No the NDA is what allows for the FOU issue. Sunshine is the best
disinfectant. The NDA gives them cover to do dirty deeds that they might
not do in the light. Even if you do not agree then I ask do you LIKE the
NDA and think it makes open source implementation of "open standard"s
better or worse? If not, why not address both while we're everyone is
paying attention?
-Andy
>
> geir
--
Buni Meldware Communication Suite
http://buni.org
Multi-platform and extensible Email,
Calendaring (including freebusy),
Rich Webmail, Web-calendaring, ease
of installation/administration.
Re: Are proprietary TCK's compatible with open standards?
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jul 4, 2007, at 10:00 PM, Joe Schaefer wrote:
> Sam Ruby <ru...@apache.org> writes:
>
>> Dalibor Topic[2]:
>>
>> "Proprietary software should not be allowed to be tied in as a
>> fundamental part of an open standard in any form."
>>
>> "It doesn't matter if such software comes from IBM, Sun, Oracle,
>> BEA, Red Hat, Google, Nokia, or someone else. It doesn't really
>> matter what the restrictions are, either."
>>
>> "If the TCK is proprietary, a JSR needs to be voted down,
>> until it
>> is resubmitted with that bug fixed."
>>
>> My initial thoughts: is this step necessary? No, not if there are
>> viable other alternatives. Is this sufficient? Actually, yes. It
>> would neatly solve both the FOU and NDA issues. It has the added
>> benefit of addressing the behavior as opposed to the person.
>
> I can see how it resolves the NDA issue, but does it really resolve
> the
> FOU also?
No, because the FOU issue has nothing to do with the NDA issue. The
FOU issue is at it's base, a breach of contract. No amount of policy
or public statements can prevent if from happening in the future.
The NDA issue is a policy issue for the ASF, based on a belief that
such limits hinder our communities.
We're reacting in anger at the FOU issue by tying the NDA issue.
geir
Re: Are proprietary TCK's compatible with open standards?
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Roy,
On Jul 6, 2007, at 2:08 PM, Roy T. Fielding wrote:
> On Jul 6, 2007, at 1:58 PM, Craig L Russell wrote:
>> On Jul 6, 2007, at 1:39 PM, Roy T. Fielding wrote:
>>> On Jul 5, 2007, at 2:21 PM, robert burrell donkin wrote:
>>>
>>>> On 7/5/07, Roy T. Fielding <fi...@gbiv.com> wrote:
>>>>
>>>>> AFAIK, Day is the only spec lead that publishes the TCK source
>>>>> also as open source,
>>>>
>>>> just FYI http://db.apache.org/jdo/
>>>
>>> Cool, that's nice to know. They are using Maven as the test
>>> harness?
>>
>> Yes, we are.
>>
>>> I wonder how that compares to using
>>>
>>> http://svn.apache.org/repos/asf/jackrabbit/trunk/contrib/tck-
>>> webapp/
>>
>> Don't know anything about jackrabbit.
>
> It really isn't (or shouldn't be) jackrabbit specific. It is just
> a webapp that runs the same Maven junit tests on an IUT and displays
> the result using graphics. I bet it is easier for a developer to just
> follow your written instructions and read the maven output. If
> you ever need a graphical interface for your TCK, then feel free to
> use that one.
Thanks for the pointer,
Craig
>
> ....Roy
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Are proprietary TCK's compatible with open standards?
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Jul 6, 2007, at 1:58 PM, Craig L Russell wrote:
> On Jul 6, 2007, at 1:39 PM, Roy T. Fielding wrote:
>> On Jul 5, 2007, at 2:21 PM, robert burrell donkin wrote:
>>
>>> On 7/5/07, Roy T. Fielding <fi...@gbiv.com> wrote:
>>>
>>>> AFAIK, Day is the only spec lead that publishes the TCK source
>>>> also as open source,
>>>
>>> just FYI http://db.apache.org/jdo/
>>
>> Cool, that's nice to know. They are using Maven as the test harness?
>
> Yes, we are.
>
>> I wonder how that compares to using
>>
>> http://svn.apache.org/repos/asf/jackrabbit/trunk/contrib/tck-
>> webapp/
>
> Don't know anything about jackrabbit.
It really isn't (or shouldn't be) jackrabbit specific. It is just
a webapp that runs the same Maven junit tests on an IUT and displays
the result using graphics. I bet it is easier for a developer to just
follow your written instructions and read the maven output. If
you ever need a graphical interface for your TCK, then feel free to
use that one.
....Roy
Re: Are proprietary TCK's compatible with open standards?
Posted by Craig L Russell <Cr...@Sun.COM>.
On Jul 6, 2007, at 1:39 PM, Roy T. Fielding wrote:
> On Jul 5, 2007, at 2:21 PM, robert burrell donkin wrote:
>
>> On 7/5/07, Roy T. Fielding <fi...@gbiv.com> wrote:
>>
>>> AFAIK, Day is the only spec lead that publishes the TCK source
>>> also as open source,
>>
>> just FYI http://db.apache.org/jdo/
>
> Cool, that's nice to know. They are using Maven as the test harness?
Yes, we are.
> I wonder how that compares to using
>
> http://svn.apache.org/repos/asf/jackrabbit/trunk/contrib/tck-webapp/
Don't know anything about jackrabbit.
Craig
>
> ....Roy
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Are proprietary TCK's compatible with open standards?
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Jul 5, 2007, at 2:21 PM, robert burrell donkin wrote:
> On 7/5/07, Roy T. Fielding <fi...@gbiv.com> wrote:
>
>> AFAIK, Day is the only spec lead that publishes the TCK source
>> also as open source,
>
> just FYI http://db.apache.org/jdo/
Cool, that's nice to know. They are using Maven as the test harness?
I wonder how that compares to using
http://svn.apache.org/repos/asf/jackrabbit/trunk/contrib/tck-webapp/
....Roy
Re: Are proprietary TCK's compatible with open standards?
Posted by robert burrell donkin <ro...@gmail.com>.
On 7/5/07, Roy T. Fielding <fi...@gbiv.com> wrote:
> AFAIK, Day is the only spec lead that publishes the TCK source also as open source,
just FYI http://db.apache.org/jdo/
- robert
Re: Testable specifications
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Ralph Goers wrote:
> Sam Ruby said:
>> Let me caution everybody here. We (the ASF) aren't here to bolster or
>> destroy monopolies[1]. Nor do we exist as a referendum of sorts on
>> various standards bodies. The ASF is a place where like minded people
>> can join together to build sustainable communities anchored by code
>> offered under the Apache License.
>
> This is true because the ASF membership has defined itself this way. If
> the ASF members decided they wanted to emulate the FSF or be a referendum
> on standards bodies, then they would be free to do so. I'm not trying to
> argue with the point you are making. I just like to point out that the way
> things are at the ASF is because that is the way we choose them to be.
This thread is entirely off topic. The definition of "what is the ASF" is
for the members to collectively decide, which is why anything more on this
topic belongs on members@. I'm pretty sure an "activist" ASF would be seen
by many (including me) as exclusionary, as opposed to inclusive. Sam's
point above is that we have built the ASF as an inclusive community of coders.
There is a huge diversity of opinion between the members on technology, the
politics of coding, IP law and so forth. And this diversity is part of what
makes the ASF unique. But the *members* are free to collectively decide to
go another direction, take it up with them :)
Re: Testable specifications
Posted by Ralph Goers <Ra...@dslextreme.com>.
Sam Ruby said:
>
> Let me caution everybody here. We (the ASF) aren't here to bolster or
> destroy monopolies[1]. Nor do we exist as a referendum of sorts on
> various standards bodies. The ASF is a place where like minded people
> can join together to build sustainable communities anchored by code
> offered under the Apache License.
>
This is true because the ASF membership has defined itself this way. If
the ASF members decided they wanted to emulate the FSF or be a referendum
on standards bodies, then they would be free to do so. I'm not trying to
argue with the point you are making. I just like to point out that the way
things are at the ASF is because that is the way we choose them to be.
Ralph
Re: Testable specifications
Posted by Sam Ruby <ru...@apache.org>.
On 7/10/07, Steve Loughran <st...@apache.org> wrote:
>
> Putting the JCP aside for a moment (they do at least have tests; its
> access that is the issue), perhaps we could consider a more ruthless
> policy towards W3C and OASIS specs in the future. Vendors are not above
> donating large bodies of code to actually legitimise a WS-*
> specification or two, and if we pushed back on specifications without
> normative test suites, they'd find greater barriers to adoption up
> front, but longer term things would actually interoperate, which can
> only be a good thing.
First, if you want to put aside the JCP for the moment, perhaps this
isn't the list to do that.
Let me caution everybody here. We (the ASF) aren't here to bolster or
destroy monopolies[1]. Nor do we exist as a referendum of sorts on
various standards bodies. The ASF is a place where like minded people
can join together to build sustainable communities anchored by code
offered under the Apache License.
- Sam Ruby
[1] http://refspace.com/quotes/The_Way_We_Live_Now:_Questions_for_Linus_Torvalds
Testable specifications
Posted by Steve Loughran <st...@apache.org>.
Andrew C. Oliver wrote:
> I kind of like the concept of a test kit personally. Spec's can be
> shitty and have 12 logical interpretations. Sure there can be multiple
> ways to pass a unit test but boy I wish clients and servers had to pass
> an IMAP TCK so that we didn't have 12 strange divergent versions of
> IMAP. I think if the TCKs were open, you'd find they'd be better as a
> side effect.
As I have said myself :
http://people.apache.org/~stevel/slides/distributed_testing_with_smartfrog_slides.pdf
Any specification without tests shouldn't exist.
I'd view WS-Addressing as a worst-in-case example; the fact that the TCK
for Java6+ has to incorporate the JAX-WS API, with its own tests for
WS-Addressing, is semi-irrelevant given there is 0 guarantee of interop
between other SOAP stacks with their own misinterpretation of WS-A, a
spec that got to the 1.0 status at the W3C without a single test case
(*). If you dont think of testing when the spec is written, it will be
untestable, and interop impossible.
Our Grid-related spec, has a test kit hosted on sourceforge:
http://sourceforge.net/projects/deployment
and it builds under Gump. Every night. We still suffer interop problems
between WS-A and WS-RF implementations, but those things we cannot take
blame for.
Putting the JCP aside for a moment (they do at least have tests; its
access that is the issue), perhaps we could consider a more ruthless
policy towards W3C and OASIS specs in the future. Vendors are not above
donating large bodies of code to actually legitimise a WS-*
specification or two, and if we pushed back on specifications without
normative test suites, they'd find greater barriers to adoption up
front, but longer term things would actually interoperate, which can
only be a good thing.
-steve
* to be precise, final draft, before they started discussing testability.
--
Steve Loughran http://www.1060.org/blogxter/publish/5
Author: Ant in Action http://antbook.org/
Re: Are proprietary TCK's compatible with open standards?
Posted by "Andrew C. Oliver" <ac...@buni.org>.
Roy T. Fielding wrote:
> On Jul 4, 2007, at 9:39 PM, Andrew C. Oliver wrote:
>
> Huh? I think there is a great deal of misunderstanding here about
> the nature of these NDAs and why they exist in the first place.
> Apache can't "refute the NDAs". What we have are legally binding
> contracts and the only way to end those contracts is to return the
> TCKs to Sun.
>
No I understand.
> When we talk about TCKs, there are two potential ND-style issues:
>
> 1) confidential negotiation of terms over access to the TCK;
>
bad I agree
> 2) disclosure of the TCK once we have access to it.
>
Even worse.
> The first ND-issue is evil because it allows Sun to lie about its open
> source strategy in public while it refuses to allow open source
> implementations in private. If we were able to post the actual
> license that Sun foisted on us in a public forum, this issue would
> have resolved itself a long time ago. Note that this isn't an actual
> NDA -- it is simply tied to the JSPA as confidential material and
> we have agreed (as part of the JSPA) to not republish other companies
> confidential material.
>
> The second ND-issue is about the TCK technology and test coverage.
> Sun demands that ND in the TCK access agreement because they agreed
> to an idiotic license with the contractor who actually built their
> harness, so Sun is stuck with both a lousy testing framework and a
> crippling limitation on feedback from actual testers. That is why
> all Sun TCKs suck, and why they all require non-disclosure on usage.
> The only way around the TCK NDA is for spec leads to stop using the
> Sun-provided harness aside from the required demonstration that the
> individual tests provide 100% signature coverage on the interface
> being standardized.
>
Not using things that suck and have egregious licensing terms sounds
like a good idea.
> Neither of those NDAs has an effect on "Apache development". It is
> often used as an excuse for not knowing about one bug or another,
> but most of the time the difference between a successful TCK run
I disagree.
> and an unsuccessful one has nothing whatsoever to do with the
> code being tested. Usually it is a bad assumption in the test case
> or an improperly configured test. Giving everyone access to the TCK
> does not improve our test results -- it only makes them worse.
> In any case, we already asked Sun for permission to discuss the TCK
> results in our public development forums for the purpose of fixing
> any revealed problems and Sun agreed.
>
That is good at least.
> The Apache NDA that Geir came up with is only about the second.
> It allows people with no formal relationship with the ASF to have
> access to the TCK which we have agreed will only be used to test
> Apache-produced software, since that is the only license available
> from Sun. And no matter how you might feel about NDAs, this second
> NDA has nothing whatsoever to do with our current problem with Sun
> regarding the first NDA and the resulting terms provided for access
> to the JCK. Nothing whatsoever. If you make that part of the
> negotiations, then we allow Sun to hide their intentions regarding
> the first NDA behind their contractual obligations regarding the
> Huh? I think there is a great deal of misunderstanding here about
> the nature of these NDAs and why they exist in the first place.
> Apache can't "refute the NDAs". What we have are legally binding
> contracts and the only way to end those contracts is to return the
> TCKs to Sun.
>
>
I completely disagree. On set of committers has full knowledge, the
other does not.
End the JSPA and return a version with the objectionable statements
deleted stating that Apache will participate under those terms. Note
that we will continue to honor the NDA parts in regards to existing TCKs
but not in further participation.
> second -- you let them off the hook for being evil.
>
Strategically, I agree that there might be an advantage to addressing
one issue before the other. However, you're continuing to compromise
"community" "consensus" and "open source" for the right to play in sun's
sandbox. The community is bifurcated by the NDA, consensus is
bifurcated by the NDA and the "open" part of open source is bifurcated
by some people having say into the next rev's architecture under the
Apache name and to commit to things under the Apache name and others not
w/o the benefit of public discussion -- let alone the TCK and FOU stuff.
> In any case, all TCKs are executable programs in binary form that
> are owned by a single company (the spec lead). AFAIK, Day is the
> only spec lead that publishes the TCK source also as open source,
> but that isn't the "official TCK". Only the spec lead can produce
> the official TCK.
>
I agree this should change.
> The meta-issue here, about open standards, is really about the
> notion of using TCKs to test conformance. In my opinion, no standard
> that requires a license predicated on "passing the TCK" is a truly
> open standard. TCKs are, in essence, a way of saying that the
> written specification does not define the standard, and therefore
> the standard was never open in the first place.
>
So should Apache help develop these proprietary standards under its good
name and even to some degree the proprietary software (TCKs)
I kind of like the concept of a test kit personally. Spec's can be
shitty and have 12 logical interpretations. Sure there can be multiple
ways to pass a unit test but boy I wish clients and servers had to pass
an IMAP TCK so that we didn't have 12 strange divergent versions of
IMAP. I think if the TCKs were open, you'd find they'd be better as a
side effect.
-Andy
> ....Roy
--
Buni Meldware Communication Suite
http://buni.org
Multi-platform and extensible Email,
Calendaring (including freebusy),
Rich Webmail, Web-calendaring, ease
of installation/administration.
Re: Are proprietary TCK's compatible with open standards?
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Jul 5, 2007, at 2:25 PM, Bill Stoddard wrote:
> Roy T. Fielding wrote:
>>
>> In any case, we already asked Sun for permission to discuss the TCK
>> results in our public development forums for the purpose of fixing
>> any revealed problems and Sun agreed.
> This is not well known. Is this documented and if so, where?
It is in one of the Sun clarification letters regarding the initial
TCK master agreement negotiations. I don't think it has been scanned
yet (or, at least, I have no idea where it was put).
....Roy
Re: Are proprietary TCK's compatible with open standards?
Posted by Bill Stoddard <bi...@wstoddard.com>.
Roy T. Fielding wrote:
>
> In any case, we already asked Sun for permission to discuss the TCK
> results in our public development forums for the purpose of fixing
> any revealed problems and Sun agreed.
This is not well known. Is this documented and if so, where?
Thanks for the clarification on the NDA.
Bill
Re: Are proprietary TCK's compatible with open standards?
Posted by Jeff Genender <jg...@apache.org>.
Dain Sundstrom wrote:
> Well what I'm getting at is we should work together to make the TCK
> experience suck less. How it works operationally (like where code is
> hosted) is way down the road.
>
BINGO! Thats why I wanted to know whats going on with this. I have
several instances where code got forked over at java.net (I have been
personally been affected by this on anther project), and I think it
would be much better if we allg ot together and did this as a community.
Jeff
> -dain3
Re: Are proprietary TCK's compatible with open standards?
Posted by Dain Sundstrom <da...@iq80.com>.
On Jul 11, 2007, at 12:13 PM, Jeff Genender wrote:
> Craig L Russell wrote:
>> Hi Dain,
>>
>> I believe it's the same code, probably repackaged, but I'm not the
>> expert. I can put you in touch with the expert. I'll have him contact
>> you directly.
>>
>
> Hrm...I hope I am understanding this correctly...
>
> Are you saying Sun put our Apache TCK maven based test harness code
> based on java.net? Or did I read this wrong?
Well what I'm getting at is we should work together to make the TCK
experience suck less. How it works operationally (like where code is
hosted) is way down the road.
-dain
Re: Are proprietary TCK's compatible with open standards?
Posted by Jeff Genender <jg...@apache.org>.
nm my last email...looking at the code base shows its different AFACT ;-)
Jeff
Jeff Genender wrote:
>
> Craig L Russell wrote:
>> Hi Dain,
>>
>> I believe it's the same code, probably repackaged, but I'm not the
>> expert. I can put you in touch with the expert. I'll have him contact
>> you directly.
>>
>
> Hrm...I hope I am understanding this correctly...
>
> Are you saying Sun put our Apache TCK maven based test harness code
> based on java.net? Or did I read this wrong?
>
> Jeff
>
>> Craig
>>
>> On Jul 11, 2007, at 11:58 AM, Dain Sundstrom wrote:
>>
>>> On Jul 10, 2007, at 6:54 PM, Craig L Russell wrote:
>>>
>>>> In fact, the TCK harness used by the CTS is open source and has been
>>>> for many months. Please see https://jtharness.dev.java.net for details.
>>> Is this the same code base used in the JEE tck or a rewrite. If it
>>> is the same, we should get a conversation started between Geronimo and
>>> this project, as Geronimo has maven plugins to run the harness.
>>>
>>> -dain
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
Re: Are proprietary TCK's compatible with open standards?
Posted by Jeff Genender <jg...@apache.org>.
Craig L Russell wrote:
> Hi Dain,
>
> I believe it's the same code, probably repackaged, but I'm not the
> expert. I can put you in touch with the expert. I'll have him contact
> you directly.
>
Hrm...I hope I am understanding this correctly...
Are you saying Sun put our Apache TCK maven based test harness code
based on java.net? Or did I read this wrong?
Jeff
> Craig
>
> On Jul 11, 2007, at 11:58 AM, Dain Sundstrom wrote:
>
>> On Jul 10, 2007, at 6:54 PM, Craig L Russell wrote:
>>
>>> In fact, the TCK harness used by the CTS is open source and has been
>>> for many months. Please see https://jtharness.dev.java.net for details.
>>
>> Is this the same code base used in the JEE tck or a rewrite. If it
>> is the same, we should get a conversation started between Geronimo and
>> this project, as Geronimo has maven plugins to run the harness.
>>
>> -dain
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Re: Are proprietary TCK's compatible with open standards?
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Dain,
I believe it's the same code, probably repackaged, but I'm not the
expert. I can put you in touch with the expert. I'll have him contact
you directly.
Craig
On Jul 11, 2007, at 11:58 AM, Dain Sundstrom wrote:
> On Jul 10, 2007, at 6:54 PM, Craig L Russell wrote:
>
>> In fact, the TCK harness used by the CTS is open source and has
>> been for many months. Please see https://jtharness.dev.java.net
>> for details.
>
> Is this the same code base used in the JEE tck or a rewrite. If
> it is the same, we should get a conversation started between
> Geronimo and this project, as Geronimo has maven plugins to run the
> harness.
>
> -dain
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Are proprietary TCK's compatible with open standards?
Posted by Dain Sundstrom <da...@iq80.com>.
On Jul 10, 2007, at 6:54 PM, Craig L Russell wrote:
> In fact, the TCK harness used by the CTS is open source and has
> been for many months. Please see https://jtharness.dev.java.net for
> details.
Is this the same code base used in the JEE tck or a rewrite. If it
is the same, we should get a conversation started between Geronimo
and this project, as Geronimo has maven plugins to run the harness.
-dain
Re: Are proprietary TCK's compatible with open standards?
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Jul 10, 2007, at 6:54 PM, Craig L Russell wrote:
> I know this isn't timely, but I've been looking into the issue of
> the TCK harness technology and can't find anything to back up Roy's
> claims here.
>
> In fact, the TCK harness used by the CTS is open source and has
> been for many months. Please see https://jtharness.dev.java.net for
> details.
Umm, that's great, but the last time I checked it was closed source,
subject to restrictive NDAs, and I was informed by those supposedly
in the know within the PMO and Sun legal that "it would never be
open sourced." That was two years ago.
It doesn't surprise me at all to see something on java.net now.
It appears to have been released as GPLv2 on November 6 but never
actually announced to the world outside java.net. 19 messages
on the list since then? *shrug*
> Perhaps, Roy, you are referring to a different test harness? Which
> one is that?
I can't tell you. Sorry. AFAIK, it should be the same one, but
I never looked at the contents of the one under NDA. I was talking
about the test harness that Sun imposed on Day for the sake of
confirming signature coverage. It was one of the excuses for Sun
legal not allowing TCKs to be distributed as open source at the time,
and we were forced to double the work in order to both create our
own harness and make our tests work under the Sun harness so that
the PMO would confirm coverage. It is certainly good to know we
won't have to do that again for JSR 283.
....Roy
Re: Are proprietary TCK's compatible with open standards?
Posted by Craig L Russell <Cr...@Sun.COM>.
I know this isn't timely, but I've been looking into the issue of the
TCK harness technology and can't find anything to back up Roy's
claims here.
In fact, the TCK harness used by the CTS is open source and has been
for many months. Please see https://jtharness.dev.java.net for details.
Perhaps, Roy, you are referring to a different test harness? Which
one is that?
Craig
On Jul 5, 2007, at 1:55 PM, Roy T. Fielding wrote:
> The second ND-issue is about the TCK technology and test coverage.
> Sun demands that ND in the TCK access agreement because they agreed
> to an idiotic license with the contractor who actually built their
> harness, so Sun is stuck with both a lousy testing framework and a
> crippling limitation on feedback from actual testers. That is why
> all Sun TCKs suck, and why they all require non-disclosure on usage.
> The only way around the TCK NDA is for spec leads to stop using the
> Sun-provided harness aside from the required demonstration that the
> individual tests provide 100% signature coverage on the interface
> being standardized.
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Are proprietary TCK's compatible with open standards?
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Jul 4, 2007, at 9:39 PM, Andrew C. Oliver wrote:
> Until Apache refutes the NDAs there are two classes and a large
> amount of the "Apache development" is neither community-based nor
> open. Apache should refute the NDAs and let Sun decide whether
> Apache can continue to serve on the spec committees.
Huh? I think there is a great deal of misunderstanding here about
the nature of these NDAs and why they exist in the first place.
Apache can't "refute the NDAs". What we have are legally binding
contracts and the only way to end those contracts is to return the
TCKs to Sun.
When we talk about TCKs, there are two potential ND-style issues:
1) confidential negotiation of terms over access to the TCK;
2) disclosure of the TCK once we have access to it.
The first ND-issue is evil because it allows Sun to lie about its open
source strategy in public while it refuses to allow open source
implementations in private. If we were able to post the actual
license that Sun foisted on us in a public forum, this issue would
have resolved itself a long time ago. Note that this isn't an actual
NDA -- it is simply tied to the JSPA as confidential material and
we have agreed (as part of the JSPA) to not republish other companies
confidential material.
The second ND-issue is about the TCK technology and test coverage.
Sun demands that ND in the TCK access agreement because they agreed
to an idiotic license with the contractor who actually built their
harness, so Sun is stuck with both a lousy testing framework and a
crippling limitation on feedback from actual testers. That is why
all Sun TCKs suck, and why they all require non-disclosure on usage.
The only way around the TCK NDA is for spec leads to stop using the
Sun-provided harness aside from the required demonstration that the
individual tests provide 100% signature coverage on the interface
being standardized.
Neither of those NDAs has an effect on "Apache development". It is
often used as an excuse for not knowing about one bug or another,
but most of the time the difference between a successful TCK run
and an unsuccessful one has nothing whatsoever to do with the
code being tested. Usually it is a bad assumption in the test case
or an improperly configured test. Giving everyone access to the TCK
does not improve our test results -- it only makes them worse.
In any case, we already asked Sun for permission to discuss the TCK
results in our public development forums for the purpose of fixing
any revealed problems and Sun agreed.
The Apache NDA that Geir came up with is only about the second.
It allows people with no formal relationship with the ASF to have
access to the TCK which we have agreed will only be used to test
Apache-produced software, since that is the only license available
from Sun. And no matter how you might feel about NDAs, this second
NDA has nothing whatsoever to do with our current problem with Sun
regarding the first NDA and the resulting terms provided for access
to the JCK. Nothing whatsoever. If you make that part of the
negotiations, then we allow Sun to hide their intentions regarding
the first NDA behind their contractual obligations regarding the
second -- you let them off the hook for being evil.
In any case, all TCKs are executable programs in binary form that
are owned by a single company (the spec lead). AFAIK, Day is the
only spec lead that publishes the TCK source also as open source,
but that isn't the "official TCK". Only the spec lead can produce
the official TCK.
The meta-issue here, about open standards, is really about the
notion of using TCKs to test conformance. In my opinion, no standard
that requires a license predicated on "passing the TCK" is a truly
open standard. TCKs are, in essence, a way of saying that the
written specification does not define the standard, and therefore
the standard was never open in the first place.
....Roy
Re: Are proprietary TCK's compatible with open standards?
Posted by "Andrew C. Oliver" <ac...@buni.org>.
"The Apache Software Foundation provides support for the Apache
community of open-source software projects. The Apache projects
<http://projects.apache.org/> are characterized by a collaborative,
consensus based development process, an open and pragmatic software
license, and a desire to create high quality software that leads the way
in its field. We consider ourselves not simply a group of projects
sharing a server, but rather a community of developers and users."
Until Apache refutes the NDAs there are two classes and a large amount
of the "Apache development" is neither community-based nor open. Apache
should refute the NDAs and let Sun decide whether Apache can continue to
serve on the spec committees.
The licensing FOU stuff is a symptom of the underlying problem. What
does Apache stand for? Is it for Open Source? No because the code is
compromised by FOU restrictions. Is it for "community developed"
software -- no because the community cannot participate in the TCK part
of the development or with other apache developers in key parts of the
architecture of those projects. Consensus? You can't gather consensus
outside the group in the know
However standing on the principals of "community-developed open source
software development" (paraphrased from the front page of
http://apache.org) could cost some people prestige and insider advance
access to Sun's proprietary information. Not that they can't apply as
individuals or as representatives of their company, but representing
Apache means quite a bit more IMO.
Refute the NDAs and vote NO an any spec that does not guarantee an open
TCK/FOU-free standard, because you believe in Apache standing for
community base open source development (it IS that simple). Let Sun
make the next move.
-Andy
> I can see how it resolves the NDA issue, but does it really resolve the
> FOU also? The FOU problem AIUI isn't with the licensing on the TCK
> software for Harmony, it's in how the results of the test may be
> interpreted.
>
> FWIW I wouldn't mind at all if we changed our voting on JSRs along
> those lines, but it might be problematic at this point to refuse
> to accept TCK licenses that are not open source. Especially when
> people are complaining about refusing them over NDAs, which are
> actually quite dangerous if they're really about protecting trade
> secrets. God forbid there is some interesting technique in the TCK
> that gets carried over into the project.
>
> In any case, IMO we *must* stop entering into NDAs in order to
> negotiate the terms of the TCK, open source or not.
>
>
Re: Are proprietary TCK's compatible with open standards?
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Sam Ruby <ru...@apache.org> writes:
> Dalibor Topic[2]:
>
> "Proprietary software should not be allowed to be tied in as a
> fundamental part of an open standard in any form."
>
> "It doesn't matter if such software comes from IBM, Sun, Oracle,
> BEA, Red Hat, Google, Nokia, or someone else. It doesn't really
> matter what the restrictions are, either."
>
> "If the TCK is proprietary, a JSR needs to be voted down, until it
> is resubmitted with that bug fixed."
>
> My initial thoughts: is this step necessary? No, not if there are
> viable other alternatives. Is this sufficient? Actually, yes. It
> would neatly solve both the FOU and NDA issues. It has the added
> benefit of addressing the behavior as opposed to the person.
I can see how it resolves the NDA issue, but does it really resolve the
FOU also? The FOU problem AIUI isn't with the licensing on the TCK
software for Harmony, it's in how the results of the test may be
interpreted.
FWIW I wouldn't mind at all if we changed our voting on JSRs along
those lines, but it might be problematic at this point to refuse
to accept TCK licenses that are not open source. Especially when
people are complaining about refusing them over NDAs, which are
actually quite dangerous if they're really about protecting trade
secrets. God forbid there is some interesting technique in the TCK
that gets carried over into the project.
In any case, IMO we *must* stop entering into NDAs in order to
negotiate the terms of the TCK, open source or not.
--
Joe Schaefer