Yes, but also stop them contributing in any way what so ever, including diligently upstreaming.

AGPL throws the community baby out with the bathwater.

Seems to be working okay for Mastodon.

Yikes, thanks for the warning.

It's working OK, but honestly that may be because 1) most people don't care about licensing, even the difference between public domain, AGPL, BSD, or GPL, or frankly shareware, or even pirated; and 2) they're running from twitter so they have to go somewhere.

It may have been bit much to say "baby with bathwater", but to fix the analogy maybe I can say "Throw the baby out with the bathwater, but it's fine because you have another baby, and half as many babies ain't too bad. At least it's not zero.".

The thing that prevents them from contributing is the license that would require them to contribute?

> The thing that prevents them from contributing is the license that would require them to contribute?

Yes. Because the way it which it mandates upstreaming means that it creates a huge liability and unclear exactly what is in scope of the mandated contributing.

E.g. real lawyers looking at it have said that if you build a web app, and it uses mongodb (AGPL) to store some state, then you may need to opensource your web app.

It's not even clear if the AGPL software needs to be in the serving path. Maybe your billing pipeline uses mongodb, and now you have to opensource your frontend?

The counter argument from AGPL proponents I've seen is almost always "Good. They should need to opensource everything on their servers. I should be able to spin up exactly what they run, on my own servers".

Even a narrower interpretation that only in-scopes your patch to make mongodb work with your in-house SSO means you need to opensource things that you don't necessarily even own.

Again, the answer from proponents is "Good, all in-house SSO should die".

The AGPL and GPL in no way mandate upstreaming, they mandate downstreaming to end-users. It is only via a culture of valuing upstreaming and or the maintenance burden of non-upstreamed changes that upstreaming happens.

A distinction without a difference for the problem with AGPL.

Sure, just correcting a factual issue in your comment.

Edit: although, I disagree AGPL is problematic, see my other comment.

I note that MongoDB is no longer AGPL, it is SSPL now, which expands the scope of the AGPL to the entire service:

https://en.wikipedia.org/wiki/MongoDB https://en.wikipedia.org/wiki/Server_Side_Public_License

If you don't modify the AGPL software, you have no obligations under AGPL at all. The extra network provisions only trigger for modified versions of the software. I would wager most companies don't modify their database software. Even those that do, don't let end users interact with that database, so should have no obligations either.

https://www.gnu.org/licenses/agpl-3.0.html

So says you, but not actual lawyers.

AGPL is not LGPL, so is the client library of a client/server thing enough to infect you? Probably.

If there is no client library, what's the license on the example code that you used in your app?

Actually the license says that, I just read it.

Not sure how an Ethernet PHY is part of a proprietary SaaS. Or how “must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version” applies to a PHY.

No, companies that abuse license agreements won't care about AGPL anyway. So the license only makes it impossible for the companies that don't want to abuse your work, but play ball and work with you.

The issue here is liability and what the lawyers counseling a company will recommend. If your design contain IP that the company has valued (very common), risking leakage of that IP by using a library that in legalese seems to suggest that you may have to release your design, you can probably bet that the lawyers will recommend to find another technical solution. Protecting business value and avoid exposure, liability drives conservatism. And in my experience will always triumph over technology choice. Esp if there seems to be a possible choice to be made. Including developing your own solution.

As an open source HW creator I have to decide if I develop stuff for my own amusement, or if I do it to (in somehow small way) help the world - which means other using my creations. And then consider if the license I use support that goal. Since I don't just develop stuff for my own amusement I've decided to use a permissive license since I think that makes it easiest for others to use my stuff.

https://github.com/secworks

Judging by the number of downloads, messages and additional work I've gotten, it seems to work out pretty ok.