Let freedom ring. #138
Let freedom ring. #138
Conversation
|
I hear that SUSE could do with some Ansible love. Just sayin' ;) |
|
@CJCShadowsan I was thinking the same. Might be good to start adding support for OpenSUSE. I certainly did with my not recent role |
|
I think you should consider relicensing under GPLv2-or-later instead of GPLv3. If you're trying to prevent Red Hat from taking your code and patching your no-RHEL checks away, this will do nothing to prevent that. The GPLv2 and GPLv3 are equivalent in this matter: they have to provide modified sources to whomever they provide binaries, but they are not obligated to provide new binaries in the future (and therefore not obligated to provide updated sources). What the GPLv3 does is mandate that any patents covering those sources be granted to the recipient, and to anyone they may redistribute the sources to. This is why most organizations forbid the use of GPLv3 code in any situation where that code may end up modified or combined with internal code. By choosing the GPLv3 you are effectively preventing anyone working for those organizations from using your code. Which obviously doesn't include Red Hat, as they already redistribute GPLv3 code today (e.g. samba, gcc, ...). It will restrict users. PS: I dislike software patents as much as the next person, but I think that the GPLv3 did nothing to help that cause, while doing plenty to damage copyleft in general. |
|
@carlosefr - Thank you for that insight; this is exactly why I'm submitting this as a PR and won't merge until I feel like whatever changes get through are the best for my downstream users. I was perfectly happy with MIT/BSD licensing in the past, because I had an informal understanding that massive open source corporations like Red Hat would 'play nice,' even while profiting off my work and the work of thousands of other developers. Since that's no longer the case, I'm re-evaluating my use of MIT/BSD and feel like the FSF was on to something with their zany free software philosophy... |
|
To the end user, library code(which is what roles are essentially) under GPL is a hassle. MIT is just practical. If you need to, I'd say LGPL is a fair compromise that will ensure that value has to be contributed back. I cannot claim to be an expert in software copyright, and this is going off of me googling around for the most part. So take this with a grain of salt. |
|
GPLv3 is ultimately less free, and harmful to users. For example:
If Apple (for example) wants to distribute unmodified binaries of a GPLv3 binary on MacOS, they run the risk of being obligated to release their signing keys or be in violation of copyright law (lacking a license to distribute). This is potentially the case even though Macs can run self compiled, modified binaries. There are ways to get around it with things like plugins, but the GPLv3 ultimately is bad (including for patent reasons). It goes user hostile in the hope that being anti company is good for other users overall. Since upstream is generally still available, users tend to gain little (since they can get the mostly same source from upstream) over something like BSD, and they give up a lot of freedom for that price. |
|
If downstream role users would be too inconvenienced by the license change (even to GPLv2), I may be willing to keep MIT for now, and re-evaluate in the future. I would not like to create extra work for downstream users with this change (unless they're running the role on RHEL), since I respect their time and the value they add to Ansible's ecosystem (by virtue of just using the code). |
|
I don't think this is the right way to continue. I disagree with you regarding the RHEL relicensing issue, but that's not what I want to discuss here. This is a quite useful tool, and preventing Red Hat users from running it will impact users, not Red Hat, and I don't think this is the right way for any open source projects to continue. Disclaimer: I am not an Ansible user, but saw your change on Twitter |
This PR would not prevent Red Hat Enterprise Linux users from running it, it would just require them to set a variable acknowledging the role is unsupported on their platform. |
|
If I understand what you’re trying to achieve, isn’t the AGPL what you want? So that they can’t just stop granting access with a Eula. All downstream users would require access to the source. So just saying we won’t give you access anymore would be a violation. |
That's what Red Hat is doing. Every user gets the source. This is what every version of the GPL, AGPL and LGPL require. They can (re-)sell software, but everyone who buys it also gets the source. AGPL adds a special clause that is mostly relevant for software offered in a SaaS context. |
While technically true (and legally, which is what I believe lawyers would be able to argue in court), that is a very charitable interpretation of the EULA's coercion. |
|
GPLv3+ would be ideal - I'm disappointed that people are disingenuously arguing here that users should not be protected against patent issues. GPLv2+ is great but I think we can do better... If corporations do not want to give users rights they should avoid using Free Software. Regardless of license choice though, I really appreciate your work Jeff! |
|
Totally support this and appreciate you taking a stand against what I consider a cynical move by a corporation very much against the spirit of FOSS - not just for your own work, but on behalf of the community. I hope anyone else who is in a position to put pressure on Redhat, or who just wants to stop those abusing FOSS for commercial reasons, also acts. (Also - OpenSuse are good guys. Worked with them on Uyuni for a while now) |
|
@geerlingguy can you elaborate more on the need to change your license as reaction to Red Hat move? Genuine question. |
AGPL is even worse, because it tries to be a EULA. In the United States (for example), you don't need a license to run legally obtained software. https://www.law.cornell.edu/uscode/text/17/117
Copyleft attempts to use copyright by providing a license to do something that copyright law wouldn't allow. You don't have to accept it, and you can't really violate it in the traditional sense. It's a license to do something the law prohibits, subject to terms. It's like a piece of sheet music that says "you can make copies of this music, provided this notice remains intact." Copyright law says you can't do a thing, the license says you can if you do X. If you don't do X, and you do the thing copyright law prohibits, you are breaking copyright law, not the license. EULAs try to get around this by claiming to be contracts, but there are a number of issues in trying to do this which I won't get into here. The GPL, being a copyright license, doesn't try to restrict running a program, in part because you don't need a license to run software you've legally obtained. With no need for a license, the terms become irrelevant, and you can completely ignore them. The AGPL, in contrast, tries to affect executing of software (which doesn't require a license) instead of distributing software (which does). It ends up twisting itself into a pretzel trying to make that happen, (for example) allowing you to "make, run and propagate covered works that you do not convey so long as your license otherwise remains in force". It runs into absurdities with itself with situations like this:
The problem with this take is that making it available to the public doesn't make you liable for infringement for the output of computer software (the software itself, though the assets may be a different matter). If it's an infringement without a license, then a large amount of software designed to be put on the internet would be infringing, lacking that license. If a license isn't required, then the terms of the AGPL don't matter. They are trying to create new exclusive rights for software licenses, in the same sort of ways EULAs do. Then, like a EULA, it tries to have a clause to kick in and take back your rights to use the software:
It's an even worse license than the GPLv3, and should die in a fire. |
That depends on if RedHat gives the source for things that get binaries. Under the GPL, it's perfectly legal for me to say "I gave you version X, here's the source for version X". Nothing obligates me to give you version Y, or charging to get binaries of Y or Z. I can quit giving you new versions beyond X. As long as the EULA doesn't stop you from getting the source from them of any binary you got from them, they are meeting the GPL requirements. Terminating access to services while maintaining source access to previous versions is fine. I've built systems that did just that. Another way to fulfil the GPL requirements is to distribute the source alongside the binaries. It's not the best for package managers, though. When distributing this way, your duty is met the minute they download, |
|
Under the GPL, redhat can meet their obligations by putting access to the source at the same place (6 d).
If you have a subscription, they are distributing to you and you have access to the source. If you don't have a subscription, they aren't distributing to you anymore, and they already fulfilled their requirement when you got the binary in the first place. There is a three year requirement for written source code offers, but that doesn't apply here. I'd point out that like a lot of companies, Oracle is also hostile to the GPL v3. https://docs.oracle.com/cd/E20451_01/html/E28370/glzey.html#scrolltoc
|
I don't plan on ever adding support for Oracle Linux. |
It's more an example of how users (including companies) will generally choose not to use the GPL v3 when given a choice. Many users flat-out blacklist it as well. It's why my ISO7816-4 applet is done under the GPLv3. It's intentionally designed to discourage companies (any companies) from using it, as well as discouraging development, sharing, and integration with other code. I want it to be open, but I don't really want people actually using it, so the GPLv3 serves as a landmine and discouragement. Anyone who would actually want a crypto applet doesn't want to release the keys, making it effectively unusable for anything other than hobby projects. When I want people to actually use, transform, and build on my stuff, I release it under BSD, Public Domain, or WTFPL, depending on the context. |
| IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN | ||
| CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. | ||
| GNU GENERAL PUBLIC LICENSE | ||
| Version 2, June 1991 |
There was a problem hiding this comment.
Just an heads up, if I remember correctly in order to change license you'll need the agreement from all of previous contributors who submitted their code under the MIT license.
There was a problem hiding this comment.
you'll need the agreement from all of previous contributors who submitted their code under the MIT license.
I wonder too.
Although MIT is the most open license, not restricting any use, no need to ask for any permission, nor implying giving back, it states "copyright notice and this permission notice shall be included in all copies or substantial portions of the Software".
So, changing licenses is not easy, although I guess @geerlingguy wrote most of it.
Which entitles to changing license for (at least) his code.
With the caveat that "Public Domain" is effectively prohibited by law in many jurisdictions. In those jurisdictions you cannot alienate your rights as copyright owner. You can, however, transfer control of those rights to someone else. It's a subtle difference. The idea is to protect the original authors from being "erased from history" — other people cannot claim to be the original authors, and the original author cannot sell them the right to claim that — and to ensure the original authors can reclaim control of their rights if the situation justifies it. Both of these goals are intimately related. |
|
Jeff, I admire your work and I think your oss stuff is awesome. I very much don't like the changes that triggered this discussion, but as a user I'm wondering: How is this proposed change increasing my freedom? Not actively supporting EL is one thing (I understand the rationale, and as I'm not a user of EL I personally don't care about that), but I don't really see how this change will be good for the people building based on your great work. |
An excellent idea! Maybe introduce a new license to enforce this. It is the G and P in GPL that RH willfully strikes at. |
|
I would like to voice my disagreement with the license change for Ansible Roles. With the companies I work with, using anything BSD/MIT licensed is easy. We do make contributions upstream where it would be of value because we want to and as a good business practice because it reduces our own maintenance burden by closely following upstream. Any time GPL code is involved, it means I may have to do a TGB/Legal review for each individual role or any other thing I'm using, even though there is no user distribution or when there is, it is literally the source code anyways. When choosing between two pieces of software, even if the GPL one is objectively better, we'll almost always go with the MIT/BSD one because of the process and headache of dealing with legal. Many will respond with that it is a problem for the business, not upstream. And they are correct. However, the business wont change, what will change is us stopping using the GPL licensed code and either writing our own, or using a MIT/BSD project/fork. |
Yes, which is why the best way to do Public Domain is something like CC0, which has a clause to address that. https://creativecommons.org/publicdomain/zero/1.0/legalcode
|
It is the author’s choice which license is applicable. GPLv2 gives permission to use, but asks you to give back in return.
I suspect you want to make clear that |
Hard to follow this line of thought. “Because of business/legal” Explain them the tremendous impact on time-saving (vs developing yourself) and (community-based) quality control. it is flight behavior from the unknown.
Then, propose business to outsource development ;)
I disagree, business in general is hardly as static as you state here. Fortunately, modern and wise businesses use OpenSource in various forms, with various licenses. |
The line is simple "when something uses a deliberately infectious mechanism, it has to be carefully treaded around, like a rattlesnake.
The GPL doesn't require anyone to give back. It requires providing of source code when distributing open source derived binaries, and even only then to the people you provide binaries to. The problems start to arise when developers inadvertently include GPL code without intending to. As a simple example, Axon's evidence sync software used libVLC. They didn't realize that libVLC by default is compiled with GPL software, and they inadvertently had distributed builds including GPL code. OpenAudible also inadvertently had GPL code in their product. They derived no benefit from that code, didn't intend to put it there, but they used a viral license within their application unknowingly, and it caused risks for their organization. If you are a company, the easiest way to avoid GPL issues is to avoid GPL software. |
|
Regarding relicensing, I could pull another Red Hat and just tell downstream users they could figure out which bits are still MIT licensed by looking at git blame on individual lines of code and seeing what wasn't authored by me. I mean, all the data is there already. (yes I'm being facetious, obligatory /s) |
Every license is - in the end. GPLv3 is infective, GPLv2 not as much.
True - as long as you keep changes to yourself, it's not an issue indeed. For example for in-house projects / developments. If you sell you have to offer source code. If you distribute (not binaries necessarily), reciprocity is required. Well explained by Fossa.
Are you referring to Distributed FFmpeg binary is not GPL compliant #384 ? I just read up. What a case... A product that includes other (licensed) GPLv2-code does not make you vulnerable by design. Maybe OpenAudible could better have written their own kernel, libs etc. Pun intended here.
As such, BSD/MIT might be easier for business (or lazier :) ? ). In the short term, yes. But really? As Linus Torvalds states: "Over the years, I've become convinced that the BSD license is great for code you don't care about." . You might want to read the full article. |
|
I was warned by many in the Drupal community that MIT/BSD licenses are preferred by companies who don't invest in open source, but just want to pull from it when it helps their projects get done. For most of the individual devs I don't think that's the full truth, but as far as legal/management goes, a lot of times, I've seen that to be the case. In the end, even GPLv2 or v3 isn't going to thwart even the best of open source companies, as we've recently witnessed :( And I think the whole 'relicensing other people's contributions' problem could take up a bit of extra discussion. I think at least as an exercise (this whole PR may just get closed), I'd want to know what's involved in that—is there a way to say "any lines in code that Another option is to just pull the roles into my private repo with a couple housekeeping roles, close the source, and stop developing in the open, but I don't think that would be good for anyone! |
IANAL, but the process I followed when some developer mistakenly released source on GitHub without putting proper LICENSE within the repo (making it by default "All Rights Reserved") was opening a PR with the new license and ask previous contributors to approve the PR accepting the license. The projects with the mistake were very small with few contributors so it has been quick and easy. |
|
License compatibility is a complicated thing, and IANAL, but in general BSD (3-clause) and MIT licensed code can be mixed with GPL licensed code. The resulting work must follow the provisions from all licenses. Since BSD/MIT only require attribution and keeping the copyright notice around, adding GPL code to a MIT/BSD codebase effectively relicenses the whole thing as GPL — i.e. if you distribute binaries, you have to provide corresponding sources for all of it, not just the GPL bits, because the whole has become a derivative work of GPL'ed code. Of course, someone can always take code written prior to any relicensing and run with it, provided they obtained that code before the relicensing occured (e.g. they have a local git clone). You can't distribute code to someone under some license and then come back later and tell that someone that you changed your mind (unless the original license says you can do so). If you have contributors from other authors, you can't relicense their code without their explicit permission. Someone can still take those specific bits of code and run with it, under the original license. |
|
Closing as wontfix — it's obvious this change would cause pain to the role's end-users, and would likely do nothing to deter the course of Red Hat Enterprise Linux. The re-licensing would also likely cause a bit of grief for everyone involved, and has some potential land mines with the way it would be rolled out (concerning contributions from other users while the role was licensed as MIT). Unlike Red Hat, I promise to talk always open up a decision to the community before I drop a hand grenade into downstream workflows. |
|
@RalphHightower - Nice, thank you for that! And I think it would still be great to document anything along those lines in this issue (or even better, maybe someone could try to do a bit more research and stick it in a good blog post somewhere!), so no problem at all there. I don't ever really lock issues or PRs, because even closed issues are a wealth of knowledge. |
|
ChatGPT is not a lawyer either, however, I wanted its assessment of open source licenses. I know that Apache 2.0 has a "poison pill" voiding the license agreement if software is contested in patent court. Still, it would be wise to consult with a lawyer. My ChatGPT prompts are in "quoted italics" PS: My column heading in my prior comment is wrong; ISO should be OSI.
|
Context: Removing official support for Red Hat Enterprise Linux
Comments welcome.
My plan is to re-license all my roles starting from the top, but to this point I have been waiting to see if Red Hat either reverses their decision to effectively cut off the downstream flow of open source software, or otherwise make amends with the rest of the open source community.
Please also provide feedback on the license change;
right now my plan is GPLv3 or later, but I've heard concerns that this may be too restrictive for some users (while not resolving the Red Hat EULA loophole). Right now my plan is GPLv2 or later.Unlike Red Hat, I'd rather give my downstream users time to plan, and a voice in the conversation, before a radical change is made which might break their workflows and trust.