www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew C. Oliver" <acoli...@buni.org>
Subject Re: Are proprietary TCK's compatible with open standards?
Date Thu, 05 Jul 2007 21:28:08 GMT
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.


Mime
View raw message