www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@apache.org>
Subject Re: Bundling and LICENSE
Date Thu, 22 Sep 2016 05:52:39 GMT
+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.

Hen


On Tue, Sep 20, 2016 at 11:30 PM, Alex Harui <aharui@adobe.com> wrote:

> 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?
>
> Thanks,
> -Alex
>
> From: Greg Stein <gstein@gmail.com>
> Reply-To: "legal-discuss@apache.org" <legal-discuss@apache.org>
> Date: Sunday, April 3, 2016 at 6:55 PM
> To: "legal-discuss@apache.org" <legal-discuss@apache.org>
> Subject: Re: Bundling and LICENSE
>
> On Sun, Apr 3, 2016 at 4:52 PM, Justin Mclean <justin@classsoftware.com>
> wrote:
> >...
>
>> > 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.
>
> Cheers,
> -g
>
>

Mime
View raw message