> - Using a copyleft license like AGPL makes this an automatic non-starter for most businesses, no matter how impressive your tech might be. You'll have a lot more luck with mid-size and enterprise adoption with an MIT license.
What makes the AGPL unattractive? I thought it was basically just the GPL with a limitation on using the software to provide a SaaS product. You don't even have to contribute unpublished changes, right?
Before reading your comment I actually checked the licensing in the repo because I was thinking the exact opposite; using MIT would be a mistake because it's too easy to undermine the turnkey offering by selling a competing service without the cost of development.
> The primary risk presented by AGPL is that any product or service that depends on AGPL-licensed code, or includes anything copied or derived from AGPL-licensed code, may be subject to the virality of the AGPL license.
> This viral effect requires that the complete corresponding source code of the product or service be released to the world under the AGPL license. This is triggered if the product or service can be accessed over a remote network interface, so it does not even require that the product or service is actually distributed.
> Because Google's core products are services that users interact with over a remote network interface (Search, Gmail, Maps, YouTube), the consequences of an engineer accidentally depending on AGPL for one of these services are so great that we maintain an aggressively-broad ban on all AGPL software to doubly-ensure that AGPL could never be incorporated in these services in any manner.
FWIW, every company I've ever worked at bans AGPL products / code.
> This viral effect requires that the complete corresponding source code of the product or service be released to the world under the AGPL license. This is triggered if the product or service can be accessed over a remote network interface, so it does not even require that the product or service is actually distributed..
This is the entire point.
The goal is to stop the SAAS loophole.
the toxic combination is (a) virality and (b) remote end user access triggering the GPL rights.
You could have one but not the other. We really need "LAGPL" to parallel LGPL, to make it clear that there is a clear and well defined way to stop the "remote access" part of AGPL from propagating accidentally into proprietary code.
In other words, to stop the process of people no longer owning their software and data and being subjected to someone else's decisions about whether a feature or service is important or should be deprecated.
I always cackle a bit when someone points out that GPL-family licenses are incompatible with large-scale enterprise heavily relying on proprietary technology for value extracting. Obviously GPL is incompatible and that's a feature and not a bug.
If Google truly had to be competitive, they surely could figure out ways to make AGPL work. But they don't have to because for now they're just taking everyone's data practically for free.
that really give one a sad state on the reality of business.
the fact that google is against AGPL, makes it even more important to use it! Whatever is good for google, it is not good for humanity, and whatever google doesn't like is beneficial for humanity. Support AGPL!
> FWIW, every company I've ever worked at bans AGPL products / code.
Is every company you've ever worked for a software vendor? Because those are the only companies that would be impacted at all by using AGPL products/code.
Any business that uses AGOL software needs to be able to provide the source code of that AGPL software to people who use their services
That is… just not something most online stores are interested in adding to their compliance burden.
And of course they will have changes. It’s a business software platform, the only way to accomplish some things is going to be through adding or modifying code.
> Any business that uses AGOL software needs to be able to provide the source code of that AGPL software to people who use their services
Step 1: add GitHub link to footer on website
...that's it, you have achieved compliance.
This "wah the AGPL is too viral" argument is the same FUDdy duddy nonsense Microsoft was whining about back in the early 2000's about the original GPL - and it's even less of a valid argument now than it was then, thanks to the existence of umpteen bajillion Git repo hosts that will gladly handle distributing said source code (and therefore making you compliant with the terms of said code's license) at zero cost to you.
> Step 2: take responsibility for all the content of that GitHub link being free of copyright infingements, patent violations, etc.
You already do this when using any open-source software (because your legal right to use it depends on upstream's legal right to distribute it to you), so if any other FOSS license is okay then so is AGPL by this metric.
> And you missed step 0: convince the boss there’s a good reason why your e-commerce storefront needs to have a link to a GitHub page on it.
You already do this for license text / copyright info when using software under nearly any other FOSS license (unless you thought those attribution requirements in the MIT/ISC/BSD/etc. licenses were mere suggestions?).
> The primary risk presented by AGPL is that any product or service that depends on AGPL-licensed code ... _may be_ subject to the virality of the AGPL license.
This is aggressive scare tactics. It's very straightforward when this is triggered.
When you're using code unmodified as a library (whether source or binary) it's not triggered at all.
When you _do_ make upstream modifications, it's triggered. That is the specific risk, and it is easily satisfied by open-sourcing the full modified version.
The whole "if a remote user uses it" argument is FUD. It closes a loophole in GPL where remote use != distribution.
Google is hostile to copyleft full stop. So are other bigcos and cargo-culting smallcos/startups. That doesn't make it right.
There is no such thing as virality, you always retain your own copyright over the code if you don't publish it under the AGPL. If you use AGPL code in a non AGPL codebase you are merely violating copyright and must remove the AGPL code from your codebase.
In this case, there is nothing at all wrong with a GPL license. Everyone is answering from the perspective of a software company. That isn't who this product seems to be targeting. It's targeting businesses that sell physical goods and need a virtual storefront to do that. They aren't looking to fork this and repackage it as a different product. The purpose of it being open source at all is so they can more easily self-host it. If you self-host an application you don't fork and modify, there is nothing for you to publish. The source was already published by the person you got the code from in the first place.
For an app like this, that would typically be configuration in the database. (Think WordPress; are you writing your marketing copy in plugin source code or are you writing it using the page editing functionality?) The AGPL doesn’t require you to publish your database.
There's a lot of FUD out there about GPL licenses and they've become pretty unpopular over the last decade. There are trade-offs, but there's nothing wrong with using the AGPL if that aligns with your own goals and values.
> What makes the AGPL unattractive? I thought it was basically just the GPL with a limitation on using the software to provide a SaaS product. You don't even have to contribute unpublished changes, right?
The things AGPL adds to GPL don't just affect people trying to do a SaaS offering of the program. If you modify it and users interact with it over a computer network you have to make source for your modified version available to them.
For example suppose it was software to add online ordering to restaurants. A restaurant modifies its copy so that it can be given the recipes of the items they sell and the modified software uses that information to allow customers to easily exclude items they might be allergic to or that violate their religious or ethical eating rules.
If that restaurant wants to use that as a competitive advantage over other restaurants they aren't going to want to have to give away their modifications, so aren't going to want to use AGPL software. They'd probably be fine with GPL software.
The kind of arguments you raise here have always, to me, basically looked like:
"I want something for nothing"
Or in more detail:
"I want to take something you created and agreed to share with me (on the proviso I like-wise share any changes as an exchange of value). I deem your software valuable to me but I won't be paying you money for it. I'll add something else to it so it fits my use-case. But, I refuse/object to sharing my changes because they're valuable."
It's not just sharing the changes. You have to be really careful how you integrate/modify the source. If you aren't you could accidentally expose proprietary information within those modifications. It's that kind of headache that means it is just easier to avoid.
> If that restaurant wants to use that as a competitive advantage over other restaurants they aren't going to want to have to give away their modifications, so aren't going to want to use AGPL software.
That's exactly the kinds of scenario the AGPL was written to avoid, right? The free software movement doesn't see software as a competitive advantage worth protecting; software is information that should be free.
To put it another way, if somebody releases software under a license that says "You may use and modify this for free, but you must contribute your changes back to the world," then your scenario seems perfectly fair.
As someone working on a product that uses open source, GPL makes development more complex.
With a permissive license, I can make a decision, with my manager, to use a technology based on its merit.
Office bureaucrats get weird when you talk about the GPL. When using it, I have to involve lawyers in the company, they don’t understand why the technology is important, but they have a bunch of questions, and to answer them it takes up time from my team. Upper management is involved and wants to know if we can use anything else, or they’ll phrase it as a question like: why can’t you use anything else? You have to deal with a lot more office politics when you use GPL instead of doing development work. So I’d say that’s the biggest downside for developers is that it wastes their time.
MongoDB is licenses as SSPL which is non Open Source license all together
BUT this is only if you are not paying for MongoDB. If you do chances are you're using MongoDB Enterprise which is licensed under commercial license or MongoDB Atlas all together
SSPL is a nearly verbatim copy of AGPL, except one section. It is more restrictive than the AGPL, in a way that many feel is anti-competitive, which is why it's not considered Open Source by many, but also in a way which doesn't really change the argument here IMO.
MongoDB - the application is. MongoDB - the service isn't.
You can use an Oracle database (however ugly its licensing is) without having an oracle license on every piece of data you expose. The same is true of Mongo license and the data it exposes as a service.
The AGPL in this case is "you use MongoDB - someone wants to know about it, the source for MongoDB is over there." MongoDB AGPL doesn't 'infect' the application it is part of.
Now, if you were to fork MongoDB and do something with that fork (FongoDB), and that deployed FongoDB would need to make it's source code available if it was accessible - not the entire application that it is part of or components that use the data that it provides.
Yes, that's the entire purpose of the AGPL. If that's the outcome this person wants for their project, they should consider the AGPL.
I'm attempting to counter the narrative that no corporation would touch any AGPL software, because it's clear that how you are using the software is an important part of the equation.
Looking at https://webassets.mongodb.com/_com_assets/legal/SSPL-compare... and in particular section 13, this is an attempt to squash a cloud service from packaging MongoDB and their own custom backup and UI software without offering the backup and UI software also under the license.
> MongoDB is a bit miffed that some cloud providers — especially in Asia — are taking its open-source code and offering a hosted commercial version of its database to their users without playing by the open-source rules.
> So while the SSPL isn’t all that different from the GNU GPLv3, with all the usual freedoms to use, modify and redistribute the code (and virtually the same language), the SSPL explicitly states that anybody who wants to offer MongoDB as a service — or really any other software that uses this license — needs to either get a commercial license or open source the service to give back the community.
If I was to write blog software that is backed by MongoDB, that blog software doesn't have to be released under the SSPL.
That said, the license and its application to patches on older versions would raise some eyebrows in legal with (likely valid) concerns that an upgrade of a point release may change the license on them as it was done before. In the interest of minimizing risk for the organization, the license and the company that changes its license so easily would be ones that would get extra scrutiny and developers using it would likely be advised to ask permission rather than forgiveness when dealing with it (rather than the other way around) as the risk to the org is greater than accidentally incorporating some GPL code in a service.
Maybe? The commercial version has some extra features, but if you don't need them then there's probably no need to. I imagine there is more value in paying for a support contract.
In an ecosystem like this you may want to have businesses build extensions or plugins that they'd sell. GPL has this reputation of spreading to everything it touches, and as such would scare them away.
I won't pretend to be a lawyer, but I do know that when we were acquired we had to list ever piece of software we used and which licence it was under. They were very concerned about copy left. We didn't have any, so I don't know how that would have changed things. MIT was what they were hoping to see.
What makes the AGPL unattractive? I thought it was basically just the GPL with a limitation on using the software to provide a SaaS product. You don't even have to contribute unpublished changes, right?
Before reading your comment I actually checked the licensing in the repo because I was thinking the exact opposite; using MIT would be a mistake because it's too easy to undermine the turnkey offering by selling a competing service without the cost of development.