www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <johndam...@apache.org>
Subject Re: Inclusion of .class files within a Apache Source Release
Date Tue, 03 Jan 2017 21:06:58 GMT
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 <papajdo@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’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.
>
> Craig
>
>
> > 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
> papajdo@gmail.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>

Mime
View raw message