TCKs and the ASF

[David Blevins <da...@gmail.com>]

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.

Re: TCKs and the ASF - Sections 2.1(b)(v) and 2.1(d)

[David Blevins <da...@gmail.com>]

On Apr 21, 2014, at 10:49 AM, David Blevins <da...@gmail.com> wrote:

>> 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.

Goal as I understand it: come up with some way for individual projects to be able to stop implementing a specification.

This is the corner case.  Most projects will perpetually implement the specifications they've chosen.  We do, however, have 150+ projects and all of them are volunteer based.  We need some legally allowable way for one of them to "opt out".

The process could include notifying Oracle and following through with some branding requirements.

Proposal from Mark Thomas:

> How about one of the following:
> - a notice requirement making clear that the supported API is not the
> latest version and where to get the latest version
> - limiting the time and/or number of major releases in which the old JSR
> may be used. e.g. (1 major release or 2 years which ever is the longer)


From a Java EE branding perspective I can see some "NOT COMPATIBLE WITH ABC 1.2.3" requirement on main page and download page being more than enough to make this an option no project would ever exercise lightly.


-David

Re: TCKs and the ASF - Section 7.5

[David Blevins <da...@gmail.com>]

On Apr 21, 2014, at 10:49 AM, David Blevins <da...@gmail.com> wrote:

>> 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.

Remains open.  One of the larger issues.


-David

Re: TCKs and the ASF - Section 2.1(c)

[David Blevins <da...@gmail.com>]

On Apr 21, 2014, at 10:49 AM, David Blevins <da...@gmail.com> wrote:

>> 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.

Also an easy one to check off the list.  Our "primary intended audiences" is the world and all our notice files are in English.


-David

Re: TCKs and the ASF

[David Blevins <da...@gmail.com>]

On Apr 21, 2014, at 10:49 AM, David Blevins <da...@gmail.com> wrote:

>> 9) Section 10.8 has a typo: "Neither party may not act..." should read "Neither
>> party may act..."

Low hanging fruit.


-David

Re: TCKs and the ASF - Section 2.1(c)(iii)

[David Blevins <da...@gmail.com>]

On Apr 21, 2014, at 10:49 AM, David Blevins <da...@gmail.com> wrote:

>> 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.

Reasonable request for clarification as everything we do is public.


-David

Re: TCKs and the ASF - Section 2.1(c)(ii)

[David Blevins <da...@gmail.com>]

On Apr 21, 2014, at 10:49 AM, David Blevins <da...@gmail.com> wrote:

>> 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.

Mark Thomas said it best:

"That said, no downstream consumer is going to be able to make any
statements about JSR compatibility without passing the TCK themselves so
they would pick up the notice requirement through their own TCK license."

This one seems to take care of itself without the need for a notice-preservation requirement.

Bottom line: you need your own license to claim compliance.


-David

Re: TCKs and the ASF - Section 2.1(c)(i)

[David Blevins <da...@gmail.com>]

> Reposting the ASF's current thoughts on what items of the licensing agreement we'd like addressed.
>> 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.

This one is easy.  Good opportunity to reduce the list and show some progress.


-David

Re: TCKs and the ASF

[Jim Jagielski <ji...@jaguNET.com>]

Thx for keeping this going!!

On Apr 24, 2014, at 11:31 PM, David Blevins <da...@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 <da...@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.
> 

Re: TCKs and the ASF

[Matthias Wessendorf <ma...@apache.org>]

that's good news, David!

-Matthias


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

Re: TCKs and the ASF

[David Blevins <da...@gmail.com>]

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 <da...@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.

Re: TCKs and the ASF - Section 2.1(c)(iv)

[David Blevins <da...@gmail.com>]

On Apr 21, 2014, at 10:49 AM, David Blevins <da...@gmail.com> wrote:

>> 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.

Clearly no divergence in goals with this one.  Should be low hanging fruit to show some progress.


-David

Re: TCKs and the ASF

[David Jencks <da...@yahoo.com>]

Nitpick, in (10) do you mean specs apache projects implement or tcks they run against or something else?

thanks
david jencks

On Apr 21, 2014, at 10:49 AM, David Blevins <da...@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.

Re: TCKs and the ASF - 2.1(b)(iv)

[David Blevins <da...@gmail.com>]

On Apr 21, 2014, at 10:49 AM, David Blevins <da...@gmail.com> wrote:

>> 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.


Apache has a few thousand tests across the various projects that verify APIs are implemented correctly as detailed by various specifications.  This needs to be ok.

We have no desire to market these as a "TCK"s or compete with Oracle as a certification authority.  Fully agreed this would be a bad thing for Java EE.

Perhaps this section could simply be more direct; licensees cannot promote, market or brand themselves as a certification authority for Java EE specifications.


-David

Re: TCKs and the ASF

[David Blevins <da...@gmail.com>]

On Apr 21, 2014, at 10:49 AM, David Blevins <da...@gmail.com> wrote:

>> 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.

I think the ball is still in our court on this particular one.


-David