Hacker News Reader

Comment by smarx007 | Hacker News Reader

That's why there a separate term for what you are describing, https://en.wikipedia.org/wiki/Source-available_software

I'm on mobile and with family today so I can't respond in-depth (happy independence day!), but have ever wondered why the term "source-available" has changed meaning, yet the term "open-source" is not 'allowed' to? (And I'd argue it already has, much to the OSI's dismay.)

The term source-available has been shoehorned to mean everything-not-OSI-approved, instead of what it used to mean: a proprietary license for a project that has its source available (e.g. Sourcegraph's license).

In reality, "open source is a broad software license that makes source code available to the general public with relaxed or non-existent restrictions on the use and modification of the code." Which is the definition the majority of developers would say is open source.

The ELv2 and most uses of BSL fall under the "relaxed restrictions" on use and modification, similar to GPL. I'd argue they are open source.

> In reality, "open source is a broad software license that makes source code available to the general public with relaxed or non-existent restrictions on the use and modification of the code."

Not to the general public, only to the users doesn't have to be generally available to the public, see recent RHEL PR debacle. It's not about the restrictions it's about what you are allowed to do with the code.

> ... Which is the definition the majority of developers would say is open source.

Can you prove your claim has anyone done demographics on this?

All my evidence is anecdotal, based on talking to my users. But that'd be a great topic for developer survey.

Also, I'm quoting Perens' definition of open source.

Why doesn't Elasticsearch B.V. refer to their software as "open source", then? They refer to it as "free and open" in their marketing, so obviously they think the idea is appealing to their customers. They refer to Logstash as "open source" and specifically to the fully Apache 2.0-licensed version as the "-oss" build.

Users of the BSL refer to it as a "source-available" license that, after a period of time, converts into an "open source" license:

https://www.couchbase.com/blog/couchbase-adopts-bsl-license/

It's literally just word-play, dancing around what they actually mean. I'd assume because of pressure from OSI and friends (i.e. bad publicity), not from the real world. The same reason my company is "open, source-available."

If the common understanding of "open source" differed so much from the OSI standard, wouldn't these companies just say "open source" and dismiss the OSI definition as archaic, too narrow, etc.? Instead, it seems like there's been a lot of work put into maintaining a formal distinction, including working with Bruce Perens to revise the BSL:

https://itsfoss.com/making-the-business-source-license-open-...

Note that I'm not coming from a position of hostility re: the BSL and similar licenses here. I think companies using that approach can be friendly neighbors with the open source community. I just think it's important for those neighbors to share a well-maintained fence to keep malicious actors from exploiting ambiguity.

No, it's not just word-play. There are real restrictions coming with source-available code if you want to use it in your business operations. One of the reasons companies express so much interest in open-source is to have no obligations before the vendor (support contracts that cannot be terminated early even if the software is being removed, licensing that makes it hard to migrate from a few large machines to many smaller containers/VMs, other forms of lock-in) and take a risk of an open-source software going unmaintained (that they usually plan to mitigate by hiring an outsourcing firm to fix the abandoned OSS projects).

Now, that is one of the main reasons why non-OSS licenses are being adopted: many companies prepare contingencies in case an OSS project dies, instead of making some arrangements to help a bit to ensure the project doesn't die. However right the vendors are, the resulting license significantly (materially, non-word-playfully) restricts the users, which is exactly why those users are compelled to start paying for the product.

P.S. None of what I wrote means I oppose those licenses, as they may be needed to ensure a healthy ecosystem. But I oppose calling them OSS.

Before this moment, I had referred to it as “transparent source” — you can look, but cannot touch.

But that's not at all what the ELv2, SSPL, or BSL licenses say. At many times, they're more permissive than GPL.

Reply on news.ycombinator.com