If one is interested in the 'hosting is distribution' aspect of the license, but you don't want the anti-Tivoization, what are the alternatives to the GNU Affero General Public License?

The original Affero General Public License version 1 is still around. It's incompatible with GNU GPL licenses. But, in a broken way? What are the consequences of that?

If you only use non-GPL code or GPL code with library exception clauses, you can still distribute as .deb or AppImage, I suppose?

Edit: I'll clarify my situation. I wrote the MQTT server FlashMQ. It's currently AGPL3, but I'm looking to change it. The reason is that for its original intent, it's a server program. And if it doesn't have network-copyleft, I might as well give it the unlicense, because who cares about distributing binaries.

But, now it's also going to be use embedded in IoT devices and they have laws to follow. GPL3 rules simply don't work.

I have two cares:

  • Any user interacting with FlashMQ needs to be able to see what they're interacting with.
  • For anybody taking the project to host it; to quote Linus Torvalds with my addition: "I give you source code, you give me your (hosted) changes back, we're even".

Speaking of Torvalds, he said that the FSF lied to people when it comes to invalidating Tivoization, for the same reason mentioned in a comment below: people can fork the project and use the full AGPL3 and then I can't take back the changes.

  • @planetmaker ok, done.
    – Halfgaar
    May 13 at 2:15

1 Answer 1


If you have a license that is slightly too strict for your purposes, you can combine it with a license exception. For example, the LGPL-3.0 is such an exception for the GPL-3.0. The A/L/GPL-3.0 license family allows the license to be combined with additional permissions (see section 7).

If you want to permit Tivoization, you could have a lawyer draft up a suitable exception from the relevant A/GPL-3.0 section 6 clauses.

Of course you can also use the original Affero license – there's probably no legal problem here. However, do note that the Apache-2 license is incompatible with older GPL-family licenses due to conflicting patent clauses. Using old licenses also misses out on other improvements in the meanwhile, for example with clearer definitions, and better adaptation to non-US jurisdictions. Finally, consider that unusual licenses make it more difficult to other people to use, modify, and share the software in novel ways, which would typically be the entire point of publishing it as Open Source. AGPL-1.0-only is a dead end when it comes to license compatibility, though AGPL-1.0-or-later would at least allow downstream changes to use the more well understood AGPL-3.0 terms instead.

There are a couple of other network-copyleft licenses, though none are as popular with the AGPL-3.0. Blue Oak has a list of "network copyleft" and "maximal copyleft" licenses, though I think that list contains some licenses that aren't network copyleft, and some licenses that aren't Open Source.

  • "However, do note that the Apache-2 license is incompatible with older GPL-family licenses" -- Is this in error? This is the only mention of the Apache-2 license here.
    – ecm
    May 12 at 13:36
  • 2
    @ecm It is not. It's just that the Apache-2 license is a widely used license that is typically recognized as "permissive", but is nevertheless incompatible with GPL-2.0. If OP were to combine Apache-2 and AGPL-1 covered components into a single program, that would be a problem.
    – amon
    May 12 at 13:44
  • 2
    This answer looks great to me; I might only add that if you permit Tivoization via a section-7 (A)GPLv3 exception, some downstream derivative/distribution could remove that permission in the future from their branch of development. (But they could also add Tivoization restrictions to their derivative if you use a permissive license, so it's not terribly different.) And it's this ability to remove extra permissions that allows your software one-way compatibility into vanilla GPL-wthout-exceptions.
    – apsillers
    May 12 at 16:25
  • Good answer and comments. I'll have to analyze it. I thought the invalidation of Tivoization was a 'lie' though. See the edit in my original question.
    – Halfgaar
    May 13 at 2:18
  • 2
    @Halfgaar I think my comment is in line with Linus: allowing Tivoization is a permission on top of the GPLv3, that you're free to grant, but recipients will be bound by the most restrictive policy in place: if 99 contributors go beyond the regular GPLv3 permissions and allow Tivoization, but 1 from an outside project does not allow it (as is the GPLv3 default) then software that uses those 100 license grants can't be Tivoized on account of the 1 "can't". (But the 1 can pull in the other 99, because they're 1-way compatible into default GPL, just like all licenses more permissive than the GPL.)
    – apsillers
    May 13 at 4:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.