It might be GPL but I would guess it's not AGPL. AGPL requires you to open source the code to run the service. They've not done that. Their legal people are likely on top of this. It's not hard to run a SaaS and avoid all AGPL
I mean my end users never interact with that service. They interact with a - let's say - proprietary one. And that service is the client to the AGPL service.
Or anything AGPL touches turns into AGPL? What is considered touching? If I use an AGPL firewall do the packets turn into AGPL? If I use an AGPL log aggregator? Or an AGPL centralized identity management thing every other service that auths turns into AGPL?
Furthermore the combining with other works is not clear in on GPL3 cases.
When combining happens and when doesn't? What happens if I combine it with proprietary software?
I wonder if it's about control. With a SaaS you can switch to a competitor. It's possible to switch between GNU/Linux distros and the companies that support them. Change is possible. This can protect you from a vendor tanking or who has bad behavior.
Oracle is an outlier. They aren't going away. There's enough business to keep them around. And, many companies are trying to get away from them slowly.
When you have an AGPL and commercial dual license it puts that vendor in control. Do big businesses like putting others in a position of power and control over them? If that business is small or a startup do they want to have that as a hard dependency? Is it a risk to the big business?
This isn't about paying for commercial licenses. It's about risk mitigation. Something big businesses do a lot of.
> 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.
So that's about who you have to give the source code to if you modify the program, right? But isn't the salient point there that it only matters if you make modifications? Why should anybody who is using the software unmodified care about that at all?
And all the stuff about "what is linking" would be the same as it is for the ordinary GPL, would it not? The "Source Code" section of both licenses are word for word identical, anyway.
It all seems like a lot of FUD from people who don't like the AGPL because it requires them to follow the spirit of the ordinary GPL when they actually do make modifications but then use them in a public-facing service instead of distributing them as a software product, i.e. when it does exactly what it's intended to do.
The other point is that the intention of this license is explicitly to prevent people commercializing software licensed this way through proprietary extensions, additions, etc. The whole point of the license is to make that difficult/impossible. If you use AGPL software, you have to respect this intention.
Gplv3 is also not that popular with legal departments for the same reason. Even Gplv2 is generally frowned upon but better understood since there is a fair bit of case law around it and known ways of dealing with it when e.g. shipping binary kernel modules with an OS, which is one of those legally grey areas where you have to depend on legal interpretations of the license. Gplv3 was explicitly written to close some of those loopholes in Gplv2: they were unintentional.
So, this is not FUD but basically lawyers doing their jobs and they are fairly consistent in their reservations with respect to this license across the industry. You talk to lawyers in any fortune 500 company and they'll probably will be very reluctant to sign off on any AGPL dependencies.
> The other point is that the intention of this license is explicitly to prevent people commercializing software licensed this way through proprietary extensions, additions, etc. The whole point of the license is to make that difficult/impossible. If you use AGPL software, you have to respect this intention.
That may be true, but why should you care if you are not actually doing that and are only using the software without modification?
> Even Gplv2 is generally frowned upon but better understood since there is a fair bit of case law around it
It is pretty uncommon for there to be existing caselaw interpreting a given software license. Proprietary software licenses are commonly unique to the software, sometimes even unique to the customer. If this is a concern then shouldn't a widely used form license like the AGPL be an advantage, because then it's more likely the first time a court has to interpret the text will be in somebody else's case and not yours?
> So, this is not FUD but basically lawyers doing their jobs and they are fairly consistent in their reservations with respect to this license across the industry. You talk to lawyers in any fortune 500 company and they'll probably will be very reluctant to sign off on any AGPL dependencies.
Have you experienced asking lawyers for their opinions on contract text? You'll generally get back a document identifying various concerns with just about every provision in the text, because that's their job.
For example, here's a fun provision from the Windows 10 license:
> [you may not] use the software as server software, for commercial hosting, make the software available for simultaneous use by multiple users over a network, install the software on a server and allow users to access it remotely, or install the software on a device for use only by remote users;
What does that mean? How will a court interpret it? Should corporations avoid Microsoft Windows as a result, because they might violate some interpretation of the license and then be liable for copyright infringement?
Lawyers having concerns about license terms is par for the course. What you haven't established is what makes the AGPL unusual in that regard, as compared with the above or a hundred other provisions in various other licenses.
FUD would be spreading unreasonable fear and uncertainty to create doubt.
The thing you don't seem to get about these licenses is the generally fuzzy language about derivative works, distribution, and modifications. The legal interpretations vs. the intent of the authors vs. the technical interpration of these licenses are three things. An engineer saying, "it's fine" means absolutely nothing. These licenses are versioned for a reason: the intent and legal reality apparently don't always line up and people try to fix these things.
The key point of the AGPL license is that it deliberately intends to prevent proprietary bundling/extensions of software licensed that way by demanding it is open sourced under a similar license (aka. the viral nature of the license). Gplv2 had similar intentions but contained enough ambiguity and weaker requirements that gave clever lawyers enough wiggle room to get away with e.g. creating things like Android which definitely has a lot of proprietary stuff covered in patents and other things. Hence, GPLv3 which aimed to rectify some of these ambiguities.
And yes, I have experience being lectured on this by actual lawyers (with a clue no less) in the context of Nokia's OSS efforts a few years back around their linux based mobile os. They had thousands of engineers collaborating with the OSS community on hundreds of projects with all sorts of licenses. Their job: protect Nokia's IP and prevent inadvertent legal fall out with patents, copyrights, etc. due to improperly licensed software. I learned a lot talking to and listening to these people.
In short their attitude was, MIT/Apache is generally fine. Gplv2, you need to know what you are doing but we know how to deal with this and mitigate potential risks. Gplv3: please avoid adding anything with this license to any Nokia product (patents were a big concern here). AGPL, no way in hell that we would approve this, ever; the risks are substantial and generally not worth it, even for server side only stuff.
Regarding the MS license; lets stay on topic and not digress about the legal saviness of their lawyers. Generally my advice would be to assume they can make life hard for you and thought long and hard about how they would do that. Any court case would likely set you back more than you or your company can afford.
What kind of interaction matters? Only directly interfacing with the Software through TCP/UDP (other OSI L4+ protocols)? What if I put a reverse proxy there? An API gateway?
Sure, courts can decide these things, they can make it intent-dependent and/or use some other weighing method.
https://github.com/moll/node-pg-error/issues/1
It also seems worthwhile to examine the differences between the APGL and the recently introduced (and much critiqued, albeit I find somewhat unfairly, in some aspects) SSPL:
1. https://news.ycombinator.com/item?id=18352171
2. https://news.ycombinator.com/item?id=18301116
The above should let you find the answers to your questions, but I'll use this comment to also point to some less on topic but still very much related to licensing granularity matters.
Compare the various FSF licenses to the OSET license:
http://www.osetfoundation.org/public-license
Two specific things I find rather atrocious about all the FSF licenses seem easiest to highlight by pointing out what the OSET license does to explicit avoid these pitfalls:
1. "Sovereign Immunity. Contracting with governments brings up a special issue that doesn’t apply to anyone else: normally, if you grant a license to government, you may not be able to sue for a violation because governments can be immune from legal claims. We ask recipients to waive this restriction, so there is a remedy if the recipient does not abide by the terms of the license. See Section 9.2 of the OPL"
2. "The OSET Foundation (then the “OSDV Foundation”) attained its full tax-exempt status under 501(c)(3) of the Internal Revenue Code declaring us a public charity in the 3rd quarter of 2013. In the course of seeking this status, as part of a negotiation⁴, we agreed to make certain changes to the license to ensure that our source code is free for everyone to use. Section 5.3 of the 2.0 license now requires that a licensee who does not abide by the terms of the license must make the Covered Software available in Source Code Form on a publicly available computer network for a period of no less than three (3) years. This goes beyond the source code delivery requirements of standard open source licenses. Section 5.4 reserves the ability of a licensor under our license to seek injunctive relief for violation of the terms of the license. It is not clear at this point whether a court could, under applicable law, order a violator to release source code. But we cannot control the law, only our license. Therefore, if that remedy is available under law, we want to make sure it is available under our license as well."
And then, even more peripherally related, none of the libre licenses I know have some variants for transcopyright, a licensing concept almost forgotten, and outlined by Ted Nelson, here:
http://www.youtube.com/watch?v=x3l7CpnpyGw
At this point, I really wish we'd have some sort of mathematically sound "mix and match" license generator, where you can pick what you want your license to do with extreme granularity, based on as detailed of a parameterization of what one might do with Software licenses in general, and get a standardised, reproducible license build.
There does exist this:
https://en.wikipedia.org/wiki/Rights_Expression_Language
But it doesn't actually really do what you might expect it to do.
For example, compare these two RDFs for the GPLv2, and the GPLv3:
https://www.gnu.org/licenses/gpl-2.0.rdf
https://www.gnu.org/licenses/gpl-3.0.rdf
The GPL v3.0 RDF pulls in http://xmlns.com/foaf/0.1/ as an additional XML Namespace, and has a logo, but in terms of the actual ccREL encoding, they seem completely identical, both just contain this:
<cc:requires rdf:resource="http://creativecommons.org/ns#Copyleft"/>
<cc:requires rdf:resource="http://creativecommons.org/ns#SourceCode"/>
<cc:requires rdf:resource="http://creativecommons.org/ns#Notice"/>
<cc:permits rdf:resource="http://creativecommons.org/ns#Distribution"/>
<cc:permits rdf:resource="http://creativecommons.org/ns#Reproduction"/>
<cc:permits rdf:resource="http://creativecommons.org/ns#DerivativeWorks"/>
Mostly, yes[0]. Parts of the package are under BSD, others FreeType license, others GPL etc.
I don't know which ones are used in imagemagick, so I can't say whether AGPL "infected" it.
[0] https://metadata.ftp-master.debian.org/changelogs//main/g/gh...