llvm dev - Oct 2015 - RFC: Improving license & patent issues in the LLVM community

On Wed, Oct 21, 2015 at 5:16 AM, Joerg Sonnenberger via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> On Tue, Oct 20, 2015 at 09:54:30PM -0700, Chris Lattner wrote:
>> On Oct 19, 2015, at 10:53 AM, Joerg Sonnenberger <joerg at
britannica.bec.de> wrote:
>> >>>> 2) We could require new contributors to sign the
Apache CLA.
>> >>>
>> >>> To me, this is the most acceptable option of the listed
terms.
>> >>
>> >> Please explain: why?
>> >
>> > First part for me is that switching the code to a different
license
>> > doesn't address some of the legal concerns regarding
"tainted" code.
>>
>> I’m not sure what you mean by that.
>
> Clearly :)
>
>> Because LLVM uses a distributed approach to copyright (i.e., all
>> contributors, or their employer, own the copyright for their work),
>> you must contact each of them to relicense the code under a new
license.
>> As part of this contact, you get them to agree to relicense under the
>> new license.  If they don’t, you aren’t allowed to retain the code.
>>
>> This seems clean to me, even if it is a huge amount of work, and even
>> if it means that you may not get to keep 100% of the code in the tree.
>
> I am not talking about the process for relicensing code. Let's assume
> that part happened. The point I am trying to make is that this doesn't
> solve any of the reasons why a CLA is normally introduced
So let me stop you right here.
Because this statement is just flat out wrong.
Let's go through your issues:
> and I do
> believe many of those are used as justification for such a license
> change in first place:
>
> (1) Clear responsibility for authorship of committed changes.
> (2) Explicit contract for patent licenses.
Again, as stated before, both of these issues are covered by the apache license.

It has a built-in CLA that explicitly grants both copyright and patent
rights from contributors when they make contributions to the work.
>
> Luckily, I don't have any legal department for pushing any corporate
> agenda here,
I'm not sure what you are suggesting here, ...
> but I am a bit surprised that especially the second part is
> considered a non-issue?
I'm also not sure why you think it's considered a non-issue.
Instead, what you are getting told is "both of your concerns are
already covered by the relicensing option".
Because they are :)

On Wed, Oct 21, 2015 at 07:52:45AM -0700, Daniel Berlin
wrote:
> On Wed, Oct 21, 2015 at 5:16 AM, Joerg Sonnenberger via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > On Tue, Oct 20, 2015 at 09:54:30PM -0700, Chris Lattner wrote:
> >> On Oct 19, 2015, at 10:53 AM, Joerg Sonnenberger <joerg at
britannica.bec.de> wrote:
> >> >>>> 2) We could require new contributors to sign the
Apache CLA.
> >> >>>
> >> >>> To me, this is the most acceptable option of the
listed terms.
> >> >>
> >> >> Please explain: why?
> >> >
> >> > First part for me is that switching the code to a different
license
> >> > doesn't address some of the legal concerns regarding
"tainted" code.
> >>
> >> I’m not sure what you mean by that.
> >
> > Clearly :)
> >
> >> Because LLVM uses a distributed approach to copyright (i.e., all
> >> contributors, or their employer, own the copyright for their
work),
> >> you must contact each of them to relicense the code under a new
license.
> >> As part of this contact, you get them to agree to relicense under
the
> >> new license.  If they don’t, you aren’t allowed to retain the
code.
> >>
> >> This seems clean to me, even if it is a huge amount of work, and
even
> >> if it means that you may not get to keep 100% of the code in the
tree.
> >
> > I am not talking about the process for relicensing code. Let's
assume
> > that part happened. The point I am trying to make is that this
doesn't
> > solve any of the reasons why a CLA is normally introduced
> 
> So let me stop you right here.
> Because this statement is just flat out wrong.
> Let's go through your issues:
> 
> > and I do
> > believe many of those are used as justification for such a license
> > change in first place:
> >
> > (1) Clear responsibility for authorship of committed changes.
> > (2) Explicit contract for patent licenses.
> 
> Again, as stated before, both of these issues are covered by the apache
license.
> 
> It has a built-in CLA that explicitly grants both copyright and patent
> rights from contributors when they make contributions to the work.
Huh? How can employee X of company Y contributing a patch grant any
patent rights on behalf of Y?

Joerg

>
>
> > Again, as stated before, both of these issues are covered by the
apache
> license.
> >
> > It has a built-in CLA that explicitly grants both copyright and patent
> > rights from contributors when they make contributions to the work.
>
> Huh? How can employee X of company Y contributing a patch grant any
> patent rights on behalf of Y?
>
>
Agent, actual, or apparent authority.
All valid.

Let's start with: In just about every country in the world, anyone
contributing on behalf of their company are exercising their employers
copyright (in most cases, even if they do it in their "spare time",
since
most people misunderstand what the law grants them there).

The license says:

"Licensor" shall mean the copyright owner or entity authorized by the
copyright owner that is granting the License.

It then uses licensor as the granter.

For example:

The copyright owner of work i do for Google is not owned by me, it's owned
Google. Thus, *Google* is the licensor, as defined by the license, even if
i am the one sending the work to llvm.

Both actual (They told me i could contribute), agent (I am also actually
authorized to contribute anyway), and apparent authority (Everyone else in
the community would normally believe i have authority to contribute, and
thus, there is apparent authority, regardless of whether Google said i
could contribute) would all bind Google when i contribute stuff.

Any one of them is sufficient.

Bottom line: If someone contributes to LLVM from a company, apparent
authority is going to bind that company.
This is why companies often try to carefully control who contributes things
to open source.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151021/1dc536fd/attachment.html>