Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Granted IANAL, can someone explain how the AGPL prevents aaS providing of _unmodified_ AGPL-licensed software?

Reading the license text[0], the prominent section related to remote network interaction very clearly notes "if you modify the Program", and the terms and conditions lay out that "Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying".

When people discuss not being able to offer AGPL-licensed programs as a service, are they exclusively talking about modifications?

Another point is the requirement to only provide source to your users, who might be bound by something else, like an EULA that prohibits them from using the AGPL software you give to them to run a competing service, for example.

I guess until this stuff gets tested in a court of law, everyone is reacting to the threat of litigation more than actual litigation but it feels like the threat to companies is overblown, except if they try to improve the software and not contribute back.

[0]: https://www.gnu.org/licenses/agpl-3.0.en.html



I had always assumed (without really verifying it) the reason for this was because for a large company that would be capable and interested in re-selling these services, they would NEED to make some changes to integrate it with their rest of their systems. And those changes would be very sensitive and specific to their own infrastructure and system.

At least in my limited experience with extremely large companies (which are the companies that would be capable/interested in reselling these services) they rarely run open source software exactly as is, even for their internal usage. They usually patch it themselves or contract out patches either to fit within their systems, or for specific features the want/need.


Ahh OK, then this is really more against large enterprises and less for lean/smaller aaS companies. Seems like there's some leverage here to be taken advantage of.


There is, but it's also not risk free.

For example, MongoDB used to be AGPL and there where some companies dedicated to provide hosted services for it. Specifically MongoHQ (later renamed to Compose) and MongoLabs (later renamed to mLabs). I believe neither of these companies had any specific contract with MongoDB, nor where they breaching the AGPL in any way.

However, MongoDB eventually changed it's license in a way that explicitly made it impossible for these services to continue to exist without making their entire stack open source, or getting a separate license agreement with them. In this particular example, the impact may have been minor for these two companies, as Compose got acquired by IBM before this, and mLabs got acquired by MongoDB themselves. But any other product that effectively ran hosted MongoDB for you would need to get a license from MongoDB. It is speculated (fairly) that these changes were made so that MongoDB could get a greater market share with their own hosted that they sell, and to block out much bigger cloud providers from finding ways to wrap their services in non license breaking ways, but still not providing much more extra value add other than hosted Mongo.


I first came across the dilemma of choosing an open source license when I wanted to create and distribute an Opera (pre-blink / chromium version) browser extension through their add-on online platform. Opera was promoting the Apache license to everyone, as a default, and urged me too to chose that when I submitted by extension. After some research online, I figured it was because an Apache license made it easier for them to re-use and integrate the code with any of their proprietary (or otherwise) product and permission for such use was implicit in the license. GPL v3 was more restrictive due to its viral nature.

I ultimately chose the GPL v3 license, so that if anyone wanted to use my code commercially in a proprietary product, they would have to consult with me to work out a suitable arrangement (like dual licensing and granting them the right to use the code with a more permissive license - this would be easy in this case, as I was the sole developer with all rights). This was not done with any monetary consideration in mind but as a young developer I just wanted to be made aware when someone wanted to use my code commercially, to mention the same in my resume.

The second reason was that GPL v3 better protects the ideal of open source that I subscribe to - the USER should have access to the source code and be able to modify and use it for their own purposes. Other more permissive open source license don't protect this right.

This is where AGPL comes in too.

With "cloud computing" and "software as a service" becoming popular, many tech corporates that had avoided GPL softwares, now started using the software on servers and offering it as an online hosted service. GPL requires you to share the source code, along with any modifications, when someone asks for it, when you distribute a software using GPL code. But with online hosted services, corporates claimed that since they weren't distributing the software and the user was not running it on his computer, they didn't need to share the source code or any modification made to it with anyone.

AGPL was created to prevent this and further protect the USERS right, as it forced anyone who chose to use AGPL software and offer it as a service, to share their source code.

I still believe GPL / AGPL is the BEST open-source license. All developers are also USERS of their application. Thus, GPL's focus to protect the USERS right at all cost, works to protect your rights as a developer too as your source code, in any form, will always be open and available.

