Relicensing: Revised Developer Policy

Hi all,

Now that we’ve settled on the license legalese to get to, we need to start the process of relicensing. We’re still sorting through all of the details of what this will take, but the first step is clear: new contributions to LLVM will need to be under both the old license structure and the new one (until the old structure is completely phased out). From a mechanical perspective, this is pretty simple, but I want to make sure that the community is aware of this and has time to digest and discuss any concerns.

In order to spell out what this will look like, we’ve gone ahead and revised http://llvm.org/docs/DeveloperPolicy.html to reflect what the new structure will look like. While the license text is the canonical truth, the DeveloperPolicy serves a few purposes: it explains to non-lawyers what the license means, provides rationale for the design, and deals with relicensing process topics.

I’ve attached a draft of the revised document below. Please take a look and let me know if anything should be further clarified or if you have any other questions and comments. Thanks!

-Chris

devpolicy.patch (16.1 KB)

I had to read this paragraph a few times before I realized that this was a TODO
message for the author of the policy, and there was nothing for me (a prior
contributor) to do yet. I would change this to something like:
" In the future we will have a mechanism for prior contributors to re-license
their code ..."

-Tom

Although the LLVM project and LLVM Foundation obviously can't give
legal advice, this page probably needs to be a little more than just a
web form. There is a wide variance in the level of understanding of
copyright and licensing issues across the developer community, even
open source contributors. As such, I think LLVM would benefit from
highlighting the sort of things contributors should be sure of before
submitting their permission, to ensure they have the authority to do
so. One scenario would be work-for-hire where permission was granted
to submit the code upstream, but copyright may still be held by the
client.

I'm really glad to see this re-licensing effort continuing to move
forwards. Thanks to everyone who has been working on it.

Best,

Alex

When we get to this point, we’ll definitely be working with the lawyer for the Foundation to make sure we get the legal things worked out correctly. I think this TODO is just essentially a note for others that “something” vetted by our lawyer will go here, not trying to forecast exactly what it will be.

That makes sense, thanks for the clarification.

Best,

Alex

Hi,

I still don't see any justification in the text why a license change is
required over having a contributor agreement including whatever patent
wording we want.

As such, I don't agree with it.

Cheers,
Rafael

Chris Lattner via llvm-dev <llvm-dev@lists.llvm.org> writes:

Hi Rafael,

We’ve discussed why a license change is preferable over the span of several years now. I’m happy to explain over the phone, contact me off list and we can talk.

-Chris

Minor nit: "what was protection was" -> "what protection was".

Sorry, but I really don't think a private conversation is appropriate
for such discussions.

If the motive cannot be explained in public I have no choice but to decide
based on what I know.

Cheers,
Rafael

Chris Lattner <clattner@llvm.org> writes:

This has already been discussed extensively in the public. The threads are available in the archives.

-Chris

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?

Thanks,
Rafael

Chris Lattner <clattner@llvm.org> writes:

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.
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).
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.

-Chris

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.
  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).
  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 think I remember another important issue in addition, let me dig through notes…

Chris Lattner <clattner@llvm.org> writes:

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.

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?

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.

Cheers,
Rafael

Chris Lattner <clattner@llvm.org> writes:

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@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

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 :slight_smile:

-Chris

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@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

Chris Lattner <clattner@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.