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 Thu, 22 Sep 2016 19:21:23 GMT
Hi Henri,

Glad to know I wasn't the only one who thought that raising issues upstream was general advice.

On the second question, it isn't about what to include, but how to include it.  The "how-to"
mentions a preference for pointers from the main LICENSE file to other license files in bundled
3rd party dependencies.  When consuming an entire artifact, it makes sense to download the
license file associated with the artifact and point to it from the main LICENSE file.  But
when you have only included snippets of a 3rd party work, and know that only part of the 3rd-party
license file applies, is it ok to download that 3rd-party license file and edit it and point
to the edited version from the main LICENSE file, or should we copy-paste the portion of the
3rd party license file into our LICENSE (or does it matter).  Editing a 3rd-party license
file feels like editing 3rd-party source file headers or editing a signed contract.  In my
mind, finding copies of portions of 3rd-party licenses in the main LICENSE file is a compilation,
not an edit.


From: Henri Yandell <bayard@apache.org<mailto:bayard@apache.org>>
Reply-To: "legal-discuss@apache.org<mailto:legal-discuss@apache.org>" <legal-discuss@apache.org<mailto:legal-discuss@apache.org>>
Date: Wednesday, September 21, 2016 at 10:52 PM
To: ASF Legal Discuss <legal-discuss@apache.org<mailto:legal-discuss@apache.org>>
Subject: Re: Bundling and LICENSE

+1 to, first step, reporting/pull-requesting to the project.

On the second question, if you're using snippets from a file you should include the licensing
that relates to the snippets. If you're unable to identify whether a piece of a license description
maps to that snippet, you should include, otherwise you can ignore if it doesn't relate to
the snippets.


On Tue, Sep 20, 2016 at 11:30 PM, Alex Harui <aharui@adobe.com<mailto:aharui@adobe.com>>
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