On Mon, 17 Nov 2003, Dalibor Topic wrote:
> Brian Behlendorf wrote:
>
> >>Example: If A wanted to make sure their competition wouldn't be able to
> >>pass a TCK, all they need to do would be to put in a test case that
> >>links to some internal, unspecified class from their implementation (say
> >>an com.a.internal.* class). I see no protection against the licensee
> >>using the TCK as a means to prevent competition instead of encouraging
> >>it in the proposed license.
> >
> >
> > Your example is somewhat bogus - a TCK for a standard that tests for
> > classes outside that namespace would not be acceptable to Apache. It
> > would be a broken project. Because the source code is published, it's
> > easy to find such bogusness.
>
> I'm not saying tests, I'm saying "links to", i.e. uses classes outside
> of the namespace. It obviously has to for TCKs outside the java.lang
> namespace in order to include java.lang.Object. ;)
OK, I understand. I still think that the normal processes by which the
code is developed at Apache (or any other open source project) would be
able to identify such mistakes (intentional or otherwise) and call them
out as bugs needing to be fixed. Much more so than the current situation,
where TCKs are created by a single company and often not available in
source code form.
> It may be possible to publish a TCK that requires a third party
> component to run which is either unspecified, so that it can not be
> recreated freely (a sun.* class, for example), or encumbered by a
> non-free/non-ASL2-compatible license.
I think the same answer applies here, though there's no guarantee anyways
that non-free software would be required. E.g., there could be a JSR A
that depends on another JSR B, and JSR B might not have an open source
implementation. That doesn't mean the implementation of JSR A is useless.
Clearly, as said before, any "hidden" requirements would be clearly
brought to light.
> The situation I'm afraid of is the following: you get the TCK, but can't
> use it to create a free, competing implementation of the specification
> because a contributor sneaked in a reference to a some unacessible code
> into the spec.
If there's a defect in the spec, then the proper place to address that is
within the JSR specification process.
> I've never seen any TCK code, so I don't know how it all works, and a
> lot of this is speculation. But seeing how you've tried to address many
> ways of trying to hijack your code, I'm wondering whether you think my
> concerns are valid or not.
I think your concerns are valid, but I think there are places other than
the TCK license requirements where those concerns can and would be
addressed.
Brian
