My take: end-users don't care very much about the license, and even for technical users, the value of an 'open' license is overstated. I simply cannot fix bugs in, say, GCC, and it would also be pretty hard for me to pay someone to do so, despite this project being pretty much the poster child (other than, of course, Linux, but that is not exactly a typical case...) for the GPL.
Corporate users want a way out of an abusive or impossible vendor relationship: source escrow can fix that as well as the GPL can (which is to say: not exactly entirely, but, close, I guess?).
Regular users want... things just to work, and someone to shout at if it doesn't. The license of the underlying source code is pretty much irrelevant for that. There are at least three levels of support/indirection prior to that making any difference.
No, it's not like that at all. My original point was that most end-users don't care about the license. Implied was that most end-users determine the state of the market, but whatever.
So, here I am, 4 downvotes to my name for stating the obvious. Despite years of membership, I don't have downvote privileges, so I guess I just have to bow to the galaxy-sized minds that have this ability, and deal with the crumbs that do leave a reply, however utterly misguided?
And once you do care as a user FOSS gives you more options since you can invest either time or money to fix your problems, and the market of who you can give money to support you isn't artificially constrained by IP access.
> Those who take the deal aren’t “locked in” by some dark legal magic.
No, they're locked in because this application has a likely proprietary data format, and conversion means you lose content... If you're even allow to export.
Proprietary programs act as data roach motels: your data checks in, and it dont check out.
> The customer gets source and permission to hack it. This is way more normal in business-to-business software deals than hackers tend to think.
Almost all proprietary software won't do this. And I've dealt with a lot of proprietary software. At best, I've seen an agreement that if the company died, they would get escrow sourcecode. And that was 1 company.
If you’re some random dude who shows up off the street, proprietary software vendors probably won’t share source. But for large contracts, it does happen. Even MS has been doing this for over 20 years.
This type of proprietary licensing is called “shared source” licensing.
And for more customizable B2B software, shared source is very common. (Or, basically, anything delivered in an interpreted language)
I mean, the consensus is that using FOSS to provide SaaS and not providing source isn't really FOSS. It doesn't award the four freedoms, and is basically a hack to make FOSS back into proprietary software rather than some gotcha.
If the literal text a the software license is, verbatim, a FOSS license, it’s a bit of a no-true-Scotsman to say that it doesn’t count. Licenses are just documents.
I think it’s silly that some people insist that FOSS licenses are perfectly infallible and proprietary licenses are always fatally flawed.
They all have pros and cons, people misuse them, and none of them are perfect. If there was one that was perfect, everyone would use it. But everyone has different needs and concerns. Pick the license that does what you want to do.
No, it's that there a definition of free software based in the four freedoms that the licences only approximate.
That's why GPL has an 'or later' clause, to patch fix issues when people find out ways to remove the four freedoms while complying with the letter of the license.
So I'm specifically not making the argument that "FOSS licenses are perfectly infallible", only that everything proprietary licenses do, FOSS licenses and support contracts do better from the user's perspective.
Software licenses are a legal document. Those legal documents are defined by the terms within them. One may argue that it isn't "in the spirit of of what RMS intended", but legally speaking, RMS's opinions have no relevance to a contract he isn't a party to.
If MIT/Apache/BSD/GPL, etc don't qualify as licenses that protect "the four freedoms" then the OSI and FSF need to update their list of approved licenses.
GPL they do update. That's the point of the "or later" part.
BSD/MIT/Apache is compatible with the four freedoms, but don't do all of the work to enforce them. That's what the FSF means by approved; these licenses are approved for being incorporated into GPL code.
Proprietary vs. open is like renting vs. owning without the legal protection offered to renters. If your data is locked in some proprietary format you're beholden to the proprietor who can - and often does - abuse his power by raising prices, adding intrusive 'features', selling access to your eyes and more. No EULA is going to change that since those agreements can be changed more or less at will.
There is nothing about proprietary licensed software that requires it to use proprietary data formats. There also exists FOSS software using esoteric formats. You can, and probably should, know how software is going to store your data before you use it, no matter what license it has.
That is the theory, now look at the practice of proprietary software/services and see if the theory holds. It clearly does not, one of the bigger problems with proprietary IT is the lock-in caused by undocumented data formats, services which do not allow bulk data extraction and similar obstacles.
You can do the same lock-in with most FOSS licenses. There’s no requirement to under any common license to document the code. And under the vast majority of them, you can deliver it as a service and be exempt from distributing your code too. Or, you can lock people in with complexity that, while anyone could legally expand on your code, they practically can not.
Data conversion may be a big cost factor in a small software deployment, but in a large deployment, it may only be a small portion of switching costs. There are a lot of switching costs that FOSS simply doesn’t address, particularly when labor, compliance, or legally related.
> There also exists FOSS software using esoteric formats.
They're esoteric, but not proprietary. The article is making the argument that with proprietary agreements you can pay someone for support. With FOSS, that's also true with the added benefit that the market for support isn't impeded by the artificial barrier of IP access.
Check how often guitar-pro changed their format for no perceived benefit. Corel didn't even support svg, last time I checked (years ago, admittedly).
The point is: a locked proprietary format is in the interest of proprietary software vendors. It benefits the vendor but hurts the user.
The vendor can even make something document well enough to be used by governments but closed enough to be impractical to be freely implementable. See ms office formats.
That’s not because of the license, though. Both the license choice and the hostile formats are caused by the author being hostile.
The authors point here isn’t that all companies that use proprietary licenses are good. It’s that a proprietary license doesn’t have to make you bad.
For B2B users, there are often FOSS terms that they find to be hostile. Limitations of liability being a big one. Waiving one’s right to use the legal system is a big deal to some people. FOSS programmers like this because it protects them. But for non-developers, this only limits their own rights.
> For B2B users, there are often FOSS terms that they find to be hostile. Limitations of liability being a big one. Waiving one’s right to use the legal system is a big deal to some people. FOSS programmers like this because it protects them. But for non-developers, this only limits their own rights.
That's only if you don't pay someone for a support contract. I've never seen a support contract for FOSS that waived liability.
If you want someone to be liable, you can pay them for the privilege, just like with proprietary software. And you don't have to just choose the original developers. This gives the end users more rights, not less as you're suggesting.
You can certainly buy support contracts but they tend to accept liability primarily in regards to their support capability, not the total extent of what the law would otherwise allow. While FOSS may convey rights that proprietary software doesn’t, those rights are not necessarily valuable to any one user in particular.
This is why people choose different licenses. A software engineer in their dorm room cares about different things than an accountant in an office.
I've never seen a support contract that conveys all liability the law allows. In general the more you spend the more the lawyers get really specific about what SLAs, etc. actually mean. And the baseline is never 'the developer is responsible for everything'. This is just as true for FOSS and it is for proprietary software.
And to talk about FOSS as happening in dorm rooms is 90s level FUD.
It's also simply not representative of what's being discussed. Support for FOSS is a many billion dollar industry, and describing it as happening in dorm rooms is absurd.
I understand that. The statement was intentionally an example of an outlier, not making a generalization as you accuse.
There is, in fact, at least one person in a dorm room writing FOSS. (I've been one, myself) And there's at least one person in an accounting office who does not write software. These are examples of two individual people who have different needs. This is not a generalization of any industry as a whole.
You haven't given a stronger plausible interpretation than spreading FUD. Your only defense so far is that it was a non-representative fact bordering on a non-sequitur.
"There is nothing about proprietary licensed software that requires it to use proprietary data formats."
All that matters is the fact that if you can't see the code then you can't implement the format unless the developer degns to give you specs, and doesn't lie about the specs. And the fact that, in practice, what actually happens is, proprietary software takes every opportunity it can possibly get away with to vendor-lock data.
It doesn't matter that they don't have to, what matters is that they do, and, you have no option to take matters into your own hands when the vendor doesn't please you.
"There also exists FOSS software using esoteric formats."
This is a stupid statement. By which I mean it invalidates it's own self.
When the source to generate some data is a available, it doesn't matter what the format is. No matter how complex and disorganized or "esoteric" the data, and no matter how terrible the source code that generated it, and even no matter how old or obscure the language or platform used, it still exists as a reference. That simple existence is the difference between possible and not-possible, and that is all the difference in the world. That difference is 1000x more important than any level of convenient vs inconvenient.
"esoteric" is a meaningless word in the presense of x-ray goggles.
The data remains usable and interoperable no matter what it is. It doesn't matter if it's common or onscure, or current or ancient, or human-readable or encrypted binary, and no one has the power to deny you access to read the data or to generate compatible data from outside of the original app, and regardless of the original developer's intentions.
There is no slightest shred of a valid argument here.
What? Why are you even trying to say that those constitute access to the source in any meaningful way to anyone?
Yes proprietary licensing does preclude source availability, obviously, because no one has access to those source licenses, and the few that do, have to sign nda's preventing them from publicising what they see. If someone is working for someone huge enough to actually have one of those source licenses, they can't use it to fork and publish a fixed version of the product, or even publish open source code to merely interoperate if the details end up disclosing inner workings indirectly. Whatever they get out of it, it doesn't do anyone else any good, and that fact itself means it doesn't even do them as much good as it could.
There may be some products where the vendor charges less than millions of dollars, because not all products are Adobe
CS or the PS5's os or Turbo Tax etc, but so what? The proprietary license itself defines the most important fact, which is who retains the right to grant and deny access and usage. The fact there may exist some products where the vendor happens to be small or cooperative means nothing at all, because others are not, and even the ones that are can and do change the deal at any time.
Those licenses don't matter, because the licensees are no different than employees. The employees who develop a proprietary product can also see the source. The special licensees are no different.
Saying the option to get one of those licenses means the source is available, is like saying you could always get a job at that company and the source would be available.
This is a baffling argument to even try to float. Not merely that the argument falls apart instantly at the first glance, the more remarkable thing is I can't imagine why anyone would even want to try.
> Yes proprietary licensing does preclude source availability, obviously, because no one has access to those source licenses, and the few that do, have to sign nda's preventing them from publicising what they see.
The people who are a party to shared source licenses, have access to the source. There licenses are very meaningful to those who use them. They might not be beneficial to you, but that is likely not their concern.
FOSS software can also be subject to NDA. In fact, this is not uncommon. Many companies use Apache/MIT/GPL software, use the software internally, and have their employees sign NDAs.
"The people who are a party to shared source licenses, have access to the source"
So do the employees of the original vendor. So what? How does that matter at all? It means nothing and has no bearing on this topic.
"FOSS software can also be subject to NDA."
Bwhahh wut? No. And I mean, by definition, no.
An organization may take some foss and use it internally and hide that modified internal version, but that means nothing to anyone else. They can't nda the original software they forked from, and they can't even nda their modified version unless the original happens to be MIT-like or they never redistribute it.
There is a lot of MIT software which doesn't require sharing back, but that still doesn't change anything.
Their private mods are no different than anything else they write privately. Whether the private thing is a diff off of a public thing, or something standalone, makes no difference and has no bearing on the original public thing. Their new private thing, if it is nda'd, is then by definition, not foss. It doesn't matter that it's comprised of a copy of some other foss plus whatever they added. It's now just some proprietary software like any other.
None of that harms anyone else or makes foss somehow just as limited as proprietary or proprietary just as available as foss.
> "The people who are a party to shared source licenses, have access to the source"
> So do the employees of the original vendor. So what? How does that matter at all? It means nothing and has no bearing on this topic.
The title of this topic begins with: "EULAs Aren't Inherently Evil"
My point is that, FOSS only provides benefits to users who care about modifying or redistributing that software. Not everyone does. Giving my mother the right to modify and redistribute software does not provide any tangible benefit to her, because she will never do that.
For the many institutional users who take advantage of shared-source licenses, they also have no desire to redistribute or change the software, they simply want to audit it. They are not being prevented from doing anything that they wanted to do.
What evil is done to a user when you take away a right to do something they had no desire to do? And for that matter, why is taking away people's tort rights something that is assumed to be good for users?
I personally appreciate and contribute to FOSS, but the idea that it protects the rights of anyone other than developers specifically is myopic.
Just like proprietary licenses restrict the rights of users, so do almost all FOSS licenses -- just in different ways. The difference is not that one protects your rights and the other one doesn't, the difference is in which rights they choose to protect.
I have seen many, many software deals with meaningful warranties from sane companies.
Disclaimers do often include the "AS IS" magic phrase. But it often appears within a structure making exception for "express warranties". In other words, "AS IS" appears, but it doesn't erase the warranties written out in the license agreement. It's there to reinforce disclaimers of default warranties in the background law, like the Uniform Commercial Code.
So these are the two claimed benefits of proprietary software (everything else listed is either the same as or worse than FOSS):
> 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
But there's nothing inherent to proprietary software about either of those things. There's nothing stopping you from using a FOSS license for your software itself, and selling a separate contract that gives those two things.
It's funny how guarantees like this work until broken. You can put whatever you want in a EULA. Once it is broken, you just say oops beyond my contol that hackers got in and did this. No longer need to honor this.
You can definitely sell extra warranties, support, or both for open software. I've helped a few clients do all those things, and published free form contracts online.
However, contracting for warranties or support does not have the same incentive-alignment effect as offering them within a broader license deal. A few thoughts come to mind:
- The one selling the warranties or the support needn't be the developer. Even if the developer does offer those things, others can step in and compete. The outsiders' costs may in fact be lower. They're not also spending on gratis software development, for one.
- Speaking of money, customers will usually pay a lot less for warranties or support than for use of software, or use of software along with warranties and support. That means fewer resources flowing back to the develop to invest in quality, security, IP hygiene, and the other drivers of risk driving demand for warranties and support.
- Offering support in isolation can produce a perverse incentive: invest too much in usability, bug hunting, architecture, and so on, and suddenly customers don't need paid support. Fundamentally, warranties and support are for when things go wrong. Training and consulting have a similar potential conflict with open documentation.
> The one selling the warranties or the support needn't be the developer. Even if the developer does offer those things, others can step in and compete. The outsiders' costs may in fact be lower. They're not also spending on gratis software development, for one.
A healthy market for support is good for the user.
> Speaking of money, customers will usually pay a lot less for warranties or support than for use of software, or use of software along with warranties and support. That means fewer resources flowing back to the develop to invest in quality, security, IP hygiene, and the other drivers of risk driving demand for warranties and support.
Definitely not true from my experience in supported B2B software. Most of the time nearly all of the real money is in the support contract. The license purchase normally only covers cogs and R&D.
> Offering support in isolation can produce a perverse incentive: invest too much in usability, bug hunting, architecture, and so on, and suddenly customers don't need paid support. Fundamentally, warranties and support are for when things go wrong. Training and consulting have a similar potential conflict with open documentation.
Equally true of proprietary software given the above calculus of how support is where the real money is. That's why you see little cottage industries of people who know crappy software, proprietary or FOSS. See the scene around maintaining Oracle DBs where uptime and throufhput seems to be measured in credit score.
> A healthy market for support is good for the user.
I'd be careful defining user welfare so narrowly, aspect-by-aspect, in isolation.
Alas, it sometimes comes to pass that A develops and releases a valuable project but B steps in, beating A out to offer support. That diverts resources from A to B. A's work lags and bugs languish, which perversely drives demand for more support. I have seen B starve A out, then step in to fix bugs and add features...to a proprietary fork, available only to customers of B. All the while, B may in fact be far less familiar with or competent on the project than A, the initial developer.
> Most of the time nearly all of the real money is in the support contract.
I've seen deals structured this way. And I've seen the opposite. Frankly, there's often no rigorous allocation of dollars across software, support, and other buckets, just a deal between the parties about who gets how much when. The rest is just "structuring". In some cases, driven as much by accounting as anything else.
> I'd be careful defining user welfare so narrowly, aspect-by-aspect, in isolation.
> Alas, it sometimes comes to pass that A develops and releases a valuable project but B steps in, beating A out to offer support. That diverts resources from A to B. A's work lags and bugs languish, which perversely drives demand for more support. I have seen B starve A out, then step in to fix bugs and add features...to a proprietary fork, available only to customers of B. All the while, B may in fact be far less familiar with or competent on the project than A, the initial developer.
As I said in the part of my response that you failed to quote that's equally true of proprietary software.
And the fact that someone can make a private proprietary fork with some FOSS licenses being a point in favor of a software product being completely proprietary seems absurd on its face.
> I've seen deals structured this way. And I've seen the opposite. Frankly, there's often no rigorous allocation of dollars across software, support, and other buckets, just a deal between the parties about who gets how much when. The rest is just "structuring". In some cases, driven as much by accounting as anything else.
What's pretty universal once you distill down the accounting trickery is that deals require support contracts to make money.
I have never seen someone making hand over fist for as-is software with no obligations, proprietary or FOSS.
46 comments
[ 2.9 ms ] story [ 102 ms ] threadCorporate users want a way out of an abusive or impossible vendor relationship: source escrow can fix that as well as the GPL can (which is to say: not exactly entirely, but, close, I guess?).
Regular users want... things just to work, and someone to shout at if it doesn't. The license of the underlying source code is pretty much irrelevant for that. There are at least three levels of support/indirection prior to that making any difference.
This is like saying free speech is not important because you have nothing to say.
So, here I am, 4 downvotes to my name for stating the obvious. Despite years of membership, I don't have downvote privileges, so I guess I just have to bow to the galaxy-sized minds that have this ability, and deal with the crumbs that do leave a reply, however utterly misguided?
And once you do care as a user FOSS gives you more options since you can invest either time or money to fix your problems, and the market of who you can give money to support you isn't artificially constrained by IP access.
No, they're locked in because this application has a likely proprietary data format, and conversion means you lose content... If you're even allow to export.
Proprietary programs act as data roach motels: your data checks in, and it dont check out.
> The customer gets source and permission to hack it. This is way more normal in business-to-business software deals than hackers tend to think.
Almost all proprietary software won't do this. And I've dealt with a lot of proprietary software. At best, I've seen an agreement that if the company died, they would get escrow sourcecode. And that was 1 company.
This type of proprietary licensing is called “shared source” licensing.
And for more customizable B2B software, shared source is very common. (Or, basically, anything delivered in an interpreted language)
Although now that you mention it, that’s not always true… which is exactly why the AGPL was written.
https://www.gnu.org/philosophy/who-does-that-server-really-s...
I think it’s silly that some people insist that FOSS licenses are perfectly infallible and proprietary licenses are always fatally flawed.
They all have pros and cons, people misuse them, and none of them are perfect. If there was one that was perfect, everyone would use it. But everyone has different needs and concerns. Pick the license that does what you want to do.
That's why GPL has an 'or later' clause, to patch fix issues when people find out ways to remove the four freedoms while complying with the letter of the license.
So I'm specifically not making the argument that "FOSS licenses are perfectly infallible", only that everything proprietary licenses do, FOSS licenses and support contracts do better from the user's perspective.
If MIT/Apache/BSD/GPL, etc don't qualify as licenses that protect "the four freedoms" then the OSI and FSF need to update their list of approved licenses.
BSD/MIT/Apache is compatible with the four freedoms, but don't do all of the work to enforce them. That's what the FSF means by approved; these licenses are approved for being incorporated into GPL code.
In other words keep your EULA, I don't want it.
Data conversion may be a big cost factor in a small software deployment, but in a large deployment, it may only be a small portion of switching costs. There are a lot of switching costs that FOSS simply doesn’t address, particularly when labor, compliance, or legally related.
They're esoteric, but not proprietary. The article is making the argument that with proprietary agreements you can pay someone for support. With FOSS, that's also true with the added benefit that the market for support isn't impeded by the artificial barrier of IP access.
The point is: a locked proprietary format is in the interest of proprietary software vendors. It benefits the vendor but hurts the user.
The vendor can even make something document well enough to be used by governments but closed enough to be impractical to be freely implementable. See ms office formats.
The authors point here isn’t that all companies that use proprietary licenses are good. It’s that a proprietary license doesn’t have to make you bad.
For B2B users, there are often FOSS terms that they find to be hostile. Limitations of liability being a big one. Waiving one’s right to use the legal system is a big deal to some people. FOSS programmers like this because it protects them. But for non-developers, this only limits their own rights.
That's only if you don't pay someone for a support contract. I've never seen a support contract for FOSS that waived liability.
If you want someone to be liable, you can pay them for the privilege, just like with proprietary software. And you don't have to just choose the original developers. This gives the end users more rights, not less as you're suggesting.
This is why people choose different licenses. A software engineer in their dorm room cares about different things than an accountant in an office.
And to talk about FOSS as happening in dorm rooms is 90s level FUD.
It was an example of polar opposite use cases, I certainly was not meaning to convey that all users belonged to one group of the other.
There is, in fact, at least one person in a dorm room writing FOSS. (I've been one, myself) And there's at least one person in an accounting office who does not write software. These are examples of two individual people who have different needs. This is not a generalization of any industry as a whole.
> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
https://news.ycombinator.com/newsguidelines.html
All that matters is the fact that if you can't see the code then you can't implement the format unless the developer degns to give you specs, and doesn't lie about the specs. And the fact that, in practice, what actually happens is, proprietary software takes every opportunity it can possibly get away with to vendor-lock data.
It doesn't matter that they don't have to, what matters is that they do, and, you have no option to take matters into your own hands when the vendor doesn't please you.
"There also exists FOSS software using esoteric formats."
This is a stupid statement. By which I mean it invalidates it's own self.
When the source to generate some data is a available, it doesn't matter what the format is. No matter how complex and disorganized or "esoteric" the data, and no matter how terrible the source code that generated it, and even no matter how old or obscure the language or platform used, it still exists as a reference. That simple existence is the difference between possible and not-possible, and that is all the difference in the world. That difference is 1000x more important than any level of convenient vs inconvenient.
"esoteric" is a meaningless word in the presense of x-ray goggles.
The data remains usable and interoperable no matter what it is. It doesn't matter if it's common or onscure, or current or ancient, or human-readable or encrypted binary, and no one has the power to deny you access to read the data or to generate compatible data from outside of the original app, and regardless of the original developer's intentions.
There is no slightest shred of a valid argument here.
Proprietary licensing does not preclude source availability. Example: “source available” licenses.
FOSS licensing does not guarantee source availability. Example: MIT/Apache/GPL software as a service.
Yes proprietary licensing does preclude source availability, obviously, because no one has access to those source licenses, and the few that do, have to sign nda's preventing them from publicising what they see. If someone is working for someone huge enough to actually have one of those source licenses, they can't use it to fork and publish a fixed version of the product, or even publish open source code to merely interoperate if the details end up disclosing inner workings indirectly. Whatever they get out of it, it doesn't do anyone else any good, and that fact itself means it doesn't even do them as much good as it could.
There may be some products where the vendor charges less than millions of dollars, because not all products are Adobe CS or the PS5's os or Turbo Tax etc, but so what? The proprietary license itself defines the most important fact, which is who retains the right to grant and deny access and usage. The fact there may exist some products where the vendor happens to be small or cooperative means nothing at all, because others are not, and even the ones that are can and do change the deal at any time.
Those licenses don't matter, because the licensees are no different than employees. The employees who develop a proprietary product can also see the source. The special licensees are no different.
Saying the option to get one of those licenses means the source is available, is like saying you could always get a job at that company and the source would be available.
This is a baffling argument to even try to float. Not merely that the argument falls apart instantly at the first glance, the more remarkable thing is I can't imagine why anyone would even want to try.
The people who are a party to shared source licenses, have access to the source. There licenses are very meaningful to those who use them. They might not be beneficial to you, but that is likely not their concern.
FOSS software can also be subject to NDA. In fact, this is not uncommon. Many companies use Apache/MIT/GPL software, use the software internally, and have their employees sign NDAs.
"The people who are a party to shared source licenses, have access to the source"
So do the employees of the original vendor. So what? How does that matter at all? It means nothing and has no bearing on this topic.
"FOSS software can also be subject to NDA."
Bwhahh wut? No. And I mean, by definition, no.
An organization may take some foss and use it internally and hide that modified internal version, but that means nothing to anyone else. They can't nda the original software they forked from, and they can't even nda their modified version unless the original happens to be MIT-like or they never redistribute it.
There is a lot of MIT software which doesn't require sharing back, but that still doesn't change anything.
Their private mods are no different than anything else they write privately. Whether the private thing is a diff off of a public thing, or something standalone, makes no difference and has no bearing on the original public thing. Their new private thing, if it is nda'd, is then by definition, not foss. It doesn't matter that it's comprised of a copy of some other foss plus whatever they added. It's now just some proprietary software like any other.
None of that harms anyone else or makes foss somehow just as limited as proprietary or proprietary just as available as foss.
What a bizzare claim to try to make.
> So do the employees of the original vendor. So what? How does that matter at all? It means nothing and has no bearing on this topic.
The title of this topic begins with: "EULAs Aren't Inherently Evil"
My point is that, FOSS only provides benefits to users who care about modifying or redistributing that software. Not everyone does. Giving my mother the right to modify and redistribute software does not provide any tangible benefit to her, because she will never do that.
For the many institutional users who take advantage of shared-source licenses, they also have no desire to redistribute or change the software, they simply want to audit it. They are not being prevented from doing anything that they wanted to do.
What evil is done to a user when you take away a right to do something they had no desire to do? And for that matter, why is taking away people's tort rights something that is assumed to be good for users?
I personally appreciate and contribute to FOSS, but the idea that it protects the rights of anyone other than developers specifically is myopic.
Just like proprietary licenses restrict the rights of users, so do almost all FOSS licenses -- just in different ways. The difference is not that one protects your rights and the other one doesn't, the difference is in which rights they choose to protect.
Disclaimers do often include the "AS IS" magic phrase. But it often appears within a structure making exception for "express warranties". In other words, "AS IS" appears, but it doesn't erase the warranties written out in the license agreement. It's there to reinforce disclaimers of default warranties in the background law, like the Uniform Commercial Code.
> 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
But there's nothing inherent to proprietary software about either of those things. There's nothing stopping you from using a FOSS license for your software itself, and selling a separate contract that gives those two things.
However, contracting for warranties or support does not have the same incentive-alignment effect as offering them within a broader license deal. A few thoughts come to mind:
- The one selling the warranties or the support needn't be the developer. Even if the developer does offer those things, others can step in and compete. The outsiders' costs may in fact be lower. They're not also spending on gratis software development, for one.
- Speaking of money, customers will usually pay a lot less for warranties or support than for use of software, or use of software along with warranties and support. That means fewer resources flowing back to the develop to invest in quality, security, IP hygiene, and the other drivers of risk driving demand for warranties and support.
- Offering support in isolation can produce a perverse incentive: invest too much in usability, bug hunting, architecture, and so on, and suddenly customers don't need paid support. Fundamentally, warranties and support are for when things go wrong. Training and consulting have a similar potential conflict with open documentation.
A healthy market for support is good for the user.
> Speaking of money, customers will usually pay a lot less for warranties or support than for use of software, or use of software along with warranties and support. That means fewer resources flowing back to the develop to invest in quality, security, IP hygiene, and the other drivers of risk driving demand for warranties and support.
Definitely not true from my experience in supported B2B software. Most of the time nearly all of the real money is in the support contract. The license purchase normally only covers cogs and R&D.
> Offering support in isolation can produce a perverse incentive: invest too much in usability, bug hunting, architecture, and so on, and suddenly customers don't need paid support. Fundamentally, warranties and support are for when things go wrong. Training and consulting have a similar potential conflict with open documentation.
Equally true of proprietary software given the above calculus of how support is where the real money is. That's why you see little cottage industries of people who know crappy software, proprietary or FOSS. See the scene around maintaining Oracle DBs where uptime and throufhput seems to be measured in credit score.
I'd be careful defining user welfare so narrowly, aspect-by-aspect, in isolation.
Alas, it sometimes comes to pass that A develops and releases a valuable project but B steps in, beating A out to offer support. That diverts resources from A to B. A's work lags and bugs languish, which perversely drives demand for more support. I have seen B starve A out, then step in to fix bugs and add features...to a proprietary fork, available only to customers of B. All the while, B may in fact be far less familiar with or competent on the project than A, the initial developer.
> Most of the time nearly all of the real money is in the support contract.
I've seen deals structured this way. And I've seen the opposite. Frankly, there's often no rigorous allocation of dollars across software, support, and other buckets, just a deal between the parties about who gets how much when. The rest is just "structuring". In some cases, driven as much by accounting as anything else.
> Alas, it sometimes comes to pass that A develops and releases a valuable project but B steps in, beating A out to offer support. That diverts resources from A to B. A's work lags and bugs languish, which perversely drives demand for more support. I have seen B starve A out, then step in to fix bugs and add features...to a proprietary fork, available only to customers of B. All the while, B may in fact be far less familiar with or competent on the project than A, the initial developer.
As I said in the part of my response that you failed to quote that's equally true of proprietary software.
And the fact that someone can make a private proprietary fork with some FOSS licenses being a point in favor of a software product being completely proprietary seems absurd on its face.
> I've seen deals structured this way. And I've seen the opposite. Frankly, there's often no rigorous allocation of dollars across software, support, and other buckets, just a deal between the parties about who gets how much when. The rest is just "structuring". In some cases, driven as much by accounting as anything else.
What's pretty universal once you distill down the accounting trickery is that deals require support contracts to make money.
I have never seen someone making hand over fist for as-is software with no obligations, proprietary or FOSS.