[jchw]

For the most part I don't think people are against shared source or closed software existing, being sold, being marketed, etc. There's really only two things people viscerally don't like:

- Marketing a project that isn't open source as open source. Debate about what the "definition" is or why it matters all you want; taking a term and using it in a way that contradicts the vast majority of domain experts is bullshit.

- Taking an open source project, which people adopted on the basis that it was open source, which people contributed issues and pull requests to on the basis that it was open source, which people evangelized and promoted because it was open source, blogged about, built on, and so forth because it was open source... and moving it to a license that isn't open source.

To be clear: yes, the unforced error here in many cases is accepting a CLA. That said, I think it's not even unreasonable that people initially accepted CLAs: many of them presumably believed they would only ever be used in good faith, as a sort-of CYA. But CLAs are now very commonplace, so refusing to contribute to any project with a CLA requirement is hard.

If nobody cared about the benefits of open source, then it would be easier for companies to just start with a closed or shared source offering and call it a day; not much backlash for not changing a license. Clearly, marketing something as open source helps... but once you've gotten what you need out of it, it's easy enough to click a button and change it back to being closed.

In my opinion the big advantage of open source is that everyone is on a level playing field. This isn't "fair", it's balanced, and that matters if you are serious about long-term software. If shared-source software is discontinued, that's probably the end of the road for it. For open source software, it only depends on if there are big enough stakeholders to keep funding development; it never has to stop.

There's ideas like BUSL, which might work better... but it's still awkward and experimental. I don't put much stock into any of the other "shared sorta-like-open source" licenses, they're mostly bullshit and sometimes catastrophically horrible, i.e. much worse than AGPL.

[prmoustache]

BUSL is the worse of both world imho. People are not willing to send patch or contribute to something that is not yet open source and vendor thus does not get any benefit of having openly readable sources.

[ensignavenger]

I would rather a software product be eventually open source than use a never open source license, but I still try not to use it if I can choose open source. And I refuse to sign CLA's that require giving more eights than the license grants to me, and won't sponsor projects that require them. (with some limited, carefully considered exceptions for well established open source foundations that require CLAs, but that have sufficient gornance to add trust)

[oddevan]

