> That’s pretty easy, right? I’m positive that your business has to deal with much more onerous contracts than the AGPL.
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.
I think you're both right. AGPL is worse for any SaaS business if you plan to build it around your modifications of that software, period. That's very simple and I think nobody disagrees with it.
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."
> 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.
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.
But this is not related to licensing: anyone can offers support for any piece of software and, as far as I can tell, there is no way to prevent that in a license. Otherwise Oracle would have eliminated Rimini Street years ago (the only thing they got is $90M in the recent lawsuit which is almost nothing).
> 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
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.
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.
> Obligatory: I’m not a lawyer; this is for informational purposes only.
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.
Agree with the ignorance for attribution demands. Apache 2.0 is also everywhere yet nobody takes it seriously (it demands a lot!) and just treats it like the 1-clause BSD license.
From my experience most commercial software licenses are much harder to understand. Especially if you want to redistribute commercial software and do not want to pay for it, it gets very complicated.
The thing that's really unclear to me about the agpl:
- 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.
> If i take the license literally, why wouldn't my db password be considered part of the derrived work?
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).
>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)
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."
I am not a lawyer, but i don't think anything would prevent you from waiting to update that source code. You could for example say "The source code provided here dates from XX/XX/XXXX and may be slightly out-of-date in regards to the latest security patches. Updates to this repository are pushed no later than 2 months after being applied on the server, and such delay is only incurred when dealing with security patches as part of a coordinated disclosure strategy with upstream project Y".
I believe there is no such provision in the APGL for a reasonable period of time/delay. Unless there is an exception in the license, one would need to give remote users the source code for the exact version of a program they are interacting with. It is no different from the traditional GPL in this regard.
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.
> Imagine getting a (binary) copy of GCC and the README said (...)
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.
I think it is the same as the GPL v3, at least these sections do not differ. See section 6.
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.
Antispam and fraud detection definitely benefit from security by obscurity. It is essentially an arms race between you and the spammers, with the goal of making spam and fraud too expensive to bother. Any extra work that your opponents have to do directly makes your work easier.
I think this answer is wrong or very dangerous, but I am not a lawyer.
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 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?
This post makes it seem like only big bad megacorps like Google (and people drinking their kool-aid) would have an issue with AGPL, even though you can definitely find individuals who object to it as well. marcan for example has been vocally against AGPL on multiple occasions.
Honestly, I initially wanted to make my software AGPL because it seemed quite attractive, but all these problems, or supposed problems even, just made me not want to deal with it and I made the software proprietary instead.
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.
I witnessed this. There was a process to submit licenses to legal. People didn't follow the process and their projects were killed off just prior to completion as audits would surface licenses. This happened multiple times. People tried to argue with legal, but they wouldn't even entertain the conversation.
This is good to know and precisely the reason I use AGPLv3 whenever I can.
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.
Its not exactly hard to comply with the AGPL. Just choose either to not modify the software, or if you do then link to the git repo you store the changes in.
> Its not exactly hard to comply with the AGPL. Just choose either to not modify the software
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".
The phrase "derivative work" comes from copyright law, so it isn't up to any one software author or license author to decide what "derivative work" means, that is for the law and the courts to decide.
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.
> The phrase "derivative work" comes from copyright law, so it isn't up to any one software author or license author to decide what "derivative work" means, that is for the law and the courts to decide.
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 go...
> 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
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.
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.
> all you have to do is provide a link to the upstream source code somewhere,
Again this is not true, another blog telling us all about AGPL who doesn't understand it. You don't have to provide source unless you as the host modified it.
This race to abuse AGPL to attack a website is pretty much the state of IT and licensing. Very clever they made a mistake so you get to use AGPL against it's intent to attack them, the IT community is just the lousy RIAA and MPAA.
I just hope they are clever back and refuse to hand the code over through their clear legal loophole. If the host bought modified code from a consultant they don't have to share that code and neither does the consultant.
If you were an architect, would you let your builders use nails from a manufacturer that required the designs of your buildings be released if a single said nail was laid?
Even having that nail in my tool chest is a liability. I wouldn’t buy those nails to begin with.
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)
AGPL uses GPL wording, it is basically GPL with extra clause.
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.
Laweyers tend go on "the safer side" so to include the most broad definition of "derivative". (As in general: the most pessimistic interpretation of any underspecified clause.)
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.
> However, just because FSF thinks linking is enough to make derivative work doesn't mean it necessarily is
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.
The main difference is that the AGPL requires you to get a copy of the software source code if you interact with it over the internet. That doesn't mean that the software you use to access it becomes part of a derived work, just that you should have access to it the same way that somebody should have access to it if they had a local copy, where the software is GPL.
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.
MinIO has switched their license to AGPL (the community is not happy https://github.com/minio/minio/issues/12143). The company behind the project is now contacting all users and tells them to pay for the commercial license. They try to make the users feels insecure about the way they use the product. They don't tell you that you are violating the license, they tell you to check with your legal, etc. So most companies will finally just buy it.
This is also a way the AGPL is used: commercial interest, not user freedom.
And what's wrong with that? At the end of the day, they need revenue to continue development. And this is a good balance between allowing FOSS use-cases whilst not allowing free-loading from proprietary, commercial uses.
I understand the need for revenue but starting your commercial relationship with a fraud will not turn out well. I think it would better to show the benefits of buying a license like support or influence in development.
The main difference between the GPL v3 and the AGPL v3 is this addition:
> 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.
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 may understand the various licenses and their limitations, if even fuzzily.
But whenever I talk to business owners, they're shocked at the terms in GPL and AGPL. I don't mean surprised, I mean shocked - they thought the code was "free" with no attribution or distribution requirements, and are deeply upset. Typically they say, "Why didn't anybody tell me? How did this happen?"
And it becomes a big deal when told they need to distribute any of their code.
At Apple, their policy for decades was to not use GPL software. When they bought other companies, the first thing they did was to rewrite any software even touching the GPL.
Note that MySQL is used everywhere across Apple now, so that's one exception that I can think of, but they can get a license from Oracle (Apple has a close contractual relationship with Oracle, from decades of Oracle Enterprise porting, and internal distribution, and MRP products.)
Note that MySQL AB re-licensed their client library from a permissive license to GPL to drive revenue from their dual licensing strategy. There is an old fork available.
58 comments
[ 2.9 ms ] story [ 123 ms ] threadYou'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.
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.
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.
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.
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.
- 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 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."
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...
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.
Companies wouldn't use security by obscurity if it didn't work. Obscurity definitely increases the time investment needed by attackers.
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'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?
https://github.com/mastodon/mastodon/issues/49#issuecomment-...
https://twitter.com/marcan42/status/1384834585834319875
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.
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 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.
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
Again this is not true, another blog telling us all about AGPL who doesn't understand it. You don't have to provide source unless you as the host modified it.
Read it for yourself -https://www.gnu.org/licenses/agpl-3.0.en.html
This race to abuse AGPL to attack a website is pretty much the state of IT and licensing. Very clever they made a mistake so you get to use AGPL against it's intent to attack them, the IT community is just the lousy RIAA and MPAA.
I just hope they are clever back and refuse to hand the code over through their clear legal loophole. If the host bought modified code from a consultant they don't have to share that code and neither does the consultant.
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.
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.
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.
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.
> 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
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 may understand the various licenses and their limitations, if even fuzzily.
But whenever I talk to business owners, they're shocked at the terms in GPL and AGPL. I don't mean surprised, I mean shocked - they thought the code was "free" with no attribution or distribution requirements, and are deeply upset. Typically they say, "Why didn't anybody tell me? How did this happen?"
And it becomes a big deal when told they need to distribute any of their code.
At Apple, their policy for decades was to not use GPL software. When they bought other companies, the first thing they did was to rewrite any software even touching the GPL.
Note that MySQL is used everywhere across Apple now, so that's one exception that I can think of, but they can get a license from Oracle (Apple has a close contractual relationship with Oracle, from decades of Oracle Enterprise porting, and internal distribution, and MRP products.)
Note that MySQL AB re-licensed their client library from a permissive license to GPL to drive revenue from their dual licensing strategy. There is an old fork available.
Source: ex-Apple.