The falsehoods of anti-AGPL propaganda (2020)
drewdevault.com
drewdevault.com
- where is the line between "config" and "program". If i take the license literally, why wouldn't my db password be considered part of the derrived work? More generally, many programs have actual code as config. Where is the line?
- security issues - if there is a security issue and it has an emergency patch but there is some coordinated disclosure going on so its not public yet, is this an agpl violation?
-antispam meassures - antispam stuff tends to benefit from security through obscurity. Can i embed antispam checks directly in the agpl source without revealing.
Configuration is just a short artifact. It's not a creative work and is therefore not copyrightable at all, whether by AGPL or otherwise.
> if there is a security issue and it has an emergency patch but there is some coordinated disclosure going on so its not public yet, is this an agpl violation?
No because:
- if you are coordinating with the developers, then you have their explicit permission to temporarily withhold those changes (AGPL copyright holders can still grant exceptions to the license)
- AGPL does not mean you must provide up-to-date source code in an automated matter; you have to be able to provide the source code upon request, and there's nothing in the license preventing any forms of delays (much less so for ensuring security of users)
> antispam stuff tends to benefit from security through obscurity. Can i embed antispam checks directly in the agpl source without revealing
I'm not convinced obscurity helps against spam at all. DKIM and blocklists have done much more against email spam than any form of "security by obscurity" corporate scheme has.
However, if the logic is separate from the configuration, you would have to publish the edited source code (the logic), but could retain the actual configuration (because once again, configuration is not copyrightable).
I'm doubtful. For example https://github.com/wikimedia/operations-mediawiki-config is wikipedia's config. It is not short, and much of it is complex enough i think it would be copyrightable (ianal)
I agree though a very traditional list of key value pairs that are simple facts like where to find the db, might lack creativity to be copyrighted (ianal). But how many real deployed systems have that simple a config. More generally i would prefer that the license was less ambigious about this especially in an international context (e.g. rules are totally different in uk over what can be copyrighted)
> I'm not convinced obscurity helps against spam at all. DKIM and blocklists have done much more against email spam than any form of "security by obscurity" corporate scheme has.
Gmail et al use techniques beyond dkim that are secret. However i meant more like web spam where you can't just rely on source vouching for users. For example on wikipedia there is a feature where admins can write "code" that block patterns in edits. When used against persistent vandals, they are often secret lest they use the info to adjust behaviour. That's the type of thing i mean.
> if you are coordinating with the developers, then you have their explicit permission to temporarily withhold those changes (AGPL copyright holders can still grant exceptions to the license)
That only works if one entity holds all the copyright. Even then, does that mean forks cannot have coordinated disclosure?
The AGPL v3 says:
>... your modified version must prominently offer all users interacting with it remotely through a computer network .... an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge.....
> if there is a security issue and it has an emergency patch but there is some coordinated disclosure going on so its not public yet, is this an agpl violation?
When you have the permission from all copyright holder to make an exception to the AGPL you do not have to publish the source code. Otherwise you have to publish it. If it is an open source project with many contributors and the copyright stays at the original authors getting such a permission is practically impossible.
I think it does, if you modify the code. From section 13 of the AGPL:
"Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software."
If you do not want to provide the user directly a current copy of your source code to downloaded, you can "accompanied [it] by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software".
Then you should be able to fulfill a request for the source code used at an exact date and time 2 years ago even when you already discontinued the product and let go of all people involved. If such a request comes from controlled country like Iran or a recently banned company like Huawei or ZTE it could also get funny for your legal department.
I am not a lawyer, please consult one if you want to find loopholes in contracts.
Imagine getting a (binary) copy of GCC and the README said —
this is version X.Y.Z. Please wait up to two months to download the source code. Until then, you can download the source code for X.Y.Z-2.
IANAL either, but my interpretation was always that you had to treat AGPL code in the same way as GPL, except for the fact that access by remote/internet users was considered a distribution.
Just like sibling commenter haukem pointed out, GPL does not mandate that you distribute the source code alongside the binary, as long as there is an official channel to request the source code.
GPL license predates version control, and code often had to be snail-mailed at the time. This can lead to funny situations like famous hacker Naomi Wu dropping by hardware manufacturer offices to get the GPL source code. [0]
So yes, you could distribute a binary version of FunnySoft v1.3, and it could take a few days/weeks/months to get a copy of the actual source code.
[0] https://nitter.snopyta.org/RealSexyCyborg/status/14287069892...
Companies wouldn't use security by obscurity if it didn't work. Obscurity definitely increases the time investment needed by attackers.
> 13. Remote Network Interaction; Use with the GNU General Public License. Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.
Here is the full diff between the two license texts: https://www.diffchecker.com/cV5JfP5H
It was a SaaS that I was fine with letting end users copy and tinker with but didn't necessarily want big companies to do the same. Now that's obviously against Free Software, but I couldn't be arsed to deal with the nuances, and I found that at least for a SaaS that you'd like to make money off of, proprietary is the likely way to go.
If you're talking about Libre Software then you were totally right in picking the AGPL: the goal is to put the user in control, not intermediaries. A big company providing a service through your software is not a user so you don't owe them anything. AGPL is actually the best license because if a company uses it, they must give their users the freedom you wanted to give users in the first place.
> I found that at least for a SaaS that you'd like to make money off of, proprietary is the likely way to go.
The always-renewed armada of email providers, all of them being just a slight variation of the same stack (postfix/dovecot/cyrus/rspam/any unix). It's the same for pretty much any internet service: I do believe that if it weren't for Open Source (not Libre Software), half of them wouldn't have taken the time and money to develop the necessary bricks. Google, Facebook, Twitter, and their monstruous influence, were made possible due to Open Source licenses that voluntarily didn't want to care about the user specifically.
The success of your business will be orthogonal to the licence you choose. You are providing a service, ie making sure the software runs, isn't slow, is at the last secure version, allows people to register etc... none of which depends on whether your software is Open Source or not.
IMO open source developers writing code on their free time for the common good or just for fun should make sure with a licence like AGPLv3 that their work isn't appropriated by fundamentally immoral corps to increase profits.
It isn't a badge of honor that a FAANG uses your library, it's just exploitation.
Unfortunately, the GPL and AGPL suffer from the same flaw: they don't rigorously define what a derivative work is. The way the licences are written they make the definition seem self evident, but it's self evident the way porn is self evident - everyone knows it when they see it.
For example, from the way the GPL is written, dynamic linking to something makes it a derivative work, but invoking services from a http server is not. So how about I circumvent your GPL licence by putting an RPC shim layer than talks over http?
Some projects have solved the problem by drawing their strict demarcation lines. For example, Linus has publicly stated on numerous occasions that using the kernel user user space API does not make a user space program a derivative work of the Linux kernel. Somewhat more dubiously, they seem to tolerate kernel modules that use GPL kernel symbols only. I've convinced myself that strong, clear demarcation is fundamental to Linux being accepted everywhere.
The reason this is important is when you say "choose to not modify the software", the software in question is the original software or any derivative work. The problem is there is no clear definition of when your code becomes a derivative work. If you give a lawyer that much wriggle room and put enough money up as the prize, and you end up spending 10's of millions defending lawsuits from Oracle's lawyers trying to wriggle through an "API is copyrightable" loophole.
A GPLv4 that insisted the licence holder clearly define what they consider to be a derivative work would IMO be a big step forward in copyleft licences. Oh and get rid of the "Installation Information" requirement, or at least make it compatible with code signing. A device defending itself by insisting any binary it runs is signed by a trusted source is not compatible with defining the private keys securing the signature are "Installation Information".
A GPLv4 without the installation requirement would not be a license that advances the goals of the FSF and the wider Free Software movement, which is to empower software users and users who can't install software are not empowered. Its definitely possible to use signing with GPLv3, just do it like UEFI Secure Boot devices do and allow users to enroll new signing keys.
Yes, I've seen that same statement rolled out on LWN. Who knows, it in principle it might even be correct.
In practice at best it's plain misleading. Neither the Law nor the courts get to have any input if the copyright holder doesn't bring the matter to their attention by suing. The choice about whether to enforce it or not is entirely up to the copyright holder.
Further, the GPL isn't claiming additional rights that might be dubious under copyright law. If the copyriht holder chose to enforce those right in a court of law they almost certainly be challenged. Instead, it's giving away rights. You have _always_ been allowed to give away rights. That's what you do when you sell something - you allow someone to take a copy in exchange for money.
The GPL is actually an agreement to not enforce copyright under some circumstances. In fact it's not too different to the backup clause in Microsoft's standard agreement. The standard agreement explicitly you may not take copies of Microsoft's software - but backups are an exception.
Now I'm not lawyer, so I'm merely guessing that if Microsoft decided to sue you anyway for taking backups they would lose.
Part of the problem arises in my use of the "derivative work". I'm copying the wording in the GPL, but really I assuming whatever the GPL is claiming is a derivative work really is a derivative work under copyright law. What I'm really saying, is that I won't sue you for copyright if you only use the derivative work in way I specify, such as only using it via a well documented API.
There is nothing new about this. Arguably the GPL, AGPL, and LGPL only differ in how they say you can use the software in question. All I am saying is that's turned out to be too ambiguous. I'd much prefer the licence define allowed usage in a way a machine check. For example, if you only call symbols defined in this .h file, you don't have to make copies available. Or (and the GNU compilers do this), you can use the compiled output of the compiler even though they are derivative works (because they contain statically linked parts of crt.o).
This argument about you can't do that because copyright law defines what a derivative work is, is a complete red hearing.
> A GPLv4 without the installation requirement would not be a license that advances the goals of the FSF and the wider Free Software movement, which is to empower software users and users who can't install software are not empowered.
The entire thing was about TvIO. It was never about preventing you from installing software in general. It could not be - the software was open source. The whole point of open source is I can modify it and install it on any device that let me do so. It was a particular _device_ that was locked down - not the software. You may be right is saying the FSF wanted to leverage their control of software licences into controlling the devices as well, which they did by demanding you provide private keys. I'm not the FSF - I can't say. What I am saying is that IMO, it was an overreach that hurt GPLv3 adoption. Without that clause I suspect the GPLv3 would have been adopted far more widely, and I think that would have been a good thing.
> Its definitely possible to use signing with GPLv3, just do it like UEFI Secure Boot devices do and allow users to enroll new signing keys.
We get back to the point above - what the copyright holder allows is not determined by a court of law. They can allow whatever they please, because if they don't bring it before a court the courts, the lawyers and the law don't get to have a say. The courts do determine what they can enforce - but that's not what's going on here. What is going on is no one has brought a law suit against Microsoft for signing Debian's secure boot loader with a key they won't reveal. And it seems very unlikely that will ever happen. But if someone did bring such a suite - well whether it was enforceable would be determined by a court of law.
My guess from how the GPLv3 is written is it would be enforceable. My opinion irrelevant of course - but the big app stores also apparently believe it would be enforceable, so they ban the GPLv3 from their stores. And if I were them, I would too - the risk is far too great.
Even having that nail in my tool chest is a liability. I wouldn’t buy those nails to begin with.
One cannot argue that all C programs must be GPL'd because GCC or Emacs uses main() or malloc().
In GPL, as far as I understand, if you release a product containing GPL-licensed software, the whole product needs to get released as GPL. Some people love this copyleft approach (RMS), some hate it (as it is a viral license, "infecting" other parts of the codebase). For using it is a library, it is usually a no-go (for virtually all commercial products, and any open source project that wants to keep a more permissive license, e.g. MIT).
> The Free Software Foundation (which holds the copyright of several notable GPL-licensed software products and of the license text itself) asserts that an executable that uses a dynamically linked library is indeed a derivative work.
LGPL seems to make (IMHO a very sane and desirable) distinction:
> A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.
How does AGPL approach this subject? Or rather - is it closer to GPL or LGPL, when it comes to the definition of "derivative works"?
(I am not a lawyer; quotations are from Wikipedia)
However, just because FSF thinks linking is enough to make derivative work doesn't mean it necessarily is. I have come to think that GPL isn't good license because of how horribly underspecified it is in that regard.
Exactly. In the EU "linking two programs does not produce a single derivative of both (each program stay covered by its primary licence)" because Directive 2009/24/EC allows this: "any portion of code that is strictly necessary for implementing interoperability can be reproduced without copyright infringement." https://joinup.ec.europa.eu/collection/eupl/matrix-eupl-comp...
On the other hand if you view the license as a contract, I believe it can make arbitrary demands about the license of other (non derivative) software.
edit: actually even if you consider it a contract it probably can't prevent you from doing something that is allowed by the law, so it can't affect the license of other software. I'm not a lawyer.
For example, in principle a screenshot would be a perfect example of a "fair use" for citation/reference. In practice, lwayers tend to disagtee - as "a small part of a work" is something horribly unspecified.
Of course, if you are Google/Facebook/Apple or so, you can do as you wish. (Unless you are at risk of a legal war with another corporation.) So because they use it in a given way does not mean that you will be able to defend yourself the same way.
As for the LGPL, that one was originally made for libraries (Library GPL), but the FSF changed the name, because they don't want to encourage its use in libraries by default - many libraries are indeed LGPL, but others are not.
If you want to your program to have the best possible commandline support, as an example, you can use the same library as the bash shell does, but only if your program is GPL.
tldr: The top comments mentioned corporate lawyers concluding AGPL ("corresponding source") was too much of a risk and subsequent replies debate about it being FUD.
I also ran across an blog article (by an attorney who writes about open source licensing) saying AGPL can be hard to understand: https://writing.kemitchell.com/2021/01/24/Reading-AGPL.html
The issue with the AGPL is that you really need to be a lawyer to understand the nuances. What constitutes a “derived work”. What is the precedent for what is a “derived work”?
With MIT, BSD, you put in the attribution and call it a day.
Where exactly and how do you need to put the attribution?
You still need to be a lawyer to be able to answer this question.
Meanwhile many project just copy paste MIT and BSD code and just "forget" the attribution.
https://github.com/mastodon/mastodon/issues/49#issuecomment-...
1. Every major free software license I can think of before AGPL triggered its source provisions on distribution. (I said "major" because I haven't examined every free software license, but I don't actually know of any that weren't triggered solely by distribution).
Placing conditions in your license on what you did with the software other than distributing it were usually considered to make your license a non-free license.
2. I can't think of a principled way to justify AGPL's triggering specifically on "remote interaction through a computer network".
Say I take a weather model program that is under AGPL, modify it to work better for forecasting weather in my region, and start a service to provide local forecasts. Users provide their address, and for a fee I provide them with a local forecast for that location.
There are several different ways I might offer this service.
A. They can stop by my kiosk in the mall, where I have several PCs running the model. They can enter their information on one of the PCs and it prints their forecast on a printer connected directly to the PC.
B. They can send me a mail via the post office asking for a forecast. I mail one back via the post office.
C. They can send me an email asking for a forecast. I email one back.
D. Same as A, except the printer is not connected directly to the PC. It is connected via a WiFi network.
E. I have one PC in the kiosk, with several terminals connected to it via WiFi. The customers use the terminals.
F. Similar to E, but I have the terminals spread out at several convenient locations throughout the mall, all communicating via WiFi with the PC running the model.
G. The PC serves a web page via a public WiFi network I offer in the mall. This network has no internet connectivity.
H. The PC serves a web page over the internet, but you have to be at the kiosk to actually order and receive a forecast.
I. The PC serves a web page over the internet, on which you can order and receive you forecast from anywhere.
J. The call me on the phone, give me their address, and I read the results to them. This is really 3 cases. J1, they and I are using modern cell phones. J2, they and I are using modern land lines. J3, we are both in an area with a very old all analog phone system (so while the phone system may be a network, it is not a "computer network").
Under AGPL I definitely have to provide source for case I.
It is not clear for cases C, D, E, F, G, H, or J. They all raise questions of what is an interaction, what is remote, what is a computer, what is a network, and what is a computer network.
I do not have to provide source in cases A and B.
In all cases the same overall thing is being accomplished: people ask for a forecast using the modified AGPL program running on my computer, the program runs, and the output is given to the person.
I find it aesthetically displeasing and philosophically ridiculous to have a license depend so much on the minutia of exactly how the information between the user and the program is transmitted.
1. It contains all the source provisions of GPLv3, which are triggered on distribution (both of modified and unmodified versions).
2. A provision that is not in GPLv3 that is triggered on users interacting remotely through a computer network with modified versions. This is section 13 of AGPLv3:
> 13. Remote Network Interaction; Use with the GNU General Public License.
> Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.
> Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License.
You're missing the point. They aren't choosing between the AGPL and Oracle's EULA. They're choosing between the AGPL and other open source software licenses.
First, every time some AGPL code has to change, a business has to review the amount of work that will go to it (patch or rewrite and replace), review the patch including legal review, etc.
Secondy, this requirement resticts my freedom. If the same code is licensed under a permissive license, I wouldn't have to do anything. Once it's approved for internal use, the overhead of dealing with OSS is almost gone.
Regardless of Google's falsehoods, it's undeniable that a permissive license doesn't restrict my freedom. And that's it - I don't need more anti-AGPL propaganda to avoid its use. If I can use the MIT or Apache or BSD licensed code, I will. Even if it's slightly worse, I'll pick it over AGPL-licensed code because in the mid and long term it won't cost me as much.
> Google wants to be able to incorporate FOSS software into their products and sell it to users without the obligation to release their derivative works.
Who doesn't? Why should anyone bother furthering your AGPL agenda over own interests and the freedom offered by permissive open source licenses?
I can't believe this crap topic comes up every so often.
This is plain false. AGPL code can be worked on just like any other license or your own proprietary product.
> Secondy, this requirement resticts my freedom
This is like being prohibited to kidnap other people. We are not allowed to do it because it would restrict other's people freedom down the line.
Another example is the https://en.wikipedia.org/wiki/Paradox_of_tolerance
As a society, we cannot have the freedom to access and modify code together with the freedom to lock down and proprietize code. They are in conflict.
> it's undeniable that a permissive license doesn't restrict my freedom
It is provably restricting mine. My android phone and many other devices are full of proprietary stuff that I cannot access, review and trust, despite being built with large amounts of FOSS.
Because the licensing allowed taking away freedom from the end user.
However, there are many cases where AGPL is the best solution. That is, when you plan to release an original piece of software, not just modify someone elses's project, and you specifically want to prevent companies like Amazon or Google to profit from it without giving you anything back. In this case, dual AGPL + commercial licensing is a good way to go.
People need to know this instead of blindly copying "Google says AGPL is bad so we must avoid it at all costs."
That might work if all you care about is making sure Amazon publishes their modifications to your software. The most common complaint though is Amazon offering support for the software, thereby removing the need for those who use the software on Amazon to purchase support from the original developer. Making your software AGPL doesn't help at all with that.
If Amazon offers support for your software on their platform, they can kill your support revenue even if they make no modifications whatsoever to your software.
Your freedom as a middle-man is not important. What matters for GNU licenses is the freedom of the final user.
> Who doesn't? Why should anyone bother furthering your AGPL agenda over own interests and the freedom offered by permissive open source licenses?
> I can't believe this crap topic comes up every so often.
You don't care about user's freedom but only yours, other people feel the opposite. There is ample space for a discussion on both viewpoints.