Code licensed under the AGPL must not be used at Google | Hacker News Reader

Code licensed under the AGPL must not be used at Google

opensource.google

61 pointsassttoasstmgr98 comments

Good, I license much of my open source software under the AGPL because of how easily bad actors are able to scare themselves with FUD about the license. I want companies who don't understand the licens to be afraid of simply taking without giving back.

That said, most of fear around the AGPL is nonsense, and there are plenty of companies and contributors who understand the license and adhere to the terms AGPL software ships under. If Google wants to limit their options, while smaller competitors get a leg up by understanding and using their AGPL options, that's good for the market.

IANAL so I don't have much experience here, but I am not sure this hits the spot.

I think that an organization like Google can afford the brain power needed to understand many of the the implications of using such a license. There are probably other legal, compliance and liability reasons behind this rather than just lack of understanding.

I agree. I think they understand that they do not want to comply with the license terms.

Yes, and they clearly state why:

> 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.

It's not that they want to fork a opensource component and they don't want to release their changes.

It's because they are afraid that accidentally one part of an AGPL code gets linked into some of their production software which would force them to disclose the sources of their own IP. And it's hard to quantify the blast radius of that, since they are linking a shit-ton of stuff in every binary (think of thick clients for their colossus storage system).

It's not that they want to pull an Amazon on OSS components they then sell as a service.

License an API under AGPL?

* license. That's what I get for posting from the gym.

Welp this is a bit of a chip in my near-term analysis of the situation[0], but I still think the future of F/OSS is AGPL.

Also since I'm bit biased I think that there's an entire group of people who see this as a welcome to build their next google-beating startup attempt on AGPL since they know Google won't touch it (not that google was the undifferentiated-hoster type anyway).

[0]: https://vadosware.io/post/the-future-of-free-and-open-source...

Google will just buy a non-AGPL license from the license holders if they really want to use a particular piece of software.

I presume that then they may attempt to buy on a different license. And that you may say "No" to that.

I presume that if the software is non-trivial, Google's chequebook can convince most open-source maintainers.

That is likely true. But I also know FOSS developers who outright rejected very large sums of money being offered for their work. From a combination of principles, values, not needing the money, or not willing to take responsibilities that come from such sale and/or restrictions of freedom that would mean. The "they just buy it" is the cynical assumption that everything always revolves around money. It often does, but not 100% of the time.

But now we are not talking about the sale of their work but simply licensing. J have not heard anyone rejecting large sums for licensing g code.

And that's hopefully why it will be the future of F/OSS :)

More money in the hands of F/OSS maintainers and teams will be the rising tide that gives us all even better ecosystems than we have now, I hope.

So the future of F/OSS is all projects taking no outside contributions or requiring copyright assignment? How else will the core contributor(s) be able to sell a license to AGPL code they don't fully own?

Looks like it's time to update that article. It was primarily intended for self-hostable projects, and as others have discussed it's an issue for libraries!

Also to more directly answer your question, the idea is that they sell a custom license to their own AGPL code -- if that code is mixed with code they don't own that is indeed a quandry! The royalty industry has a pretty well established model, so maybe we can use that.

Again I want to point out that this is probably not reasonable for library authors (for many other reasons as well), I'm mostly thinking of people who are making software someone might want to rehost.

Funny, there actually might be a business in here for managing the licensing and royalties for upstream projects in this future I'm envisioning ever comes true.

> So the future of F/OSS is all projects taking no outside contributions or requiring copyright assignment? How else will the core contributor(s) be able to sell a license to AGPL code they don't fully own?

You can do it without copyright assignment by, for example, contributors granting the maintainer a license to relicense their contributions.

If the license holders are a definable and reachable entity.

Once a project takes contributions without a CLA, there can be hundreds or thousands of authors, many of whom are unreachable.

That seems like a win for the maintainer.

I'm curious on your take of this for library code (as opposed to a full application like a web server or database).

