[Ourgon]

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.

In other words keep your EULA, I don't want it.

[kube-system]

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.

[marcodiego]

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.

[kube-system]

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.

[monocasa]

> 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.

[kube-system]

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.

[monocasa]

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.

[Brian_K_White]

"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.

[kube-system]

> All that matters is the fact that if you can't see the code

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.

[Brian_K_White]

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.

[kube-system]

> 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.

[Brian_K_White]

You are babbling full-on gibberish now.

"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.

[monocasa]

> 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.

[Ourgon]

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.

[kube-system]

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.