EULAs Aren't Inherently Evil(writing.kemitchell.com)
writing.kemitchell.com
EULAs Aren't Inherently Evil
https://writing.kemitchell.com/2022/04/22/EULAs-Arent-Inherently-Evil
9 comments
> the customer can run, patch, and run as patched, but not share with others
> patches must be shared and licensed back to the developer
I could get behind all of those terms except the two above. A patch is not the copyrighted work of the original developer. It is a creation of the user. A license with these terms is usurping the copyright of the user on their modifications.
"All rights reserved" is as far right on the free-to-proprietary scale as I'm willing to go. I'm not ready to entertain additional restrictions added to those of copyright. If that makes me a raving ideologue, so be it.
> patches must be shared and licensed back to the developer
I could get behind all of those terms except the two above. A patch is not the copyrighted work of the original developer. It is a creation of the user. A license with these terms is usurping the copyright of the user on their modifications.
"All rights reserved" is as far right on the free-to-proprietary scale as I'm willing to go. I'm not ready to entertain additional restrictions added to those of copyright. If that makes me a raving ideologue, so be it.
I am not a lawyer.
Technically, not all EULAs are evil, but most of them as far as I know are, at least partly. The nature of many EULAs is mainly to take away rights people would normally have without contract law. The most offensive part of what is likely a typical EULA is that it tries to gain personal property rights (No, not IP rights, I mean ACTUAL physical property rights) over what you should morally own. This not only gets around the copyright limitation, but if enforceable, they can legally stop you from doing what you lawfully want involving real property rights, even having nothing to do with IP rights. A lot of people never understand that I think, and as someone who researched this so many times, that's likely what these things usually try to do, and it's depressing when you think about it.
Some might say that you need a proper EULA to lawfully use lawful software, but that's actually not true. Copyright limitations in many places takes care of that (e.g. RAM doctrine), and it's already proven that manylawful proprietary software being sold without a EULA worked out. The main nature of a EULA is to bypass the law in favor of more control.
Many FOSS licenses only grants you certain rights that you normally don't have assuming I'm remembering right. Even if you lost those licenses, at least your regular default certain rights are there, unless there was a separate thing taking those away too.
Technically, not all EULAs are evil, but most of them as far as I know are, at least partly. The nature of many EULAs is mainly to take away rights people would normally have without contract law. The most offensive part of what is likely a typical EULA is that it tries to gain personal property rights (No, not IP rights, I mean ACTUAL physical property rights) over what you should morally own. This not only gets around the copyright limitation, but if enforceable, they can legally stop you from doing what you lawfully want involving real property rights, even having nothing to do with IP rights. A lot of people never understand that I think, and as someone who researched this so many times, that's likely what these things usually try to do, and it's depressing when you think about it.
Some might say that you need a proper EULA to lawfully use lawful software, but that's actually not true. Copyright limitations in many places takes care of that (e.g. RAM doctrine), and it's already proven that manylawful proprietary software being sold without a EULA worked out. The main nature of a EULA is to bypass the law in favor of more control.
Many FOSS licenses only grants you certain rights that you normally don't have assuming I'm remembering right. Even if you lost those licenses, at least your regular default certain rights are there, unless there was a separate thing taking those away too.
> the customer can run, patch, and run as patched, but not share with others.
> the seller guarantees the software will work as documented, won’t be infected with malware, won’t be riddled with security holes, won’t contain plagiarized code.
The two points together are dangerous: they make the seller commit that the software works as intended, even if it is patched by the customer.
The second point is also terrible for the seller: it creates an unbounded liability in case of bug or security issues. Let's assumme that a security vulnerability is discovered, the seller is liable for its exploitation even if they released a patched version that the customer has not applied.
The two points together are dangerous: they make the seller commit that the software works as intended, even if it is patched by the customer.
The second point is also terrible for the seller: it creates an unbounded liability in case of bug or security issues. Let's assumme that a security vulnerability is discovered, the seller is liable for its exploitation even if they released a patched version that the customer has not applied.
> The customer can fix bugs and make improvements. Better yet, while they pay, they can foist this off on the seller. What the customer could usually only hope for in the best case with open source—a timely response from a responsible person—they now get by right, under contract.
> If the seller drops the product, the customer can fork and maintain under fallback license. Or hire someone else to do it.
I don't see how a proprietary license can efficiently ensure these two properties without just being a open source license + service contract. I do agree that OSL + service contract is a useful type of license, but I think almost every other type of proprietary license for software is worse for the consumer.
I don't think you can in general "foist" improvements and bug fixes onto the developer; they still have the option to not implement the features you think are best. In fact if they have multiple clients there is a good chance they cannot even acting in good faith fulfill everyone's requests.
I haven't seen many contracts of this type, but I would suspect most licenses don't have a fallback license that allows multiple clients to choose to use a new company to maintain the product. This is one of the most important properties of OSL, it is easy to fork while still sharing maintenance costs.
> If the seller drops the product, the customer can fork and maintain under fallback license. Or hire someone else to do it.
I don't see how a proprietary license can efficiently ensure these two properties without just being a open source license + service contract. I do agree that OSL + service contract is a useful type of license, but I think almost every other type of proprietary license for software is worse for the consumer.
I don't think you can in general "foist" improvements and bug fixes onto the developer; they still have the option to not implement the features you think are best. In fact if they have multiple clients there is a good chance they cannot even acting in good faith fulfill everyone's requests.
I haven't seen many contracts of this type, but I would suspect most licenses don't have a fallback license that allows multiple clients to choose to use a new company to maintain the product. This is one of the most important properties of OSL, it is easy to fork while still sharing maintenance costs.
It seems to me like mostly wishful thinking, or at least I have never seen these two points actually written in a license, let alone implemented in practice:
- the seller guarantees the software will work as documented, won’t be infected with malware, won’t be riddled with security holes, won’t contain plagiarized code
- the seller provides support and maintenance via e-mail, with a response-time service-level agreement
Usually there is a clause that is the exact opposite of the first (i.e. no obligation that the software actually works for what it should), and the second in practice means "if you e-mail us, we will open a ticket with no deadline whatsoever, we will solve the issue or completely fail to in whatever time we see fit".
Admittedly, I have not a lot of experience with commercial programs that offer a service of assistance, and generally speaking they do work just fine (and contain no bugs/malware/etc.) but the few times I found something not working as expected (actually as it should) it was a nightmare to have the issue fixed in a timely manner (or at all).
- the seller guarantees the software will work as documented, won’t be infected with malware, won’t be riddled with security holes, won’t contain plagiarized code
- the seller provides support and maintenance via e-mail, with a response-time service-level agreement
Usually there is a clause that is the exact opposite of the first (i.e. no obligation that the software actually works for what it should), and the second in practice means "if you e-mail us, we will open a ticket with no deadline whatsoever, we will solve the issue or completely fail to in whatever time we see fit".
Admittedly, I have not a lot of experience with commercial programs that offer a service of assistance, and generally speaking they do work just fine (and contain no bugs/malware/etc.) but the few times I found something not working as expected (actually as it should) it was a nightmare to have the issue fixed in a timely manner (or at all).
I have, once. IBM does exactly that for z/OS (with the exeption that you can share patches). This is of course a whole other level of software and price tag.
I am missing the 'No EULA' option.
In the software, the No EULA scenario is presented as impossible. People claim that this would allow anyone to do unlimited copying.
But selling e.g. books works just fine without them. The governement still makes unlimited copying illigal.
So the EULA serves other, more nefarious purposes, e.g. Limiting warranties and taking away rights.
I am not against licensing. Between 2 businesses, there might be enough negotiating power to make them usefull. But confronting the average consumer with complicated legal frameworks should never have been allowed, as there is no way they have enough negotiating power.
In the software, the No EULA scenario is presented as impossible. People claim that this would allow anyone to do unlimited copying.
But selling e.g. books works just fine without them. The governement still makes unlimited copying illigal.
So the EULA serves other, more nefarious purposes, e.g. Limiting warranties and taking away rights.
I am not against licensing. Between 2 businesses, there might be enough negotiating power to make them usefull. But confronting the average consumer with complicated legal frameworks should never have been allowed, as there is no way they have enough negotiating power.
I agree. Copyright already provides (more than) reasonable protections for software authors. There is usually no need for a license/contract at all.
> It reinforced a stark, limited view of the industry—characteristic of young and commercially sheltered coders dealing entirely with dominant apps from megacorps, on one hand, and open source from hackers, on the other—as all relevant reality. [...] No experience of negotiation—engineering terms to circumstances—to speak of.
Reads as "Coders are just too young and 'commercially sheltered' to realize how great my preferred proprietary terms are"
Go away with this stuff. We're engineers, we want to engineer, being 'commercially sheltered' is exactly what we want to be -- not a mistake caused by our lack of your experience in middle management.