By count of projects alone, most of the OSS that I use is library code: parsers, REST client, compression, serialization, logging, IOC, unit tests, etc. I have absolutely zero interest in literally any aspect of the bureaucracy of paying for this, just for the sheer volume of projects. I'd be more likely to build - and release under an extremely permissive license - my own library for most of the above. I'm sure I'm not alone in that.

I have no issue with A/GPL software (though employers sometimes do), but I very strongly prefer MIT/BSD for library code for everything I do (personal, OSS, and paid) because complying is easy and implications are minimal.

IANAL, I'm a yak shaver by trade.

That said, I think it's completely different for library code. Library code is conveyed to the user, whereas network access is not conveying a work. They didn't mention this, but even more abstractly, network access to the result of some computation is clearly not a sustainable thing to try to control either.

> By count of projects alone, most of the OSS that I use is library code: parsers, REST client, compression, serialization, logging, IOC, unit tests, etc. I have absolutely zero interest in literally any aspect of the bureaucracy of paying for this, just for the sheer volume of projects. I'd be more likely to build - and release under an extremely permissive license - my own library for most of the above. I'm sure I'm not alone in that.

> I have no issue with A/GPL software (though employers sometimes do), but I very strongly prefer MIT/BSD for library code for everything I do (personal, OSS, and paid) because complying is easy and implications are minimal.

Yeah I think this is the fundamental breaking point -- AGPL is much more viral/complicated for conveyed works (as it was intended to be). Probably not a good idea in that use case.

I should amend my post to note that AGPL is the future for self-hostable F/OSS, not necessarily library F/OSS.

That said, I do think that it could be a great default license that encourages purchases for F/OSS though. If you're building F/OSS then the library is free for you. If you're not building F/OSS then pay for a separate license. If your goal is adoption (and the most users, arguably greatest good/utility) then AGPL stands in the way of that.

Are you familiar with the Mozilla Public License 2.0? It basically fulfills the role of library-compatible copyleft license in a way that LGPL never did. If a file is MPL-2, then all modifications to that file must be shared. But it is otherwise not viral, and so you can freely link with other proprietary code, or include it in a statically linked binary.

I've made two npm utilities to check for licenses like this:

`npx check-licenses`: lean library, requires npm+package-lock.json

`npx legally`: checks the filesystem under node_modules, might overfetch license files that are unused

Example output:

   ┌────────────────────────────────────────────────────────────────────────┐
   │                                                                        │
   │                            Licenses (1326)                             │
   │                                                                        │
   ├──────────────────────────────────────────┬──────────────┬──────────────┤
   │ License                                  │ Number       │ %            │
   ├──────────────────────────────────────────┼──────────────┼──────────────┤
   │ MIT                                      │ 1069         │ 80           │
   │ ISC                                      │ 65           │ 4            │
   │ BSD 2 Clause                             │ 44           │ 3            │
   │ CC0                                      │ 40           │ 3            │
   │ Apache 2.0                               │ 37           │ 2            │
   │ BSD 3 Clause                             │ 36           │ 2            │
   │ W3C                                      │ 19           │ 1            │
   │ Unlicense                                │ 3            │ 0            │
   │ 0BSD                                     │ 2            │ 0            │
   │ GPL 2.0                                  │ 2            │ 0            │
   │ AFL 2.1                                  │ 1            │ 0            │
   │ CC BY 4.0                                │ 1            │ 0            │
   │ CC-BY                                    │ 1            │ 0            │
   │ MPL 1.1                                  │ 1            │ 0            │
   │ MPL 2.0                                  │ 1            │ 0            │
   │ ODC By 1.0                               │ 1            │ 0            │
   │ Python 2.0                               │ 1            │ 0            │
   │ Ruby                                     │ 1            │ 0            │
   │ WTFPL                                    │ 1            │ 0            │
   └──────────────────────────────────────────┴──────────────┴──────────────┘

For the lazy:

- https://www.npmjs.com/package/check-licenses

- https://www.npmjs.com/package/legally

This feels like the kind of thing that might make for a good (paid?) app on the github marketplace francisco :)

This is, at least, an improvement compared to orgs which just use the code anyway in violation of its license.

