Documentation: Add a file explaining the requested Linux kernel license enforcement policy
Subsystems (2)
The following changes since commit 33d930e59a98fa10a0db9f56c7fa2f21a4aef9b9:
Linux 4.14-rc5 (2017-10-15 21:01:12 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/ tags/enforcement-4.14-rc6
for you to fetch changes up to 9ed95129ffcabbde564b40ffbbf9c26e8702d858:
Documentation: Add a file explaining the Linux kernel license enforcement policy (2017-10-16 11:14:43 +0200)
----------------------------------------------------------------
Documentation: Add a file explaining the requested Linux kernel license enforcement policy
Here's a pull request to add a new file to the kernel's Documentation directory. It adds a short document describing the views of how the Linux kernel community feels about enforcing the license of the kernel.
The patch has been reviewed by a large number of kernel developers already, as seen by their acks on the patch, and their agreement of the statement with their names on it. The location of the file was also agreed upon by the Documentation maintainer, so all should be good there.
For some background information about this statement, see this article written by some of the kernel developers involved in drafting it:
http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement/ and this article that answers a number of questions that came up in the discussion of this statement with the kernel developer community: http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement-faq/
If anyone has any further questions about it, please let me, and the TAB members, know and we will be glad to help answer them.
----------------------------------------------------------------
Greg Kroah-Hartman (1):
Documentation: Add a file explaining the Linux kernel license enforcement policy
Documentation/process/index.rst | 1 + .../process/kernel-enforcement-statement.rst | 147 +++++++++++++++++++++ 2 files changed, 148 insertions(+) create mode 100644 Documentation/process/kernel-enforcement-statement.rst
PATCH 1/1 Documentation: Add a file explaining the Linux kernel license
From: Greg Kroah-Hartman <[email protected]>
This adds a short document describing the views of how the Linux kernel community feels about enforcing the license of the kernel.
--- Documentation/process/index.rst | 1 + .../process/kernel-enforcement-statement.rst | 147 +++++++++++++++++++++ 2 files changed, 148 insertions(+) create mode 100644 Documentation/process/kernel-enforcement-statement.rst
Documentation/process/index.rst +1 -0
@@ -25,6 +25,7 @@ Below are the essential guides that every developer should read. submitting-patches coding-style email-clients + kernel-enforcement-statement Other guides to the community that are of interest to most developers are:
Documentation/process/kernel-enforcement-statement.rst new file +147 -0
147 lines not on this page · raw message
Signature · 1 line
2.14.2
Re: [PATCH] Documentation: Add a file explaining the Linux kernel license
Hi Greg,
Quoted 99 lines · Greg KH
From: Greg Kroah-Hartman <[email protected]>
This adds a short document describing the views of how the Linux kernel community feels about enforcing the license of the kernel.
Acked-by Al Viro <[email protected]>Acked-by Andrea Arcangeli <[email protected]>Acked-by Andy Gross <[email protected]>Acked-by Aneesh Kumar K.V <[email protected]>Acked-by Anna Schumaker <[email protected]>Acked-by Ard Biesheuvel <[email protected]>Acked-by Arnd Bergmann <[email protected]>Acked-by Arvind Yadav <[email protected]>Acked-by Bart Van Assche <[email protected]>Acked-by Bhumika Goyal <[email protected]>Acked-by Bjorn Andersson <[email protected]>Acked-by Borislav Petkov <[email protected]>Acked-by Christian König <[email protected]>Acked-by Chuck Lever <[email protected]>Acked-by Colin Ian King <[email protected]>Acked-by Daniel Borkmann <[email protected]>Acked-by Daniel Lezcano <[email protected]>Acked-by Daniel Vetter <[email protected]>Acked-by Darrick J. Wong <[email protected]>Acked-by David Kershner <[email protected]>Acked-by David S. Miller <[email protected]>Acked-by Dmitry Torokhov <[email protected]>Acked-by Doug Ledford <[email protected]>Acked-by Fabio Estevam <[email protected]>Acked-by Felipe Balbi <[email protected]>Acked-by Florian Westphal <[email protected]>Acked-by Guenter Roeck <[email protected]>Acked-by Hannes Reinecke <[email protected]>Acked-by Hans de Goede <[email protected]>Acked-by Heiko Carstens <[email protected]>Acked-by Heiko Stuebner <[email protected]>Acked-by Heiner Kallweit <[email protected]>Acked-by Ingo Molnar <[email protected]>Acked-by Ivan Safonov <[email protected]>Acked-by Jaegeuk Kim <[email protected]>Acked-by Jan Kara (SUSE) <[email protected]>Acked-by Jeff Kirsher <[email protected]>Acked-by Jens Axboe <[email protected]>Acked-by Jes Sorensen <[email protected]>Acked-by Jiri Kosina <[email protected]>Acked-by Jiri Pirko <[email protected]>Acked-by Joe Perches <[email protected]>Acked-by Johan Hovold <[email protected]>Acked-by Josh Poimboeuf <[email protected]>Acked-by Juergen Gross <[email protected]>Acked-by Julia Lawall <[email protected]>Acked-by K. Y. Srinivasan <[email protected]>Acked-by Khalid Aziz <[email protected]>Acked-by Larry Finger <[email protected]>Acked-by Laura Abbott <[email protected]>Acked-by Lee Jones <[email protected]>Acked-by Leon Romanovsky <[email protected]>Acked-by Lv Zheng <[email protected]>Acked-by Masahiro Yamada <[email protected]>Acked-by Masami Hiramatsu <[email protected]>Acked-by Mel Gorman <[email protected]>Acked-by Michal Hocko <[email protected]>Acked-by Mike Marshall <[email protected]>Acked-by Namhyung Kim <[email protected]>Acked-by Neil Armstrong <[email protected]>Acked-by Olof Johansson <[email protected]>Acked-by Paolo Bonzini <[email protected]>Acked-by Paul Burton <[email protected]>Acked-by Paul E. McKenney <[email protected]>Acked-by Peter Zijlstra <[email protected]>Acked-by Ralf Baechle <[email protected]>Acked-by Rik van Riel <[email protected]>Acked-by Rob Clark <[email protected]>Acked-by Rob Herring <[email protected]>Acked-by Shawn Guo <[email protected]>Acked-by Shuah Khan <[email protected]>Acked-by Simon Horman <[email protected]>Acked-by Sven Eckelmann <[email protected]>Acked-by Tejun Heo <[email protected]>Acked-by Thierry Reding <[email protected]>
Quoted 8 lines
Acked-by Tony Luck <[email protected]>Acked-by Ulf Hansson <[email protected]>Acked-by Vinod Koul <[email protected]>Acked-by Viresh Kumar <[email protected]>Acked-by Vivien Didelot <[email protected]>Acked-by Wei Yongjun <[email protected]>Acked-by Xin Long <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>
FWIW, please feel free to add:
Quoted 161 lines
--- Documentation/process/index.rst | 1 + .../process/kernel-enforcement-statement.rst | 147 +++++++++++++++++++++ 2 files changed, 148 insertions(+) create mode 100644 Documentation/process/kernel-enforcement-statement.rstDocumentation/process/index.rst +1
-0@@ -25,6 +25,7 @@ Below are the essential guides that every developer should read. submitting-patches coding-style email-clients + kernel-enforcement-statement Other guides to the community that are of interest to most developers are:Documentation/process/kernel-enforcement-statement.rst new file +137
-0@@ -0,0 +1,147 @@ +Linux Kernel Enforcement Statement +---------------------------------- + +As developers of the Linux kernel, we have a keen interest in how our software +is used and how the license for our software is enforced. Compliance with the +reciprocal sharing obligations of GPL-2.0 is critical to the long-term +sustainability of our software and community. + +Although there is a right to enforce the separate copyright interests in the +contributions made to our community, we share an interest in ensuring that +individual enforcement actions are conducted in a manner that benefits our +community and do not have an unintended negative impact on the health and +growth of our software ecosystem. In order to deter unhelpful enforcement +actions, we agree that it is in the best interests of our development +community to undertake the following commitment to users of the Linux kernel +on behalf of ourselves and any successors to our copyright interests: + + Notwithstanding the termination provisions of the GPL-2.0, we agree that + it is in the best interests of our development community to adopt the + following provisions of GPL-3.0 as additional permissions under our + license with respect to any non-defensive assertion of rights under the + license. + + However, if you cease all violation of this License, then your license + from a particular copyright holder is reinstated (a) provisionally, + unless and until the copyright holder explicitly and finally + terminates your license, and (b) permanently, if the copyright holder + fails to notify you of the violation by some reasonable means prior to + 60 days after the cessation. + + Moreover, your license from a particular copyright holder is + reinstated permanently if the copyright holder notifies you of the + violation by some reasonable means, this is the first time you have + received notice of violation of this License (for any work) from that + copyright holder, and you cure the violation prior to 30 days after + your receipt of the notice. + +Our intent in providing these assurances is to encourage more use of the +software. We want companies and individuals to use, modify and distribute +this software. We want to work with users in an open and transparent way to +eliminate any uncertainty about our expectations regarding compliance or +enforcement that might limit adoption of our software. We view legal action +as a last resort, to be initiated only when other community efforts have +failed to resolve the problem. + +Finally, once a non-compliance issue is resolved, we hope the user will feel +welcome to join us in our efforts on this project. Working together, we will +be stronger. + +Except where noted below, we speak only for ourselves, and not for any company +we might work for today, have in the past, or will in the future. + + - Bjorn Andersson (Linaro) + - Andrea Arcangeli (Red Hat) + - Neil Armstrong + - Jens Axboe + - Pablo Neira Ayuso + - Khalid Aziz + - Ralf Baechle + - Felipe Balbi + - Arnd Bergmann + - Ard Biesheuvel + - Paolo Bonzini (Red Hat) + - Christian Borntraeger + - Mark Brown (Linaro) + - Paul Burton + - Javier Martinez Canillas + - Rob Clark + - Jonathan Corbet + - Vivien Didelot (Savoir-faire Linux) + - Hans de Goede (Red Hat) + - Mel Gorman (SUSE) + - Sven Eckelmann + - Alex Elder (Linaro) + - Fabio Estevam + - Larry Finger + - Bhumika Goyal + - Andy Gross + - Juergen Gross + - Shawn Guo + - Ulf Hansson + - Tejun Heo + - Rob Herring + - Masami Hiramatsu + - Michal Hocko + - Simon Horman + - Johan Hovold (Hovold Consulting AB) + - Christophe JAILLET + - Olof Johansson + - Lee Jones (Linaro) + - Heiner Kallweit + - Srinivas Kandagatla + - Jan Kara + - Shuah Khan (Samsung) + - David Kershner + - Jaegeuk Kim + - Namhyung Kim + - Colin Ian King + - Jeff Kirsher + - Greg Kroah-Hartman (Linux Foundation) + - Christian König + - Vinod Koul + - Krzysztof Kozlowski + - Viresh Kumar + - Aneesh Kumar K.V + - Julia Lawall + - Doug Ledford (Red Hat) + - Chuck Lever (Oracle) + - Daniel Lezcano + - Shaohua Li + - Xin Long (Red Hat) + - Tony Luck + - Mike Marshall + - Chris Mason + - Paul E. McKenney + - David S. Miller + - Ingo Molnar + - Kuninori Morimoto + - Borislav Petkov + - Jiri Pirko + - Josh Poimboeuf + - Sebastian Reichel (Collabora) + - Guenter Roeck + - Joerg Roedel + - Leon Romanovsky + - Steven Rostedt (VMware) + - Ivan Safonov + - Ivan Safonov + - Anna Schumaker + - Jes Sorensen + - K.Y. Srinivasan + - Heiko Stuebner + - Jiri Kosina (SUSE) + - Dmitry Torokhov + - Linus Torvalds + - Thierry Reding + - Rik van Riel
Documentation/process/kernel-enforcement-statement.rst line 147
Quoted 10 lines
Documentation/process/kernel-enforcement-statement.rst new file +10
-0+ - Geert Uytterhoeven (Glider bvba) + - Daniel Vetter + - Linus Walleij + - Richard Weinberger + - Dan Williams + - Rafael J. Wysocki + - Arvind Yadav + - Masahiro Yamada + - Wei Yongjun + - Lv Zheng
... and my name here as well:
+ - Sumit Semwal
Quoted 3 lines
--
2.14.2
Best,
Sumit.
Re: [PATCH] Documentation: Add a file explaining the Linux kernel license
Quoted 3 lines · Sumit Semwal
... and my name here as well:
+ - Sumit Semwal
Thanks, but can you send me a patch to add this to the file now?
thanks,
greg k-h
Quoted 14 lines · Greg KH
Documentation: Add a file explaining the requested Linux kernel license enforcement policy
Here's a pull request to add a new file to the kernel's Documentation directory. It adds a short document describing the views of how the Linux kernel community feels about enforcing the license of the kernel.
The patch has been reviewed by a large number of kernel developers already, as seen by their acks on the patch, and their agreement of the statement with their names on it. The location of the file was also agreed upon by the Documentation maintainer, so all should be good there.
For some background information about this statement, see this article written by some of the kernel developers involved in drafting it:
Quoted 7 lines
http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement/ and this article that answers a number of questions that came up in the discussion of this statement with the kernel developer community: http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement-faq/If anyone has any further questions about it, please let me, and the TAB members, know and we will be glad to help answer them.
It's a shame you don't explicitly mention the FSF's / Conservancy's Principles of Community-Oriented GPL Enforcement:
https://www.fsf.org/licensing/enforcement-principles
I think this approach is a good thing in general, and I know Conservancy have been talking about it for a while, including conversations with the TAB on early drafts of this — but I'm a little concerned that what we've ended up with is a bit one-sided. We're giving something away, for nothing in return.
In the long period of negotiation with violators, what typically happens is they keep providing "candidate" source releases which are ever closer to being compliant, but rarely *actually* compliant.
With a binding promise to forgive them for past violations as soon as they're fixed, we basically lose one of the few levers we had to encourage them to come *completely* into compliance. Now I fear some of them will only ever come close enough that they know we won't actually take the last resort of legal action, purely for what *remains* to be fixed.
This would have been better if it specified that it applied to *unintentional* violations, and also gave a time limit — automatic reinstatement *only* happens if complete compliance is achieved within 90 days, for example. That would help genuine developers who are only *accidentally* committing a criminal offence through not paying enough attention, while not giving succour to those who intentionally do so.
Quoted 20 lines · David Woodhouse
Quoted 19 lines · Greg KH
Documentation: Add a file explaining the requested Linux kernel license enforcement policy
Here's a pull request to add a new file to the kernel's Documentation directory. It adds a short document describing the views of how the Linux kernel community feels about enforcing the license of the kernel.
The patch has been reviewed by a large number of kernel developers already, as seen by their acks on the patch, and their agreement of the statement with their names on it. The location of the file was also agreed upon by the Documentation maintainer, so all should be good there.
For some background information about this statement, see this article written by some of the kernel developers involved in drafting it:
http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement/ and this article that answers a number of questions that came up in the discussion of this statement with the kernel developer community: http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement-faq/
Quoted 6 lines
Quoted 2 lines
If anyone has any further questions about it, please let me, and the TAB members, know and we will be glad to help answer them.
It's a shame you don't explicitly mention the FSF's / Conservancy's Principles of Community-Oriented GPL Enforcement:
https://www.fsf.org/licensing/enforcement-principles
What? I thought I did in my blog post! Ugh, you are right, it's not there, my fault, it was in an earlier draft, I swear, sorry about that, must have gotten lost when I turned it from text into a markdown-formatted document. I'll go add it and push out the updated post in a bit.
Quoted 1 line
I think this approach is a good thing in general,
Great!
Quoted 5 lines
and I know
Conservancy have been talking about it for a while, including conversations with the TAB on early drafts of this — but I'm a little concerned that what we've ended up with is a bit one-sided. We're giving something away, for nothing in return.
I don't feel that is true at all, what we are doing here is providing a well-documented way toward compliance and the reinstatement of our license. That's a key issue with regards to the existing trolls we are currently facing today, which we have to address in order to preserve our community.
Quoted 11 lines
In the long period of negotiation with violators, what typically happens is they keep providing "candidate" source releases which are ever closer to being compliant, but rarely *actually* compliant.
With a binding promise to forgive them for past violations as soon as they're fixed, we basically lose one of the few levers we had to encourage them to come *completely* into compliance. Now I fear some of them will only ever come close enough that they know we won't actually take the last resort of legal action, purely for what *remains* to be fixed.
Quoted 6 lines
This would have been better if it specified that it applied to *unintentional* violations, and also gave a time limit — automatic reinstatement *only* happens if complete compliance is achieved within 90 days, for example. That would help genuine developers who are only *accidentally* committing a criminal offence through not paying enough attention, while not giving succour to those who intentionally do so.
Defining "unintentional" and "accidentally", might be a bit difficult, given that GPLv3 didn't even attempt to do something like that. And I'm pretty sure I remember it coming up during the drafting of that, don't you?
We aren't in the business of showing "intent" here, we want to be able to offer a way for someone who is not in compliance, to be able to join our community successfully after they come back into compliance. That's it, we aren't trying to complicate anything, but rather, make things more simpler and easier to understand for everyone in order to stop the issue we are currently facing.
thanks,
greg k-h
I want to thank everyone who has spent years putting together this Linux Kernel Enforcement Statement. Conservancy issued a public thank-you today:
https://sfconservancy.org/news/2017/oct/16/linux-kernel-enforcement-statement/
Quoted 2 lines · Greg
What? I thought I did in my blog post! Ugh, you are right, it's not there, my fault, it was in an earlier draft, I swear, sorry about that,
No problem! Here's the stable URL for that link when you add it:
https://sfconservancy.org/copyleft-compliance/principles.html
When Conservancy released those Principles of Community-Oriented GPL Enforcement, we asked for the copyleft-using community (in general) and the Linux community (in particular) to join us in discussing it and looking for ways to adopt those Principles in everyday work. I'm thus really glad to see this great outcome!
The additional permission in Greg's proposed patch is an excellent way to begin incorporation of those Principles into Linux's license officially, via an opt-in exception for copyright holders. Conservancy plans this week to officially sign it for the Linux copyrights that have been assigned to us.
I also would like to invite everyone to the mailing list created specifically for this subject, at
https://lists.sfconservancy.org/mailman/listinfo/principles-discuss . Folks should feel free to Cc that list with this thread, and/or (if the discussion becomes OT for LKML) start a new thread there.
Greg, finally, I noticed you had some links to resources about compliance in your blog post. Your readers may also be interested in FSF and Conservancy's Copyleft Guide, which is at https://copyleft.org/guide/. A direct link to the chapters on GPL compliance are:
https://copyleft.org/guide/comprehensive-gpl-guidepa2.html#x17-116000II
https://copyleft.org/guide/comprehensive-gpl-guidepa3.html#x26-152000III
I think the latter (the case studies) are particularly useful and my talk on the most recent case study was well-received at Embedded Linux Conference 2015.
--
Bradley M. Kuhn
Distinguished Technologist of Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter
Quoted 1 line · Greg KH
I'll go add it and push out the updated post in a bit.
Thanks. I think it's especially important to show how useful Conservancy's work in this area is.
If there's anyone who's nodding in approval to this document but who *hasn't* joined Conservancy's group of kernel developers to help drive the policies and decision-making there, I'd strongly recommend that you do so: https://sfconservancy.org/copyleft-compliance/
Quoted 9 lines
Quoted 3 lines
conversations with the TAB on early drafts of this — but I'm a little concerned that what we've ended up with is a bit one-sided. We're giving something away, for nothing in return.
I don't feel that is true at all, what we are doing here is providing a well-documented way toward compliance and the reinstatement of our license. That's a key issue with regards to the existing trolls we are currently facing today, which we have to address in order to preserve our community.
Which trolls? Do you mean Broadcom or Patrick? :)
I think think this directly addresses either of them. Not unless you're planning to get Patrick, or those who aspire to his methods, to sign up to this document somehow?
I do agree that *both* of them need dealing with somehow though.
I'm actually *more* worried about the Broadcoms of this world, because with Patrick there's an easy safeguard that most people seem to have forgotten about — do not break the law. Make sure you are so obviously complying with the GPL that any claim to the contrary would be immediately thrown out of court and your costs awarded. (I know that's over-simplifying quite a bit — but while I don't condone Patrick's actions, at a personal level I do find it slightly hard to sympathise with his victims.)
Quoted 9 lines
Quoted 6 lines
This would have been better if it specified that it applied to *unintentional* violations, and also gave a time limit — automatic reinstatement *only* happens if complete compliance is achieved within 90 days, for example. That would help genuine developers who are only *accidentally* committing a criminal offence through not paying enough attention, while not giving succour to those who intentionally do so.
Defining "unintentional" and "accidentally", might be a bit difficult, given that GPLv3 didn't even attempt to do something like that.
Sure. But as you know, those who are *intentionally* violating the licence will drag out their repeated candidate releases for years, fixing one thing at a time and costing us loads of time and money as we painstakingly investigate each attempt. While genuine mistakes are much more quickly fixed.
So a time limit may well have worked as as primitive proxy for "intent".
We do have a time limit operating in *one* direction, to the benefit of the criminal — if you stop offending within 30 days, your licence is automatically reinstated. But we didn't do it in the opposite direction — however long they take to come into compliance, we still promise that their licence is reinstated by default when they do. Again it's one- sided.
And more to the point, it deprives us of the *one* lever we have, short of the last resort of legal action, for persuading them to come into *complete* compliance as we define it.
My main concern is that we used to be able to iterate with a violator until *we* agreed they were compliant. Now I fear that all they have to do is get into the grey area where they don't think we'll really sue for what's *left* — if we've signed away our ability to withhold the licence from them for the original violations.
So given that Patrick was never going to sign this in the first place, so it doesn't really protect anyone from his abuse, it seems that *all* we've done is make live easier for the other kind of troll AFAICT. It's a nice idea, but I'm just not sure it's really going to help overall.
Quoted 11 lines · David Woodhouse
Quoted 9 lines · Greg KH
Quoted 3 lines
conversations with the TAB on early drafts of this — but I'm a little concerned that what we've ended up with is a bit one-sided. We're giving something away, for nothing in return.
I don't feel that is true at all, what we are doing here is providing a well-documented way toward compliance and the reinstatement of our license. That's a key issue with regards to the existing trolls we are currently facing today, which we have to address in order to preserve our community.
Quoted 5 lines
Which trolls? Do you mean Broadcom or Patrick? :)
I think think this directly addresses either of them. Not unless you're planning to get Patrick, or those who aspire to his methods, to sign up to this document somehow?
In consulting with a _lot_ of people, and lawyers involved in cases with Patrick, they have told us that this _will_ help with the troll issue that Patrick is currently engaging in.
Quoted 10 lines
I do agree that *both* of them need dealing with somehow though.
I'm actually *more* worried about the Broadcoms of this world, because with Patrick there's an easy safeguard that most people seem to have forgotten about — do not break the law. Make sure you are so obviously complying with the GPL that any claim to the contrary would be immediately thrown out of court and your costs awarded. (I know that's over-simplifying quite a bit — but while I don't condone Patrick's actions, at a personal level I do find it slightly hard to sympathise with his victims.)
You should sympathise, as the "victims" here are almost always companies that had no idea what was going on in the first place. Their first interaction with this "Linux thing" is a person demanding that they pay up in court, and then, when they initially comply because they think that is what they need to do, they get hit again with loads of other issues out of their control and are forced to pay even more money.
Does that help us as a community? No. It ensures that no one wants to use Linux in their products.
Yes, the correct response is of course providing tools and education and other methods in which companies can learn, change, and then track their open source usage and ensure that they are compliant. And that is what a lot of people have been doing for the past few years, look at the links I did provide with regards to that.
Heck, one of those free e-books could pretty much be subtitled "How to avoid being hit by a copyright troll!"
So that's one front in fixing this obvious problem where companies are just not compliant. We have to also cut off the ability for trolls to go after companies like this, and that's what this statement is for, and will help out immediately.
I understand you are wanting to help solve the Broadcom issues in the world. Great, let's work to address that, and we can take it off-line if you want. But that's not what we are trying to solve here at all.
Don't get into the common mistake that lots of people are doing right now of, "Oh look, why didn't they also do this and this and this as I wish they always would have!" That's not how you solve specific problems.
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
This would have been better if it specified that it applied to *unintentional* violations, and also gave a time limit — automatic reinstatement *only* happens if complete compliance is achieved within 90 days, for example. That would help genuine developers who are only *accidentally* committing a criminal offence through not paying enough attention, while not giving succour to those who intentionally do so.
Quoted 8 lines
Quoted 2 lines
Defining "unintentional" and "accidentally", might be a bit difficult, given that GPLv3 didn't even attempt to do something like that.
Sure. But as you know, those who are *intentionally* violating the licence will drag out their repeated candidate releases for years, fixing one thing at a time and costing us loads of time and money as we painstakingly investigate each attempt. While genuine mistakes are much more quickly fixed.
Intentional violators are a different issue here, as you say. And really, this 30 days thing means nothing to them, as it is not meant to at all.
Quoted 1 line
So a time limit may well have worked as as primitive proxy for "intent".
Maybe, if so, why doesn't GPLv3 have this in it? :)
Quoted 3 lines
And more to the point, it deprives us of the *one* lever we have, short of the last resort of legal action, for persuading them to come into *complete* compliance as we define it.
I disagree, see my previous public statements about how I feel is the best way to work with companies to get them to properly comply with our license.
Hint, it's not to bring in lawyers, we have many many other "levers" we can, and do, use to solve it.
thanks,
greg k-h
Hi!
Quoted 7 lines
Quoted 5 lines
I don't feel that is true at all, what we are doing here is providing a well-documented way toward compliance and the reinstatement of our license. That's a key issue with regards to the existing trolls we are currently facing today, which we have to address in order to preserve our community.
Which trolls? Do you mean Broadcom or Patrick? :)
Do you have link to the Broadcom case? According to wikipedia there were some problems in 2003 with FSF, but I don't think that's what you are refering to.
Thanks,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 28 lines · Greg KH
Quoted 20 lines · David Woodhouse
Quoted 19 lines · Greg KH
Documentation: Add a file explaining the requested Linux kernel license enforcement policy
Here's a pull request to add a new file to the kernel's Documentation directory. It adds a short document describing the views of how the Linux kernel community feels about enforcing the license of the kernel.
The patch has been reviewed by a large number of kernel developers already, as seen by their acks on the patch, and their agreement of the statement with their names on it. The location of the file was also agreed upon by the Documentation maintainer, so all should be good there.
For some background information about this statement, see this article written by some of the kernel developers involved in drafting it:
http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement/ and this article that answers a number of questions that came up in the discussion of this statement with the kernel developer community: http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement-faq/Quoted 6 lines
Quoted 2 lines
If anyone has any further questions about it, please let me, and the TAB members, know and we will be glad to help answer them.
It's a shame you don't explicitly mention the FSF's / Conservancy's Principles of Community-Oriented GPL Enforcement:
https://www.fsf.org/licensing/enforcement-principles
Quoted 5 lines
What? I thought I did in my blog post! Ugh, you are right, it's not there, my fault, it was in an earlier draft, I swear, sorry about that, must have gotten lost when I turned it from text into a markdown-formatted document. I'll go add it and push out the updated post in a bit.
Ok, in reviewing my previous drafts, and my notes for this, I see why I didn't include it in the final version, so I'll just leave my post as-is.
thanks,
greg k-h