What does evil mean in this case? To me, it means a EULA that:
gives more advantage to the software creator/seller than the customer, when it should be equal, and/or
absolves the creator/seller of responsibility.
With that in mind, I think Mr. Mitchell is right in general.
In practice, how many EULA’s are not evil? I think Mr. Mitchell has probably seen a few, probably written a few. I think that may be because his work is probably mostly between two business customers.
But as an individual software consumer, I have never seen such a EULA. I’ve only seen EULA’s that are “evil” (which I define as a EULA that gives more advantage to the software creator than the customer, when it should be equal), at least in the software that I use.
That is why I use Open Source software as much as possible: that extreme is better than the other, of being locked down by EULA’s that advantage the creator over me or absolve the creator of responsibility.
This is in addition to a few of the other problems mentioned by comments on the orange site.
So in theory, practice and theory are no different; in practice, they are.
But it would be a good world if Mr. Mitchell was right in practice, as long as customers always had access to source code and the ability to modify it, and the creator/seller accepted responsibility for it.
It’s also a rare case of arguing for a strawman. ;)
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.
The problem is that for all practical purposes such an EULA doesn’t exist. No software developer can be expected to do any work without an incentive to do that. If there’s a problem the vendor isn’t personally having and leaving it unfixed does not lead to significant user base shrinking, they will not do it, and who can blame them?
EULAs with negative financial incentives for the vendor to fix bugs/add features or solve your problems kinda do exist, but they are out of reach even for average business users. There are also many ways to game those incentives by sticking to their letter without keeping their spirit, e.g. giving a reply within the SLA timeframe but not supplying any actually useful information there. And then even the most well-intentioned support providers should be wary of any guarantees to solve the problem, because anyone can take you to court and claim you didn’t solve their problem. That’s not counting cases when a problem really can be solved.
If people can share modified versions, there may be hope that someone is having the same problem as you but better programming skills and will make a patch. In a “use, but don’t distribute” model there’s no way for anyone to share it, so even if someone fixes it, you will not benefit from it.
P.S. For the record, I do make money from open-source software with a “pay for precompiled binaries and support” model, and we do have a EULA covering the binaries with proprietary and trademarked artwork embedded in them (exactly like RedHat and Mozilla do). But we don’t give any guarantees of solving user’s problem because it would be false advertising. We don’t game SLA response time guarantees that we give, because we all had multiple proprietary vendors play that trick on us, and we hate it.
The problem is that for all practical purposes such an EULA doesn’t exist. No software developer can be expected to do any work without an incentive to do that.
Licenses like that get signed all the time.
The vendor’s support commitment requires them to respond timely to requests. Where those requests identify bugs, the result is a fix, which the vendor’s maintenance commitment requires it to provide. If the vendor falls down on its support commitment, the customer gets credits against its fees, and possibly an out from the contract. The vendor’s incentivized to avoid that.
Blank-check commitments for new features aren’t so common, for obvious reasons. I have seen many deals where particular roadmap points got included in the terms. But even without a hard commitment to develop new features, support request → roadmap item → minor release stories are very common. Features existing customers ask for can be features potential customers want.
Maybe if you pay hundreds thousands dollars… Haven’t seen anything like that from proprietary vendors in the thousands or tens of thousands dollar range.
I have seen bugs in very expensive software go unfixed for months and years just because they weren’t affecting the majority of users, and it wasn’t a real threat to the vendor. I did see many prompt fixes, mind you, but my point is that in the vast majority of cases there’s no guarantee that your bug will be fixed, no matter how critical is it to you.
I have definitely seen good support SLAs in that range of ARR. And happy customers who never had to send a ticket!
I hear you on languishing bugs in pricey software. It happens. Frustratingly, sometimes it’s just efficient.
I have also seen side deals where customers ponied up extra to get a bug squashed or a feature added, even one arguably covered by their existing support-maintenance deal. The remedies under that deal weren’t enough to move the vendor, and the loss from the customer walking came in under the cost of the fix. Another day at the office.
I think we’d probably be better off in a wold with more source available deals like the one I outlined in the blog post: fix it yourself if you want to, just send the patch back to the vendor. But often enough, the vendor’s still the one who can get the work done with lowest cost, especially when the customer isn’t a “software company”. The vendor has the people who know the code.
In practice, how many EULA’s are not evil? I think Mr. Mitchell has probably seen a few, probably written a few. I think that may be because his work is probably mostly between two business customers.
But as an individual software consumer, I have never seen such a EULA. …
I really appreciate this comment.
I was 50-50 on the second part of the blog post, after the <hr>. The bit where I speculate on why this black-white view persists. I knew my speculation’s informed, but speculation’s always a jump. I worried it would distract or detract more than it added. I’m glad I went with it now.
The HN discussion already has two or three threads where I see someone with software deals experience butting heads with someone who only sees take-it-or-leave-it terms. Here you’ve hit the same insight with introspection, without all the noise and squabble. It’s nice to be here on lobste.rs ;-D
The relevant bit of my post was here:
[The black-and-white view of licensing] 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. There wasn’t any burgeoning gray area of independent software sales in this picture…. No experience of negotiation—engineering terms to circumstances—to speak of. No rallying call to develop those chops.
When a vendor has you over a barrel—market power, exclusive deal—the terms they deign give are more than likely bad news. Same with the software, for that matter. Microsoft doesn’t need to give us source code to keep Word in pole position. If a hardware vendor controls their tech, the dev kit can be lousy.
As solo devs cruising the web for code, we have no leverage. The cost of just discussing terms with us would eat all our value as potential customers. So terms are take-it-or-leave-it.
The reason I’m on about this to solo devs and indie firms is that I think we could get a lot more out of ourselves and each other if we accepted that deals engineering is an art we can get good at that could unlock a ton of latent potential. Some of this is business basics: many firms now offer multiple take-it-or-leave-it deals, at different “tiers”, with a features grid. As programmers, we have the skills to do that and so much more. And we have the skills to automate it—software configuration, legal terms, payment, the whole shebang.
Contracts that don’t allow for a meeting of the minds are inherently lacking. Regardless of whether it’s evil, it’s certainly not fair. As somebody pointed out on the orange site, proprietary software usually is not sold with such rich support contracts, and rich support is the only supposed advantage of a non-FLOSS EULA.
As we covered last time, claims like “won’t be infected with malware, won’t be riddled with security holes” are not upheld by proprietary vendors. Similarly, plagiarism or inappropriate reuse of licensed code (e.g. use of code from Stack Overflow without citation) is rampant. So, the only thing left that a proprietary vendor can offer is an SLA (and discounts for committed use, etc.)
“Meeting of the minds” is really important latent wisdom. I agree it’s been neglected. And I’m glad to see it mentioned in a software forum!
I can’t agree that support is the only advantage of a commercial deal. I think that’s just one aspect of taking responsibility for the software sold. Same for quality, security, and IP guarantees.
I have definitely seen commercial software vendors fall down on quality, security, and IP. Same with open source, of course. Software isn’t perfect, and no license agreement can make it so. Nor would a typical customer pay perfection’s price. There are exceptions: medical devices, weapons, critical infrastructure. Fields, as a rule, where open never caught on as elsewhere.
So software’s imperfect, but license terms say it should be. The value isn’t just in telling pleasant lies. The value is that when things go wrong, with consequences, the vendor’s committed to stand responsible, financially. With dollars at risk, they’re incentivized to invest in prevention.
If the customer fears the vendor may be under-investing, they can insist the vendor carry insurance. The carrier in turn will question vendor’s practices and price their premium accordingly.
Returning to my Sony BMG example, at what point did Sony BMG fully disclose what they had done, instead of lying? They shrugged off several class-action lawsuits, and only an FTC action was able to reimburse customers; were they accepting responsibility? Was their insurance affected?
In the linked thread on the orange site, it’s shown that licenses like AGPL are comparable to your list of terms in a “proprietary” deal. The main distinction are these two clauses:
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
This first clause is completely countered by the Sony BMG example. They published malware, the malware opened up security holes by installing a rootkit that sheltered other malware, and the malware contained plagiarized Free Software without appropriate licensing. This really does happen, the consequences are dire, and the publishers walk away without effort.
The second clause is just selling software as a service with an SLA!
(I apologize for pulling teeth, but it’s clear that you’ll ignore anything cited unless it’s directly quoted or explained.)
What does evil mean in this case? To me, it means a EULA that:
With that in mind, I think Mr. Mitchell is right in general.
In practice, how many EULA’s are not evil? I think Mr. Mitchell has probably seen a few, probably written a few. I think that may be because his work is probably mostly between two business customers.
But as an individual software consumer, I have never seen such a EULA. I’ve only seen EULA’s that are “evil” (which I define as a EULA that gives more advantage to the software creator than the customer, when it should be equal), at least in the software that I use.
That is why I use Open Source software as much as possible: that extreme is better than the other, of being locked down by EULA’s that advantage the creator over me or absolve the creator of responsibility.
This is in addition to a few of the other problems mentioned by comments on the orange site.
So in theory, practice and theory are no different; in practice, they are.
But it would be a good world if Mr. Mitchell was right in practice, as long as customers always had access to source code and the ability to modify it, and the creator/seller accepted responsibility for it.
It’s also a rare case of arguing for a strawman. ;)
The problem is that for all practical purposes such an EULA doesn’t exist. No software developer can be expected to do any work without an incentive to do that. If there’s a problem the vendor isn’t personally having and leaving it unfixed does not lead to significant user base shrinking, they will not do it, and who can blame them?
EULAs with negative financial incentives for the vendor to fix bugs/add features or solve your problems kinda do exist, but they are out of reach even for average business users. There are also many ways to game those incentives by sticking to their letter without keeping their spirit, e.g. giving a reply within the SLA timeframe but not supplying any actually useful information there. And then even the most well-intentioned support providers should be wary of any guarantees to solve the problem, because anyone can take you to court and claim you didn’t solve their problem. That’s not counting cases when a problem really can be solved.
If people can share modified versions, there may be hope that someone is having the same problem as you but better programming skills and will make a patch. In a “use, but don’t distribute” model there’s no way for anyone to share it, so even if someone fixes it, you will not benefit from it.
P.S. For the record, I do make money from open-source software with a “pay for precompiled binaries and support” model, and we do have a EULA covering the binaries with proprietary and trademarked artwork embedded in them (exactly like RedHat and Mozilla do). But we don’t give any guarantees of solving user’s problem because it would be false advertising. We don’t game SLA response time guarantees that we give, because we all had multiple proprietary vendors play that trick on us, and we hate it.
Licenses like that get signed all the time.
The vendor’s support commitment requires them to respond timely to requests. Where those requests identify bugs, the result is a fix, which the vendor’s maintenance commitment requires it to provide. If the vendor falls down on its support commitment, the customer gets credits against its fees, and possibly an out from the contract. The vendor’s incentivized to avoid that.
Blank-check commitments for new features aren’t so common, for obvious reasons. I have seen many deals where particular roadmap points got included in the terms. But even without a hard commitment to develop new features, support request → roadmap item → minor release stories are very common. Features existing customers ask for can be features potential customers want.
Maybe if you pay hundreds thousands dollars… Haven’t seen anything like that from proprietary vendors in the thousands or tens of thousands dollar range.
I have seen bugs in very expensive software go unfixed for months and years just because they weren’t affecting the majority of users, and it wasn’t a real threat to the vendor. I did see many prompt fixes, mind you, but my point is that in the vast majority of cases there’s no guarantee that your bug will be fixed, no matter how critical is it to you.
I have definitely seen good support SLAs in that range of ARR. And happy customers who never had to send a ticket!
I hear you on languishing bugs in pricey software. It happens. Frustratingly, sometimes it’s just efficient.
I have also seen side deals where customers ponied up extra to get a bug squashed or a feature added, even one arguably covered by their existing support-maintenance deal. The remedies under that deal weren’t enough to move the vendor, and the loss from the customer walking came in under the cost of the fix. Another day at the office.
I think we’d probably be better off in a wold with more source available deals like the one I outlined in the blog post: fix it yourself if you want to, just send the patch back to the vendor. But often enough, the vendor’s still the one who can get the work done with lowest cost, especially when the customer isn’t a “software company”. The vendor has the people who know the code.
I really appreciate this comment.
I was 50-50 on the second part of the blog post, after the
<hr>. The bit where I speculate on why this black-white view persists. I knew my speculation’s informed, but speculation’s always a jump. I worried it would distract or detract more than it added. I’m glad I went with it now.The HN discussion already has two or three threads where I see someone with software deals experience butting heads with someone who only sees take-it-or-leave-it terms. Here you’ve hit the same insight with introspection, without all the noise and squabble. It’s nice to be here on lobste.rs ;-D
The relevant bit of my post was here:
When a vendor has you over a barrel—market power, exclusive deal—the terms they deign give are more than likely bad news. Same with the software, for that matter. Microsoft doesn’t need to give us source code to keep Word in pole position. If a hardware vendor controls their tech, the dev kit can be lousy.
As solo devs cruising the web for code, we have no leverage. The cost of just discussing terms with us would eat all our value as potential customers. So terms are take-it-or-leave-it.
The reason I’m on about this to solo devs and indie firms is that I think we could get a lot more out of ourselves and each other if we accepted that deals engineering is an art we can get good at that could unlock a ton of latent potential. Some of this is business basics: many firms now offer multiple take-it-or-leave-it deals, at different “tiers”, with a features grid. As programmers, we have the skills to do that and so much more. And we have the skills to automate it—software configuration, legal terms, payment, the whole shebang.
Contracts that don’t allow for a meeting of the minds are inherently lacking. Regardless of whether it’s evil, it’s certainly not fair. As somebody pointed out on the orange site, proprietary software usually is not sold with such rich support contracts, and rich support is the only supposed advantage of a non-FLOSS EULA.
As we covered last time, claims like “won’t be infected with malware, won’t be riddled with security holes” are not upheld by proprietary vendors. Similarly, plagiarism or inappropriate reuse of licensed code (e.g. use of code from Stack Overflow without citation) is rampant. So, the only thing left that a proprietary vendor can offer is an SLA (and discounts for committed use, etc.)
“Meeting of the minds” is really important latent wisdom. I agree it’s been neglected. And I’m glad to see it mentioned in a software forum!
I can’t agree that support is the only advantage of a commercial deal. I think that’s just one aspect of taking responsibility for the software sold. Same for quality, security, and IP guarantees.
I have definitely seen commercial software vendors fall down on quality, security, and IP. Same with open source, of course. Software isn’t perfect, and no license agreement can make it so. Nor would a typical customer pay perfection’s price. There are exceptions: medical devices, weapons, critical infrastructure. Fields, as a rule, where open never caught on as elsewhere.
So software’s imperfect, but license terms say it should be. The value isn’t just in telling pleasant lies. The value is that when things go wrong, with consequences, the vendor’s committed to stand responsible, financially. With dollars at risk, they’re incentivized to invest in prevention.
If the customer fears the vendor may be under-investing, they can insist the vendor carry insurance. The carrier in turn will question vendor’s practices and price their premium accordingly.
Returning to my Sony BMG example, at what point did Sony BMG fully disclose what they had done, instead of lying? They shrugged off several class-action lawsuits, and only an FTC action was able to reimburse customers; were they accepting responsibility? Was their insurance affected?
In the linked thread on the orange site, it’s shown that licenses like AGPL are comparable to your list of terms in a “proprietary” deal. The main distinction are these two clauses:
This first clause is completely countered by the Sony BMG example. They published malware, the malware opened up security holes by installing a rootkit that sheltered other malware, and the malware contained plagiarized Free Software without appropriate licensing. This really does happen, the consequences are dire, and the publishers walk away without effort.
The second clause is just selling software as a service with an SLA!
(I apologize for pulling teeth, but it’s clear that you’ll ignore anything cited unless it’s directly quoted or explained.)
That’s not an apology. I’m not throwing time or attention after it.
Well, I’m not contrite. I prefer opinions which are backed by evidence, and I’ll continue to introduce counterexamples.
I disagree with the statement in the headline.