llvm dev - Aug 2017 - Relicensing: Revised Developer Policy

On Aug 10, 2017, at 3:08 PM, Rafael Avila de Espindola via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
> Chris Lattner <clattner at llvm.org> writes:
> 
>>> On Aug 10, 2017, at 2:59 PM, Rafael Avila de Espindola
<rafael.espindola at gmail.com> wrote:
>>> 
>>> I can find old threads about it, but nothing saying why it was
decided
>>> that contributor agreement wouldn't work. Care to send the URL?
>> 
>> Here are some quick points that come to mind:
>> 
>> 1. It raises the bar to contribution, because something must be
>> “signed” before a contribution can be made.
> 
> Yes, but changing the license impacts our users, which is a bigger issue
IMHO.
We don’t believe that the relicense will impact users of LLVM.  Also, a
relicense is unavoidable, as I already explained.
>> 2. The Apache CLA is the only widely available one, but it is
unsuitable for LLVM’s goals because it allows a project to relicense
contributions.
>> 3. Some contributors are significantly concerned with the Apache CLA,
partially because of #2, but there are other concerns.  Losing contributors
would be unfortunate.
>> 4. We do not want a novel legal device (e.g. a new or significantly
hacked up CLA).
> 
> We are proposing moving to modified Apache license. Why is a modified
> license less troublesome than a modified CLA?
The proposal is not a modified apache license.  It is an apache license that has
some exceptions which can be completely ignored by a user of LLVM if they
choose, and the exceptions are carefully scoped by many lawyers to ensure they
are bounded in the right ways.

Designing a new CLA would be a significantly novel device which is very bad for
reasons I’ve already explained in previous threads.
>> 5. The only way to achieve our goals (e.g. the ability to move code
between the compiler and runtime libraries) is through a relicense, so a CLA
doesn’t make anything simpler.
> 
> I have no problem changing the license to something FreeBSD and OpenBSD
> are happy with.
I request that you let other people worry about and represent their own
concerns: there is no need for you to try to defend or represent other other
people’s interests.  There is a lot of diligence that is happening off list,
which is one of the reasons progress is slow.  We’re doing everything possible
to make sure the right thing happens for users and contributors, even if it is
at the expense of calendar time.

That said, my understanding is that they are currently evaluating this, and the
current (but not finalized) belief is that the new license is good for FreeBSD.

-Chris

Chris Lattner <clattner at llvm.org> writes:
>> Yes, but changing the license impacts our users, which is a bigger
issue IMHO.
>
> We don’t believe that the relicense will impact users of LLVM.  Also, a
relicense is unavoidable, as I already explained.
The impact depends on the license. I don't think anyone ever objected to
MIT for example, and relicensing to that solves the issue of different
parts of llvm having different licenses.
>> I have no problem changing the license to something FreeBSD and OpenBSD
>> are happy with.
>
> I request that you let other people worry about and represent their own
concerns: there is no need for you to try to defend or represent other other
people’s interests.  There is a lot of diligence that is happening off list,
which is one of the reasons progress is slow.  We’re doing everything possible
to make sure the right thing happens for users and contributors, even if it is
at the expense of calendar time.
>
> That said, my understanding is that they are currently evaluating this, and
the current (but not finalized) belief is that the new license is good for
FreeBSD.
It is my interest to see my code used. In particular I am really excited
to see llvm/clang/lld/lldb/etc replacing more and more of the previous
components on these systems. I really don't want to harm that change.

If FreeBSD and OpenBSD are OK with license X, I am OK with license X.

Cheers,
Rafael

On Aug 10, 2017, at 5:29 PM, Rafael Avila de Espindola <rafael.espindola at
gmail.com> wrote:
>>> I have no problem changing the license to something FreeBSD and
OpenBSD
>>> are happy with.
>> 
>> I request that you let other people worry about and represent their own
concerns: there is no need for you to try to defend or represent other other
people’s interests.  There is a lot of diligence that is happening off list,
which is one of the reasons progress is slow.  We’re doing everything possible
to make sure the right thing happens for users and contributors, even if it is
at the expense of calendar time.
>> 
>> That said, my understanding is that they are currently evaluating this,
and the current (but not finalized) belief is that the new license is good for
FreeBSD.
> 
> It is my interest to see my code used. In particular I am really excited
> to see llvm/clang/lld/lldb/etc replacing more and more of the previous
> components on these systems. I really don't want to harm that change.
> 
> If FreeBSD and OpenBSD are OK with license X, I am OK with license X.
Great, thanks Rafael. I totally understand where you’re coming from.  I think
that many of us contributors care a lot about our code being used as widely as
possible :-)

-Chris

