LLVM Relicensing Update

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

LLVM Relicensing Update

via cfe-dev
Greetings,

I wanted to provide an update to all the LLVM project (including all of its sub-projects) developers about the ongoing effort to relicense under LLVM under a new, unified license.

TL;DR: It’s actually happening. If you are a contributor to LLVM, help us out by filling out our form and signing an agreement to cover any individual contributions you have made:

All of this information and the latest status can always be found on the relicensing website here:


## Background and Process

For background, here is the new license:
The motivation, scope, and discussion of the license itself, please see the most recent thread from Chris on the subject:
Also, we have the proposed new developer policy discussed here:

Based on these discussions, there seems clear consensus to move forward, and we (the Foundation) have been working on this for the past year. I want to update folks on the progress and the next steps in the more boring logistics side of this: how do we actually switch.

Our plan, roughly outlined when discussing the developer’s policy last year, is to install the new license and the developer policy that references both the new and old license. At that point, all subsequent contributions will be under both licenses. To ensure contributors are aware, we have a two-fold plan:

1) We’re going to get as many active contributors (both companies and individuals) to explicitly sign an agreement to relicense their contributions. This will make the change clear and will cover historical contributions as well.
2) For any remaining contributors, turn off their commit access until we can confirm they are covered by one of the above agreements.

We plan to have the *vast majority* of contributors handled via #1 ahead of time, so this will not be disruptive. If necessary, we can delay this to ensure that #1 covers enough of the active contributors. We do not want to unnecessarily disrupt contributions, but we also want to move this forward as fast as we can. For contributors who cannot, for whatever reason, complete the outlined process (#2 above), please send email to [hidden email] and we'll work, in conjunction with our legal counsel, to find a path forward.

Our current planned timeline is to install the new developer policy and the new license after the LLVM 8.0 release branch in January. We will then be focused on getting all of the historical contributions under an agreement to relicense so we can remove the old license(s).


## Relicensing Agreements

For #1 to work, we need both individuals and companies to sign an agreement to relicense. The Foundation has worked with our lawyer and built a process for both companies and individuals.

For individuals, we’re asking everyone to fill out a form so we have the necessary information (email addresses, potential employers, etc.) to effectively relicense their contributions. It contains a link to a DocuSign agreement to relicense any of their individual contributions under the new license. We’re really hoping that most people will just sign this agreement as it avoids us needing to prove whether every contribution is definitively covered by some company. You can fill out the form and sign the agreement here:

For companies, we also have a DocuSign agreement:
We have already reached out to many major companies already, and a few have already signed this agreement. We will be collecting more companies from the form responses and reaching out to them. Feel free to reach out to your employer with the DocuSign link above, but please check the list of companies we’ve already contacted and try to coordinate internally to avoid duplicate work.

Once we get the new policy and license in place, we’ll be iterating with these tools until we have everything relicensed, or we have a concrete plan about what to do with any remaining material.


## New File Headers

With the new license and developer policy, we also need to update the file headers. The Foundation worked with our lawyer to get a new header approved that is both minimal and functional:
```
//===-- file/name - File description ----------------------------*- C++ -*-===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
```

Some notable aspects:
- No explicit copyright notice. After discussion with our lawyer, the value doesn’t seem worthwhile and it avoids the yearly need to update these.
- Super compact, but includes things like an SPDX marker to ease automated license analysis.

We will install these new file headers at the same time as the new developer policy and license.


Thanks all, and don’t hesitate to reach out with any questions!
-Chandler (on behalf of the LLVM Foundation)


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [libcxx-dev] LLVM Relicensing Update

via cfe-dev

Dear LLVM community,

Please do not agree to relicense LLVM under the Apache 2 license. It will make LLVM less useful, prevent other open source projects from using it, and encourage the proliferation of software patents on LLVM technologies.

