I actually prefer the approach of LF, EF or CNCF where it's transparent where folks work for and your affiliation is disclosed upfront. In the CNCF for example, we separate out technical project decisions (maintainers) from funding decisions (members). That is healthier than blending it all in one at the ASF imho and having no idea where person is working for imho.

And when was Apache more popular? I thought it was the uncool place where stuff was written in Java, that became popular because people's conception of Java (and the language/ecosystem itself) changed.

In my opinion, Stallman has been proven right many times over.

Richard Stallman himself doesn't seem to make money from any software he made directly, but from various grants and such, for example:

https://web.archive.org/web/20220123032418/http://tech.mit.e...

I thought he was on the payroll for FSF, but his reportable compensation has been zero from 2002 to 2022 according to:

https://www.fsf.org/about/financial

It will be even worse after the GPL developer generation is gone.

Many CLAs are just a hassle (basically, DCO that has to be reviewed by the legal department). But a lot are asymmetrical in a substantial way and the original developer gets to play by different rules than the rest. CLAs in the second category tend to be problematic.

Even that is not a completely clear indicator because in some cases, the asymmetry is only intended to help with potential future relicensing in alignment with the project's goals, and not to enable commercialization (either today or at some point in the future). Some organizations have resisted direct commercialization of the code they have been entrusted with for decades, so that can happen even with an asymmetrical CLA.

For many contributors, they're ok giving full ownership of their contributions to a project owner on the owner's terms. Some contributors may not be ok with that of course, but it doesn't mean that every project owner has nefarious plans with said code ownership.

CLA = Contributor License Agreement

Good examples are React from Facebook, and TypeScript from Microsoft. Both require a CLA. But these projects are never going to go closed-source. They are complements to the companies' core business strategies.

There's this balance between being a project forever run out of someone's garage and actually growing into a larger and more used system. I'd say the line is dilineated by many factors: who is the project's primary user? Enterprise? Devs? How much money is changing hands? What's the business model? Is there investment involved? How restrictive is the primary license? How restrictive is the CLA?

I think any open-source project that has aspirations to actually make money for the creators is shooting themselves in the foot without a CLA. And it's fine to judge them for this, but we live in a system where people have to extract value out of this shit even if it's against their ethos.

If people truly and ultimately believe in open-source, then the most logical conclusion is that capitalism does not allow for open source and that must be changed. Fighting things at the license level can only delay the inevitable. But people want to have their cake and eat it too: "I want the system to stay the same AND I want open-source creators to keep pumping out stuff for free forever."

Many things would have to be re-added from scratch in a fork.

If cone entity does the development, they can change direction or licensing and it is hard for anyone to fork.

If you have more of a bazaar form of development with many contributors neither is as easy (even less so if you do not have a CLA). Even if you have a small core team of developers, a really bad direction is likely to lead to a split.

Yes, that’s right!

> But BSL doesn't disqualify software from being open source.

No, that’s wrong: https://spdx.org/licenses/BUSL-1.1.html

> The Business Source License […] is not an Open Source license.

One good way of looking at the goals of open source licenses is to force companies to compete on offering services related to the code. Whether this is a sustainable idea is a different question, but this is one of the bedrock ideas about OSS (and FLOSS as well). The other is of course that the rights of those running the software are absolute and trump any rights that the original creators have, except where the users would try to prevent other users from gaining the same rights.

I agree it’s a reasonable license. But it’s not an open source license.

— The Business Source License

https://mariadb.com/bsl11/

The AGPL is absolutely viable in commercial contexts. There are a handful of companies that have hangups about it, but the industry overall has long since realized that it is almost identical to the GPL for most practical purposes.

As far as I know, this is case for most GNU projects.

Linux only requires a confirmation that you wrote the patch; previous poster was mistaken about that, but they were correct about GNU.

Ironically, CLAs like the one Google and Meta use for their projects on GitHub do not require ownership transfer -- only the rights to redistribute, because the prevailing Lawyer-brain belief is (roughly, to my understanding) that just assuming that right from the license itself isn't necessarily sound.

