In other words keep your EULA, I don't want it.
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.
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.
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 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.
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.
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)
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.
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?