If LLVM is relicensed, projects like OpenBSD will no longer be able to include upstream changes, because the patent termination clause restricts users’ rights. Even if you do not use OpenBSD, you almost certainly use OpenSSH, OpenBSD’s SSH implementation. If the project loses the ability to include a recent compiler, many people will suffer the consequences.

Relicensing will also encourage privately held software patents on LLVM. Under US [1] and European [2] law, public disclosure of intellectual property invalidates patentability. That means if you release source code without filing patents, the code becomes unpatentable by anyone. When code is committed under the current license, everyone gains a permanent right to use it.

For the patent termination clause of the Apache 2 license to be valid, patents must be filed preemptively. Other contributors who have not filed their own patents are then placed at a legal disadvantage. This creates an “arms race” where everyone has to patent their unique contributions, creating the threat of retaliation to avoid potentially getting sued for infringement.

Even if you acknowledge that the current license is not perfect, relicensing LLVM will violate the spirit of good will and cooperation that makes open source possible. It will take away the ability for other projects to use LLVM, and increase the legal risks for those who choose not to patent their contributions. If you are a programmer, not a lawyer, relicensing LLVM is not in your interest.

Thanks,
Pavan

[1] http://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title35-section102&num=0&edition=prelim

[2] https://www.epo.org/law-practice/legal-texts/html/epc/2016/e/ar54.html


On Tue, Oct 16, 2018, 7:37 PM Chandler Carruth via libcxx-dev <[hidden email]> wrote:
Greetings,

I wanted to provide an update to all the LLVM project (including all of its sub-projects) developers about the ongoing effort to relicense under LLVM under a new, unified license.

TL;DR: It’s actually happening. If you are a contributor to LLVM, help us out by filling out our form and signing an agreement to cover any individual contributions you have made:

All of this information and the latest status can always be found on the relicensing website here:


## Background and Process

For background, here is the new license:
The motivation, scope, and discussion of the license itself, please see the most recent thread from Chris on the subject:
Also, we have the proposed new developer policy discussed here:

Based on these discussions, there seems clear consensus to move forward, and we (the Foundation) have been working on this for the past year. I want to update folks on the progress and the next steps in the more boring logistics side of this: how do we actually switch.

Our plan, roughly outlined when discussing the developer’s policy last year, is to install the new license and the developer policy that references both the new and old license. At that point, all subsequent contributions will be under both licenses. To ensure contributors are aware, we have a two-fold plan:

1) We’re going to get as many active contributors (both companies and individuals) to explicitly sign an agreement to relicense their contributions. This will make the change clear and will cover historical contributions as well.
2) For any remaining contributors, turn off their commit access until we can confirm they are covered by one of the above agreements.

We plan to have the *vast majority* of contributors handled via #1 ahead of time, so this will not be disruptive. If necessary, we can delay this to ensure that #1 covers enough of the active contributors. We do not want to unnecessarily disrupt contributions, but we also want to move this forward as fast as we can. For contributors who cannot, for whatever reason, complete the outlined process (#2 above), please send email to [hidden email] and we'll work, in conjunction with our legal counsel, to find a path forward.

Our current planned timeline is to install the new developer policy and the new license after the LLVM 8.0 release branch in January. We will then be focused on getting all of the historical contributions under an agreement to relicense so we can remove the old license(s).


## Relicensing Agreements

For #1 to work, we need both individuals and companies to sign an agreement to relicense. The Foundation has worked with our lawyer and built a process for both companies and individuals.

For individuals, we’re asking everyone to fill out a form so we have the necessary information (email addresses, potential employers, etc.) to effectively relicense their contributions. It contains a link to a DocuSign agreement to relicense any of their individual contributions under the new license. We’re really hoping that most people will just sign this agreement as it avoids us needing to prove whether every contribution is definitively covered by some company. You can fill out the form and sign the agreement here:

For companies, we also have a DocuSign agreement:
We have already reached out to many major companies already, and a few have already signed this agreement. We will be collecting more companies from the form responses and reaching out to them. Feel free to reach out to your employer with the DocuSign link above, but please check the list of companies we’ve already contacted and try to coordinate internally to avoid duplicate work.

