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?
EdB On Mon, Dec 22, 2014 at 9:59 AM, Alex Harui <aha...@adobe.com> wrote: > > > On 12/21/14, 1:13 PM, "Justin Mclean" <jus...@classsoftware.com> wrote: > >>Hi, >> >>> 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 >>>checkbox >>> 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 >>notified. > > 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 >>>aren’t >>> 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