On 11 Aug 2017, at 01:29, Rafael Avila de Espindola via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> If FreeBSD and OpenBSD are OK with license X, I am OK with license X.
Note: I don’t speak for either project, as I stood down from the FreeBSD Core
Team last election (after two terms, I was owed some time off for good
behaviour), but as I was part of the FreeBSD Core Team for much of this long
process, I’m going to comment anyway.

OpenBSD and FreeBSD have different license policies, but Chris and others
involved in this process have iterated with the FreeBSD project and the latest
version has been sent to the FreeBSD Foundation’s lawyer.  We had several
concerns about early versions of the license.  Most notably, we want to ship
libc++ and compiler-rt as part of the base system and place no obligations on
any third-party code.  The current version of the exemption appears to allow
this[1] and also makes a number of other uses (e.g. using DRI drivers with X.org
that use LLVM) equally simple.

My understanding of the new license is that it will make life easier for a
number of downstream consumers, at the cost of a bit more legalese to wade
through (though far less than the GPL, even v2).  I would be happier if we could
achieve the same objective with less legal text, but the Apache 2 license plus
the LLVM exemption appears to be close to the minimum that possible with the
desired goals (permissive license, no restrictions on library use, patent
protection).  In particular, the Apache 2 license has already been scrutinised
by a lot of lawyers working for both companies that use / distribute open source
software and for various open source foundations and is well understood.  The
exemption is clear and excludes the only terms of the license that are not
simply describing good manners.

Relicensing all of the code is going to be a complicated process, and I’m
grateful to the LLVM Foundation for undertaking this effort.  There will
probably be some pain in the intermediate steps, but I believe that the end
state will be an improvement over the current state.

David

[1] I am not a lawyer, so I don’t make this claim strongly until we’ve heard
back from the Foundation’s lawyer, but it looks pretty clear.

Chris Lattner <clattner at llvm.org> writes:
>>> 2. The Apache CLA is the only widely available one, but it is
unsuitable for LLVM’s goals because it allows a project to relicense
contributions.
>>> 3. Some contributors are significantly concerned with the Apache
CLA, partially because of #2, but there are other concerns.  Losing contributors
would be unfortunate.
>>> 4. We do not want a novel legal device (e.g. a new or significantly
hacked up CLA).
>> 
>> We are proposing moving to modified Apache license. Why is a modified
>> license less troublesome than a modified CLA?
>
> The proposal is not a modified apache license.  It is an apache license
that has some exceptions which can be completely ignored by a user of LLVM if
they choose, and the exceptions are carefully scoped by many lawyers to ensure
they are bounded in the right ways.
The code is then effectively dual licensed. It is both Apache and
Apache+exceptions.

Could it be Apache+MIT for example?

Since every contributor would be agreeing with both, we would still get
section 3 (the grant of patents), and could drop our current patent
wording.

Cheers,
Rafael

On Fri, Aug 11, 2017 at 1:07 PM, Rafael Avila de Espindola via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Chris Lattner <clattner at llvm.org> writes:
> >>> 2. The Apache CLA is the only widely available one, but it is
> unsuitable for LLVM’s goals because it allows a project to relicense
> contributions.
> >>> 3. Some contributors are significantly concerned with the
Apache CLA,
> partially because of #2, but there are other concerns.  Losing contributors
> would be unfortunate.
> >>> 4. We do not want a novel legal device (e.g. a new or
significantly
> hacked up CLA).
> >>
> >> We are proposing moving to modified Apache license. Why is a
modified
> >> license less troublesome than a modified CLA?
> >
> > The proposal is not a modified apache license.  It is an apache
license
> that has some exceptions which can be completely ignored by a user of LLVM
> if they choose, and the exceptions are carefully scoped by many lawyers to
> ensure they are bounded in the right ways.
>
> The code is then effectively dual licensed. It is both Apache and
> Apache+exceptions.
>
This is not correct.  It is apache + additional permissions.
That is not a dual license, in theory or practice, any more than if i said
"My code is GPLv2, but you are free to ignore section 2" is dual
licensed.
>
> Could it be Apache+MIT for example?
>
Folks went through almost every possibility you can think of before
arriving at this choice.
Dual licensing has the horrible outcome that you must choose which of the
two licenses you are using, and you will get very different rights
depending on your choice.  You don't get to use it under both
simultaneously - It is not the quantum superposition of licenses.

> Since every contributor would be agreeing with both, we would still get
> section 3 (the grant of patents), and could drop our current patent
> wording.
>
This is not correct, as i stated, you have to choose which you are using it
under.
If i choose MIT, you are welcome to sue me for patents without fear you
will lose something.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170811/fc22f4e9/attachment.html>