> counterpoint: At the end of the day, I want people to use my stuff, but not grab and run with it, claiming ownership of it, depriving future users of the freedoms in exchange for improvements.

If your stuff is complex enough, then it should be easy to outcompete any improvements made by organizations. SQLite, for example, has multiple proprietary tests [1]. Corporations can try to improve on SQLite, but without these tests and the knowledge of Richard Hipp on their side, it will most likely fail.

[1]: https://www.sqlite.org/testing.html

“SQLite is a successful open source project thanks to the fact that a significant chunk of development infrastructure isn’t open source” isn’t a great argument regarding the sustainability of open source… If Richard gets hit by a bus, and the community tries to keep the project alive according to free and open-source principles, then they’re going to face all the same barriers that a corporation would :/

> “SQLite is a successful open source project thanks to the fact that a significant chunk of development infrastructure isn’t open source” isn’t a great argument regarding the sustainability of open source…

To maintain open source over a long period of time, some durable competitive advantage is probably required yes. With such a moat, competitors can be beaten. Luckily, being open source is also a small moat since it avoids vendor lock-in and some businesses need vendor lock-in to survive (I'm looking at your SAP).

> If Richard gets hit by a bus, and the community tries to keep the project alive according to free and open-source principles, then they’re going to face all the same barriers that a corporation would :/

The project sits inside Richard's company and the company has some other engineers working there.

They are using this infrastructure as the moat. ReadTheDocs is also doing the same thing.

Deploy if you dare: https://github.com/readthedocs/readthedocs.org

Parent and you have different goals so you pick different licenses. There is nothing inherently wrong in both positions.

Personally I go the (A)GPL way all the time.

> Parent and you have different goals so you pick different licenses.

Yes.

> There is nothing inherently wrong in both positions.

Also, yes.

Hope more people understand this clearly.

> Personally I go the (A)GPL way all the time.

Me, too.

MIT doesn't allow no corporate to claim ownership on your software, much unlike open-core GNU licenses that promote CLA-s and thwart any competition.

> MIT doesn't allow no corporate to claim ownership on your software,

Nor requires them to give anything back.

Putting your code in MIT license is basically slogan "take all of it and give nothing back". Which is why so many corporate developers push for it, no lawyer to talk to when you take MIT-licensed code to use in your project.

> much unlike open-core GNU licenses that promote CLA-s and thwart any competition.

There are no "open core GNU licenses". It is just perversion of the idea and abusing the fact some of them are not restrictive enough that you can still have paid parts that are closed source

> [MIT] Nor requires them to give anything back.

The copyleft licenses don't require to give anything back either, they only require to give source code forward to downstream users, who may or may not contribute back upstream to the original project.

So they require to give something back to the users of the software

I'd call that giving something forward rather than back, like the "pay it forward" movement:

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

They will do a fancy wrapper and no credits will be given though. Users will never see MyApp only the MyAppFancyCloudVersion

That would be breaking the terms of the license. Could've as well just taken some AGPL-licensed code and not release the source.

Who will really know?

Most commercial products just write some useless statement like "this software may use open source components" or include a generic MIT license without the original copyright holder statement inside.

Who is telling these companies they are doing it wrong?

Very rare when someone ever does.

Ever seen the android about info? It has licenses and copyright information for a loooooong list of android's components.

Yes, reviewed it professionally. Despite their effort, can tell you that it is still incomplete and innacurate.

These kind of things take several months of efforts by deep expert, when it is done by normal open source developers who think they know about licenses and compliance, it tends to result in poor results even if the output looks "big" from a surface view.

The issue is not credits (well, companies tend to forget doing this, too), but contribution of the improvements made to the base.

xGPL family of licenses force contribution back of improvements, and rightfully, it's not about developer freedom, but user freedom.

The copyleft licenses don't require to give anything back, they only require to give source code forward to downstream users, who may or may not contribute back upstream to the original project.

At least, you keep the source code in the open, and the changes stay in the open. It's giving enough, when compared to BSD/MIT and similar "permissive" licenses to fork away without making anything available.

No, the changes don't have to stay in the open, they only have to get given to your downstream users, not publicly in the open and not back to the upstream project. You can definitely fork a GPL project without making anything public, although your users can choose to make the modified code that you send to them public, but they might not ask for it or might not publish it if they do get it.