Out of curiosity (since I'm pursuing an AGPL/proprietary dual-license), how would you consider a CLA that explicitly tied my right to sell the proprietary license to releasing under the AGPL?

> Smolblog shall be entitled to make Your Contributions available under a proprietary license provided Smolblog also makes Your Contributions available to the public under the terms of the GNU Affero General Public License version 3 or later.

[ensignavenger]

That gives you more rights than it gives me. I was always free to release my patch under the AGPL, why would I need you to do it? (well, if you do it I wouldn't have to maintain a fork, which is something I will admit).

It would allow you to maintain a proprietary product with proprietary features that you don't release under the AGPL and use my code within that product.

I like reciprical licenses, if I get code from you under the MIT license, I will give you code back under the MIT license (which you can use however you want to, under that license, just like I can.) On the other hand if you give me your code under the AGPLv3, I give you back code under the AGPLv3 (and you can take it or leave it, so long as if you take it, it is under the terms of the AGPLv3 license).

At least, that is my idealist stance. But in reality, practicality sometimes takes precedence, so I might make a minor bugfix or something. But then I have all the trouble of reading the CLA, making sure I understand it, and agreeing to it, so practicality may just as likely lead me to just file an issue instead and patch my own copy.

[oddevan]

Totally fair, thanks for responding!

> It would allow you to maintain a proprietary product with proprietary features that you don't release under the AGPL and use my code within that product.

As much as I can say "everything in my version is AGPL; this is just for _other_ companies" I don't know that there's a way to _legally_ guarantee it that wouldn't be easily circumventable, at least not without rendering the idea useless in one way or another.

So yeah, thanks for the insight, I really appreciate it!

[ensignavenger]

Yeah, I thought about that, and unless you form a nonprofit with explicit governance requiring the release to all code, and the CLA is to the nonprofit, it would be difficult to guarantee. Even the nonprofit route isn't a guarantee, which is why I would evaluate each organization separately for their history and governance. It would likely take some time for a new organization to develop the reputation.

[sanderjd]

I think you make good points here, but it's also annoying that the words "open source" are defined to mean something a lot more specifically detailed than what the words themselves intuitively mean.

For instance, your post calls things "shared source", which, to me, is a lot less clear of a description for the projects you're describing that way. ("Shared" how? Shared ownership? Or what?)

I think "source available" is intuitive and fine (and better than "shared source"), but to me it's still a bit weirder. To me, it sounds like if you send the company an email, they might send you back a zip file with a bunch of source code. But most of these "source available" projects operate just like any other open source project.

But I'm also not unsympathetic to your arguments here at all.

[bad_user]

"Shared source" comes from Microsoft's initiative, back in Ballmer's days when they were attacking Linux with FUD campaigns and patent threats (which continued well after their "Microsoft changed" marketing campaign).

https://en.wikipedia.org/wiki/Shared_Source_Initiative

The software industry called their initiative for what it is. Whether it's "shared source" or "source available", it's a poisoned gift. In the case of Microsoft's shared sources, this was because it was opening up readers of that source to the possibility of patents lawsuits. I remember for instance that Microsoft was making more money from Android, by threatening phone makers with patents, than they did from Windows Mobile.

[jchw]

> I think you make good points here, but it's also annoying that the words "open source" are defined to mean something a lot more specifically detailed than what the words themselves intuitively mean.

I have flipped and flopped back and forth on this, but nowadays I think it is worth reconsidering. I think the term "open source" is probably fine and it would be better to actually just double down on it. I'm not sure it could be much better than it is.

What you are saying is largely true: open source is defined to mean much more than what the two-word phrase actually implies intuitively. Fair point, and a common point of contention.

However, that's actually true of lots of domain-specific jargon in general. After all, language doesn't always have a succinct way to intuitively define specific concepts. It evolved naturally over time and surely largely out of necessity to be able to communicate effectively. Every language has blindspots, as well as oddly specific terms you wouldn't expect, like the perennially-cited Japanese term 「青木まりこ現象」(aoki marikogenshō) for the urge to defecate shortly after entering a book store.

When it comes to domain-specific terms, I think we have to accept that the there will sometimes be things where the layperson simply cannot intuitively understand the jargon no matter how its phrased. There's certainly not two words that can accurately explain what it means for something to be "open source" or "free software" according to the champions of said phrases. I mean, take for example, how many words Open Source Initiative has to spend on accurately defining it themselves[1]. Certainly it could be more terse, but no matter how you shake it there's just a lot of detail there.

So what happens is that jargon gets invented where if you know, you know. Sometimes jargon is just bullshit that could be replaced with much more obvious English, but I think often it really is just a lot of domain-specific stuff that can't be described sufficiently with short, simple phrases, so it winds up being bundled into less specific phrases. Does everyone really know what an "operating system" is? I'm not even sure if many computer scientists will agree on a definition for it. Yet, most people agree on which things are and are not operating systems somehow, and it remains an immensely useful term to describe a class of software that virtually everyone, including laypeople, often have a need to describe.

In that regard, I think "open-source software" is about as good as it possibly could be. As far as I could find when researching the topic, it was essentially a completely unused phrase before it was coined, and the people who coined it were very deliberate about giving it a very specific definition and tying it to a very specific movement; and most importantly, they defined rigorously what it was not, which wound up being very important.

I mean, we could call it something else, to be fair, like "free/libre and open-source software" or what have you, but the issue is that open-source is so well-known that it's somewhat understood by people with very little domain knowledge in software. I think the term open source has "stuck". It is true that not everyone really grasps what it means, but I think a lot of people, even if they couldn't define exactly what it means, sort of "get it" anyways. I think that many people who are not software developers have an intuitive understanding for the mutually beneficial nature of open-source software. Don't get me wrong, it's very clear that many people also do not: those people make themselves known in many ways, like being abusive on GitHub issue trackers.

I don't think we can get much more people to understand what open-source software actually is, at least not by force, so I think the better play is to defend the term we have. It's also totally fine, of course, if people want to use "expanded" terms like, again, "free/libre and open-source software", just to make it completely clear what they mean, but I suspect it's just too long and cumbersome to ever catch on the way the term open source itself has, and letting that term get diluted is a loss that will lead to confusion and manipulative behavior.

> For instance, your post calls things "shared source", which, to me, is a lot less clear of a description for the projects you're describing that way. ("Shared" how? Shared ownership? Or what?)

> I think "source available" is intuitive and fine (and better than "shared source"), but to me it's still a bit weirder. To me, it sounds like if you send the company an email, they might send you back a zip file with a bunch of source code. But most of these "source available" projects operate just like any other open source project.

To be honest, I only really use "shared source" because it feels like an analog to "open source". I have no particularly strong attachment to it and would be happy to call it "source available" or anything else. I do have roughly the same feelings though. "Source available" would be a strictly better term overall but I think this all suffers from the same problem that "open source" does: boiling a concept like this down to two words will never be perfect.

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