Chris Lattner via llvm-dev
2017-Apr-17 14:37 UTC
[llvm-dev] RFC #3: Improving license & patent issues in the LLVM community
Hello everyone, This email is a continuation of a discussion started in October 2015, and continued in September 2016: http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536.html http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html As with those emails, this is a complicated topic and deals with sensitive legal issues. I am not a lawyer, and this email is not intended to be legal advice in the formal sense. That said, I have spoken with many lawyers about this, Heather Meeker (a prominent and distinguished OSS licensing attorney) has agreed to represent the interests of the LLVM Community as independent counsel. This proposal incorporates all of their feedback. The goals of this effort are outlined in the first email but, in short, we aim to: - encourage ongoing contributions to LLVM by preserving low barrier to entry for contributors. - protect users of LLVM code by providing explicit patent protection in the license. - protect contributors to the LLVM project by explicitly scoping their patent contributions with this license. - eliminate the schism between runtime libraries and the rest of the compiler that makes it difficult to move code between them. - ensure that LLVM runtime libraries may be used by other open source and proprietary compilers. Here we are discussing what the best end game is -- not the logistics of how to get from here to there. In case you haven’t been following, here is an attempt at quick recap the history, leading to today: The first email thread addressed the issue of how to structure the new LLVM license, what the problem to be solved is, and rationale for a general approach. We decided and converged on using the approach of the industry standard Apache 2 License, with exceptions to correct problematic cases for the LLVM community (specifically, the issue of runtime libraries that are implicitly linked into an application by the compiler). The concern there is that users of LLVM compilers (e.g. Clang) would not necessarily know that runtime libraries are implicitly linked into their application, and thus fail to attribute the LLVM project in binaries. The LLVM project generally isn’t widely concerned with binary attribution, but widespread noncompliance with license terms can lead to problems enforcing other terms in the license. That first discussion recognized the binary attribution issue, but a second concern was raised by some who believe the Apache 2 and GPL version 2.0 licenses are incompatible. The second email thread addressed that compatibility concern by introducing a second exception clause. In the second email thread, those concerned about GPL2 were satisfied, but an additional issue was raised about the first binary attribution clause: specifically, we aim for the LLVM runtime libraries to be used very permissively, even by proprietary compilers and linkers. This led to another round of intense (offline) discussion about the concrete wording of the exceptions, which brings us to today. Today we’re proposing a new wording, in line with the previous approach: we use the Apache 2.0 license with two exceptions, one to address binary attribution issues and one to address concerns about GPL2 compatibility. In addition, we have striven to align the wording and legal terminology with those in the Apache 2.0 license. For general rationale and framing for why these approaches are important, I’ll refer you back to the first and second threads. Here is our new proposed wording: ---- Exceptions to the Apache 2.0 License: —— As an exception, if, as a result of your compiling your source code, portions of this Software are embedded into an Object form of such source code, you may redistribute such embedded portions in such Object form without complying with the conditions of Sections 4(a), 4(b) and 4(d) of the License. In addition, if you combine or link compiled forms of this Software with software that is licensed under the GPLv2 (“Combined Software”) and if a court of competent jurisdiction determines that the patent provision (Section 3), the indemnity provision (Section 9) or other Section of the License conflicts with the conditions of the GPLv2, you may retroactively and prospectively choose to deem waived or otherwise exclude such Section(s) of the License, but only in their entirety and only with respect to the Combined Software. ---- end — Despite the effort required to reach this point, this is only a small shift from the second round proposal. We believe that this will resolve the issue of LLVM runtime libraries being used by proprietary and other non-LLVM compilers, and the wording has been carefully vetted by a team of super-smart legal folks, led by Heather (who represents the interests of the LLVM community). We expect that we will need to have a name for this wording, and propose the name "Apache 2.0 License with LLVM Exception” to align the naming with the other exception clauses listed in the SPDX database (https://spdx.org/licenses/exceptions-index.html). Several other approaches to naming were considered, but we believe that, in this case at least, the most obvious answer is the best. At this point, we’re fairly confident that this wording covers all of the known bases. That said, we welcome comments and questions on this thread, because while we know that it is impossible to please everyone, we want to know if we’ve missed the mark in a significant way. If the LLVM community is generally on board with this approach, we’ll ask the LLVM Foundation Board of Directors to approve this, and we can move on to the logistical discussion of how to enact a new license structure: itself a difficult act. Thanks, -Chris
David Chisnall via llvm-dev
2017-Apr-18 07:36 UTC
[llvm-dev] RFC #3: Improving license & patent issues in the LLVM community
Hi Chris, On 17 Apr 2017, at 15:37, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > ---- Exceptions to the Apache 2.0 License: —— > > As an exception, if, as a result of your compiling your source code, portions of this Software are embedded into an Object form of such source code, you may redistribute such embedded portions in such Object form without complying with the conditions of Sections 4(a), 4(b) and 4(d) of the License. > > In addition, if you combine or link compiled forms of this Software with software that is licensed under the GPLv2 (“Combined Software”) and if a court of competent jurisdiction determines that the patent provision (Section 3), the indemnity provision (Section 9) or other Section of the License conflicts with the conditions of the GPLv2, you may retroactively and prospectively choose to deem waived or otherwise exclude such Section(s) of the License, but only in their entirety and only with respect to the Combined Software. > > ---- end — > > > Despite the effort required to reach this point, this is only a small shift from the second round proposal. We believe that this will resolve the issue of LLVM runtime libraries being used by proprietary and other non-LLVM compilers, and the wording has been carefully vetted by a team of super-smart legal folks, led by Heather (who represents the interests of the LLVM community). > > We expect that we will need to have a name for this wording, and propose the name "Apache 2.0 License with LLVM Exception” to align the naming with the other exception clauses listed in the SPDX database (https://spdx.org/licenses/exceptions-index.html). Several other approaches to naming were considered, but we believe that, in this case at least, the most obvious answer is the best. > > At this point, we’re fairly confident that this wording covers all of the known bases. That said, we welcome comments and questions on this thread, because while we know that it is impossible to please everyone, we want to know if we’ve missed the mark in a significant way.It’s not clear to me that this covers the case of code (e.g. template definitions) in libc++ headers being included in programs. With this license, if I compile a program that uses C++ standard library #includes on a platform (e.g. macOS, FreeBSD) where libc++ is the default C++ standard library implementation, am I required to add explicit LLVM attribution to binaries that I distribute? I’m happy with the platform that ships libc++ having to include an attribution in its docs somewhere, but requiring the attribution for every C++ program is very difficult to comply with. David
Hal Finkel via llvm-dev
2017-Apr-18 11:45 UTC
[llvm-dev] RFC #3: Improving license & patent issues in the LLVM community
On 04/18/2017 02:36 AM, David Chisnall via llvm-dev wrote:> Hi Chris, > > On 17 Apr 2017, at 15:37, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> ---- Exceptions to the Apache 2.0 License: —— >> >> As an exception, if, as a result of your compiling your source code, portions of this Software are embedded into an Object form of such source code, you may redistribute such embedded portions in such Object form without complying with the conditions of Sections 4(a), 4(b) and 4(d) of the License. >> >> In addition, if you combine or link compiled forms of this Software with software that is licensed under the GPLv2 (“Combined Software”) and if a court of competent jurisdiction determines that the patent provision (Section 3), the indemnity provision (Section 9) or other Section of the License conflicts with the conditions of the GPLv2, you may retroactively and prospectively choose to deem waived or otherwise exclude such Section(s) of the License, but only in their entirety and only with respect to the Combined Software. >> >> ---- end — >> >> >> Despite the effort required to reach this point, this is only a small shift from the second round proposal. We believe that this will resolve the issue of LLVM runtime libraries being used by proprietary and other non-LLVM compilers, and the wording has been carefully vetted by a team of super-smart legal folks, led by Heather (who represents the interests of the LLVM community). >> >> We expect that we will need to have a name for this wording, and propose the name "Apache 2.0 License with LLVM Exception” to align the naming with the other exception clauses listed in the SPDX database (https://spdx.org/licenses/exceptions-index.html). Several other approaches to naming were considered, but we believe that, in this case at least, the most obvious answer is the best. >> >> At this point, we’re fairly confident that this wording covers all of the known bases. That said, we welcome comments and questions on this thread, because while we know that it is impossible to please everyone, we want to know if we’ve missed the mark in a significant way. > It’s not clear to me that this covers the case of code (e.g. template definitions) in libc++ headers being included in programs. With this license, if I compile a program that uses C++ standard library #includes on a platform (e.g. macOS, FreeBSD) where libc++ is the default C++ standard library implementation, am I required to add explicit LLVM attribution to binaries that I distribute? I’m happy with the platform that ships libc++ having to include an attribution in its docs somewhere, but requiring the attribution for every C++ program is very difficult to comply with.The intent is not to require attribution for all users of libc++. Can you explain why you feel that it might not cover this case? In case it helps, I'll point out that the Apache 2 license's definition of Object form is very general: ""Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to..." -Hal> > David > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory
Robinson, Paul via llvm-dev
2017-Apr-19 22:44 UTC
[llvm-dev] RFC #3: Improving license & patent issues in the LLVM community
Let me say first that I personally am awed and gratified by the effort, patience and persistence of the people who have been pursuing the licensing topic. I have some idea what it's like. One question came up internally, which I am passing back to the interested parties. While it is clear about the intent of the clause to address compatibility with GPLv2, what is the state of compatibility with respect to LGPLv2.1? Thanks, --paulr -----Original Message----- From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Chris Lattner via llvm-dev Sent: Monday, April 17, 2017 7:37 AM To: llvm-dev Subject: [llvm-dev] RFC #3: Improving license & patent issues in the LLVM community Hello everyone, This email is a continuation of a discussion started in October 2015, and continued in September 2016: http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536.html http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html As with those emails, this is a complicated topic and deals with sensitive legal issues. I am not a lawyer, and this email is not intended to be legal advice in the formal sense. That said, I have spoken with many lawyers about this, Heather Meeker (a prominent and distinguished OSS licensing attorney) has agreed to represent the interests of the LLVM Community as independent counsel. This proposal incorporates all of their feedback. The goals of this effort are outlined in the first email but, in short, we aim to: - encourage ongoing contributions to LLVM by preserving low barrier to entry for contributors. - protect users of LLVM code by providing explicit patent protection in the license. - protect contributors to the LLVM project by explicitly scoping their patent contributions with this license. - eliminate the schism between runtime libraries and the rest of the compiler that makes it difficult to move code between them. - ensure that LLVM runtime libraries may be used by other open source and proprietary compilers. Here we are discussing what the best end game is -- not the logistics of how to get from here to there. In case you haven’t been following, here is an attempt at quick recap the history, leading to today: The first email thread addressed the issue of how to structure the new LLVM license, what the problem to be solved is, and rationale for a general approach. We decided and converged on using the approach of the industry standard Apache 2 License, with exceptions to correct problematic cases for the LLVM community (specifically, the issue of runtime libraries that are implicitly linked into an application by the compiler). The concern there is that users of LLVM compilers (e.g. Clang) would not necessarily know that runtime libraries are implicitly linked into their application, and thus fail to attribute the LLVM project in binaries. The LLVM project generally isn’t widely concerned with binary attribution, but widespread noncompliance with license terms can lead to problems enforcing other terms in the license. That first discussion recognized the binary attribution issue, but a second concern was raised by some who believe the Apache 2 and GPL version 2.0 licenses are incompatible. The second email thread addressed that compatibility concern by introducing a second exception clause. In the second email thread, those concerned about GPL2 were satisfied, but an additional issue was raised about the first binary attribution clause: specifically, we aim for the LLVM runtime libraries to be used very permissively, even by proprietary compilers and linkers. This led to another round of intense (offline) discussion about the concrete wording of the exceptions, which brings us to today. Today we’re proposing a new wording, in line with the previous approach: we use the Apache 2.0 license with two exceptions, one to address binary attribution issues and one to address concerns about GPL2 compatibility. In addition, we have striven to align the wording and legal terminology with those in the Apache 2.0 license. For general rationale and framing for why these approaches are important, I’ll refer you back to the first and second threads. Here is our new proposed wording: ---- Exceptions to the Apache 2.0 License: —— As an exception, if, as a result of your compiling your source code, portions of this Software are embedded into an Object form of such source code, you may redistribute such embedded portions in such Object form without complying with the conditions of Sections 4(a), 4(b) and 4(d) of the License. In addition, if you combine or link compiled forms of this Software with software that is licensed under the GPLv2 (“Combined Software”) and if a court of competent jurisdiction determines that the patent provision (Section 3), the indemnity provision (Section 9) or other Section of the License conflicts with the conditions of the GPLv2, you may retroactively and prospectively choose to deem waived or otherwise exclude such Section(s) of the License, but only in their entirety and only with respect to the Combined Software. ---- end — Despite the effort required to reach this point, this is only a small shift from the second round proposal. We believe that this will resolve the issue of LLVM runtime libraries being used by proprietary and other non-LLVM compilers, and the wording has been carefully vetted by a team of super-smart legal folks, led by Heather (who represents the interests of the LLVM community). We expect that we will need to have a name for this wording, and propose the name "Apache 2.0 License with LLVM Exception” to align the naming with the other exception clauses listed in the SPDX database (https://spdx.org/licenses/exceptions-index.html). Several other approaches to naming were considered, but we believe that, in this case at least, the most obvious answer is the best. At this point, we’re fairly confident that this wording covers all of the known bases. That said, we welcome comments and questions on this thread, because while we know that it is impossible to please everyone, we want to know if we’ve missed the mark in a significant way. If the LLVM community is generally on board with this approach, we’ll ask the LLVM Foundation Board of Directors to approve this, and we can move on to the logistical discussion of how to enact a new license structure: itself a difficult act. Thanks, -Chris _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Daniel Berlin via llvm-dev
2017-Apr-19 22:48 UTC
[llvm-dev] RFC #3: Improving license & patent issues in the LLVM community
LGPLv2.1 has no real compatibility issues with anything, because it allows additional restrictions and license of choice (as long as they meet two requirements that apache can meet). --Dan On Wed, Apr 19, 2017 at 3:44 PM, Robinson, Paul via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Let me say first that I personally am awed and gratified by the > effort, patience and persistence of the people who have been > pursuing the licensing topic. I have some idea what it's like. > > One question came up internally, which I am passing back to the > interested parties. While it is clear about the intent of the > clause to address compatibility with GPLv2, what is the state of > compatibility with respect to LGPLv2.1? > > Thanks, > --paulr > > -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > Chris Lattner via llvm-dev > Sent: Monday, April 17, 2017 7:37 AM > To: llvm-dev > Subject: [llvm-dev] RFC #3: Improving license & patent issues in the LLVM > community > > Hello everyone, > > This email is a continuation of a discussion started in October 2015, and > continued in September 2016: > http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536.html > http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html > > As with those emails, this is a complicated topic and deals with sensitive > legal issues. I am not a lawyer, and this email is not intended to be > legal advice in the formal sense. That said, I have spoken with many > lawyers about this, Heather Meeker (a prominent and distinguished OSS > licensing attorney) has agreed to represent the interests of the LLVM > Community as independent counsel. This proposal incorporates all of their > feedback. > > > The goals of this effort are outlined in the first email but, in short, we > aim to: > - encourage ongoing contributions to LLVM by preserving low barrier to > entry for contributors. > - protect users of LLVM code by providing explicit patent protection in > the license. > - protect contributors to the LLVM project by explicitly scoping their > patent contributions with this license. > - eliminate the schism between runtime libraries and the rest of the > compiler that makes it difficult to move code between them. > - ensure that LLVM runtime libraries may be used by other open source and > proprietary compilers. > > Here we are discussing what the best end game is -- not the logistics of > how to get from here to there. > > > In case you haven’t been following, here is an attempt at quick recap the > history, leading to today: > > The first email thread addressed the issue of how to structure the new > LLVM license, what the problem to be solved is, and rationale for a general > approach. We decided and converged on using the approach of the industry > standard Apache 2 License, with exceptions to correct problematic cases for > the LLVM community (specifically, the issue of runtime libraries that are > implicitly linked into an application by the compiler). The concern there > is that users of LLVM compilers (e.g. Clang) would not necessarily know > that runtime libraries are implicitly linked into their application, and > thus fail to attribute the LLVM project in binaries. The LLVM project > generally isn’t widely concerned with binary attribution, but widespread > noncompliance with license terms can lead to problems enforcing other terms > in the license. > > That first discussion recognized the binary attribution issue, but a > second concern was raised by some who believe the Apache 2 and GPL version > 2.0 licenses are incompatible. The second email thread addressed that > compatibility concern by introducing a second exception clause. In the > second email thread, those concerned about GPL2 were satisfied, but an > additional issue was raised about the first binary attribution clause: > specifically, we aim for the LLVM runtime libraries to be used very > permissively, even by proprietary compilers and linkers. This led to > another round of intense (offline) discussion about the concrete wording of > the exceptions, which brings us to today. > > > Today we’re proposing a new wording, in line with the previous approach: > we use the Apache 2.0 license with two exceptions, one to address binary > attribution issues and one to address concerns about GPL2 compatibility. > In addition, we have striven to align the wording and legal terminology > with those in the Apache 2.0 license. For general rationale and framing > for why these approaches are important, I’ll refer you back to the first > and second threads. Here is our new proposed wording: > > > ---- Exceptions to the Apache 2.0 License: —— > > As an exception, if, as a result of your compiling your source code, > portions of this Software are embedded into an Object form of such source > code, you may redistribute such embedded portions in such Object form > without complying with the conditions of Sections 4(a), 4(b) and 4(d) of > the License. > > In addition, if you combine or link compiled forms of this Software with > software that is licensed under the GPLv2 (“Combined Software”) and if a > court of competent jurisdiction determines that the patent provision > (Section 3), the indemnity provision (Section 9) or other Section of the > License conflicts with the conditions of the GPLv2, you may retroactively > and prospectively choose to deem waived or otherwise exclude such > Section(s) of the License, but only in their entirety and only with respect > to the Combined Software. > > ---- end — > > > Despite the effort required to reach this point, this is only a small > shift from the second round proposal. We believe that this will resolve > the issue of LLVM runtime libraries being used by proprietary and other > non-LLVM compilers, and the wording has been carefully vetted by a team of > super-smart legal folks, led by Heather (who represents the interests of > the LLVM community). > > We expect that we will need to have a name for this wording, and propose > the name "Apache 2.0 License with LLVM Exception” to align the naming with > the other exception clauses listed in the SPDX database ( > https://spdx.org/licenses/exceptions-index.html). Several other > approaches to naming were considered, but we believe that, in this case at > least, the most obvious answer is the best. > > At this point, we’re fairly confident that this wording covers all of the > known bases. That said, we welcome comments and questions on this thread, > because while we know that it is impossible to please everyone, we want to > know if we’ve missed the mark in a significant way. > > If the LLVM community is generally on board with this approach, we’ll ask > the LLVM Foundation Board of Directors to approve this, and we can move on > to the logistical discussion of how to enact a new license structure: > itself a difficult act. > > Thanks, > > -Chris > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170419/bfe34006/attachment-0001.html>
Mark Kettenis via llvm-dev
2017-Apr-23 15:50 UTC
[llvm-dev] RFC #3: Improving license & patent issues in the LLVM community
> Date: Mon, 17 Apr 2017 07:37:17 -0700 > From: Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org>Chris and others, As stated before the APL 2.0 poses a serious problem for OpenBSD as it contradicts the poject goals of providing a freely distributable base operating system that includes all the tools to build from source. What changed since the last time the license change came up is that OpenBSD now uses clang as the system compiler and lld as the system compiler to support OpenBSD/arm64, and that we're actively working on using it on other hardware platforms supported by OpenBSD as well. OpenBSD developers (myself included) are becoming more involved with LLVM development as a result. Triggered by recent discussions related to the proposed OpenSSL license change our position on the Apache license has been clarified on the porject goals web page http://www.openbsd.org/policy.html: Apache The original Apache license was similar to the Berkeley license, but source code published under version 2 of the Apache license is subject to additional restrictions and cannot be included into OpenBSD. In particular, if you use code under the Apache 2 license, some of your rights will terminate if you claim in court that the code violates a patent. A license can only be considered fully permissive if it allows use by anyone for all the future without giving up any of their rights. If there are conditions that might terminate any rights in the future, or if you have to give up a right that you would otherwise have, even if exercising that right could reasonably be regarded as morally objectionable, the code is not free. In addition, the clause about the patent license is problematic because a patent license cannot be granted under Copyright law, but only under contract law, which drags the whole license into the domain of contract law. But while Copyright law is somewhat standardized by international agreements, contract law differs wildly among jurisdictions. So what the license means in different jurisdictions may vary and is hard to predict. Sadly the changes made over the last few months do not address these concerns. Especially the "patent termination clause" has not been removed even though I don't see how that clause is essential to achieve the goals of the proposed license change. I also wonder if the international context has been taken into account. As the recent European LLVM Developers Meeting shows, LLVM is a very international project so I think this deserves a more international approach, especially because US copyright is so hopelessly interlocked in contract law. Mark
André Jansen Medeiros Villar via llvm-dev
2017-Apr-23 16:15 UTC
[llvm-dev] RFC #3: Improving license & patent issues in the LLVM community
2017-04-23 12:50 GMT-03:00 Mark Kettenis via llvm-dev < llvm-dev at lists.llvm.org>:> In particular, if you use code under the Apache 2 license, > some of your rights will terminate if you claim in court that the > code violates a patent. >I'm really ignorant of the legal nuances but this is my question: Isn't it irrelevant what the licence says in this case? The limitation of rights happens anyways, because patent law trumps copyright law, no ? I am making an honest question, not intended to sparkle a flame war or to be trollish. With that said I will recognize here that i do not agree with with the openBSD or even the the GPLv3 folks. Also could you suggest what kind of alteration would make you guys happy and still provide for patent protection for individuals and corporations? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170423/10b35915/attachment.html>
Daniel Berlin via llvm-dev
2017-Apr-23 16:18 UTC
[llvm-dev] RFC #3: Improving license & patent issues in the LLVM community
On Sun, Apr 23, 2017 at 8:50 AM, Mark Kettenis via llvm-dev < llvm-dev at lists.llvm.org> wrote:> > Date: Mon, 17 Apr 2017 07:37:17 -0700 > > From: Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> > > Chris and others, > > As stated before the APL 2.0 poses a serious problem for OpenBSD as it > contradicts the poject goals of providing a freely distributable base > operating system that includes all the tools to build from source. > What changed since the last time the license change came up is that > OpenBSD now uses clang as the system compiler and lld as the system > compiler to support OpenBSD/arm64, and that we're actively working on > using it on other hardware platforms supported by OpenBSD as well. > OpenBSD developers (myself included) are becoming more involved with > LLVM development as a result. > >So let me ask: What do you expect to happen here? Your goals seem irreconcilable with the other goals here. "I also wonder if the international context has been taken into account." It definitely was. Do you have a specific concern here? "n particular, if you use code under the Apache 2 license, some of your rights will terminate if you claim in court that the code violates a patent." This is true but deliberate. While you may think otherwise, maintaining patent peace between otherwise-competing contributors is actually quite important to the health of projects like LLVM. "In addition, the clause about the patent license is problematic because a patent license cannot be granted under Copyright law, but only under contract law. which drags the whole license into the domain of contract law. But while Copyright law is somewhat standardized by international agreements, contract law differs wildly among jurisdictions. So what the license means in different jurisdictions may vary and is hard to predict." FWIW: This is pretty much FUD. I think you should leave it out of this discussion. I hope this was not written by an IP lawyer, because, it's actually just flat out wrong. But here's a detailed analysis, FWIW: "granted under Copyright law, but only under contract law." Errr, no, both are IP law, but IP law is already a subset of contract law for the most part. There is no framing under which patent law is not exactly as special as you think copyright law is. (IE there are exactly as special as each other). "which drags the whole license into the domain of contract law. " This is just a muddle. Granting *licenses* is always contract law, for both copyright, and patents, in every jurisdiction (maybe you can find one where it's not, but i'll just go with "every" for now). It just happens the remedies may be different, and there may be specific requirements for the contracts. That does not make it any less contract law. I believe whoever wrote this is confused because people refer to breach of contract and copyright infringement as different things. the same, fwiw, is true of patent infringement (see above). This is all true, but would be irrelevant. It just means there is a separate statute you can sue under, outside of normal contract law. Again, true for both copyrights and patents. It's still a contract. Just one with more remedies. But there is no difference between a "license" and a "contract". IE any grant of rights i give you as a "license" is really a "contract". Again, in just about every jurisdiction i can choose to sue you either for breach of contract or copyright infringement or patent infringement, or all of them. People usually don't because the contract damages would be hard to quantify. " So what the license means in different jurisdictions may vary and is hard to predict." Apache was vetted quite heavily by a large number of international lawyers prior to release, much like GPLv3. So this falls into the "cast random aspersions on license with no concrete concern". -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170423/331140af/attachment.html>
Rafael Espíndola via llvm-dev
2017-Apr-27 21:43 UTC
[llvm-dev] RFC #3: Improving license & patent issues in the LLVM community
Sorry for the delay, I was on vacations. Ed, what is the FreeBSD position about the apache version 2 in base? A quick search only shows it in contrib/ and crypto/openssl. If I understand the issue, we can achieve the desired results with a license change that handles patents or by keeping a minimal license for runtime and llvm, but requiring a contributor agreement in the project before we accept changes. Am I correct? Not requiring a contributor agreement is awesome. It makes it really easy for people to join the project or send one time fixes. It also saves committers from having to check some database before committing a patch by someone else. On the other hand, at least for me, one of the main motivations for wanting to contribute to llvm projects is how widely used they are. I understand that an effort was made for gpl2 compatibility, but that is a bit of innovation that we were trying to avoid. More importantly, it is hard to say that is the only issue one will ever find. Also, at least the OpenBSD project is reluctant to use the Apache2 license. From where I stand it doesn't really matter if their concerns with the license are unfounded: until they are convinced otherwise the change is undesirable from the perspective of making llvm used as much as possible. Given the situation I would prefer to penalize the development process a bit and have a contributor agreement instead of the license change. Cheers, Rafael On 17 April 2017 at 10:37, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote:> Hello everyone, > > This email is a continuation of a discussion started in October 2015, and continued in September 2016: > http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536.html > http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html > > As with those emails, this is a complicated topic and deals with sensitive legal issues. I am not a lawyer, and this email is not intended to be legal advice in the formal sense. That said, I have spoken with many lawyers about this, Heather Meeker (a prominent and distinguished OSS licensing attorney) has agreed to represent the interests of the LLVM Community as independent counsel. This proposal incorporates all of their feedback. > > > The goals of this effort are outlined in the first email but, in short, we aim to: > - encourage ongoing contributions to LLVM by preserving low barrier to entry for contributors. > - protect users of LLVM code by providing explicit patent protection in the license. > - protect contributors to the LLVM project by explicitly scoping their patent contributions with this license. > - eliminate the schism between runtime libraries and the rest of the compiler that makes it difficult to move code between them. > - ensure that LLVM runtime libraries may be used by other open source and proprietary compilers. > > Here we are discussing what the best end game is -- not the logistics of how to get from here to there. > > > In case you haven’t been following, here is an attempt at quick recap the history, leading to today: > > The first email thread addressed the issue of how to structure the new LLVM license, what the problem to be solved is, and rationale for a general approach. We decided and converged on using the approach of the industry standard Apache 2 License, with exceptions to correct problematic cases for the LLVM community (specifically, the issue of runtime libraries that are implicitly linked into an application by the compiler). The concern there is that users of LLVM compilers (e.g. Clang) would not necessarily know that runtime libraries are implicitly linked into their application, and thus fail to attribute the LLVM project in binaries. The LLVM project generally isn’t widely concerned with binary attribution, but widespread noncompliance with license terms can lead to problems enforcing other terms in the license. > > That first discussion recognized the binary attribution issue, but a second concern was raised by some who believe the Apache 2 and GPL version 2.0 licenses are incompatible. The second email thread addressed that compatibility concern by introducing a second exception clause. In the second email thread, those concerned about GPL2 were satisfied, but an additional issue was raised about the first binary attribution clause: specifically, we aim for the LLVM runtime libraries to be used very permissively, even by proprietary compilers and linkers. This led to another round of intense (offline) discussion about the concrete wording of the exceptions, which brings us to today. > > > Today we’re proposing a new wording, in line with the previous approach: we use the Apache 2.0 license with two exceptions, one to address binary attribution issues and one to address concerns about GPL2 compatibility. In addition, we have striven to align the wording and legal terminology with those in the Apache 2.0 license. For general rationale and framing for why these approaches are important, I’ll refer you back to the first and second threads. Here is our new proposed wording: > > > ---- Exceptions to the Apache 2.0 License: —— > > As an exception, if, as a result of your compiling your source code, portions of this Software are embedded into an Object form of such source code, you may redistribute such embedded portions in such Object form without complying with the conditions of Sections 4(a), 4(b) and 4(d) of the License. > > In addition, if you combine or link compiled forms of this Software with software that is licensed under the GPLv2 (“Combined Software”) and if a court of competent jurisdiction determines that the patent provision (Section 3), the indemnity provision (Section 9) or other Section of the License conflicts with the conditions of the GPLv2, you may retroactively and prospectively choose to deem waived or otherwise exclude such Section(s) of the License, but only in their entirety and only with respect to the Combined Software. > > ---- end — > > > Despite the effort required to reach this point, this is only a small shift from the second round proposal. We believe that this will resolve the issue of LLVM runtime libraries being used by proprietary and other non-LLVM compilers, and the wording has been carefully vetted by a team of super-smart legal folks, led by Heather (who represents the interests of the LLVM community). > > We expect that we will need to have a name for this wording, and propose the name "Apache 2.0 License with LLVM Exception” to align the naming with the other exception clauses listed in the SPDX database (https://spdx.org/licenses/exceptions-index.html). Several other approaches to naming were considered, but we believe that, in this case at least, the most obvious answer is the best. > > At this point, we’re fairly confident that this wording covers all of the known bases. That said, we welcome comments and questions on this thread, because while we know that it is impossible to please everyone, we want to know if we’ve missed the mark in a significant way. > > If the LLVM community is generally on board with this approach, we’ll ask the LLVM Foundation Board of Directors to approve this, and we can move on to the logistical discussion of how to enact a new license structure: itself a difficult act. > > Thanks, > > -Chris > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Chris Lattner via llvm-dev
2017-Apr-28 05:12 UTC
[llvm-dev] RFC #3: Improving license & patent issues in the LLVM community
Hi Rafael, I believe that all of these points are covered in the first round of discussion, including the FreeBSD team’s position. -Chris> On Apr 27, 2017, at 2:43 PM, Rafael Espíndola via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Sorry for the delay, I was on vacations. > > Ed, what is the FreeBSD position about the apache version 2 in base? A > quick search only shows it in contrib/ and crypto/openssl. > > If I understand the issue, we can achieve the desired results with a > license change that handles patents or by keeping a minimal license > for runtime and llvm, but requiring a contributor agreement in the > project before we accept changes. Am I correct? > > Not requiring a contributor agreement is awesome. It makes it really > easy for people to join the project or send one time fixes. It also > saves committers from having to check some database before committing > a patch by someone else. > > On the other hand, at least for me, one of the main motivations for > wanting to contribute to llvm projects is how widely used they are. I > understand that an effort was made for gpl2 compatibility, but that is > a bit of innovation that we were trying to avoid. More importantly, it > is hard to say that is the only issue one will ever find. > > Also, at least the OpenBSD project is reluctant to use the Apache2 > license. From where I stand it doesn't really matter if their concerns > with the license are unfounded: until they are convinced otherwise the > change is undesirable from the perspective of making llvm used as much > as possible. > > Given the situation I would prefer to penalize the development process > a bit and have a contributor agreement instead of the license change. > > Cheers, > Rafael > > On 17 April 2017 at 10:37, Chris Lattner via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hello everyone, >> >> This email is a continuation of a discussion started in October 2015, and continued in September 2016: >> http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536.html >> http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html >> >> As with those emails, this is a complicated topic and deals with sensitive legal issues. I am not a lawyer, and this email is not intended to be legal advice in the formal sense. That said, I have spoken with many lawyers about this, Heather Meeker (a prominent and distinguished OSS licensing attorney) has agreed to represent the interests of the LLVM Community as independent counsel. This proposal incorporates all of their feedback. >> >> >> The goals of this effort are outlined in the first email but, in short, we aim to: >> - encourage ongoing contributions to LLVM by preserving low barrier to entry for contributors. >> - protect users of LLVM code by providing explicit patent protection in the license. >> - protect contributors to the LLVM project by explicitly scoping their patent contributions with this license. >> - eliminate the schism between runtime libraries and the rest of the compiler that makes it difficult to move code between them. >> - ensure that LLVM runtime libraries may be used by other open source and proprietary compilers. >> >> Here we are discussing what the best end game is -- not the logistics of how to get from here to there. >> >> >> In case you haven’t been following, here is an attempt at quick recap the history, leading to today: >> >> The first email thread addressed the issue of how to structure the new LLVM license, what the problem to be solved is, and rationale for a general approach. We decided and converged on using the approach of the industry standard Apache 2 License, with exceptions to correct problematic cases for the LLVM community (specifically, the issue of runtime libraries that are implicitly linked into an application by the compiler). The concern there is that users of LLVM compilers (e.g. Clang) would not necessarily know that runtime libraries are implicitly linked into their application, and thus fail to attribute the LLVM project in binaries. The LLVM project generally isn’t widely concerned with binary attribution, but widespread noncompliance with license terms can lead to problems enforcing other terms in the license. >> >> That first discussion recognized the binary attribution issue, but a second concern was raised by some who believe the Apache 2 and GPL version 2.0 licenses are incompatible. The second email thread addressed that compatibility concern by introducing a second exception clause. In the second email thread, those concerned about GPL2 were satisfied, but an additional issue was raised about the first binary attribution clause: specifically, we aim for the LLVM runtime libraries to be used very permissively, even by proprietary compilers and linkers. This led to another round of intense (offline) discussion about the concrete wording of the exceptions, which brings us to today. >> >> >> Today we’re proposing a new wording, in line with the previous approach: we use the Apache 2.0 license with two exceptions, one to address binary attribution issues and one to address concerns about GPL2 compatibility. In addition, we have striven to align the wording and legal terminology with those in the Apache 2.0 license. For general rationale and framing for why these approaches are important, I’ll refer you back to the first and second threads. Here is our new proposed wording: >> >> >> ---- Exceptions to the Apache 2.0 License: —— >> >> As an exception, if, as a result of your compiling your source code, portions of this Software are embedded into an Object form of such source code, you may redistribute such embedded portions in such Object form without complying with the conditions of Sections 4(a), 4(b) and 4(d) of the License. >> >> In addition, if you combine or link compiled forms of this Software with software that is licensed under the GPLv2 (“Combined Software”) and if a court of competent jurisdiction determines that the patent provision (Section 3), the indemnity provision (Section 9) or other Section of the License conflicts with the conditions of the GPLv2, you may retroactively and prospectively choose to deem waived or otherwise exclude such Section(s) of the License, but only in their entirety and only with respect to the Combined Software. >> >> ---- end — >> >> >> Despite the effort required to reach this point, this is only a small shift from the second round proposal. We believe that this will resolve the issue of LLVM runtime libraries being used by proprietary and other non-LLVM compilers, and the wording has been carefully vetted by a team of super-smart legal folks, led by Heather (who represents the interests of the LLVM community). >> >> We expect that we will need to have a name for this wording, and propose the name "Apache 2.0 License with LLVM Exception” to align the naming with the other exception clauses listed in the SPDX database (https://spdx.org/licenses/exceptions-index.html). Several other approaches to naming were considered, but we believe that, in this case at least, the most obvious answer is the best. >> >> At this point, we’re fairly confident that this wording covers all of the known bases. That said, we welcome comments and questions on this thread, because while we know that it is impossible to please everyone, we want to know if we’ve missed the mark in a significant way. >> >> If the LLVM community is generally on board with this approach, we’ll ask the LLVM Foundation Board of Directors to approve this, and we can move on to the logistical discussion of how to enact a new license structure: itself a difficult act. >> >> Thanks, >> >> -Chris >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
David Chisnall via llvm-dev
2017-Apr-28 10:16 UTC
[llvm-dev] RFC #3: Improving license & patent issues in the LLVM community
On 27 Apr 2017, at 22:43, Rafael Espíndola via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > Sorry for the delay, I was on vacations. > > Ed, what is the FreeBSD position about the apache version 2 in base? A > quick search only shows it in contrib/ and crypto/openssl.It’s not something that we’re enthusiastic about, but something that we tolerate. I don’t have personal objections to it (and at work we use an Apache 2-derived license for a lot of stuff we release), but a few other FreeBSD contributors have told me that it will decrease their interest in working on LLVM.> If I understand the issue, we can achieve the desired results with a > license change that handles patents or by keeping a minimal license > for runtime and llvm, but requiring a contributor agreement in the > project before we accept changes. Am I correct?(IANAL) I believe that the separate copyright and patent license makes it hard for one to revoke the other, so a company that starts suing others for infringing their patents would lose their patent license, but not their copyright license for LLVM and so would be free distribute LLVM while they sue non-patent-owning LLVM distributors without fear of a countersuit (until they annoy a company that does hold LLVM patents).> Not requiring a contributor agreement is awesome. It makes it really > easy for people to join the project or send one time fixes. It also > saves committers from having to check some database before committing > a patch by someone else.Note that other projects have handled this quite easily. Microsoft, for example, makes it easy to associate a GitHub identity with a CLA signatory and has a bot that tags all pull requests with either ‘CLA required’ or ‘CLA completed’, so committers know not to merge pull requests that don’t have the correct tag. I believe that the difficulties were more on the other side - getting certain companies to agree to sign a CLA (it’s unidirectional: they agree not to sue, but distributors that don’t contribute don’t agree not to sue them, whereas the proposed license means that if you sue over a patent infringed by LLVM then you are blocked from distributing LLVM - not that I expect this to make a difference as long as it’s easy for NPEs to sue for patent infringement, as it’s easy to sell a patent to a new NPE in exchange for a perpetual license and 95% of the proceeds from any other licenses. The NPE then sues everyone, but doesn’t distribute LLVM). David
Maybe Matching Threads
- RFC #3: Improving license & patent issues in the LLVM community
- RFC #3: Improving license & patent issues in the LLVM community
- RFC #2: Improving license & patent issues in the LLVM community
- RFC: Improving license & patent issues in the LLVM community
- Relicensing: Revised Developer Policy