For licenses like Apache 2.0, assignment/ownership is a kind of irrelevant practical distinction because entities can just distribute proprietary versions anyway (and because it's not clear if you really agree to much more than e.g. Apache 2.0 implies), which is the prevailing worry people have. Most of the people here actually want GPL-style copyleft licenses along with some vague idea of a "communal project", even if they don't know it. Because that's the only way to achieve the practical desired outcome, where your code and contributions stay open and are difficult to "rework" in this way. The talk about CLAs and all the other stuff is irrelevant; it's a matter of the politics and composition of the project, not the exact legal words in the license.

> everyone that contributed, even if it's just a 1 line change

That depends on the jurisdiction. There is a concept called the "threshold of originality" in the US which states roughly that some obvious, trivial things just can't be copyrighted. Typofix patches that change "form" to "from" aren't meaningful enough to be given copyright, so you literally do not need to be consulted on the matter at all. It is not clear that simple bugfixes fit under this definition either for example, because they may be obvious. Realistically, I'd say there are very few contributions that are going to fit in 1 line while being original enough for copyright to apply. They could also just not include your patch too or rewrite it, in that case, so the "1 line" case is pretty much meaningless in practice.

https://github.com/apple/foundationdb

https://deno.com/blog/building-deno-kv

I just don't understand how for-profit company can develop true open source software. You can have a non profit foundation and a for profit support studio. Godot effectively does this.

Plus if you've taken VC money you can always get voted out in a few years. Or just have a nice exit. I wouldn't be mad at anyone for taking a large payday and retiring. But then the for profit company is free to change the license.

It feels more straightforward to use a proprietary or copy left license from the start. Your company exists to make money, and I think most of us can respect that. We just don't want to start building our projects off of open source software, that converts to some other license years down the road.

1. Company builds cool OSS and releases it to the world.

2. The product becomes stable, mature, and users are happy with its feature set. Development slows down.

3. Company starts having to make money so they relicense future code.

4. A few large users of the software (that company was hoping for $$$ from) realize that since it's mature and stable it's massively lower cost to just maintain the last OSS version.

5. At the time of the license chance the new OSS fork is identical to what everyone is already using and so it's the the least resistance migration.

6. The consortium of actual users of the software drive its future direction instead of the company.

I'm not mad about the cycle, it's the moment VC backed software gets turned over to the community. But I always wonder how it turns out for the companies in the long run.

And it makes sense (for Enterprise "tech stack" software). A license violator would just crack your software anyway and legitimate paying users pay for it and want less hassle.

You probably will save on some support calls if their engineers can take a quick look themselves.

Same goes for any "secret Sauce" in the Code. Most Software of that Type isn't algorithmically novel enough to warrant drm and obfuscation.

And again a serious criminal comoetitor would spend the money to reverse it

The issue here is that if you're an org with less than $10M turnover, you're currently on the Core plan and don't want to negotiate the full "Enterprise" licence (which is presumably priced towards larger users than you anyway), then you can't use the thing at all anymore unless you agree to telemetry and some vague disclosure of personal data thing that will get your lawyers in a spin (especially if you serve states in which GDPR applies).

EDIT: oh, and PCI-DSS requirements if you want to take credit cards? That's going to be fun.

This is why standard APIs, protocols, and languages are a more important thing than specific pieces of software. If there is compatibility you have choice.

It used to be Apache2. :)

Their blog post announcing this in 2019 happens to now 404:

https://www.cockroachlabs.com/blog/oss-relicensing-cockroach...

But see also: https://news.ycombinator.com/item?id=40058332.

if nobody forked it five years ago, they probably aren't going to fork it now

if somebody did fork it five years ago, they probably aren't going to try to merge in new source code drops as they convert to open source

Having different parts written in different languages is awful too, because it brings some micro improvements (if any) but makes project look complex and scary for many new-comers :(

The architecture is ingenious, though.

It's like saying "freedom".

reading this:

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

"the definition is the most common standard for open-source software."

It is not exclusive.

saying "open source" does not describe a license. It is a generic term.

And the point is that unless someone points to a standard or a license, they can call their software open source, just show you the source with restrictions and use ambiguity to do different things than expected.