llvm dev - Jan 2019 - New license landing 2019-01-18 (end of next week!)

Greetings all!

# Summary
- We will put the new LLVM license and developer policy in place for all
subsequent commits next Friday (2019-01-18).
- Commit access will be stopped while this is done (starting 3pm PST,
hopefully under 3 hours).
- We will restore commit access for everyone covered by relevant corporate
and/or individual agreements.
- Others will need to take some steps to restore commit access (see below
for details).
- When committing patches contributed to the list by non-committers, ensure
they're aware of the new license.
- We are continuing to collect agreements for historical contributions,
working to full coverage.

If you haven’t yet, please go through the form:
https://goo.gl/forms/X4HiyYRcRHOnTSvC3

# Details

It’s been a long time coming, but we’re in a good position to put the new
license structure in place. This will cover all subsequent contributions to
LLVM projects. Once we complete collecting agreements for historical
contributions (this will take quite some time!), we will be able to remove
the old license. This follows the plan outlined and discussed on the lists:
http://lists.llvm.org/pipermail/llvm-dev/2018-October/126991.html
http://lists.llvm.org/pipermail/llvm-dev/2017-August/116266.html

We plan to install the new developer policy on Friday (2019-01-18). We will
disable all commit access while we install this, update all the relevant
license files, and update the headers of all files across the project. We
expect to turn off commit access at 3pm PST, and will restore everything
ASAP. We will send emails to the list an hour before this begins, when it
begins, and when everything is restored.

Once this is complete, we will start re-enabling commit access. We will
automatically enable commit access for all committers who match either of
these criteria:
1) Signed the individual agreement *and* any relevant employer signed a
corporate agreement.
2) Commits using an email address ending in one of the domains we can
trivially match with an employer that has signed a corporate agreement
covering all such employees.

We have emailed everyone who has committed in the last six months and isn't
covered by one of the above. These emails cover both individual agreements
and any missing corporate agreement. We are working on emailing everyone
who has committed in the last two years before the cut-over. If you haven't
gotten any recent emails about this, you're probably fine. We don't have
a
better way of testing whether you're impacted (if we did, we'd use it to
send you a pro-active email).

## Re-enabling commit access

If your commit access isn't automatically re-enabled, you will have to take
some action. There are several cases here:

a) If you haven't filled out the form (you can do this without signing
anything!), please do that first: https://goo.gl/forms/X4HiyYRcRHOnTSvC3

b) If you signed the individual agreement, but not all companies you listed
in the form are covered, but your current employer is covered, just ask
license-questions at llvm.org and let us know who your current employer is and
we will re-enable.

c) If your commits are 100% owned by a company (or companies) despite your
use of a personal email address (or an email we don't recognize for a
company) and you can't sign the individual agreement, please write an email
to license-questions at llvm.org explicitly stating your name, the relevant
company, and that they own your contributions. As soon as we have this in
our archive and confirm the company is covered, we will re-enable commit
access. We'll follow up regarding historical contributions later. However,
I want to repeat that this case is challenging for historical contributions
and signing the individual agreement is often much simpler and more
cost-effective for the LLVM project.

d) If your current employer hasn't yet signed the agreement, please send
email to license-questions at llvm.org clearly stating that both you and your
current employer are aware of the new license and that all subsequent
contributions will be under this license, and we'll try to re-enable
access. However, getting agreement only for subsequent contributions may be
just as much work as getting the full corporate agreement, so if possible
please simply work with your employer as outlined here:
http://llvm.org/foundation/relicensing/#corporate_agreement

e) If you believe all relevant agreements are signed and your commit access
should have been re-enabled but we made an error, just send email to
license-questions at llvm.org and we will try and fix everything.

We are doing everything we can before the cut-over on Friday to minimize
how many contributors will be impacted by one of these cases. And we will
have folks working hard to respond rapidly to any further issues.

## Non-committer contributions

For non-committer contributions such as patches on lists, bugzilla, or
tools like phabricator, we want to make sure the author is aware of the new
license and intending their contribution to be under it before committing
it.

The easiest case is if the patch's baseline is after the cut-over. This can
be spotted by checking the file headers.

Otherwise, if you are committing a patch for someone else, please ask them
to explicitly acknowledge that it is under the new license. An easy way to
do this is by just asking them to rebase the patch.

