Return-Path: X-Original-To: apmail-jcp-open-archive@www.apache.org Delivered-To: apmail-jcp-open-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B15D011FA1 for ; Fri, 25 Apr 2014 07:16:15 +0000 (UTC) Received: (qmail 17010 invoked by uid 500); 25 Apr 2014 07:16:11 -0000 Delivered-To: apmail-jcp-open-archive@apache.org Received: (qmail 16803 invoked by uid 500); 25 Apr 2014 07:16:05 -0000 Mailing-List: contact jcp-open-help@apache.org; run by ezmlm Precedence: bulk Reply-To: jcp-open@apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list jcp-open@apache.org Received: (qmail 16796 invoked by uid 99); 25 Apr 2014 07:16:03 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 25 Apr 2014 07:16:03 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of mwessendorf@gmail.com designates 209.85.217.171 as permitted sender) Received: from [209.85.217.171] (HELO mail-lb0-f171.google.com) (209.85.217.171) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 25 Apr 2014 07:15:59 +0000 Received: by mail-lb0-f171.google.com with SMTP id w7so2737547lbi.2 for ; Fri, 25 Apr 2014 00:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=g+ereJnEb5ID9lQomrU/5XyQN1YNy6dSnUtEVQYrugQ=; b=BCcG1G/Z1Qsrty6xAUKoe29cQponvn0If8QOZdyN4qdBS+t2DB71k0fwZJyeFNng7f 8JnHAVaZG83ZrWf3qQ9l/eGsZqVjn8SWZKynTagnG5KjevYQCfNW+uk+GV5QI8CluWLy CMXJKDmsJS8T8xinNtJFRg/AYCE+zwMNCzrMFnMyJEbIE3B4+O89G06fuz2VF/wBJ0mI QbUPFX5/Isev3l1hNAgMK8eceFwz1GWZKeucKuV8pp3M5hb7PR9XOTHtYO8eW0Q+TX4z W9rVpTUnxBOSCLFGpULTYIUpqV8lyUp92t8jIMBXb24c3OMfkM66GnQrAYAY/dM8c43F mCNw== MIME-Version: 1.0 X-Received: by 10.152.18.229 with SMTP id z5mr4524735lad.27.1398410138199; Fri, 25 Apr 2014 00:15:38 -0700 (PDT) Sender: mwessendorf@gmail.com Received: by 10.114.98.10 with HTTP; Fri, 25 Apr 2014 00:15:38 -0700 (PDT) In-Reply-To: References: <07372B92-FCBF-46B3-BE00-7A1720E4FDAF@gmail.com> Date: Fri, 25 Apr 2014 09:15:38 +0200 X-Google-Sender-Auth: yq2UkE-mShKQ68R8Vk125S06PjM Message-ID: Subject: Re: TCKs and the ASF From: Matthias Wessendorf To: jcp-open@apache.org Content-Type: multipart/alternative; boundary=089e014940ea89ac4104f7d8bb00 X-Virus-Checked: Checked by ClamAV on apache.org --089e014940ea89ac4104f7d8bb00 Content-Type: text/plain; charset=UTF-8 that's good news, David! -Matthias On Fri, Apr 25, 2014 at 5:31 AM, David Blevins 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 > 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 --089e014940ea89ac4104f7d8bb00 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
that's good news, David!

-Matthias<= /div>


On= Fri, Apr 25, 2014 at 5:31 AM, David Blevins <david.blevins@gmail.c= om> wrote:
FYI, spent about 3 hours on the phone with C= ameron yesterday going through this list explaining why we are asking for s= ome of these things, confirming my understanding of what each section is ac= tually trying to achieve from a Java EE/JCP perspective and discussing angl= es that meet both requirements.

The call went well.

It'll likely take some circling on his side before he can further comme= nt, but for the meantime I can update any of my comments with what was disc= ussed. =C2=A0It was 90% what was mentioned on this list already, so will on= ly 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 add= ressed.
>
>> 1) Section 2.1(b)(iv) prohibits licensees from developing test sui= tes "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, on= ce an
>> application has been tested using the current TCK, all future rele= ases of that
>> application must comply with the then-current spec. For open sourc= e projects,
>> which rely on volunteer effort, this is an extremely burdensome re= quirement. If
>> a project's volunteer developers decide to take a previously t= ested application
>> in a new direction and Oracle subsequently publishes a new spec, t= his
>> 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 d= oesn'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 inco= mpatible
>> intermediate releases. Apache uses the term "SNAPSHOT" t= o refer to software in
>> this state, and would request that this term be added to the accep= table 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 Apac= he License,
>> which only requires the preservation of attribution notices. We wo= uld have no
>> problem with including the notice without the notice-preservation = requirement.
>>
>> 5) Section 2.1(c)(iii) prohibits marketing or promoting Intermedia= te Builds; we
>> need to be certain that announcing these builds on mailing lists a= nd 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. Th= is would
>> conflict with ASF's security practices in the event that a maj= or, public
>> security breach was identified in that previous release. We need f= lexibility to
>> remove the compromised release until its security issues are resol= ved.
>>
>> 7) The last paragraph of Section 2.1(c) requires licensees to tran= slate required
>> notices into the language of each of the product's "prima= ry intended audiences,"
>> but that term is not defined. We'd like clarification on the s= cope 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= 9;s mere use of
>> the TCK.
>>
>> 9) Section 10.8 has a typo: "Neither party may not act...&quo= t; should read "Neither
>> party may act..."
>>
>> 10) Exhibit A is missing a number of the TCKs that ASF projects im= plement and
>> that ASF would need to be part of the agreement. Assuming the omis= sion wasn't
>> intentional, we can compile a complete list.




--
= Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/<= br> sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
--089e014940ea89ac4104f7d8bb00--