[benatkin]

I'll respond to the little part where it puts using a "non-OSI approved license" under the umbrella of open source. It's not OSI approved because it isn't open source, as the community defined it long ago, and as it still makes sense for it to be defined. If you want me to agree with you, don't do that.

Otherwise, I don't feel compelled to consider a bunch of disparate things as a Win. Here's one that could be more of a trap than a win, depending on the particulars of the job: "Employed by Microsoft to work on Python?" Look no further than https://ghuntley.com/fracture/

[lolinder]

He anticipated your comment and already replied. You're free to disagree with him, but he clearly thought that part through already and already knows he disagrees with you and with the OSI. This entire post is his justification for his disagreement, while all you have is an appeal to the OSI definition that he's specifically rejecting.

> “open source” / “free software”

> Note the deliberate use of lower case. I’m not referring to Open Source™ as defined by OSI, nor to Free Software™ as defined by the FSF. I mean these terms in the broadest, most inclusive sense: “software with source code that I can read and modify and release variants of, perhaps under some conditions.” So I’m including OSI and FSF licenses, but also the Polyform licenses and the JSON license and, yes BSL in my version of “open source”.

> This is perhaps a side point, but the “minimalist” definition of Open Source meaning “only OSI-approved licenses” – or, worse, “the GPL is the only ’true’ Free Software license” – is part of the problem here. I want to see more experimentation and variety in licensing options, and if that means introducing some additional restrictions beyond “anyone can use this for any purpose” I’m pretty okay with that. In my book, a broad spectrum of licenses from Blue Oak to BSL (and even more restrictive) “count” as open source.

> ... I’ll put it this way: if my sloppy use of these terms bothers you in the context of talking about how people make their living, it implies that you care more about terminology and definitions than about the people, and I’d like you to sit in that discomfort for a while.

[benatkin]

I used lower case deliberately as well.

It's a term that excludes source available not just because of OSI but because of the original community. And members of the current community can argue for a new, weaker, openwashed meaning of it, but people can always look back to the early days and see the true meaning of it.

[lolinder]

What "original community" are you referring to here? Are we talking about the free software movement that Richard Stallman founded, or the Open Source Initiative that forked off of the movement in an effort to be more friendly to businesses?

It's a bit ironic that people now wax lyrical about the "true meaning" of Open Source when the OSI described their origin like this (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. "Open source", contributed by Chris Peterson, was the best thing they came up with.

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

[benatkin]

> What "original community" are you referring to here?

It's a big community with a wide range of perspectives, but not so big that it can't be understood. To me the original community was mostly over a decade or two. This is similar to other communities such as a burgeoning genre of music. Whatever it was, it was established long before the words "Business Source License" were uttered. The first date range that comes to mind is 1993 to 2003 if it's one decade, or 1990 to 2010 if it's two decades. With the smaller range, you have the development of Linux, and the way Linux took over servers. With the larger range, there is Firefox taking on IE, as well as WordPress, Django, and Ruby on Rails becoming popular.

Even people who tried to fight it understand it. That is why before the deliberately misleading strategy being used now, some who wanted to promote code that could be read but couldn't freely be used settled for calling source available.

[lolinder]

Again, though—you're fighting for the moral integrity of a term that was explicitly coined to try to buck the moralizing that was associated with the Free Software movement and make the new concept of Open Source more appealing to corporations.

The BSL isn't the first sign of the bastardization of the ideal behind Linux. The bastardization started as soon as the OSI decided that they needed to appeal to corporations, and in condemning the BSL the OSI is just following the same business-friendly playbook they've held to all along.

Don't get me wrong, I'm glad that the OSI provided a watered-down version of free software that got us to where we are today. I just disapprove of the moralizing that surrounds them when they were explicitly founded on pragmatism.

[palata]

> condemning the BSL

Are they "condemning" the BSL by saying "it is bad, don't use it", or are they just saying "BSL is not open source"?

Because my understanding is that BSL is not open source. Rather it is a commitment of becoming open source (GPLv2) at a point later (maximum 4 years). So BSL is effectively source available until GPLv2 is added. Which does not make BSL open source: GPLv2 is.

[cratermoon]

By picking his own definition of what open source means, is the author really arguing for paying people to work on open source? Or is his argument more one of being in favor allowing a bunch of things that happen to pay people to work on them be counted as "open source"?