For commercial open source projects, dual license (partially or fully closed + GPL) is the way to go. MySQL / MariaDB is a good example.


Good decision, that is also my approach.


Here are some more thoughts:

I'm also wondering if it's even worth bothering with this at all and whether companies should just open source the orchestration software/shim layer. Open sourcing the shim/adapter you use to orchestrate running the unmodified software doesn't even seem to be an issue, because usually what's stopping competitors is not simply development difficulty. Then the question becomes how far past the orchestration does the virality go -- I think it's pretty hard to make a case that your customer frontend (which is where the money gets made) that calls out to the orchestration software (maybe it doesn't even, maybe it just puts a message on a queue) is now a work derived from the Program.

Here's a more concrete example. If I want to run a hosted mongo service, I can take mongodb's own k8s operator[0] and build using that. For this to be damaging to the business, the virality of AGPL would have to extend all the way to whatever software I use to check out customers, but even that seems like it would be fine if that software was open source too (imagine some self-hostable saas project that takes your stripe key as an ENV variable).

Here's another thing worth considering -- who is going to sue companies that violate? Some random group of developers? The EFF/FSF + a developer? when are they going to sue you? By the time that you're a giant company off of the software, even if a competitor got the complete source code to one, two or all services that run on your platform, could they really replicate it? Wouldn't they still have to get that source from a customer (user) that requested the source?

It seems that if you really want to stop this from happening, something like the Business Source License[1] (or some equivalent license) or bust.

Aside from all this, it really feels like AGPL is the best license for all software -- it really hits the "don't use this if you will improve it but not contribute back" intention perfectly -- if you make your derived work public (such that your modified version becomes the unmodified version) it seems like there are little to no issues running a business on it.

[0]: https://github.com/mongodb/mongodb-kubernetes-operator

[1]: https://mariadb.com/bsl11


I can explain in one word: Greed.

They want to have the option to, when they see a market opportunity, slap a logo and one tiny feature on top, and a price tag!

If there was a single, one, any tiny reason to not use GPL, nobody would be using linux.

Not using GPLv3 is sabotaging open source. People who stand with corporations and dislike GPLv3, are the same people that stood with microsoft in the 90s and disliked GPLv2. There's no way to please that people. Let them go. You do not need them.


I am mostly a commercial software user, but I owe the GPL the possibility of having had access to UNIX at home.

As such everything I do outside work, is dual licensed, don't want to pay me? GPL

Want to earn money with my work? Lets talk about a commercial license that makes sense to both parties.

I was there in the shareware/public domain days, and this is where everything is going back to with these decisions of moving away from the GPL.

The major uptake of BSD UNIX clones across the industry shows how it would have worked out without Linux and GNU being GPL, basically HP-UX, Solaris, Aix, Irix would still dominate the server room.


Everyone who tries to predict alternative universes will get it wrong.

You say that because there was BSD, apple could have OSX and not license Solaris or what not.

I say that without BSD licenses, Apple would have OSX with proper open source and up to date releases. Heck they did that with the kernel and most of the distro for a while.


> ...HP-UX, Solaris, Aix, Irix would still dominate the server room.

No word about Apple, where did you got it from?


Maybe unmodified AGPL software can be run as a network service without providing the source code because the source code is already available from the original author.


Yup that's precisely my point -- if this is the case then where is the protection from aaS that everyone seems to think is there? All the provider has to do is just... not modify the software, or only make modifications that don't expose their proprietary orchestration systems and benefit everyone else in the process (but they really benefit the most, because they're making money off of the software).

If you get more nefarious with it, what if they started building tooling around it -- like a proxy that rewrote requests to fix a bug, or a file system that sat underneath the program that solved some issue with IO?

I also think that the majority of value delivered by something like RDS is not actually proprietary changes, it's just the underlying software being kinda good (because it was developed in the open, and the F/OSS community was leveraged as bug finders and fixers) -- I'm thinking mostly of Postgres. Even things like HA and scalability are often considered in projects these days, so you wouldn't even need to add much to check off the usual enterprise-y boxes.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: