Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 8CE0F200BF1 for ; Tue, 3 Jan 2017 22:07:12 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 8B6A0160B43; Tue, 3 Jan 2017 21:07:12 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 3A262160B20 for ; Tue, 3 Jan 2017 22:07:11 +0100 (CET) Received: (qmail 10211 invoked by uid 500); 3 Jan 2017 21:07:10 -0000 Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: Reply-To: legal-discuss@apache.org List-Id: Delivered-To: mailing list legal-discuss@apache.org Received: (qmail 10197 invoked by uid 99); 3 Jan 2017 21:07:10 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Jan 2017 21:07:10 +0000 Received: from mail-yw0-f174.google.com (mail-yw0-f174.google.com [209.85.161.174]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id D61E61A05A7 for ; Tue, 3 Jan 2017 21:07:09 +0000 (UTC) Received: by mail-yw0-f174.google.com with SMTP id v81so197052122ywb.2 for ; Tue, 03 Jan 2017 13:07:09 -0800 (PST) X-Gm-Message-State: AIkVDXI/OO7fwqNwE5PzQF2+Gb9DeOaS04HBI11/kG5hLa4s8WJMWJOOFUobcqPJol+ktulc5vJ/rHmwRr+6AA== X-Received: by 10.13.219.69 with SMTP id d66mr59473950ywe.148.1483477629056; Tue, 03 Jan 2017 13:07:09 -0800 (PST) MIME-Version: 1.0 References: <531A8CB0-9ABF-4A45-97E6-2871034AC1A1@yahoo.de> <5668C0C4-6A3A-476A-96A9-8775D4FE4C52@yahoo.de> In-Reply-To: From: "John D. Ament" Date: Tue, 03 Jan 2017 21:06:58 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Inclusion of .class files within a Apache Source Release To: legal-discuss@apache.org Content-Type: multipart/alternative; boundary=001a114fc6c01cbfae0545370d32 archived-at: Tue, 03 Jan 2017 21:07:12 -0000 --001a114fc6c01cbfae0545370d32 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Craig, Its a good point. However, the inclusion of a NOTICE would imply a policy stating that the contents of non-verifiable source are documented in NOTICE= . To me, legal-discuss is probably the right place to talk through policy changes as well. Maybe final resolution to members? John On Tue, Jan 3, 2017 at 2:15 PM Craig Russell wrote: > I do not see a legal or policy issue with this case. Putting a test file > into a resource directory for distribution is perfectly ok. > > I=E2=80=99d even generalize it to say that you might imagine wanting vari= ous > .class files compiled with different options, even different versions of > compilers, perhaps compilers that are no longer available. And in that > case, you would want to preserve the .class files even if they can no > longer be created from their original source. > > In case this comes up in future, perhaps you could document the origin of > the .class file(s) exactly the same way as you would document the origin = of > .gif, .jpg files that are used as test resources. > > Craig > > > > On Jan 3, 2017, at 10:15 AM, Mark Struberg > wrote: > > > > Btw, since all seem to agree that this is NOT a legal problem but might > at worst be an ASF *policy* question I consider this topic resolved (at > least on this very list). > > It simply has nothing to do with legal, right? > > John, please open a ticket in members@ or any other apropriate list if > you still think it's needed. > > > > txs and LieGrue, > > strub > > > >> Am 03.01.2017 um 19:07 schrieb Mark Struberg >: > >> > >> I propose to simply rename it to .noclass and we are done ;P > >> > >> LieGrue, > >> strub > >> > >> > >>> Am 03.01.2017 um 18:57 schrieb Romain Manni-Bucau < > rmannibucau@gmail.com>: > >>> > >>> > >>> 2017-01-03 18:42 GMT+01:00 Alex Harui : > >>> Hi Romain, > >>> > >>> AIUI, it isn't a "no binary" policy, it is a "no compiled sources" > policy. Distributing a compiled binary puts the responsibility of the > effects of executing that code on the ASF and should scare away customers= . > You are taking a big chance by running the source build script if it > executes that .class file if you can't verify it came from the source you > said it did. Sure a customer might have a bad tool chain that compiles > the sources into a bad binary, but that is not the ASF's responsibility. > >>> > >>> > >>> About "no binary" vs "no compiled sources": it leads to the trust or > not of the downloaded package which is guaranteed - between others - by t= he > signing we do of the package, not by the extension (as explained it is ea= sy > to exploit a .png containing a .class). If you can't trust the signing of > the source bundle then .class is the least issue you can get I fear so > really not an issue. > >>> > >>> Also for this particular case: these .classes are in *test* resources > so not used until you run tests and if you do so you likely want to have > them. When I spoke of bad tool chain it was about the project itself, not > the user: if you don't use that trick you need to generate classes in the > build but NOT in the test-classes folder to ensure these classes are NOT = in > the classpath (point of having them as resources). Most of solutions woul= d > break IDE support and would make entry cost of the project high for a poo= r > gain, that is why it got done this way. Also note that these .class are i= n > the "wrong" folder regarding their package and are NOT classes the way th= ey > are stored. Without some actual file copy you will not load them by defau= lt > even if in the classpath. So running them needs some knowledge on them > which reduces again the risk. > >>> > >>> BTW not the first time this trick is used @asf cause it is the best > compromise for such things (not breaking dev tooling). > >>> > >>> So concretely I read this thread as "do we trust our signing". If the > answer is no then I think we have a big problem to solve but I'm not seei= ng > why it would be the case at the moment. > >>> > >>> > >>> -Alex > >>> > >>> From: Romain Manni-Bucau > >>> Reply-To: "legal-discuss@apache.org" > >>> Date: Tuesday, January 3, 2017 at 9:17 AM > >>> To: "legal-discuss@apache.org" > >>> Subject: Re: Inclusion of .class files within a Apache Source Release > >>> > >>> Please don't diverge: too much > >>> > >>> - can we do better: probably, even if "process-test-resources > life-cycle goal seems read-made for this" doesn't really help since it > requires a build setup we likely don't want to ensure we have these class= es > only for some part of some tests and not the whole test phase. it also > breaks IDE support to do it this way and reduce contributions capabilitie= s > but that's another topic.... > >>> - is it legal: yes (otherwise as mentionned all projects with binary > resources would be illegal) > >>> - is it unsecured? likely as much as generating bytecode at runtime s= o > probably out of topic for here too. Also note that a picture (.png for > instance) can be a .class and be loaded by a JVM is correctly launched so > security there is not really a point IMHO. > >>> > >>> In summary I don't see why it makes so much noise for really an > implementation detail and I'm not seeing what is the alternative proposal > to not distribute ANY binary if we care about it? Do I miss an important > point? > >>> > >>> > >>> > >>> Romain Manni-Bucau > >>> @rmannibucau | Blog | Old Blog | Github | LinkedIn | JavaEE Factory > >>> > >>> 2017-01-03 18:05 GMT+01:00 Alex Harui : > >>> > >>> > >>> On 1/3/17, 3:51 AM, "Mark Struberg" wrote= : > >>> > >>>> The class file in question was added by ASF member rmannibucau under > ALv2 > >>>> as a >>resource<< and not as a source file. > >>>> The original file of course has the ASF license header, but the > 'class' > >>>> resource is still checked in to our SVN as .class file. > >>>> > >>>> This is for testing some bytecode stuff in OpenBebBeans. We could > >>>> probably later change this to have another project module, compile i= t, > >>>> unpack it, copy it over, blablabla. > >>>> But that doesn't change anything about the fact that this file is AL= v2 > >>>> licensed. But since it's a binary it obviously does not have any ALv= 2 > >>>>>> SOURCE<< header. > >>>> > >>>> In other words: this .class file is a test resource and handled > exactly > >>>> the same like a png or jpeg file. > >>>> > >>>> I don't see any legal problem. > >>> > >>> There may not be a legal problem, but I thought the reason behind the > "no > >>> compiled code" rule/policy was about verification/auditing of the > release > >>> artifact. See Marvin Humphrey [1]. > >>> > >>> Anybody auditing a release would scan each file for headers and find > >>> binaries. They could examine binaries proposing to be image files an= d > >>> verify that they have image file headers and are thus safe to open in > an > >>> application. But verification of the safety of executing a .class fi= le > >>> seems risky to me. I'm surprised to learn that some ASF projects > allow it. > >>> > >>> -Alex > >>> > >>> [1] > >>> > https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201606.mbox/%= 3c > >>> CAAS6=3D7gVXGHqeKVeFV_r1849Qpi0+Ca0jc2QWQBQfRdZnCwVpA@mail.gmail.com%= 3e > >>> > >>>> > >>>> LieGrue, > >>>> strub > >>>> > >>>> > >>>>> Am 03.01.2017 um 12:45 schrieb John D. Ament >: > >>>>> > >>>>> Hi, > >>>>> > >>>>> While looking at [1] and looking at a proposed Apache OpenWebBeans > [2] > >>>>> it was discovered that .class files were contained in the source > >>>>> release. It seems in the past that image files were generally > >>>>> considered OK in source releases, since they typically had to do wi= th > >>>>> building websites, the traceability of the image was easy to > discover. > >>>>> > >>>>> .class files are the compiled output from .java source files (as we= ll > >>>>> as .groovy and other JVM languages, depending on how you compile). > >>>>> Since they are compiled output, it seems they shouldn't be in a > source > >>>>> release. However, the only true policy I could find that it violat= ed > >>>>> was that we require appropriate licensing [3] and there is no way t= o > >>>>> verify the licensing of these files. > >>>>> > >>>>> So I'm wondering 1. is that accurate? and 2. is there an acceptable > way > >>>>> to verify that the license is correct? > >>>>> > >>>>> [1]: > >>>>> > http://www.apache.org/dev/release.html#what-must-every-release-contain > >>>>> [2]: > >>>>> > https://lists.apache.org/thread.html/869c739764d5d55d81199576d730d485d66d > >>>>> f8be17ae16398dd7ca1f@%3Cdev.openwebbeans.apache.org%3E > >>>>> [3]: http://www.apache.org/dev/release-publishing.html#valid > >>>>> > >>>> > >>>> > >>>> --------------------------------------------------------------------= - > >>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org > >>>> For additional commands, e-mail: legal-discuss-help@apache.org > >>>> > >>> > >>> > >>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org > >> For additional commands, e-mail: legal-discuss-help@apache.org > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org > > For additional commands, e-mail: legal-discuss-help@apache.org > > > > Craig Russell > papajdo@gmail.com > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org > For additional commands, e-mail: legal-discuss-help@apache.org > > --001a114fc6c01cbfae0545370d32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Craig,

Its a good point.=C2=A0 However,= the inclusion of a NOTICE would imply a policy stating that the contents o= f non-verifiable source are documented in NOTICE.

= To me, legal-discuss is probably the right place to talk through policy cha= nges as well.=C2=A0 Maybe final resolution to members?

=
John

On Tue, Jan 3,= 2017 at 2:15 PM Craig Russell <pap= ajdo@gmail.com> wrote:
I do = not see a legal or policy issue with this case. Putting a test file into a = resource directory for distribution is perfectly ok.

I=E2=80=99d even generalize it to say that you might imagine wanting variou= s .class files compiled with different options, even different versions of = compilers, perhaps compilers that are no longer available. And in that case= , you would want to preserve the .class files even if they can no longer be= created from their original source.

In case this comes up in future, perhaps you could document the origin of t= he .class file(s) exactly the same way as you would document the origin of = .gif, .jpg files that are used as test resources.

Craig


> On Jan 3, 2017, at 10:15 AM, Mark Struberg <struberg@yahoo.de.INVAL= ID> wrote:
>
> Btw, since all seem to agree that this is NOT a legal problem but migh= t at worst be an ASF *policy* question I consider this topic resolved (at l= east on this very list).
> It simply has nothing to do with legal, right?
> John, please open a ticket in members@ or any other apropriate list if= you still think it's needed.
>
> txs and LieGrue,
> strub
>
>> Am 03.01.2017 um 19:07 schrieb Mark Struberg <struberg@yahoo.de= .INVALID>:
>>
>> I propose to simply rename it to .noclass and we are done ;P
>>
>> LieGrue,
>> strub
>>
>>
>>> Am 03.01.2017 um 18:57 schrieb Romain Manni-Bucau <rma= nnibucau@gmail.com>:
>>>
>>>
>>> 2017-01-03 18:42 GMT+01:00 Alex Harui <aharui@adobe.com&= gt;:
>>> Hi Romain,
>>>
>>> AIUI, it isn't a "no binary" policy, it is a &qu= ot;no compiled sources" policy.=C2=A0 Distributing a compiled binary p= uts the responsibility of the effects of executing that code on the ASF and= should scare away customers.=C2=A0 You are taking a big chance by running = the source build script if it executes that .class file if you can't ve= rify it came from the source you said it did.=C2=A0 =C2=A0 Sure a customer = might have a bad tool chain that compiles the sources into a bad binary, bu= t that is not the ASF's responsibility.
>>>
>>>
>>> About "no binary" vs "no compiled sources"= : it leads to the trust or not of the downloaded package which is guarantee= d - between others - by the signing we do of the package, not by the extens= ion (as explained it is easy to exploit a .png containing a .class). If you= can't trust the signing of the source bundle then .class is the least = issue you can get I fear so really not an issue.
>>>
>>> Also for this particular case: these .classes are in *test* re= sources so not used until you run tests and if you do so you likely want to= have them. When I spoke of bad tool chain it was about the project itself,= not the user: if you don't use that trick you need to generate classes= in the build but NOT in the test-classes folder to ensure these classes ar= e NOT in the classpath (point of having them as resources). Most of solutio= ns would break IDE support and would make entry cost of the project high fo= r a poor gain, that is why it got done this way. Also note that these .clas= s are in the "wrong" folder regarding their package and are NOT c= lasses the way they are stored. Without some actual file copy you will not = load them by default even if in the classpath. So running them needs some k= nowledge on them which reduces again the risk.
>>>
>>> BTW not the first time this trick is used @asf cause it is the= best compromise for such things (not breaking dev tooling).
>>>
>>> So concretely I read this thread as "do we trust our sign= ing". If the answer is no then I think we have a big problem to solve = but I'm not seeing why it would be the case at the moment.
>>>
>>>
>>> -Alex
>>>
>>> From: Romain Manni-Bucau <rmannibucau@gmail.com>=
>>> Reply-To: "legal-discuss@apache.org" <= legal-discuss@apache.org>
>>> Date: Tuesday, January 3, 2017 at 9:17 AM
>>> To: "legal-discuss@apache.org" <legal-discuss@apache.org>
>>> Subject: Re: Inclusion of .class files within a Apache Source = Release
>>>
>>> Please don't diverge: too much
>>>
>>> - can we do better: probably, even if "process-test-resou= rces life-cycle goal seems read-made for this" doesn't really help= since it requires a build setup we likely don't want to ensure we have= these classes only for some part of some tests and not the whole test phas= e. it also breaks IDE support to do it this way and reduce contributions ca= pabilities but that's another topic....
>>> - is it legal: yes (otherwise as mentionned all projects with = binary resources would be illegal)
>>> - is it unsecured? likely as much as generating bytecode at ru= ntime so probably out of topic for here too. Also note that a picture (.png= for instance) can be a .class and be loaded by a JVM is correctly launched= so security there is not really a point IMHO.
>>>
>>> In summary I don't see why it makes so much noise for real= ly an implementation detail and I'm not seeing what is the alternative = proposal to not distribute ANY binary if we care about it? Do I miss an imp= ortant point?
>>>
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau |=C2=A0 Blog | Old Blog | Github | LinkedIn | Jav= aEE Factory
>>>
>>> 2017-01-03 18:05 GMT+01:00 Alex Harui <aharui@adobe.com&= gt;:
>>>
>>>
>>> On 1/3/17, 3:51 AM, "Mark Struberg" <struberg@yah= oo.de.INVALID> wrote:
>>>
>>>> The class file in question was added by ASF member rmannib= ucau under ALv2
>>>> as a >>resource<< and not as a source file. >>>> The original file of course has the ASF license header, bu= t the 'class'
>>>> resource is still checked in to our SVN as .class file. >>>>
>>>> This is for testing some bytecode stuff in OpenBebBeans. W= e could
>>>> probably later change this to have another project module,= compile it,
>>>> unpack it, copy it over, blablabla.
>>>> But that doesn't change anything about the fact that t= his file is ALv2
>>>> licensed. But since it's a binary it obviously does no= t have any ALv2
>>>>>> SOURCE<< header.
>>>>
>>>> In other words: this .class file is a test resource and ha= ndled exactly
>>>> the same like a png or jpeg file.
>>>>
>>>> I don't see any legal problem.
>>>
>>> There may not be a legal problem, but I thought the reason beh= ind the "no
>>> compiled code" rule/policy was about verification/auditin= g of the release
>>> artifact.=C2=A0 See Marvin Humphrey [1].
>>>
>>> Anybody auditing a release would scan each file for headers an= d find
>>> binaries.=C2=A0 They could examine binaries proposing to be im= age files and
>>> verify that they have image file headers and are thus safe to = open in an
>>> application.=C2=A0 But verification of the safety of executing= a .class file
>>> seems risky to me.=C2=A0 I'm surprised to learn that some = ASF projects allow it.
>>>
>>> -Alex
>>>
>>> [1]
>>> https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201606.= mbox/%3c
>>> CAAS6=3D7gVXGHqeK= VeFV_r1849Qpi0+Ca0jc2QWQBQfRdZnCwVpA@mail.gmail.com%3e
>>>
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>>> Am 03.01.2017 um 12:45 schrieb John D. Ament <j= ohndament@apache.org>:
>>>>>
>>>>> Hi,
>>>>>
>>>>> While looking at [1] and looking at a proposed Apache = OpenWebBeans [2]
>>>>> it was discovered that .class files were contained in = the source
>>>>> release.=C2=A0 It seems in the past that image files w= ere generally
>>>>> considered OK in source releases, since they typically= had to do with
>>>>> building websites, the traceability of the image was e= asy to discover.
>>>>>
>>>>> .class files are the compiled output from .java source= files (as well
>>>>> as .groovy and other JVM languages, depending on how y= ou compile).
>>>>> Since they are compiled output, it seems they shouldn&= #39;t be in a source
>>>>> release.=C2=A0 However, the only true policy I could f= ind that it violated
>>>>> was that we require appropriate licensing [3] and ther= e is no way to
>>>>> verify the licensing of these files.
>>>>>
>>>>> So I'm wondering 1. is that accurate? and 2. is th= ere an acceptable way
>>>>> to verify that the license is correct?
>>>>>
>>>>> [1]:
>>>>> http://www.apache.org/dev/release.html#what-must-every-release-= contain
>>>>> [2]:
>>>>> https://lists.apache.org/thread.html/869c739764d5d55d81199576= d730d485d66d
>>>>> f8be17ae16398dd7ca1f@%3= Cdev.openwebbeans.apache.org%3E
>>>>> [3]: http://www.apache.org/dev/release-publishing.html#valid
>>>>>
>>>>
>>>>
>>>> ----------------------------------------------------------= -----------
>>>> To unsubscribe, e-mail: legal-discuss-u= nsubscribe@apache.org
>>>> For additional commands, e-mail: legal-discuss= -help@apache.org
>>>>
>>>
>>>
>>>
>>
>>
>> ------------------------------------------------------------------= ---
>> To unsubscribe, e-mail: legal-discuss-unsubscri= be@apache.org
>> For additional commands, e-mail: legal-discuss-help@ap= ache.org
>>
>
>
> ---------------------------------------------------------------------<= br class=3D"gmail_msg"> > To unsubscribe, e-mail: legal-discuss-unsubscribe@a= pache.org
> For additional commands, e-mail: legal-discuss-help@apache= .org
>

Craig Russell
= papajdo@gmail.com




---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache= .org
For additional commands, e-mail: legal-discuss-help@apache.org<= /a>

--001a114fc6c01cbfae0545370d32--