flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Current FlexJS license/notice issues
Date Tue, 20 Sep 2016 17:37:05 GMT
IMO, there are 3 categories of inclusion:

1) Bundling an entire release artifact.
2) Bundling an entire file from a release artifact where the top-level
license applies to that file.
2a) and then modifying that file
3) Copying portions of an existing work into an ASF-owned fie.

Then there is a dimension of "compliance" where either the artifact and/or
file has properly executed its license requirements by having a copy of
the license in a downloadable file, and a reasonable header in each file.

For #1 and #2, when the artifact is compliant, it is easy to copy the
license and header as per the how-to.  But when we get to #3 and the
artifacts are not compliant, I think it becomes a judgement call.  But if
you are going to quote policy and precedent, I am going to take the time
to ask about other policy and precedent that seems to be in conflict with
your proposal.  And then we have to decide as a PMC whether to accept your
proposed changes based on policy, or just preference.  These exercises
should be somewhat educational in order to help make it worth the time we
spend on it, so I am going to make sure the information here is accurate
and that how-to guidelines for common cases are not confused with policy.
None of us are lawyers and this stuff can be confusing enough that both of
us have been inaccurate in our advice in the past.

More responses in-line.

On 9/20/16, 12:44 AM, "Justin Mclean" <justin@classsoftware.com> wrote:

>>  Are you proposing to get the OpenFL community to accept headers on
>>their source
>> files by submitting a pull request on their repos and then replicating
>> that header under the ASF header in Matrix.as?
>No I was going to add a header to make it clear that the code wasn’t
>originally Apache licensed and originally come from somewhere else.

Matrix.as [4] currently has the following added by me:

// Implementation derived fromL
//     https://github.com/openfl/openfl/blob/develop/openfl/geom/Matrix.hx
// available under MIT License.

I added this after the release.  This is because whatever code Harbs did
borrow came from a file that did not have a header.  What policy or
precedent are you saying requires the synthesis of a header on behalf of
OpenFL?  Remember that a senior Apache member recommended filing an
upstream issue in this email [5].  If you help make OpenFL more
"compliant" by filing the upstream bug or pull request then they will have
an approved header that we can copy.

>> And are you going to have the build download their LICENSE.md file from
>> repo and adjust our LICENSE to point to it?
>Yes but only downloading it once and adding a file to our repo. It can be
>found here. [1] I'd only use the MIT bits as the other bits don’t apply
>to what we used.

Given that the source header policy [2] says not to modify third-party
headers, it seems odd to be modifying a third-party license file.  I've
always assumed this was one scenario where it was better to copy the full
text of the applicable parts of the license into our LICENSE.  Have you
seen a past decision that it is ok to synthesize or subset a third-party
LICENSE file in order to use a pointer instead a copy?

>> Again, we are not consuming an entire artifact or file.
>The original code is copyright other people and under a different
>license, as per policy [2] changes to a differently licensed file keeps
>the original license. Even if it was extensively modified (and the bar is
>generally very high for that) it would still be useful to note that it
>was originally owned by someone else and under a different license. The
>guiding principle also applies here, if it bundled and permissive then it
>needs to be mentioned in license. And it’s also important that we should
>abide by the terms of the MIT license and have the copyright owner and
>full text somewhere.

We have noted that portions of this file came from someone else under a
different license.  The copyright owner and full text are in LICENSE [6].
I don't see any policy violations here, so any changes here are based on
preference, assuming it really is ok to modify someone's license file.  If
you are certain it is ok to subset a third-party license file, then go
ahead and make that change.  I just want to make sure folks understand
this change is not driven by policy.
>>  Are you proposing to submit a pull request to the Flat UI folks to
>>have them put a correct
>> MIT license in their repo or README.md?
>No. They do however link to MIT [3] on their page so it clear what their
>intent is and what the license text would be.

To me, [5] recommends having the FlatUI folks make changes so their use of
the MIT license is "compliant" and thus it we handle this dependency
consistently with how we handle the OpenFL dependency.  Otherwise, it
seems odd for you to synthesize a version of the MIT license on their
behalf in our repo.  You would be putting their copyright on it even
though you are effectively the copyright owner of that file.  Feels like
signing a contract for someone.  If you contribute that file to FlatUI and
they accept it, then they are effectively "signing the contract".

The gist of [5] to me says that we should not be fixing other folks'
LICENSE documentation errors on their behalf, so it seems to contradict
what you are proposing.

>> when my manager returns in about 3 weeks I will seek permission to make
>>the donation so we can avoid
>> debating this issue and maybe get some positive attention from the
>>CreateJS community.
>Adding the header is simple and covers us until that has been sorted out.
>"Worse case" I’ll be happy to remove the header if required at a later
>date. IMO It’s better to have a possible documentation issue than a
>possible licensing error.

One you add a header to make a file third-party, can you remove the header
later?  IMO, it is safer to not give away things we shouldn't.  It will
all get sorted out by donating these files to CreateJS.  There is no major
risk mandating this change now.

>> If we do the steps above, what else will need a pointer?  And, if you
>> time, what policy document requires pointers?
>It’s only in the how to (that I’m aware of), but Ross (+ others) has said
>to use the short form many times. It makes the license smaller and easier
>to understand for anyone looking at. Oddly I can’t find legal policy that
>says the full text must be copied into LICENSE either, can you provide a
>link to that please?

I didn't say there was any requirement for copies.  I prefer pointers as
well, but I don't know if it has to be to downloadable artifacts, or if
pointers to  synthesized artifacts is also ok.  You stated that we would
be "more in line with policy" by going to pointers and I'm not clear that
is an accurate statement.

>So am I good to make all of the above changes?

I guess I don't understand why we should be ignoring the advice in [5].
I'm also not sure about pointers to synthesized licenses.  I also don't
want to spend a lot of time arguing about it, so if we agree to leave the
CreateJS stuff for now, I won't veto any changes for OpenFL and Flat, but
I believe these changes are being made on preference not policy, and may
not be what senior Apache members recommend.


>1. https://github.com/openfl/openfl/blob/develop/LICENSE.md
>2. https://www.apache.org/legal/src-headers.html#3party (see points 3 + 4)
>3. https://opensource.org/licenses/mit-license.html


View raw message