www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Inclusion of .class files within a Apache Source Release
Date Tue, 03 Jan 2017 17:42:58 GMT
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.


From: Romain Manni-Bucau <rmannibucau@gmail.com<mailto:rmannibucau@gmail.com>>
Reply-To: "legal-discuss@apache.org<mailto:legal-discuss@apache.org>" <legal-discuss@apache.org<mailto:legal-discuss@apache.org>>
Date: Tuesday, January 3, 2017 at 9:17 AM
To: "legal-discuss@apache.org<mailto:legal-discuss@apache.org>" <legal-discuss@apache.org<mailto: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
- 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<https://twitter.com/rmannibucau> |  Blog<https://blog-rmannibucau.rhcloud.com>
| Old Blog<http://rmannibucau.wordpress.com> | Github<https://github.com/rmannibucau>
| LinkedIn<https://www.linkedin.com/in/rmannibucau> | JavaEE Factory<https://javaeefactory-rmannibucau.rhcloud.com>

2017-01-03 18:05 GMT+01:00 Alex Harui <aharui@adobe.com<mailto:aharui@adobe.com>>:

On 1/3/17, 3:51 AM, "Mark Struberg" <struberg@yahoo.de.INVALID<mailto:struberg@yahoo.de.INVALID>>

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



>> Am 03.01.2017 um 12:45 schrieb John D. Ament <johndament@apache.org<mailto: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]:
>> [2]:
>> [3]: http://www.apache.org/dev/release-publishing.html#valid
>To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org<mailto:legal-discuss-unsubscribe@apache.org>
>For additional commands, e-mail: legal-discuss-help@apache.org<mailto:legal-discuss-help@apache.org>

View raw message