Once we get the new policy and license in place, we’ll be iterating with these tools until we have everything relicensed, or we have a concrete plan about what to do with any remaining material.


## New File Headers

With the new license and developer policy, we also need to update the file headers. The Foundation worked with our lawyer to get a new header approved that is both minimal and functional:
```
//===-- file/name - File description ----------------------------*- C++ -*-===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
```

Some notable aspects:
- No explicit copyright notice. After discussion with our lawyer, the value doesn’t seem worthwhile and it avoids the yearly need to update these.
- Super compact, but includes things like an SPDX marker to ease automated license analysis.

We will install these new file headers at the same time as the new developer policy and license.


Thanks all, and don’t hesitate to reach out with any questions!
-Chandler (on behalf of the LLVM Foundation)

_______________________________________________
libcxx-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [libcxx-dev] LLVM Relicensing Update

via cfe-dev
On Tue, Oct 16, 2018 at 4:51 PM Pavan Maddamsetti <[hidden email]> wrote:

Dear LLVM community,

Please do not agree to relicense LLVM under the Apache 2 license.

This has already been discussed extensively. Please see the posts I cited. I don't really want to re-discuss this, there was clear consensus in the previous threads.

I acknowledge that some still have concerns, but I don't think re-discussing it here is going to be constructive. If there is new information, then a new discussion (not this thread) should be started. However, the content of your email brings up points that have been discussed already.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [libcxx-dev] LLVM Relicensing Update

via cfe-dev
In reply to this post by via cfe-dev


On Oct 16, 2018, at 4:51 PM, Pavan Maddamsetti via cfe-dev <[hidden email]> wrote:

Dear LLVM community,

Please do not agree to relicense LLVM under the Apache 2 license. It will make LLVM less useful, prevent other open source projects from using it, and encourage the proliferation of software patents on LLVM technologies.

Hi Pavan,

Thank you for expressing your concerns, but as Chandler mentioned, we’ve already extensively discussed this in email threads over the last several years.  

Since you mention it, one of the major reasons I am personally motivated to get the relicensing effort done is to clarify the software patent situation.  These are complex matters and I respect your right to hold an opinion.  However, it is important for me to say that your interpretation of the situation in direct contradiction with virtually every expert I’ve spoken to about the matter - including the independent lawyer that represents the LLVM community (who happens to be a OSS software license expert).

The LLVM community is based on the idea of engineers across the world coming together to collaborate in neutral ground to build amazing infrastructure.  It is important that this remains independent of corporate or business conflicts that their affiliations may or may not have with other contributor’s organizations.  I’m super proud of the how strong the community is on this point and how collaborative and inclusive the community is, and the relicensing is just a small bit of insurance to help make sure things stay that way.

-Chris


If LLVM is relicensed, projects like OpenBSD will no longer be able to include upstream changes, because the patent termination clause restricts users’ rights. Even if you do not use OpenBSD, you almost certainly use OpenSSH, OpenBSD’s SSH implementation. If the project loses the ability to include a recent compiler, many people will suffer the consequences.

Relicensing will also encourage privately held software patents on LLVM. Under US [1] and European [2] law, public disclosure of intellectual property invalidates patentability. That means if you release source code without filing patents, the code becomes unpatentable by anyone. When code is committed under the current license, everyone gains a permanent right to use it.

For the patent termination clause of the Apache 2 license to be valid, patents must be filed preemptively. Other contributors who have not filed their own patents are then placed at a legal disadvantage. This creates an “arms race” where everyone has to patent their unique contributions, creating the threat of retaliation to avoid potentially getting sued for infringement.

Even if you acknowledge that the current license is not perfect, relicensing LLVM will violate the spirit of good will and cooperation that makes open source possible. It will take away the ability for other projects to use LLVM, and increase the legal risks for those who choose not to patent their contributions. If you are a programmer, not a lawyer, relicensing LLVM is not in your interest.

