www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthias Wessendorf <mat...@apache.org>
Subject Re: TCKs and the ASF
Date Fri, 25 Apr 2014 07:15:38 GMT
that's good news, David!

-Matthias


On Fri, Apr 25, 2014 at 5:31 AM, 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 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.
>
>


-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Mime
View raw message