On Mon, 17 Nov 2003, Dalibor Topic wrote:
> I think "industry standard" is a little far fetched, unless Apache Software
> Foundation starts providing TCKs for standards proposed by
> standardization bodies. Sun's desire to promote their APIs as an "industry
> standard", a meaningless term unless we are talking about ISO, ECMA or
> ANSI, shouldn't result in marketing speak polluting the license.
The scope of this license is very clear, at the top:
== This TCK version is for use by JSR-defined projects releasing ==
== an official TCK for a JSR under JSPA 2.5. ==
It's not intended to be applicable to any other standards effort. The
people from Apache have been involved in the Java Community Process on the
premise that we can drag this community, kicking and screaming if need be,
into being a real multilateral standards effort. We are not alone in that
goal, and even within Sun there are people who want to do "the right
thing" in this regard. If you don't agree with this premise, then just
ignore this license, it has no bearing on projects that are not JCP TCKs.
> 3. Contributors and Contributions.
>
> A. The Licensor and any individual or legal entity that
> voluntarily submits to the Licensor a Contribution to the Work are
> collectively addressed herein as "Contributors". For legal
> entities, the entity making a Contribution and all other entities
> that control, are controlled by, or are under common control with
> that entity are considered to be a single Contributor. For the
> purposes of this definition, "control" means (i) the power, direct
> or indirect, to cause the direction or management of such entity,
> whether by contract or otherwise, or (ii) ownership of fifty
> percent (50%) or more of the outstanding shares, or
> (iii) beneficial ownership of such entity.
>
> Beside the obvious philosophical dicussion about how much in charge a
> person is about their actions ("The devil made me contribute!"), this
> paragraph's vague definition of control under (1) doesn't seem to make
> much sense. I can make someone read this comment by posting it to the
> mailing list, therefore I'm in control of that person because I
> used my indirect power to directed the person to read using
> "otherwise" means aka as posting? ASF, all your code belongs to me ;)
>
> It's not obvious why that piece of legalese is in the license.
This is the same language as in the 2.0 license, by the way, as is the
rest of your comments.
Consider the situation where company A wishes to insert a submarine patent
into an Apache project. They form a small company, company B, and have it
write the patent-infringing code, and then donate that code to the
organization. They then disband company B, and start to pursue legal
claims against the ASF and/or its others based on the code contributed by
Company B. Our ability to pass liability for that through to the original
Contributor is really difficult when that Contributor is defunct.
Therefore, language like this helps make it clear that playing a game like
that won't work.
>
> B. A "Contribution" is the original version of the Work and any
> modification or addition to the Work that has been submitted for
> inclusion in the Work, where such modifications and/or additions
> to the Work originate from that particular Contributor, or from
> some entity acting on behalf of that Contributor.
>
> C. A Contribution is "submitted" when any form of electronic,
> verbal, or written communication is sent to the Licensor,
> including but not limited to communication on electronic mailing
> lists, source code control systems, and issue tracking systems
> that are managed by, or on behalf of, the Licensor for the purpose
> of discussing and improving the Work, but excluding communication
> that is conspicuously marked or otherwise designated in writing by
> the Contributor as "Not a Contribution."
>
> How does one designate verbal communication in writing? An attempt to
> be overly broad, yet so limited. Basically, anything you tell us
> belongs to us, nyah nyah nyah.
You're missing the "conspicuously marked", which could apply to verbal
communication.
You're also exaggerating the claim. It doesn't "belong to us", we get the
non-exclusive right to redistribute it on our terms. And yes, if someone
tells us something, whether verbal or otherwise, we want that right to
incorporate it into Apache code, unless that person clearly says we can't.
> There are situations imaginable where I could tell ASF about A, but
> would have no right to contribute A to the ASF without being the
> copyright holder. The 'ours by default' claim hidden in this license
> may get in you trouble when you get lax on checking if people are
> actually allowed to contribute the content of the conversation.
Simply telling us "about" A isn't what we're concerned about. Telling us
"this is how some other project implements A" doesn't give us all rights
to A, either. Nothing in the license suggests this. It means that, if A
is a derivative of the licensed code, any IP ownership *you* have in A,
you are granting us the right to redistribute.
> Example: During the discussion of a TCK test someone brings up an
> excerpt from a regression test in Kaffe's regression test suite. ASF
> can according to their license claim it as a contribution, and add it
> to their TCK.
That would only be true *if*
the person who posted the test case to the list was the copyright
holder, or otherwise had the necessary rights to be able to contribute
it to the ASF, and
it was a derivative work from Apache-2.0-licensed code.
In your example, it sounds like neither would be the case. The Apache 2.0
license does *not* mean that suddenly anything posted to an Apache
development list is "borg"ed into being a contribution to the ASF.
[Section 7]
> (d) You must do one of the following:
>
> (1) remove from the Derived Work all tests that are specific
> to features of the Specification and all documentation
> describing the Specification and those specific tests; or
>
> (2) cause the Derived Work to be clearly and conspicuously
> labeled as "not the official TCK for the Specification"
> and "for research purposes only", and clearly and
> conspicuously identify within the documentation and
> packaging of the Derived Work that it is not the official
> TCK for the Specification, and further that passing the
> tests in the Derived Work does not indicate that an
> implementation has passed the TCK for the Specification.
>
> I am not sure I parse that correctly: does that mean I can do (1) such
> that I take a TCK, remove everything that refers to the specification,
> and redistribute it as "The real TCK" without any labelling? Cute.
Well, you can call it "the real TCK", and without being able to claim
which standard it is a TCK for, it's pretty useless. Why would you want
to do that?
> The restrictions on the labeling may make the TCK license GPL
> incompatible.
It is not a goal for the TCK license to be GPL compatible. We know it
can't be - the concept of testing for conformance is contrary to the goals
of the GPL.
> Other restrictions, like the clause that only if you pass
> the original TCK you can say that you passed it, may give the original
> contributor a lot of power to close out competing implementations by
> including references to code outside the specification in the TCK.
This license is not intended to allow derivative works to claim to
be TCKs for a given specification.
> 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.
> 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?
Brian
