[llvm-dev] [Openmp-dev] New license landing 2019-01-18 (end of next week!)
Dimitry Andric via llvm-dev
llvm-dev at lists.llvm.org
Sat Jan 12 07:11:37 PST 2019
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?
> 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.
> Openmp-dev mailing list
> Openmp-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 223 bytes
Desc: Message signed with OpenPGP
More information about the llvm-dev