This is only needed for the first few weeks after the new license and
policy is introduced to avoid confusion for contributors unaware of the
change. The new license is self executing and won't require any special
steps to accept contributions once in place.

## New file header

We will be using the file header described here:
http://llvm.org/foundation/relicensing/#header

```
//===-- 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
//
//===----------------------------------------------------------------------===//
```

All code in the project will be made available by the LLVM project under
the new license, so you will see that the license headers include that
license only. Some contributors have contributed code under the old
license, and accordingly, we will retain a copy of the old license notice
in the top-level files.

## Finishing the relicensing

While this is a very big, and very important step, it isn't the end. =]
While contributions going forward are under the new license, we will
continue to work through the history of contributions to the project in
order to get full coverage of the entire project. Once we finish, we will
remove the old license.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190112/958dd381/attachment.html>

Hi Chandler,

Just to make sure: will the 8.0 branch, which is going to be created 2019-01-16
(Wednesday), be affected?  If not, and 8.0 will come out under the previous
license, how will merges from trunk be handled?

-Dimitry
> On 12 Jan 2019, at 11:59, Chandler Carruth via Openmp-dev <openmp-dev at
lists.llvm.org> wrote:
> 
> Greetings all!
> 
> # Summary
> - We will put the new LLVM license and developer policy in place for all
subsequent commits next Friday (2019-01-18).
> - Commit access will be stopped while this is done (starting 3pm PST,
hopefully under 3 hours).
> - We will restore commit access for everyone covered by relevant corporate
and/or individual agreements.
> - Others will need to take some steps to restore commit access (see below
for details).
> - When committing patches contributed to the list by non-committers, ensure
they're aware of the new license.
> - We are continuing to collect agreements for historical contributions,
working to full coverage.
> 
> If you haven’t yet, please go through the form:
> https://goo.gl/forms/X4HiyYRcRHOnTSvC3
<https://goo.gl/forms/X4HiyYRcRHOnTSvC3>
> 
> # Details
> 
> It’s been a long time coming, but we’re in a good position to put the new
license structure in place. This will cover all subsequent contributions to LLVM
projects. Once we complete collecting agreements for historical contributions
(this will take quite some time!), we will be able to remove the old license.
This follows the plan outlined and discussed on the lists:
> http://lists.llvm.org/pipermail/llvm-dev/2018-October/126991.html
<http://lists.llvm.org/pipermail/llvm-dev/2018-October/126991.html>
> http://lists.llvm.org/pipermail/llvm-dev/2017-August/116266.html
<http://lists.llvm.org/pipermail/llvm-dev/2017-August/116266.html>
> 
> We plan to install the new developer policy on Friday (2019-01-18). We will
disable all commit access while we install this, update all the relevant license
files, and update the headers of all files across the project. We expect to turn
off commit access at 3pm PST, and will restore everything ASAP. We will send
emails to the list an hour before this begins, when it begins, and when
everything is restored.
> 
> Once this is complete, we will start re-enabling commit access. We will
automatically enable commit access for all committers who match either of these
criteria:
> 1) Signed the individual agreement *and* any relevant employer signed a
corporate agreement.
> 2) Commits using an email address ending in one of the domains we can
trivially match with an employer that has signed a corporate agreement covering
all such employees.
> 
> We have emailed everyone who has committed in the last six months and
isn't covered by one of the above. These emails cover both individual
agreements and any missing corporate agreement. We are working on emailing
everyone who has committed in the last two years before the cut-over. If you
haven't gotten any recent emails about this, you're probably fine. We
don't have a better way of testing whether you're impacted (if we did,
we'd use it to send you a pro-active email).
> 
> ## Re-enabling commit access
> 
> If your commit access isn't automatically re-enabled, you will have to
take some action. There are several cases here:
> 
> a) If you haven't filled out the form (you can do this without signing
anything!), please do that first: https://goo.gl/forms/X4HiyYRcRHOnTSvC3
<https://goo.gl/forms/X4HiyYRcRHOnTSvC3>
> 
> b) If you signed the individual agreement, but not all companies you listed
in the form are covered, but your current employer is covered, just ask
license-questions at llvm.org <mailto:license-questions at llvm.org> and
let us know who your current employer is and we will re-enable.
> 
> c) If your commits are 100% owned by a company (or companies) despite your
use of a personal email address (or an email we don't recognize for a
company) and you can't sign the individual agreement, please write an email
to license-questions at llvm.org <mailto:license-questions at llvm.org>
explicitly stating your name, the relevant company, and that they own your
contributions. As soon as we have this in our archive and confirm the company is
covered, we will re-enable commit access. We'll follow up regarding
historical contributions later. However, I want to repeat that this case is
challenging for historical contributions and signing the individual agreement is
often much simpler and more cost-effective for the LLVM project.
> 
> d) If your current employer hasn't yet signed the agreement, please
send email to license-questions at llvm.org <mailto:license-questions at
llvm.org> clearly stating that both you and your current employer are aware
of the new license and that all subsequent contributions will be under this
license, and we'll try to re-enable access. However, getting agreement only
for subsequent contributions may be just as much work as getting the full
corporate agreement, so if possible please simply work with your employer as
outlined here: http://llvm.org/foundation/relicensing/#corporate_agreement
<http://llvm.org/foundation/relicensing/#corporate_agreement>
> 
> e) If you believe all relevant agreements are signed and your commit access
should have been re-enabled but we made an error, just send email to
license-questions at llvm.org <mailto:license-questions at llvm.org> and
we will try and fix everything.
> 
> We are doing everything we can before the cut-over on Friday to minimize
how many contributors will be impacted by one of these cases. And we will have
folks working hard to respond rapidly to any further issues.
> 
> ## Non-committer contributions
> 
> For non-committer contributions such as patches on lists, bugzilla, or
tools like phabricator, we want to make sure the author is aware of the new
license and intending their contribution to be under it before committing it.
> 
> The easiest case is if the patch's baseline is after the cut-over. This
can be spotted by checking the file headers.
> 
> Otherwise, if you are committing a patch for someone else, please ask them
to explicitly acknowledge that it is under the new license. An easy way to do
this is by just asking them to rebase the patch.
> 
> This is only needed for the first few weeks after the new license and
policy is introduced to avoid confusion for contributors unaware of the change.
The new license is self executing and won't require any special steps to
accept contributions once in place.
> 
> ## New file header
> 
> We will be using the file header described here:
> http://llvm.org/foundation/relicensing/#header
<http://llvm.org/foundation/relicensing/#header>
> 
> ```
> //===-- 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 <https://llvm.org/LICENSE.txt>
for license information.
> // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
> //
>
//===----------------------------------------------------------------------===//
> ```
> 
> All code in the project will be made available by the LLVM project under
the new license, so you will see that the license headers include that license
only. Some contributors have contributed code under the old license, and
accordingly, we will retain a copy of the old license notice in the top-level
files.
> 
> ## Finishing the relicensing
> 
> While this is a very big, and very important step, it isn't the end. =]
While contributions going forward are under the new license, we will continue to
work through the history of contributions to the project in order to get full
coverage of the entire project. Once we finish, we will remove the old license.
> 
> -Chandler
> _______________________________________________
> Openmp-dev mailing list
> Openmp-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190112/66300884/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190112/66300884/attachment-0001.sig>