Thanks,
Pavan

[1] http://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title35-section102&num=0&edition=prelim


[2] https://www.epo.org/law-practice/legal-texts/html/epc/2016/e/ar54.html


On Tue, Oct 16, 2018, 7:37 PM Chandler Carruth via libcxx-dev <[hidden email]> wrote:
Greetings,

I wanted to provide an update to all the LLVM project (including all of its sub-projects) developers about the ongoing effort to relicense under LLVM under a new, unified license.

TL;DR: It’s actually happening. If you are a contributor to LLVM, help us out by filling out our form and signing an agreement to cover any individual contributions you have made:

All of this information and the latest status can always be found on the relicensing website here:


## Background and Process

For background, here is the new license:
The motivation, scope, and discussion of the license itself, please see the most recent thread from Chris on the subject:
Also, we have the proposed new developer policy discussed here:

Based on these discussions, there seems clear consensus to move forward, and we (the Foundation) have been working on this for the past year. I want to update folks on the progress and the next steps in the more boring logistics side of this: how do we actually switch.

Our plan, roughly outlined when discussing the developer’s policy last year, is to install the new license and the developer policy that references both the new and old license. At that point, all subsequent contributions will be under both licenses. To ensure contributors are aware, we have a two-fold plan:

1) We’re going to get as many active contributors (both companies and individuals) to explicitly sign an agreement to relicense their contributions. This will make the change clear and will cover historical contributions as well.
2) For any remaining contributors, turn off their commit access until we can confirm they are covered by one of the above agreements.

We plan to have the *vast majority* of contributors handled via #1 ahead of time, so this will not be disruptive. If necessary, we can delay this to ensure that #1 covers enough of the active contributors. We do not want to unnecessarily disrupt contributions, but we also want to move this forward as fast as we can. For contributors who cannot, for whatever reason, complete the outlined process (#2 above), please send email to [hidden email] and we'll work, in conjunction with our legal counsel, to find a path forward.

Our current planned timeline is to install the new developer policy and the new license after the LLVM 8.0 release branch in January. We will then be focused on getting all of the historical contributions under an agreement to relicense so we can remove the old license(s).


## Relicensing Agreements

For #1 to work, we need both individuals and companies to sign an agreement to relicense. The Foundation has worked with our lawyer and built a process for both companies and individuals.

For individuals, we’re asking everyone to fill out a form so we have the necessary information (email addresses, potential employers, etc.) to effectively relicense their contributions. It contains a link to a DocuSign agreement to relicense any of their individual contributions under the new license. We’re really hoping that most people will just sign this agreement as it avoids us needing to prove whether every contribution is definitively covered by some company. You can fill out the form and sign the agreement here:

For companies, we also have a DocuSign agreement:
We have already reached out to many major companies already, and a few have already signed this agreement. We will be collecting more companies from the form responses and reaching out to them. Feel free to reach out to your employer with the DocuSign link above, but please check the list of companies we’ve already contacted and try to coordinate internally to avoid duplicate work.

Once we get the new policy and license in place, we’ll be iterating with these tools until we have everything relicensed, or we have a concrete plan about what to do with any remaining material.


## New File Headers

With the new license and developer policy, we also need to update the file headers. The Foundation worked with our lawyer to get a new header approved that is both minimal and functional:
```
//===-- file/name - File description ----------------------------*- C++ -*-===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
```

Some notable aspects:
- No explicit copyright notice. After discussion with our lawyer, the value doesn’t seem worthwhile and it avoids the yearly need to update these.
- Super compact, but includes things like an SPDX marker to ease automated license analysis.

We will install these new file headers at the same time as the new developer policy and license.


Thanks all, and don’t hesitate to reach out with any questions!
-Chandler (on behalf of the LLVM Foundation)

_______________________________________________
libcxx-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev