Mailing-List: contact jcp-open-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: jcp-open@apache.org
Received-SPF: pass (herse.apache.org: domain of joe@sunstarsys.com designates
 64.139.134.58 as permitted sender)
From: Joe Schaefer <joe+apache@sunstarsys.com>
To: jcp-open@apache.org
Subject: Re: Are proprietary TCK's compatible with open standards?
References: <468C3166.5020903@apache.org>
Date: Wed, 04 Jul 2007 22:00:00 -0400
In-Reply-To: <468C3166.5020903@apache.org> (Sam Ruby's message of "Wed, 04 Jul
	2007 19:46:46 -0400")
Message-ID: <878x9v7gpr.fsf@gemini.sunstarsys.com>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Sam Ruby <rubys@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