7 ms·
EULAs Aren’t Inherently Evil – Proprietary done right can beat free and open
- mdb31 4y agoMy 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.
- marcodiego 4y ago> I simply cannot fix bugs in, say, GCC, and it would also be pretty hard for me to pay someone This is like saying free speech is not important because you have nothing to say.
- mdb31 4y agoNo, 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?
- monocasa 4y agoThey don't care... until they do. 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.
- noasaservice 4y ago> 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.
- kube-system 4y agoIf 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)
- marcodiego 4y agoIf you’re some random dude who shows up off the street, FLOSS devs will share source.
- kube-system 4y agoI never said otherwise, and neither did the author. Although now that you mention it, that’s not always true… which is exactly why the AGPL was written.
- monocasa 4y agoI 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. https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html https://www.gnu.org/philosophy/who-does-that-server-really-s...
- Ourgon 4y agoProprietary 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. In other words keep your EULA, I don't want it.
- kube-system 4y agoThere 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.
- Ourgon 4y agoThat 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.
- kube-system 4y agoYou 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.
- monocasa 4y ago> 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.
- Beltiras 4y agoI've never seen proprietary software licenses not have an AS-IS clause. The license presented will be offered by no sane software house.
- kemitchell 4y agoI 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.
- monocasa 4y agoRight, if you pay someone, now you generally get a warranty. That's orthogonal to proprietary vs. FOSS.
- pgcj_poster 4y agoIt seems like all of the benefits named here are a result of paying developers... not a result of software being proprietary.
- josephcsible 4y agoSo 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.
- encryptluks2 4y agoIt'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.
- kemitchell 4y agoYou 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.
- monocasa 4y ago
- Brian_K_White 4y agoI want to downvote the article itself but upvote the act of surfacing it for discussion.