www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Russell <papa...@gmail.com>
Subject Re: Inclusion of .class files within a Apache Source Release
Date Tue, 03 Jan 2017 19:15:37 GMT
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’d even generalize it to say that you might imagine wanting various .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.


> On Jan 3, 2017, at 10:15 AM, Mark Struberg <struberg@yahoo.de.INVALID> 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 <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 <rmannibucau@gmail.com>:
>>> 2017-01-03 18:42 GMT+01:00 Alex Harui <aharui@adobe.com>:
>>> 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 the signing we do of the package,
not by the extension (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* 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 would break
IDE support and would make entry cost of the project high for a poor gain, that is why it
got done this way. Also note that these .class are in the "wrong" folder regarding their package
and are NOT classes 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 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 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-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 classes 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 capabilities
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 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 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 <aharui@adobe.com>:
>>> On 1/3/17, 3:51 AM, "Mark Struberg" <struberg@yahoo.de.INVALID> 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 it,
>>>> unpack it, copy it over, blablabla.
>>>> But that doesn't change anything about the fact that this file is ALv2
>>>> licensed. But since it's a binary it obviously does not have any ALv2
>>>>>> 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 and
>>> 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 file
>>> 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=7gVXGHqeKVeFV_r1849Qpi0+Ca0jc2QWQBQfRdZnCwVpA@mail.gmail.com%3e
>>>> LieGrue,
>>>> strub
>>>>> Am 03.01.2017 um 12:45 schrieb John D. Ament <johndament@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.  It seems in the past that image files were generally
>>>>> considered OK in source releases, since they typically had to do with
>>>>> building websites, the traceability of the image was easy to discover.
>>>>> .class files are the compiled output from .java source files (as well
>>>>> 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 violated
>>>>> was that we require appropriate licensing [3] and there is no way to
>>>>> 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

To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

View raw message