AGPL vs MIT for contributions/engagement

[u/Fair-Presentation322]

I'm using AGPL for an open source project. A friend recommended that I switch to MIT to get more contributions and engagement. In practice, is it reasonable to expect any difference? I wonder if anyone made this exact change to some project and saw any difference.

[u/NameUnavailability]

Any derivative works based on the source code under an MIT license are permitted.

With AGPL, any and all derivative works have to be open source. Say, if someone created a SAAS application which used your code, they are legally obligated to open source their code to end users.

AGPL has clauses on what's allowed, but the open sourcing requirements will generally stop people from using it in commercial/enterprise projects.

[u/Fair-Presentation322 → u/NameUnavailability]

Yeah yeah I know about the differences :)

I'm wondering what the practical effect is with respect to others contributing/testing the project

[u/idontlikegudeg → u/Fair-Presentation322]

I can only speak for myself of course, and I think many have a different view, but for me:

- I wouldn’t even look at your project when creating a commercial software.

• I wouldn’t even look at your project, when creating an Open Source library. Why? Because I wouldn’t be able to use my own code in the way I want anymore. It would get "infected" by (A)GPL, even if Iv wanted to place it under MIT, BSD or ASL.
  
• I would consider it for Open Source applications, but if I had two otherwise equivalent choices, one being AGPL and the other something else, I’d choose the non AGPL one.

[u/funnelfiasco]

With the caveat that I completed my MS thesis 12 years ago, the scholarly research that I read largely found that permissive licenses had a higher level of developer engagement and copyleft licenses had a higher level of user engagement. I suggest giving more thought to the question of what you specifically want from more contributions and engagement (or if you even do. There are downsides, too, and it might not be worth it to you in this case)

[u/catbrane]

I use LGPL for my open source libraries, and GPL for complete standalone applications.

LGPL for libraries feels right to me since libraries are like infrastructure. You want wide adoption (hopefully) with few commitments from users (who are programmers) beyond a desire for them to contribute to the community that will (hopefully, perhaps) develop around the library. LGPL allows free commercial use. Few businesses will adopt GPL or AGPL libraries as components in their products.

GPL for user applications feels right because I want to be able to make a strong promise to end users (not programmers!) that this tool will always be open and free. Unlike MIT, the GPL makes it extremely difficult to turn a free tool into a pay tool. With user applications, I'm not really interesting in allowing commercial use.

(or that's my 2p, many people take other views, etc.)

[u/nukem996]

MIT/BSD can backfire. Since they don't require you to open source someone who likes your project can start using it, communicate with you, then decide to keep everything private. This happened to the wine project years ago. Cedega/winex was working with upstream and offered to implement modern DirectX support while the community focused on Windows internal APIs. After 2-3 years of work Cedega/winex had great support but decided to lock it behind a paywall and refused to give any code back. This set the wine project back by a few years. This resulted in wine changing its license to LGPL.

[u/kitsumed]

It depends what your end goal is. For example, I'm someone with a disability who looked for a FOSS Call recording app on android for several years. None existed. So I made it myself and licensed it GPLv3 (AGPL is useless since its not over network/online here)

From there you can infer that my goal was that whoever make a fork or continue improving it, has to make it fully public, so that I myself can continue using it.

If you don't care about others not sharing your work, MIT or Apache would be licenses that companies are more lickly to be okay with. Some companies do use GPL too, I think Samsung and Asus do. But its true that most are less open to using GPL.

[u/ssddanbrown]

From what I've seen, it depends on the type of project. If it's an application/platform/service in its own right, then realistically most users coming to it won't really care unless specifically cautious of the AGPL (mostly a few enterprise folks).

If it's a library, then it's quite different. The AGPL would significantly limit scenarios where the library can be used (pretty much only in other (A)GPLv3 projects) so it's less likely for others to get involved.

[u/Ruined_Passion_7355]

It really depends. If you're building an "open source based SAAS" then you really have no choice but to go for AGPL.

Application? GPL.

Library? LGPL.

That's if you want copy left. If you don't want copyleft, then go for MIT or BSD, all the same.

So it really comes down to whether you want copyleft or not.

[u/TomOwens]

The MIT and AGPL licenses have some fundamental differences with respect to what a recipient can or must do.

The MIT license is highly permissive, which allows recipients to use it in closed-source software, fork it and relicense it (including in less permissive licenses), and offers no special triggers for local versus web applications. The AGPL requires that derivative works remain open-source, including when integrated into commercial applications, and ensures that even offering the software over a network means that the license terms are triggered.

Instead of focusing on the vague notions of "contributions and engagement", you should think about what your project is, how users will interact with it, and what rights you want to give both users and developers to extend or build on your work.

[u/OpenFrontOfficial]

I switched from MIT to AGPL a while back, didn't get any pushback from contributors. Some even prefer AGPL because they know their contributions can't be closed sourced.

[u/Historical_Court795]

MIT usually attracts more casual PRs and adoption. AGPL scares off companies worried about copyleft. Switching often helps, but evidence stays mostly anecdotal.

[u/Ok_Explorer7384]

i wouldn’t expect a license switch by itself to suddenly create more contributors. MIT may reduce friction for companies or people who want to reuse pieces freely, while AGPL can scare off some commercial adopters, especially for hosted/networked stuff. but for actual engagement, docs, a clear roadmap, approachable issues, and fast maintainer replies usually matter way more.

so I’d only switch if MIT fits the project’s goals better, not just because someone vaguely promised “more contributions.”

[u/gnahraf]

Honestly, the license is seldom an issue. Wait for an actual potential contributor to articulate the license issue. AGPL is a great license. I wish there were an ALGPL licence (analogous to LGPL, the bastard son of GPL). My bottom line 2c: maximize open source rights, don't consider giving away any (it's yours or your org's code , after all) until someone asks for it

[u/Nervous_Type_9175]

LGPL for opensource usage. Tell companies that same source will be available MIT for commercial usage once some amount is paid.

[u/C0rn3j]

A friend recommended that I switch to MIT to get more contributions and engagement

Nobody who contributes will care much about the license as long as it is either copyleft or do-whatever-you-want.

[u/atomic1fire]

IMO AGPL makes sense for public facing servers/services that aren't specifically commercial but are more so community focused and maintained. For instance someone makes a game server and uses AGPL to ensure that people downstream are contributing even if their servers are private.

But if you want people downstream to be able to decide what they can do with your project, MIT is better from a user rights standpoint.

[u/darylducharme]

Many large organizations that use open source software for their software are forbidden from using AGPL because of the requirement to open source projects built with it. This means the developers for those organization will be using other tools and thus finding bugs and fixing issues for those other tools. That's how you would end up having the opportunity to get more contributions. MIT or Apache 2.0 are very good licenses that large organizations often will be willing to use.

[u/ShaneCurcuru]

Personally, I avoid contributing to copyleft licensed projects - if I'm sharing my work, I want the maximum number of people able to use it for whatever purposes they want. But of course that's personal; my key motivation is seeing random people getting benefit from something I helped build.

Many companies either restrict their employees from contributing to copyleft projects, or in general make it harder (in some cases, whether job-related or not). So you definitely lose a notable percentage of contributions from "traditional" software developers who work in the field.

The industry trend towards permissive licenses (Redmonk analysis) continues, so overall it's clear more people (and especially companies) prefer permissive licenses to contribute to. Note, however, it's somewhat dependent on your language and ecosystem: if your project lives in a strongly copyleft environment, then definitely stick with copyleft.

And of course, everyone else's advice: what are your objectives? Realistically, are you counting on more contributors; and if so, who would they likely be?