I'm part of Conservancy's GPL Compliance Project for Linux
I am one of the Linux copyright holders who has signed an agreement for the Software Freedom Conservancy to enforce the GPL on my behalf, as part of the Conservancy's GPL Compliance Project For Linux Developers. I’m also a financial supporter of Conservancy. We're a group of Linux kernel developers that give input and guidance on Conservancy's strategy in dealing with compliance issues on the Linux kernel.
Joining was not something I took lightly, when I started hacking on Linux I was at ends with arguments over morality on free software put forward by the FSF and simply felt the GPLv2 on Linux was a nice coincidence; I felt I just wanted to hack and be productive. It took me over 10 years in philosophical thought to make a final decision about where I stand with regards to software freedom. I've made my motivation and intent in the community clear before, but its worth reiterating now: work harder always in spirit of what I believe is right, and accept no compromises on shit engineering.
I've been hacking on Linux since I was in college, after doing kernel development in the industry for a while I have learned the hard way that "Don't be evil" or "Do the right thing" is easier said than done for companies, specially with regards to software freedom. I've determined that without a mathematical and economics framework that takes into consideration and appreciates freedom it will take a lot of foresight, or for Free and Open Source software principles to be part of your company DNA in order for a company to appreciate the freedoms behind free software. To help companies embrace copyleft, within the community we really need to figure out how copyleft can affect and help businesses, the complexities it brings about, and work with both the community and companies on helping evolve both copyleft and businesses in amicable ways. Its easier said than done.
Consider answering these questions in today's business world when contributing to Linux.
I've covered these issues before, what follows is a terse summary. Copyleft obviously is an imminent threat to proprietary software that relies on copylefted software such that the proprietary software is arguably subject to the conditions of the license that the copylefted software is distributed under. An implicit requirement however is that copyright holders of the copylefted software are both willing to and capable of seeking legal remedies against distributors of the proprietary software. In this light, if a business does not know how to phase out proprietary software it can be affected, short term, or long term. Patents can be implicated by some free software licenses. Paying for patent licensing also adds up. Patents can also be used to sue people. If you have signed conflict of interest agreement with business partners, things can get really hairy, and puts the industry at ends when it comes to free and open source software even if you're an "open source company". Since we lack the mathematical and economics framework to tangibly appreciate freedoms over patents and since patents can ultimately be endangered by certain free software licenses its only natural corporate interests will want to undermine certain free software licenses.
As businesses evolve, copyleft evolves. Patents were one of the latest additions to free software licenses, both through the GPLv3 and the Apache 2.0 license. I consider the Apache 2.0 license one of the best legal innovations in our arsenal in the free software world: if you want to really test what seems to be claim of only opposition to copyleft, ask if the Apache 2.0 license can be used instead. Now in the Linux kernel though we have an issue, since its GPLv2 and it only provides an implicit patent grant, and since we can't add GPLv3 or Apache 2.0 licensed material to the Linux kernel -- it still leaves the patent question open for businesses to address. To help with this, its why linux-firmware now also requires an explicit or implicit patent grant requirement. We need to close all the gaps that prevent copyleft evolution. And sure, we can use permissive licenses on Linux, but that should only be used as a compromise -- not a de-facto practice. For instance getting ZFS relicensed to the ISC license might be a great compromise for all parties involved. Fully permissive licenses without patent provisions should be our last resort and compromise. Since patents are prevalent everywhere this means businesses have to deal with a lot of issues implicitly behind the scenes.
Case in point, as covered recently by lwn, at linux.conf.au 2016 Bradley talked about corporate opposition to copyleft. He explained how corporations will typically not do GPL enforcement in the name of the community, unless of course it fits your business model. He gave the example where Red Hat was sued by a patent troll, and in response Red Hat then alleged GPL infringement against Twin Peaks, with this Red Hat got a patent license but Twin Peaks software remained proprietary. Red Hat is an example that has Open Source software built-in to its business DNA, and even they seem to walk on eggshells when it comes to GPL enforcement. They are not to blame though, doing GPL enforcement for the community responsibly is hard, specially these days in such a complex, technology business sector, where anyone can be your partner and business contracts typically forbid you from engaging in actions that may harm any of your business partners.
Because of the challenges explained above even the best of Free and Open Source companies are walking on egg shells when it comes to GPL enforcement. By now you should have a sense of why some corporate interests may be trying to undermine copyleft licenses to effectively be as good as permissive licenses. We can't let that happen. Evidence shows the number of GPL violations has skyrocketed over the years to the extent that we cannot deal with them. There were only a few community groups dealing with GPL violations as well, this was outside of the Linux kernel, Linux kernel GPL violations remain common and unenforced. For this reason GPL enforcement is critical for the Linux kernel and community.
To address this Conservancy published a set of principles that should govern GPL enforcement, the primary objective is simply to bring about license compliance. We are not out for money, or blood, simply compliance to the license to strengthen the commons. We give input and guidance on Conservancy's strategy in dealing with compliance issues on the Linux kernel. Responsibly enforcing the GPL for the community, within the community with due care should be of utmost interest to any business contributing to Linux. If you're a Linux developer and would like to chime in and help us with these efforts you should consider joining the Conservancy's GPL Compliance Project For Linux Developers, please contact <linux-services@sfconservancy.org> for more details.
On the post where I describe my epiphany which after over 10 years allowed me to finally cope with software freedom philosophy I explained how helping evolve copyleft is important, I'll provide a summary of that in light of the Linux kernel and its GPLv2 license. I believe some of the challenges described above are self inflicted as we were not able to move to GPLv3, given that we have all these patent considerations. I don't necessarily think we should move to GPLv3, but do consider the tensions that arose from those discussions really unfortunate. Lesson learned: we should consider evolving copyleft openly, in the community, with the community. If you'd like to help with that I invite you to take a look at copyleft-next, there is a github tree and mailing list. Copyleft-next is GPLv2 compatible.
- I don't take this lightly
- "Don't be evil" is hard
- Why things are hairy when it comes to the Linux kernel and GPL enforcement
- Why we need GPL enforcement
- How can we enforce the GPL responsibly
- Evolving copyleft
I don't take this lightly
Joining was not something I took lightly, when I started hacking on Linux I was at ends with arguments over morality on free software put forward by the FSF and simply felt the GPLv2 on Linux was a nice coincidence; I felt I just wanted to hack and be productive. It took me over 10 years in philosophical thought to make a final decision about where I stand with regards to software freedom. I've made my motivation and intent in the community clear before, but its worth reiterating now: work harder always in spirit of what I believe is right, and accept no compromises on shit engineering.
"Don't be evil" is hard
Why things are hairy when it comes to the Linux kernel and GPL enforcement
Consider answering these questions in today's business world when contributing to Linux.
- Who owns the copyrights or patents to the software that Joe Hacker wrote prior to joining Yoyodyne, Inc?
- Who owns the copyrights or patents to the software that Joe Hacker will write for Yoyodyne Inc?
- What software projects can Joe Hacker contribute to while at Yoyodyne Inc?
- How to replace proprietary solutions
- The Linux kernel is licensed under GPLv2 and as such only gets implicit patent grants
- These days companies have no option but to address patents considerations
- Addressing possible company conflict of interests
I've covered these issues before, what follows is a terse summary. Copyleft obviously is an imminent threat to proprietary software that relies on copylefted software such that the proprietary software is arguably subject to the conditions of the license that the copylefted software is distributed under. An implicit requirement however is that copyright holders of the copylefted software are both willing to and capable of seeking legal remedies against distributors of the proprietary software. In this light, if a business does not know how to phase out proprietary software it can be affected, short term, or long term. Patents can be implicated by some free software licenses. Paying for patent licensing also adds up. Patents can also be used to sue people. If you have signed conflict of interest agreement with business partners, things can get really hairy, and puts the industry at ends when it comes to free and open source software even if you're an "open source company". Since we lack the mathematical and economics framework to tangibly appreciate freedoms over patents and since patents can ultimately be endangered by certain free software licenses its only natural corporate interests will want to undermine certain free software licenses.
As businesses evolve, copyleft evolves. Patents were one of the latest additions to free software licenses, both through the GPLv3 and the Apache 2.0 license. I consider the Apache 2.0 license one of the best legal innovations in our arsenal in the free software world: if you want to really test what seems to be claim of only opposition to copyleft, ask if the Apache 2.0 license can be used instead. Now in the Linux kernel though we have an issue, since its GPLv2 and it only provides an implicit patent grant, and since we can't add GPLv3 or Apache 2.0 licensed material to the Linux kernel -- it still leaves the patent question open for businesses to address. To help with this, its why linux-firmware now also requires an explicit or implicit patent grant requirement. We need to close all the gaps that prevent copyleft evolution. And sure, we can use permissive licenses on Linux, but that should only be used as a compromise -- not a de-facto practice. For instance getting ZFS relicensed to the ISC license might be a great compromise for all parties involved. Fully permissive licenses without patent provisions should be our last resort and compromise. Since patents are prevalent everywhere this means businesses have to deal with a lot of issues implicitly behind the scenes.
Case in point, as covered recently by lwn, at linux.conf.au 2016 Bradley talked about corporate opposition to copyleft. He explained how corporations will typically not do GPL enforcement in the name of the community, unless of course it fits your business model. He gave the example where Red Hat was sued by a patent troll, and in response Red Hat then alleged GPL infringement against Twin Peaks, with this Red Hat got a patent license but Twin Peaks software remained proprietary. Red Hat is an example that has Open Source software built-in to its business DNA, and even they seem to walk on eggshells when it comes to GPL enforcement. They are not to blame though, doing GPL enforcement for the community responsibly is hard, specially these days in such a complex, technology business sector, where anyone can be your partner and business contracts typically forbid you from engaging in actions that may harm any of your business partners.
Why we need GPL enforcement
Because of the challenges explained above even the best of Free and Open Source companies are walking on egg shells when it comes to GPL enforcement. By now you should have a sense of why some corporate interests may be trying to undermine copyleft licenses to effectively be as good as permissive licenses. We can't let that happen. Evidence shows the number of GPL violations has skyrocketed over the years to the extent that we cannot deal with them. There were only a few community groups dealing with GPL violations as well, this was outside of the Linux kernel, Linux kernel GPL violations remain common and unenforced. For this reason GPL enforcement is critical for the Linux kernel and community.
How can we enforce the GPL responsibly?
To address this Conservancy published a set of principles that should govern GPL enforcement, the primary objective is simply to bring about license compliance. We are not out for money, or blood, simply compliance to the license to strengthen the commons. We give input and guidance on Conservancy's strategy in dealing with compliance issues on the Linux kernel. Responsibly enforcing the GPL for the community, within the community with due care should be of utmost interest to any business contributing to Linux. If you're a Linux developer and would like to chime in and help us with these efforts you should consider joining the Conservancy's GPL Compliance Project For Linux Developers, please contact <linux-services@sfconservancy.org> for more details.
Evolving copyleft
On the post where I describe my epiphany which after over 10 years allowed me to finally cope with software freedom philosophy I explained how helping evolve copyleft is important, I'll provide a summary of that in light of the Linux kernel and its GPLv2 license. I believe some of the challenges described above are self inflicted as we were not able to move to GPLv3, given that we have all these patent considerations. I don't necessarily think we should move to GPLv3, but do consider the tensions that arose from those discussions really unfortunate. Lesson learned: we should consider evolving copyleft openly, in the community, with the community. If you'd like to help with that I invite you to take a look at copyleft-next, there is a github tree and mailing list. Copyleft-next is GPLv2 compatible.
Comments
Find the best free slot machines 강원도 출장샵 in San Francisco and 원주 출장안마 other 부천 출장샵 San Francisco suburbs. Newest Slot Machines in San Francisco. Get 창원 출장마사지 free slot machine 바카라 games here.