For example, if RHEL still counts as open source, then Red Hat's programmers are paid open source developers, but if RHEL is now proprietary, then there are fewer people being paid to work on open source.

[cipherboy]

Even with the changes to RHEL licensing, Red Hat developers are still encouraged to upstream changes before landing them in Fedora (and in turn, before landing them in CentOS stream and ultimately RHEL). Nearly every developer at Red Hat working on RHEL will do work in the public, on OSI-licensed packages upstream, before landing changes in RHEL.

The change to RHEL licenses is not around source availability of the packages themselves, that has not and cannot change by Red Hat's hand. And it is a risk to Red Hat's business to heavily (internally) diverge packages from upstream as it makes future updates harder.

Is it a good move? Many think not. But that doesn't change the vast amount of upstream (OSI-licensed) work that Red Hat directly or indirectly sponsors, past RHEL into their JBoss and OpenShift orgs as well.

[cratermoon]

This is mostly irrelevant to my question. I wasn't speculating about RHEL specifically, but about source available under non-OSI, non-FSF licenses generally.

If what counts as "open source" can be anything the author says counts, there are potentially lots of projects not previously considered open source, and the developers paid to work on them as "paid open source" developers.

[cipherboy]

I don't see how it is irrelevant: you ask if they still count, and the answer is yes, because they contribute rather heavily to OSI-approved code, so they'd count regardless.

The real question is, would we consider MongoDB or my former employer, HashiCorp's products, presently open source projects?

In the latter's case, the answer from the community at large has been to fork (edit: not always successfully), giving a fairly good indication as to the answer...