When I was at Apple they were very cautious about this too. It wasn't banned but it was definitely something you had to get approval for.

Apple hates the GPL more generally, not just the GPL, and purged a number of packages from macOS (e.g. terminal-mode Emacs, which has been included since the days of NeXTsteo).

Has nothing to do with hate. The viral nature of the license makes it a nonstarter.

GPL has the same virality as AGPL other than it isn't implicated by access over a network. Apple has plenty of software that isn't accessed over a network, so it makes sense that they would care about both. (So does Google, but that code is largely open source already - Android, Chrome/ChromeOS, etc.)

"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."

Huh? Does that mean that if you do an HTTP request to an AGPL server, your client code must be AGPL compliant? That does not make sense...

No, it means that you as a client are allowed to request and should be given the source code for that server.

No, it just explains that whenever you make an HTTP request to an AGPL server, you are entitled to the source code of the server (under AGPL). Obviously, Google does not want to give you the source code to any of its services (which are generally accessible via HTTP), so it needs to be very careful not to get any of those under AGPL (which could happen by linking (not just HTTP-connecting) to AGPL libraries/software).

Doubtful, "can be accessed" is unlikely to be interpreted as "can be used to access" by any reasonable court.

The world "viral" immediately made me think about the Microsoft era[0]:

In 2001 Microsoft vice-president Craig Mundie remarked "This viral aspect of the GPL poses a threat to the intellectual property of any organization making use of it."

[0] https://www.nytimes.com/2001/05/03/business/technology-micro...

The title of this NYT piece is "Microsoft Is Set To Be Top Foe Of Free Code." It's a peculiar feeling for all of us who saw the birth of Google and actually felt this particular company is very different from others - and especially from Microsoft.

This post lacks historical context.

Google is the company that initiated the whole movement against the GPL and the AGPL. I was in touch with their OSS guru, Chris diBona at the time. Also, Bruno Lowagie's book "Entreprenerd" gives some more details about this initiative.

In short, Google were caught in violation of the GPL's copyleft terms and decided that they could not be caught in violation again on any of their principal technologies. So they started a very public campaign to strip the GPL from the company and because they are so reliant on OSS, to dissuade OSS developers from using the GPL (and by extension the AGPL). At the time, the GPL was, depending on survey the #1 or #2 license in OSS.

However, contrary to their public position, Google still uses GPL products widely inside the company. Linux and Java, for example, are both licensed under the GPL and used extensively at Google. And the parts of Android that are based on Linux are licensed under the GPL [0].

Note that all major companies that sell licenses to their OSS use the GPL or AGPL licenses. This is because the copyleft provision provides OSS developers with leverage ("Either open-source your app if you use our product for free or buy a license.") This is what Google does not want to do. None of the more permissive licenses give developers this leverage: under MIT, Apache, and the other licenses, the developer gives up the GPL's copyleft leverage.

Some companies have followed Google's lead and used scanning tools to eliminate GPL/AGPL code from their codebases. This is in part due to the copyleft provision and also to the so-called "viral clause" (if any part of the software is GPL/AGPL, the rest of the software it's part of must also be GPL/AGPL). This makes a lot of sense.

However, for developers of stand-alone tools, the GPL is a good option and much less disfavored in corporate contexts (as evidenced by the widespread use of Linux, Java, MySQL, etc. in corporations) and the GPL license provides OSS developers a possible monetary stream from companies that want to modify the tool without disclosing the source code.

Personal note: all of my OSS projects are released under permissive, non-GPL licenses because I'm not looking to make a business out of them and I want the widest possible distribution. Here, I simply want to provide context to the OP and clarify that it should be seen in the context of a long campaign by Google to dissuade OSS developers from the GPL/AGPL and to point out that those licenses have benefits for projects looking to pursue a business model based on licensing.

[0] https://source.android.com/setup/start/licenses

Do you have a source for any of that?

I worked at Google from 2011 to 2017, and the licensing policy was always pretty clear that the GPL was broadly OK for server-side but the AGPL was not. They're one of the few corporate entities I know of that are willing to use GPLv3 code, and when I went through their process for open-sourcing personal projects they had no problem with my use of the GPL.

