www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@gmail.com>
Subject TCKs and the ASF
Date Mon, 21 Apr 2014 17:49:17 GMT
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 to
> 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. If
> 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; we
> 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 to
> 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.

Mime
View raw message