Hi Dmitry,

TL;DR: IANAL, but 8.0 release is not affected. There are no problems
with merging.
> Just to make sure: will the 8.0 branch, which is going to be created
2019-01-16 (Wednesday), be affected?  If not, and 8.0 will come out under the
previous license, how will merges from trunk be handled?
No *relicensing* is actually made (neither is planned to be made along
with 8.0 release branch). This certainly is not possible without
either approval of all the contributors and / or rewriting or removing
the corresponding code. Instead, per Chandler's e-mail, the new
developer policy will be installed. And new developer policy (see
http://llvm.org/foundation/relicensing/devpolicy.patch) is pretty
clear on this matter:

+To relicense LLVM, we will be seeking approval from all of the
copyright holders
+of code in the repository, or potentially remove/rewrite code if we cannot.
+This is a large
+and challenging project which will take a significant amount of time to
+complete.  In the interim, **all contributions to the project will be
made under
+the terms of both the new license and the legacy license scheme**
(each of which
+is described below).  The exception to this is the legacy patent grant, which
+will not be required for new contributions.
+
+When all of the code in the project has been converted to the new license or
+removed, we will drop the requirement to contribute under the legacy license.
+This will achieve the goal of having
+a single standardized license for the entire codebase.
+

So, there is no problem of merging the patches from the mainline to
the release branch as far as I can see. Though, you may, as usual,
contact your lawyer for more clarifications :)

-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University