flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik de Bruin <e...@ixsoftware.nl>
Subject Re: [4.14] binary vs. source package legal docs
Date Sun, 28 Dec 2014 12:31:05 GMT
Even after rereading the thread, I won't pretend to understand what's
being discussed, but... Are we any closer to a resolution?  if so, is
this something that absolutely has to be addressed with this release?


On Mon, Dec 22, 2014 at 9:59 AM, Alex Harui <aharui@adobe.com> wrote:
> On 12/21/14, 1:13 PM, "Justin Mclean" <justin@classsoftware.com> wrote:
>>> Changing the 4.14 LICENSE and NOTICE won’t help older releases.
>>I assume we'll have to make point releases of them.
> It might be worth asking on legal-discuss as to whether that is required.
>>> 1) I’m wondering if one of the reasons for the Installer having a
>>> for SWFObject is because the Installer doesn’t let the customer review
>>> LICENSE and NOTICE of the release before installing, and the checkboxes
>>> effectively take the customer through the LICENSE.
>>Where is this written down as an Apache legal requirement? I think you
>>may be confusing the license with a EULA. If I download the source
>>package I don't have to view the LICENSE or NOTICE. As long as everything
>>is Apache or a compatible license (ie MIT, BSD or W3C) all's good as I
>>have the same rights. In the case of MPL there's an issue if the MPL
>>source is included and the weak copy-left kicks in and then I need to be
> I don’t know for sure.  Maybe Om remembers why SWFObject is listed.  I did
> find [3] in the archives where Bertrand says:
>   -All required dependencies have compatible licenses as per
>    http://apache.org/legal/resolved.html
>   -Users can easily find out what those compatible licenses are
> So maybe that’s the history behind it.
>>> 2) I’m for more bundling as well, but I’ve been trying to setup releases
>>> with less bundling because of [2] where it says: "the binary/bytecode
>>> package must have the same version number as the source release and may
>>> only add binary/bytecode files that are the result of compiling that
>>> version of the source code release.”  That sort of implies that we
>>> supposed to have 3rd party binaries in the binary package.
>>I'd read that as just saying that you can't have unreleased source
>>compiled into a binary release. Also see LEGAL jiras, for instance Open
>>Office was given permission to add GPL 3rd party files to their binary
>>[1] and this [2] (note the "yes" to adding it as a binary dependancy) and
>>there's probably others. Have you investigated what other projects do?
> AOO got an exception for what is more like a data file.  I looked through
> our archives and didn’t see any mentor advice on how to set up a binary
> package so no history to lean on there.  I poked at a few projects, not
> that you can use that as a reference point, but we’d have to examine their
> source packages and compare.  Apache seems to be historically
> source-oriented and maven-oriented, so I’m wondering if binary packages
> that have non-Apache jars got created by downloading the source for those
> non-Apache things and compiling them.  And other consumers of other binary
> packages just fish all the dependencies out of Maven so jars aren’t in the
> package.
> I’ll poke around a bit more tomorrow and maybe ask on legal-discuss or
> general@incubator.
> -Alex
>>1. https://issues.apache.org/jira/browse/LEGAL-117
>>2. https://issues.apache.org/jira/browse/LEGAL-72
> [3] http://s.apache.org/TNB

Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

View raw message