Hi Brian,
thanks for your quick reply. You've cleared up my mistakes in interpretation quite nicely ;)
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. ;)
The license should in my opinion require that the code covered by it is always completely runnable and buildable within the specified framework, or referenced frameworks within the specification, or with code provided alongside the TCK under a compatible license.
What problem exists without these requirements?
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.
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. What matters to me is that the TCK allows creation of competing, spec-compliant implementations without imposing restrictions that can not be fulfilled by the free software community/independant efforts outside the JCP, like 'here's the TCK but you need this TCKrunner software to run the tests, which is only available under 'some non-ASL2-compatible' license'.
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.
thanks again for taking the time to reply, dalibor topic
