Hacker News new | ask | show | jobs
by lolinder 857 days ago
This is as good a context as any to remind people of the origins of the Open Source Initiative and its definitions. Here's how the OSI described its history on its website in 2007 (emphasis added):

> The conferees decided it was time to dump the moralizing and confrontational attitude that had been associated with "free software" in the past and sell the idea strictly on the same pragmatic, business-case grounds that had motivated Netscape. They brainstormed about tactics and a new label. ... A month later ... the participants voted to promote the use of the term 'open source', and agreed to adopt with it the new rhetoric of pragmatism and market-friendliness that Raymond had been developing.

I find it a bit amusing that here we are, decades later, and people who use non-OSI licenses to try to thwart exploitation by enormous corporations are condemned on highly moralistic grounds for not being "truly open source".

http://web.archive.org/web/20071115150105/https://opensource...

1 comments

Even businesses care about the distinction between OSI-approved and SSPL/BUSL licensed code bases. In the latter, they often cannot host services that use BUSL licensed code which puts risks on the business. Some examples:

Do they need to consult with a lawyer to understand if their particular use case is acceptable?

If not now, then how do they know when that threshold is met?

When the service is offered for revenue?

Or only when offered directly to customers?

What about if theirs is a consulting-structured business e.g., IBM or Collins, where any internally service provided to another team is billed and paid for internal to the company (even though its not paid for by an external customer)?

Can they hire developers to contribute to the code when the upstream is unresponsive to their bugs/features? Or, if they have to integrate with other custom internal infrastructure/tooling? Are they free to remix these tools into larger projects of theirs?

It is possible to separate the moralizing aspects of these licenses and articulate concerns strictly in business cases that make them unsuitable for OSI and thus not "open source" in spirit.