You might be confusing Google with Apple, which was historically willing to use GPLv2 code but is strongly opposed to GPLv3.

  > the so-called "viral clause" (if any part of the software is GPL/AGPL,
  > the rest of the software it's part of must also be GPL/AGPL)

This is not an accurate summary of the GPL, or of software licensing in general. There is no requirement that all parts of some piece of software use the same license. As one famous example, the Linux kernel (largely GPLv2) also contains code covered by the MIT and BSD licenses.

I'm also bothered by how you use "GPL/AGPL" repeatedly. The GPL is a standard copyright license, the AGPL is a EULA, and there's good reasons to distinguish them.

It may not be an accurate summary, but GPLv3 makes extensive claims and none of that has been tested in court, so it is not unreasonable of them to be wary and not take any risks. They abandoned plans to incorporate ZFS in macOS and implemented the inferior APFS instead simply because of a patent troll lawsuit by NetApp against Sun.

> I'm also bothered by how you use "GPL/AGPL" repeatedly. The GPL is a standard copyright license, the AGPL is a EULA, and there's good reasons to distinguish them.

I'm not sure what distinction you're trying to make. The very first line of the AGPL reads: "The GNU Affero General Public License is a free, copyleft license". And from the FSF's own site: "The GNU Affero General Public License is a modified version of the ordinary GNU GPL version 3. It has one added requirement..." [0]

[0] https://www.gnu.org/licenses/why-affero-gpl.html

The GPL is a copyright license. It applies when copyright law would otherwise prevent distributing some program. If I were to violate the GPL, for example by sending someone a compiled version and refusing to provide the source, then there's a clear legal theory by which copyright law could be applied.

That "one added requirement" in the AGPL turns it into a EULA, because it's an attempt to regulate for which purposes a user may run the program. If I were to run a modified AGPL'd SSH server on my own hardware, the question of whether I'm violating the AGPL depends on whether I'm allowing others to access it remotely. If the AGPL can be violated without copyright infringement, it's clearly in a different legal category than the GPL.

There's no need for uninformed speculation, their actual GPL policy is available on the same site as the submission: https://opensource.google/documentation/reference/thirdparty...

Can you give a couple of examples of this "campaign to dissuade OSS developers from using GPL"? It should be pretty easy since it was so very public.

You might be right that the active dissuasion was principally about the AGPL. However, less active dissuasion of the GPL is definitely Google policy. To wit, the Google link you point to says w.r.t. "restricted" licenses, which it defines as including all the GPL licenses, "Third-party software made available under one of these licenses must not be part of Google products that are delivered to outside customers."

Use of AGPL is generally considered a big red flag when a startup is undergoing due diligence to be acquired.

Even though companies overreact a bit, isn't this a clear signal that AGPL is working as intended?

Yes. AGPL was designed to avoid issues like Amazon offering a hosted cloud service based on an open source project, but then never giving back to the project. E.g. what they did with PostgreSQL. Microsoft & Google at least donated, Amazon did not.

Does it really work, if they really want they'll implement it themselves like DocumentDB. Just makes everyone else's life hard.

Seems reasonable, the restriction on installing AGPL stuff on your devices seems odd (how would that influence publicly deployed services?) but it mentions there's an approval process which makes it possible, so... Good enough?

I'd guess it's for making really sure that AGPL code doesn't end up in a published service by accident.

Probably for making sure they won't give up work for free. Say you used an AGPL software that you had to make 10x times faster, being forced to giveaway something like that for Google is not good. At least they'd wanna have the option.

As a google employee I think by far the most likely outcome of that scenario (where a google engineer modifies a piece of OSS to make it significantly better) would be that engineer using a lightweight process to get permission to contribute to that project (if it’s not already white listed for contributions) and then sending the improvements to be merged upstream.

There are many, many open source contributors at google and there is an entire group of people staffed to work on open source, among their responsibilities is to make it easy for google engineers to contribute to open source projects (both in their spare time and also as part of their daily work).

Presumably the bigger fear is that some AGPL program gets linked into their monorepo and the entire multi-billion line codebase is considered a "derivative work"

What if you use some kind of Remote Desktop to access your own device? Then you'd violate the AGPL.

you wouldn't, as GPL/AGPL only requires distributing the code to the users, and only if you changed anything.

You would just have to offer yourself your own source code to comply. Unless you plan on suing yourself, you don't even have to comply in this trivial case at all.

Is there any uptake in AGPL use? Besides perhaps the initial spike near AGPL creation, any popular opensource library using AGPL since?

Since it's in the news today... Mastodon.

Mold (the linker) uses it

There is a recent uptake in companies who want to make sure that their software isn't 'resold' by hosting companies (or book shops). They license the software under AGPL, so it's still "free", and can be used by individuals (or carefully by companies), but also have a commercial license available. You can't make "Hosted $THING" without a partnership.

Grafana is the biggest example that comes to mind: https://grafana.com/blog/2021/04/20/grafana-loki-tempo-relic...

This is inaccurate: you can definitely make "Hosted $THING" under AGPL. What you cannot do is modify said THING, host that (more precisely, make it publicly available as a service; if it's private, it's still ok), and keep the changes private.

> They license the software under AGPL, so it's still "free"

What's with the scare quotes?

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

Some of the ones on that list I didn’t know used AGPL: Anki, Bitwarden, Ghostscript, EdX, Diaspora, Mastodon, Searx, Signal’s server code.

So a fair few from different time periods. Obviously doesn’t have the adoption rate of more popular open source licenses.

Nextcloud comes to mind.

Most other AGPL usage I'm aware of is using it as a poison pill license in order to sell a proprietary license.

iText, probably the most widely used non-Adobe PDF library, uses the AGPL.

> any popular opensource library using AGPL since?

Not quite a library, but overleaf (the online LaTeX editor) is pretty big in the scientific community and it's agpl.

https://github.com/overleaf/overleaf

I would assume at googles scale that this has to be violated pretty often, how could you possibly police this well?

I assume they do license scanning at the very least.

we're not Google scale, but this works very well with precommit hooks and automatic CI checks that inspect dependencies for know vulnerabilities and incompatible licenses (you know, sonarqube and the likes).

I would assume this is pretty well policed for all existing projects and by default for all new projects.

You are only allowed to use imports that are in the monorepo, and each time a library is added to the monorepo, the license is checked.

A lot of Google operates outside the monorepo these days.

Every single 3p library that's imported into Google's monorepo gets vetted for license. If it's one of the standard licenses, it gets approved somewhat fast, but it's still time time consuming.

I would assume any library is vetted for security, a company like Google cannot afford wild-west practices with dependencies. Adding a license audit to the process would not be a big imposition.

Correct. The security vetting is indeed more cumbersome. All 3p code is reviewed with the same standards as internal projects, in theory.

Google has tools for making sure that outgoing open source projects have kosher licensing (e.g. cross: https://opensource.google/documentation/reference/glossary#c...).

I wouldn't be surprised if there's something similar that runs on incoming code and freaks out if it sees the text "under the terms of the GNU Affero General Public License". It'd be hard to introduce AGPL code accidentally.

So MongoDB is out

I think MongoDB gets an unfair shake when it comes their updated license terms. They tried to be good OSS participants while still trying to run a business. They put it out there under a permissive license but tried to make some money of it (which is a tough already). And then they got popular and AWS basically just resold their tech because of the license. They had to change their terms and regular users freaked out. If you don't resell Mongo "as-a-service" you're fine. A lot of developers didn't see it that way and it hurt them.

As usual, whenever anyone is against the AGPL, it's because they want to commit the exact bad behavior that the AGPL is designed to protect people against.

The AGPL cannot fail you—you can only fail the AGPL.

If you're picking a license to reveal who is up to no good, I'd also recommend the hippocratic license. Even more hilarious if used in a dual license setup with a commercial paid second license.

It's like the spiritial successor to the old jslint license. Not using it or using the second license is like an implicit admission of maybe wanting to do evil.

That license is wild. It bans all sorts of activities and I can't imagine any company's lawyer signing off on it. Some examples of things that terminate your license...

* Serve in the military: "Be an entity or a representative, agent, affiliate, successor, attorney, or assign of an entity which conducts military activities;"

* Sell anything to a police department: "Be an individual or entity, or a or a [sic] representative, agent, affiliate, successor, attorney, or assign of an individual or entity, that provides good or services to, or otherwise enters into any commercial contracts with, any local, state, or federal law enforcement agency;"

* Distribute violent media: "Be an individual or entity, or a or a [sic] representative, agent, affiliate, successor, attorney, or assign of an individual or entity, that broadcasts messages promoting killing, torture, or other forms of extreme violence;"

* Have a corporate charter that doesn't reserve enough board seats for low-pay workers: "Ensure that if the Licensee has a Board of Directors, 30% of Licensee's board seats are held by Workers paid no more than 200% of the compensation of the lowest paid Worker of the Licensee;"

* Discriminate (even unintentionally) based on a protected class: "Discriminate on the basis of sex, gender, sexual orientation, race, ethnicity, nationality, religion, caste, age, medical disability or impairment, and/or any other like circumstances"

To be extra fair, the license is modular[1] now and the base version anchors itself mostly on the Universal Declaration of Human Rights.

It it still, obviously, something most lawyers would advise against. That doesn't make the mind game of commercially licensing something dual licensed with this being equal to admitting you reserve the right to be unethical less entertaining.

[1]: https://firstdonoharm.dev/version/3/0/license/license.md

> licensing something dual licensed with this being equal to admitting you reserve the right to be unethical

That's not actually equal, though, because this license prohibits a bunch of things that aren't actually unethical. For example, it prohibits any use by police, military, and basically anyone in Israel.

What is unethical is often up to personal interpretation. I can make the case for all the things you listed. This is exactly why all of them are optional modules.

I'm going to go out on a limb and say that the vast majority of people do not consider it unethical for a country to enforce its laws or have a military. As for restricting use by Israelis, I'll just point out that the license itself considers it an ethical requirement to treat people equally regardless of their nationality.

>I'm going to go out on a limb and say that the vast majority of people do not consider it unethical for a country to enforce its laws or have a military.

Enforcing laws and the current sorry state of the police in the US (and elsewhere to different debrees) are not in a 1:1 relationship.

>As for restricting use by Israelis, I'll just point out that the license itself considers it an ethical requirement to treat people equally regardless of their nationality.

It doesn't restrict based on nationality. Read the license. It has an optional module to defer to the judgement of BDS. This is much more selective than whatever the US is doing to Cuba within the country but also includes a bunch of international companies that profit of what BDS considers unethical activity. (Not here to judge or assess the validity of the BDS list, but it does correspond to some people's notion of ethics)

Who said anything about US police? The license prevents selling to any law enforcement agency in any country

It feels like you're taking half my answer and then strawman the remainder (here i mentioned other places quite explicitly), it's a bit annoying so I'm gonna stop engaging in this thread.

Google like most tech companies may support "open source" but they do so only in the context of dev tools. This is a real problem for modern open source.

Free software it seems is trending away from software products that are open source, instead Open source is being limited to developer tools, libraries and framework.

Great for devs. Bad for end users and software in general

I understand that AGPL is an attempt to combat software-as-a-service otherwise hiding open source behind a network interface (and yes I know, the FSF's preference against that term).

It's still rather heavy-handed to a point that I would even avoid using AGPL software even for myself. It goes far beyond what the standard GPL demands and might even violate the freedoms to run a program as I wish, and to redistribute the software as I wish.

The standard GPL already puts "restrictions" on the latter, but at least said restrictions only apply if I choose to distribute binaries. In the case of SaaS, I am more comfortable with running a service and making the choice to distribute my source or not. Personally, I probably would publish substantial changes to software regardless, but if the only thing I do is change a line of CSS, I also don't think it's right to force me to have to set up infrastructure to publish my modified source.

AGPL is basically a clickwrap EULA instead of a distribution license, it also arguably violates freedom 0 of the free software definition.

With that logic virtually every free (and non-free) software violates the freedom 0 because there is no warranty that the software is fit for any particular purpose. The freedom 0 is simply about being able to run the software and doesn't talk about the consequence thereafter.

What infrastructure are you talking about? You could literally just publish the source tarball from upstream and a .patch file.

Alternatively, you could put in on github/gitlab for free.

This is a particularly low bar, given that you'll need a server to serve the app anyway.

> running a service and making the choice to distribute my source or not.

This right here is exactly why AGPL (and OSL that I use) exists.

It counters your sentence with "no, you can't do that". The fact that it removes your choice is a feature, not a bug. These licences don't give companies an escape hatch from sharing the source code, and I support that.

The AGPL is a modified code distribution suicide pact (to make it possible to merge upstream), not an anti-commercialization license.

The people it punishes are those who modify software but don't contribute changes back upstream.

See the FSF article (https://www.fsf.org/bulletin/2021/fall/the-fundamentals-of-t... ), reproduced below:

> Simply put, the AGPLv3 is effectively the GPLv3, but with an additional licensing term that ensures that users who interact over a network with modified versions of the program can receive the source code for that program. In both licenses, sections four through six provide the terms that give users the right to receive the source code of a program. These terms cover the distribution of verbatim or modified source code as well as compiled executable binaries. However, they only apply when a program is distributed, or more specifically, conveyed to a recipient. Using a program over a network is not "conveying." It is important to note that this only applies to the code running on the server, and not for example to the JavaScript programs that your browser may download and run locally — these are conveyed to you.

Some discussion a while back: https://news.ycombinator.com/item?id=30952949

[EDIT] - Altered the initial description, there's no requirement to merge upstream, just to make the code available!

The AGPL just forces you to make the source code of your changes available under itself. There's no obligation to get them merged upstream.

Thanks for this correction, updated the comment!

AFAIU there's no obligation to contribute upstream at all, just the need to provide the source such that anyone who wants to can contribute upstream. So you can't grab the code in your SaaS and extend it without making it available to the public.

For example the Truth Social was briefly in violation of AGPL when they took and adapted the Mastodon source code. Later on they provided a zip-file with the codes in it.

Thanks for this correction, updated the comment!

> The standard GPL already puts "restrictions" on the latter, but at least said restrictions only apply if I choose to distribute binaries.

You seem to have it backwards. The GPL and the AGPL concern the relationship between the programmer and the users. They are specifically designed to:

1. Grant the users of the program the "four freedoms".

2. Forbid any third-party middlemen to strip the users of the program of these freedoms.

The second point is what separates permissive "google-friendly" licences and copyleft. It doesn't make a difference for the users, but it avoids third party distributors to strip users of the program of the four freedoms. In that sense, I'd say that copyleft really gives "more freedom" to the users (unless they intend to re-distribute the program and strip other users of the freedoms that the original author granted to them).

Users of AGPL software are thus assured that they will have the four freedoms forever, regardless of who distributes the program that they use.

Construing the GPL or the AGPL as "putting restrictions" to the users can only be done in bad faith.

> Personally, I probably would publish substantial changes to software regardless, but if the only thing I do is change a line of CSS, I also don't think it's right to force me to have to set up infrastructure to publish my modified source.

The modified CSS is already being distributed to the user, so I think the requirement is being satisfied.

Now, if you are producing CSS from a different source language, like SASS, you might have to provide that, as it would be the "preferred form of the work for making modifications to it" .

Similar logic would apply to minified JS, I think.

But in any case, your fear of having to set up infra is overblown. A link to a GitHub or Gitlab repo would suffice (you do have your changes under version control, right?), or a tarball in Google Drive, or any number of other "dumb" solutions. And keep in mind that none of this applies unless your deployment is public- (or client- or customer-) facing. If your use of the modified software is internal to your organization (which includes employees, contractors, and even vendors) the changes can stay private.

Reply on news.ycombinator.com