flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [4.14] binary vs. source package legal docs
Date Sun, 21 Dec 2014 16:14:04 GMT
@Justin, thanks for the link to “prominent label”.  IMO, what to do about
older releases is a different topic.  Changing the 4.14 LICENSE and NOTICE
won’t help older releases.

I had two other thoughts on this topic:

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

If we can in fact bundle more stuff in the binary package, maybe we go all
the way and bundle SWFObject and OSMF too?

-Alex

[2] http://www.apache.org/dev/release.html

On 12/21/14, 1:20 AM, "Erik de Bruin" <erik@ixsoftware.nl> wrote:

>Funny thing: I'm with Justin on this ;-)
>
>Let's make this simpler for the end-user, not more complicated. If we
>can reasonable assume that we can either pre-tick something, or leave
>out the option altogether, we want to do that. We don't want to do
>something that affects the user "just to make extra doubly sure we run
>even the slightest chance of having to change this again at some point
>in the future (which is really the worst case scenario)".
>
>EdB
>
>
>
>On Sun, Dec 21, 2014 at 9:38 AM, Justin Mclean <justin@classsoftware.com>
>wrote:
>> Hi,
>>
>>> I’m ok with pulling out SWFObject when we go tweak the install script
>>> unless someone has a good reason it should stay in there.
>>
>> A possible option would be to pre tick and/or remove the checkbox in
>>the installer?
>>
>>> My temptation is to fix this by making Saxon a download behind a prompt
>>
>> Why do we need a prompt? We're not downloading the source, just the jar
>>right?
>>
>>>  That avoids us having to figure out what “prominent label” means.
>>
>> This has been discussed and seems reasonably clear,  but the JIRA is
>>not marked as closed. [1]
>>
>>> And yet another option is to download all of these jars in the install.
>>
>> We currently are as we are downloading the binary and they are
>>contained in that, but I assume you mean removing them from the binary
>>and downloading them separately via the installer script? In that case
>>how would we handler older versions of the SDK?
>>
>>> It would probably be the fewest changes to the repo to make it work as
>>> then we wouldn’t need to muck with LICENSE and NOTICE as much, but then
>>> there are more downloads that could fail during the install.
>>
>> Given we already have a large number of download failures I'm not sure
>>that's the best option.
>>
>>>> * NOTICE file may not be correct as velocity original NOTICE file has
>>>>no
>>>> downstream effects.
>>>
>>> Not sure I understood what you mean by that.
>>
>> The Velocity NOTICE file in the jar doesn't look like the
>>original/right one and may of been incorrectly replaced.
>>
>>> From the above list, do we need to add W3C if all jars that have W3C
>>>also
>>> have AL licenses?
>>
>> My understanding is that its not dual licensed (ie select the license
>>you want), but different parts of the code are licensed under different
>>licenses. The W3C license is compatible with Apache and I assume you
>>treat it like MIT/BSD license ie just add it to LICENSE.
>>
>> Thanks,
>> Justin
>>
>> 1. https://issues.apache.org/jira/browse/LEGAL-77
>
>
>
>-- 
>Ix Multimedia Software
>
>Jan Luykenstraat 27
>3521 VB Utrecht
>
>T. 06-51952295
>I. www.ixsoftware.nl

Mime
View raw message