www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Bundling and LICENSE
Date Wed, 21 Sep 2016 06:30:30 GMT
Sorry to revive this thread.

Two similar scenarios have arisen in Flex again.  In one case, snippets were taken from an
MIT-licensed file in a GH repo.  The particular file did not have any sort of header on it.
 Justin is proposing that we invent a header on their behalf for inclusion in our code.  My
understanding from this thread was that we should file a bug or pull request with the GH repo
owners to have them put in headers so we know which header to copy.  Or was your advice to
file an upstream issue specific to the Google NOTICE scenario and doesn't expand to cover
other third parties in general?

In another scenario, some MIT-licensed code was copied but the GH repo it came from does not
have a copy of the MIT license in their repo.  Their README simply has a link to an MIT License
on the web.   My understanding from this thread was that we should file an upstream issue
to have that GH repo put in a proper LICENSE file.  Justin wants us to create a LICENSE file
on their behalf.

And since I have your attention already, if a GH repo has a license file which lists dependency
licenses but you are only copying snippets so only a subset of that file applies, is it ok
to copy their license file into our repo and remove the irrelevant parts so our LICENSE can
point to it, or is that when you should just copy the relevant subset into our LICENSE and
not use pointers?  Or does it matter?


From: Greg Stein <gstein@gmail.com<mailto:gstein@gmail.com>>
Reply-To: "legal-discuss@apache.org<mailto:legal-discuss@apache.org>" <legal-discuss@apache.org<mailto:legal-discuss@apache.org>>
Date: Sunday, April 3, 2016 at 6:55 PM
To: "legal-discuss@apache.org<mailto:legal-discuss@apache.org>" <legal-discuss@apache.org<mailto:legal-discuss@apache.org>>
Subject: Re: Bundling and LICENSE

On Sun, Apr 3, 2016 at 4:52 PM, Justin Mclean <justin@classsoftware.com<mailto:justin@classsoftware.com>>
> that person can void every other PMC member's vote because as soon as an
> irregularity is found

A -1 is not a veto / does not void a release. In the last RC it was suggested that the LICENSE/NOTICE
issue be fixed for the next release and no one voted -1. Even if there was a -1 all that means
that that individual PMC member doesn’t think the RC is release quality (for a good reason)
and is not a veto. Also people can change their vote once it is decided how to resolve the
issue in question.

This is important. The PMC can still make a release, if it has (3) +1 votes.

I think the important point here: what is the *intent* behind Google's applying the ALv2 to
GCL? Easy. They want you to use it under that license. If they missed a NOTICE, that should
not scuttle your release. It isn't like you've got a whole house of cards that is about to
fall down.

Look. Back in 2005, I chose ALv2 for Google's default license. Exceptions were to be made
(eg. GPL for GNU tools and BSD for Mac stuff), but otherwise Google uses ALv2 for all it can.
Their *intent* is for you to use it however you like. No skin off their back. Possibly even
good for them, if you find a way to use the code. So it isn't like they're about to roll around
and get pissed off at your bundling of GCL. Just do it, file an upstream issue, and stop writing
emails about this stuff.


View raw message