(Whether this is as a result of the act of relicensing the code base or as a result of the license choice probably cannot be fully understood without parallel universes... I'm sure someone would complain and potentially fork if they had relicensed, e.g., from MPLv2 to AGPLv3--another OSI license, but a more restrictive one--though probably nobody would care enough to fork if they had suggested e.g., MIT instead, because the MIT is more permissive.)

However, developer categorization into OSI/non-OSI buckets is rather meaningless.

What we've by and large found is that Linux businesses (regardless of license model, even fully proprietary) can usually find funding, due to the large number of companies willing to pay for support & contract development on it. Many more businesses have been successful here: vendors like RH, Canonical, SUSE, Oracle, and even Microsoft and AWS, but also many smaller vendors & independent developers who make smaller livings and profits.

What's been harder has been the non-Linux Open Source/Free Software business model.

And that's what needs to be solved, one way or another. Perhaps that's committing up front to a license (if you want to use the BUSL, so be it, but don't expect the community to be happy if you do so after your project becomes successful).

But more likely, its by raising awareness and making sure people at the top of the organization (board members, shareholders) understand the value of OSI licenses and how their companies can benefit from it. And on the flip side, how changing the terms of contracts afterwards can cause problems. :-)

[richardfontana]

There were no changes to RHEL licensing whatsoever.

[cipherboy]

I agree.

I think what OP is talking about is change in the (for rebuilders) source distribution availability, e.g., https://www.redhat.com/en/blog/furthering-evolution-centos-s... -- but as a later blog post points out (https://www.redhat.com/en/blog/red-hats-commitment-open-sour...), the source is still available in a different location, though perhaps at a slightly different point in the release cycle: forward looking to RHEL next.

My response is in that context, that even if one were to consider the removal of those source locations somehow a "license change" (and I agree with you, it is not), nearly everyone working on RHEL would still be an OSI developer, for reasons pointed out by Mike.

Which is a very good thing, and as a former Red Hatter, thank you for helping to keep that possible Richard!

[sanderjd]

I think this is a pretty good microcosm of the whole debate in this one sentence where you say:

> It's not OSI approved because it isn't open source, ...

> ... as the community defined it long ago, ...

Yep, definitely! Nobody disagrees that the OSI defined this long ago.

> ... and as it still makes sense for it to be defined.

Maybe! But that's where the debate is. Is that the most sensible definition? Perhaps, even probably, yes. But it's also a totally valid question to interrogate. And that's what people are doing.

[benatkin]

The debate would be for a new meaning of the term open source, which has already been established. People can create a new meaning but it doesn't change the original meaning of it, which I like to call the true meaning.

The license is far from being the only thing about open source. What makes open source what it is are its triumphs, such as the popularity of Linux and how many developers prefer open source tools and platforms. However, using a license like the Business Source License indicates a lack of belief in the vision of open source, and a need to exert control.

[mixologic]

> What makes open source what it is are its triumphs

If you define triumphs to include only 'popularity' and developer preferences, then sure, its triumphant.

> using a license like the Business Source License indicates a lack of belief in the vision of open source

The issue is that the vision of open source itself is lacking, because it doesn't recognize that it fails to provide a pathway to being compensated and rewarded, tangibly, for building, contributing, and maintaining open source software and the infrastructure that supports it.

[benatkin]

Popularity is absolutely part of the triumphs I had in mind. It is often a very good thing in open source. It meant Internet Explorer 6 being less popular, as well as Windows on servers.

As far as the pathway to being compensated and rewarded - I want the community to be compensated and rewarded, not just those that started the project. We've seen this play out with ElasticSearch and OpenSearch, as well as Hashicorp. Even Sentry has an alternative https://glitchtip.com/

[sanderjd]

> The debate would be for a new meaning of the term open source, which has already been established.

Yes, that's what I'm saying, that people are interrogating whether that (inarguably) already established (arguably) "true meaning" is a good one.

I'm certainly sympathetic to the frustration people feel at new debates popping up over definitions that they feel are already perfectly good. But it's not up to you or anyone else individually; the way people use language broadly evolves all the time. It's useful to advocate for why the existing definition you prefer is the right one, but less useful to primarily focus on "we already have a definition of this, that's the only thing it could ever possibly mean!".

[ZoomZoomZoom]

> popularity of Linux

You surely meant to say it's a triumph of Free Software? /s

[tzs]

> I'll respond to the little part where it puts using a "non-OSI approved license" under the umbrella of open source. It's not OSI approved because it isn't open source, as the community defined it long ago, and as it still makes sense for it to be defined

So what would you call a license that meets OSI's open source definition [1] but has not been OSI-approved?

OSI no longer approves new licenses unless they think the new license fills a gap that is not filled by existing OSI-approved licenses, which means there are millions of possible new licenses that meet every criteria of their open source definition but will become OSI-approved.

[1] https://opensource.org/osd/

[em-bee]

So what would you call a license that meets OSI's open source definition [1] but has not been OSI-approved?

arrogant, as in: do you really believe that your project is so different that one of the existing approved licenses will not do? (addressed to the hypothetical project with such a license)

i mean, i am with bruce perens who believes that we need to rethink licenses completely to address many problems that have come up recently: https://news.ycombinator.com/item?id=38783500 and i guess this article does hints at some of the problems that need to be addressed. but coming up with a license that is in the spirit of FOSS and yet solves some of these problems is a non-trivial task that i do not believe an average developer or company is capable of by themselves, therefore it is very unlikely that your non-approved license is really worth it.

by all means please participate in the process of developing a new license, but do not actually use such a non-approved license until there is a broader consensus that this new license actually is worth it. otherwise it's just making things complicated for no good reason.

[tzs]

> do you really believe that your project is so different that one of the existing approved licenses will not do? (addressed to the hypothetical project with such a license)

Actually, I think it would be pretty easy to have a project for which none of the existing OSI approved licenses will do without even being all that different, ever since OSI approved AGPLv3.

AGPLv3 contains a distribution requirement that triggers for your program if you have users who are "interacting with it remotely through a computer network".

Now all it takes is wanting a license similar to that, but with the trigger being different. Maybe a project agrees with AGPLv3 that if you run their program on your server you should have to give the users source, but wants that to also apply to users who are interacting with it locally on a computer network, or are interacting via some method other than a "computer network" such as serial terminals.

[franga2000]

I love the AGPL, but even that has some holes. One classic case is a "backend service", which the user doesn't ever directly interact with, but is used by the application backend to provide the user service. Like if I modify an AGPL geocoding microservice, which is used by my backend to plan a trip to show the user, do I need to release the source? What if it's not displayed to the user at all and is just a small part of another calculation that is (like predicting bus arrival times)? What about an AGPL database or cache server? And if backend services don't count, are the users not interacting only with the reverse proxy and everything else is a backend service?

[em-bee]

yes, it is easy to come up with a change that seems to make sense. but it is not at all easy to vet that change legally. and no: "we have talked to our lawyers about this" is not enough. your lawyers operate in your interest. they are not operating in the interest of the Free Software or Open Source definitions. the bar for a license that would be acceptable to OSI is much much higher. and my claim that it is not easy to come up with a new license is based on that.