Hacker News Reader

Comment by morgante | Hacker News Reader

"Source-available but not strictly OSS" is, in most cases, not really giving anything of value to the community. You are not free to use it in building your own solutions. At best, it allows easier collaboration with customers.

Open core absolutely is open source. There's a clear and valuable open source core that others can build on to build their own products.

This isn't just hypothetical. As far as I know, no source-available license allows you to actually use it to build your own product. While VS Code has many other products built on the core (including products that lawyers have reviewed closely for compliance).

View on HN

> You are not free to use it in building your own solutions

Tell that to the LLMs.

A program that allows me to freely use and modify it as long as I’m not a multi-billion-dollar corporation is much more useful to me than a program which allows anyone to use and modify a part of it.

> Open core absolutely is open source. There's a clear and valuable open source core that others can build on to build their own products.

Depending on where the line is drawn. How functional the "core" in a real life scenario is. Often companies use some "enterprise security" features as closed thing, like saml/oauth/... where one could argue those should be default state of things these days.

vscode is seemingly on the right side of the line, considering all the places where monaco and oss vscode has been used.

With licenses like Elastic I agree 100%, but what about delayed licenses like BUSL or FSL?

There are several complications; see here: https://lwn.net/Articles/984249/.

For example, if the copyright holder applies a security fix to an old version that had "expired" and is now open source, will that cause old version to revert to source-available? Does any security fix, even the simplest one, require clean room reverse engineering on part of the community? Unless these questions are answered clearly by the copyright holder, BUSL/FSL are not really usable as open source even after the expiration date.

> For example, if the copyright holder applies a security fix to an old version that had "expired" and is now open source, will that cause old version to revert to source-available?

Yeah, it’s tricky. By default, I think it does go back to source-available, but I would trust the vendor to explicitly release the fix as open source instead. Of course, it should be addressed in future versions of such licenses, and in the meanwhile vendors should promise to not hold security updates out.

It’s not something exclusive to delayed licenses though: vendor of a permissively licensed software can make a security fix under a proprietary license. They don’t do this because it would be a dick move and the community will fork the software, but this is a possibility.

Never "trust" a vendor to do something in your best interest for free. That's like trusting your landlord not to raise your rent.

Reply on news.ycombinator.com