www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: TCKs and the ASF
Date Fri, 25 Apr 2014 11:32:48 GMT
Thx for keeping this going!!

On Apr 24, 2014, at 11:31 PM, David Blevins <david.blevins@gmail.com> wrote:

> FYI, spent about 3 hours on the phone with Cameron yesterday going through this list
explaining why we are asking for some of these things, confirming my understanding of what
each section is actually trying to achieve from a Java EE/JCP perspective and discussing angles
that meet both requirements.
> The call went well.
> It'll likely take some circling on his side before he can further comment, but for the
meantime I can update any of my comments with what was discussed.  It was 90% what was mentioned
on this list already, so will only update where needed.
> -David
> On Apr 21, 2014, at 10:49 AM, David Blevins <david.blevins@gmail.com> wrote:
>> Reposting the ASF's current thoughts on what items of the licensing agreement we'd
like addressed.
>>> 1) Section 2.1(b)(iv) prohibits licensees from developing test suites "intended
>>> to validate compatibility with the [licensed spec]." Arguably, this could
>>> include thorough unit tests for a project that implements a spec -- we'd like
>>> see unit tests clearly excepted from this.
>>> 2) Sections 2.1(b)(v) and 2.1(d) together seem to require that, once an
>>> application has been tested using the current TCK, all future releases of that
>>> application must comply with the then-current spec. For open source projects,
>>> which rely on volunteer effort, this is an extremely burdensome requirement.
>>> a project's volunteer developers decide to take a previously tested application
>>> in a new direction and Oracle subsequently publishes a new spec, this
>>> requirement could potentially require the developers to throw out months of work
>>> or cease development entirely. Additionally, if the new spec adds significant
>>> new functionality that is out of spec for the Apache project, the project could
>>> be compelled to undertake substantial development on features it doesn't need.
>>> Locking volunteer developers into a roadmap for future development set by a
>>> third party, and largely invisibly, is antithetical to open source principles
>>> and the Apache way.
>>> 3) Section 2.1(c)(i) lists the words that may be used to mark incompatible
>>> intermediate releases. Apache uses the term "SNAPSHOT" to refer to software in
>>> this state, and would request that this term be added to the acceptable identifiers.
>>> 4) Section 2.1(c)(ii) requires licensees to include a notice with intermediate
>>> builds, identifying them as such and requiring preservation of the notice with
>>> any redistribution. This restriction is incompatible with the Apache License,
>>> which only requires the preservation of attribution notices. We would have no
>>> problem with including the notice without the notice-preservation requirement.
>>> 5) Section 2.1(c)(iii) prohibits marketing or promoting Intermediate Builds;
>>> need to be certain that announcing these builds on mailing lists and in similar
>>> contexts does not qualify.
>>> 6) Section 2.1(c)(iv) would require ASF to make the previous, spec-compliant
>>> release available alongside any subsequent Intermediate Builds. This would
>>> conflict with ASF's security practices in the event that a major, public
>>> security breach was identified in that previous release. We need flexibility
>>> remove the compromised release until its security issues are resolved.
>>> 7) The last paragraph of Section 2.1(c) requires licensees to translate required
>>> notices into the language of each of the product's "primary intended audiences,"
>>> but that term is not defined. We'd like clarification on the scope of this
>>> requirement.
>>> 8) The indemnity clause in Section 7.5 creates potentially massive exposure for
>>> ASF, a nonprofit without the resources to defend itself, much less Oracle, from
>>> (for example) a patent infringement lawsuit arising from Apache's mere use of
>>> the TCK.
>>> 9) Section 10.8 has a typo: "Neither party may not act..." should read "Neither
>>> party may act..."
>>> 10) Exhibit A is missing a number of the TCKs that ASF projects implement and
>>> that ASF would need to be part of the agreement. Assuming the omission wasn't
>>> intentional, we can compile a complete list.

View raw message