The terms of the AGPL are pretty easy to comply with(drewdevault.com)
drewdevault.com
The terms of the AGPL are pretty easy to comply with
https://drewdevault.com/2020/07/27/Anti-AGPL-propaganda.html
326 comments
I’ve taken AGPL through two FAANG reviews. Both arrived at the same very-much-not-FUD legal conclusion.
Paragraph 1 of section 13 requires modifications to be disclosed and source code for them to be offered to remote users. The license uses the term of art Corresponding Source for this.
Corresponding Source is defined in section 1 in a crystal clear way. Two separate teams of lawyers concluded that they could coherently argue the Corresponding Source definition implied not only the modified AGPL software, but also stuff that merely _uses_ it, on the basis that “scripts to control” among other things implies the infrastructure most shops build around software, such as Borg configuration and possibly by extension Borg. After all, a modified version of PostGIS is only useful to run in context, and Corresponding Source requires the context.
AGPL is unchallenged in court. The risk to being wrong about it as huge. It’s risk aversion, not ideology, and it’s important to remember that identifying an argument as part of legal review does not call it the correct one. Anyone who’s ever worked with legal matters knows there is no such thing as “correct,” there are rulings. The existence of the argument condemns the license for FAANG, not its validity. Testing that validity against a claim is perilous.
Perhaps if random engineers stopped calling legal opinion FUD and falsehoods and took a moment to listen to the feedback from lawyers who didn’t write the license, we’d get somewhere with finding a palatable license for all parties. Instead, we get a holy war.
Strong disagree on developers not shooting themselves in the foot. If it’s on GitHub, it ships. If you think about licenses in your day to day engineering, you are the 1%.
Paragraph 1 of section 13 requires modifications to be disclosed and source code for them to be offered to remote users. The license uses the term of art Corresponding Source for this.
Corresponding Source is defined in section 1 in a crystal clear way. Two separate teams of lawyers concluded that they could coherently argue the Corresponding Source definition implied not only the modified AGPL software, but also stuff that merely _uses_ it, on the basis that “scripts to control” among other things implies the infrastructure most shops build around software, such as Borg configuration and possibly by extension Borg. After all, a modified version of PostGIS is only useful to run in context, and Corresponding Source requires the context.
AGPL is unchallenged in court. The risk to being wrong about it as huge. It’s risk aversion, not ideology, and it’s important to remember that identifying an argument as part of legal review does not call it the correct one. Anyone who’s ever worked with legal matters knows there is no such thing as “correct,” there are rulings. The existence of the argument condemns the license for FAANG, not its validity. Testing that validity against a claim is perilous.
Perhaps if random engineers stopped calling legal opinion FUD and falsehoods and took a moment to listen to the feedback from lawyers who didn’t write the license, we’d get somewhere with finding a palatable license for all parties. Instead, we get a holy war.
Strong disagree on developers not shooting themselves in the foot. If it’s on GitHub, it ships. If you think about licenses in your day to day engineering, you are the 1%.
> AGPL is unchallenged in court. The risk to being wrong about it as huge. It’s risk aversion, not ideology, and it’s important to remember that identifying an argument as part of legal review does not call it the correct one. Anyone who’s ever worked with legal matters knows there is no such thing as “correct,” there are rulings. The existence of the argument condemns the license for FAANG, not its validity.
Having worked with lawyers, this largely overstates the risk. Companies are happy to discuss, modify and sign new contracts every day.
All these contracts are "unchallenged in court", by definition, because they are entirely custom.
A lot of software licensing contracts for closed source have complex and restrictive clauses to prevent "renting" such software through SaaS or weakening limitations using legal loopholes.
Yet companies still sign such contracts.
Another type of custom and complex contract is employment.
Furthermore, companies sue each other every other day over contract violation around IP, copyright, trademarks, patents but also employment contracts, rent, building regulations, shipment delays, all of that.
The idea that a FLOSS license is some scary monster is propaganda.
The goal of such propaganda is to drive the FLOSS community to provide valuable software for free and with zero strings attached - aka free labor.
Having worked with lawyers, this largely overstates the risk. Companies are happy to discuss, modify and sign new contracts every day.
All these contracts are "unchallenged in court", by definition, because they are entirely custom.
A lot of software licensing contracts for closed source have complex and restrictive clauses to prevent "renting" such software through SaaS or weakening limitations using legal loopholes.
Yet companies still sign such contracts.
Another type of custom and complex contract is employment.
Furthermore, companies sue each other every other day over contract violation around IP, copyright, trademarks, patents but also employment contracts, rent, building regulations, shipment delays, all of that.
The idea that a FLOSS license is some scary monster is propaganda.
The goal of such propaganda is to drive the FLOSS community to provide valuable software for free and with zero strings attached - aka free labor.
No, companies are not happy to discuss, modify, and sign new contracts every day. They are quite hesitant to. At Matasano, it became our practice simply to tell new clients we'd be happy to sign their paper and not ours, because we'd lose weeks just to get to the point where their legal would consider looking at our contracts. At my last company, we non-negotiably used our own contracts, and budgeted a month to legal review for every signup. New contracts are a big deal.
And, what's more, the contracts we're talking about are all basically pro-forma. They're nothing like the AGPL, which has, in reasonable interpretations, far-reaching impact on IP across the whole company.
And, what's more, the contracts we're talking about are all basically pro-forma. They're nothing like the AGPL, which has, in reasonable interpretations, far-reaching impact on IP across the whole company.
> No, companies are not happy to discuss, modify, and sign new contracts every day. They are quite hesitant to.
[citation needed]
> And, what's more, the contracts we're talking about are all basically pro-forma.
I had very custom employment contracts with 2 well-known large tech companies. When asking to remove some clauses and add new ones they did not flinch at the ask and let me have meetings with their lawyers.
I have many other examples but a quick search on the internet can show how many contract-related discussions happen between large companies, suppliers, local governments & so on
Matasano is not the size of a FAANG and similar or maybe it has a small legal team by choice.
[citation needed]
> And, what's more, the contracts we're talking about are all basically pro-forma.
I had very custom employment contracts with 2 well-known large tech companies. When asking to remove some clauses and add new ones they did not flinch at the ask and let me have meetings with their lawyers.
I have many other examples but a quick search on the internet can show how many contract-related discussions happen between large companies, suppliers, local governments & so on
Matasano is not the size of a FAANG and similar or maybe it has a small legal team by choice.
The authors of AGPL packages are also not the size of a FAANG! That's the point! If they were, they wouldn't be negotiating AGPL with Google; they'd be negotiating an actual contract.
(I have zero problem with AGPL and happily use it myself for things, but I use it the same way I feel most of my peers use it, as an explicit "no, FAANG, you can't use this code, pay me instead" marker.)
(I have zero problem with AGPL and happily use it myself for things, but I use it the same way I feel most of my peers use it, as an explicit "no, FAANG, you can't use this code, pay me instead" marker.)
>If they were, they wouldn't be negotiating AGPL with Google; they'd be negotiating an actual contract.
This would stop being true if (and when) FAANG figured out how to effectively use AGPL internally. In my opinion, this is inevitable as long as software continues to be published under this license. From their perspective it seems they don't even have to do anything besides wait for other smaller companies to get in legal disputes and set a precedent. Or better yet, wait for a potential acquisition to come along that happens to have won one of these disputes.
This would stop being true if (and when) FAANG figured out how to effectively use AGPL internally. In my opinion, this is inevitable as long as software continues to be published under this license. From their perspective it seems they don't even have to do anything besides wait for other smaller companies to get in legal disputes and set a precedent. Or better yet, wait for a potential acquisition to come along that happens to have won one of these disputes.
If you're trying to pivot this to a place where I'll concede that AGPL is a good thing, you're wasting energy, because I already think AGPL is a good thing. I'm not making this point about contracts because I'm motivated to talk down AGPL; I'm doing it because, in my experience over the last 15 years, it has definitely not been the case that companies are comfortable entering into arbitrary contracts. It's just not true.
Precisely. Also the negotiation takes a long time and usually the risk is not as high as agpl, since these contracts dont have clauses like 'all your ip is mine'(except one player here known to try to sneak such a clause in every time).
From doing many sales negotiations with companies, my experience has been nobody is _happy_ to modify their contracts. Full stop. They can be convinced to do so if you've got appropriate leverage, but time with lawyers is expensive, and hard to automate (currently). Employment contract changes are not the same as commercial contracts, nor the same as IP arrangements.
>I have many other examples but a quick search on the internet can show how many contract-related discussions happen between large companies, suppliers, local governments & so on
It would be surprising if these negotiations were accomplished within a small number of months. I am a small company (smaller than Matasano) and have had my contract accepted, but it is a non-trivial effort. There will certainly be items that come back, then they go to my lawyer followed by more discussion.
In the past, I did a contract negotiation with a very large (non FAANG) company and it took months, and required me to recruit internal advocates for my position.
It would be surprising if these negotiations were accomplished within a small number of months. I am a small company (smaller than Matasano) and have had my contract accepted, but it is a non-trivial effort. There will certainly be items that come back, then they go to my lawyer followed by more discussion.
In the past, I did a contract negotiation with a very large (non FAANG) company and it took months, and required me to recruit internal advocates for my position.
[deleted]
The remedy for a violation is also in play. Private contract between two companies, cutting a 10 figure check makes it all better. Being wrong about AGPL, you have to release a lot of code that you really don't want to release, that is very important to your core business.
That's the other side, uncertainty with acceptable error bars vs uncertainty with unacceptable error bars.
That's the other side, uncertainty with acceptable error bars vs uncertainty with unacceptable error bars.
> Being wrong about AGPL, you have to release a lot of code
That is also false scaremongering. You always have the option to simply cease distributing until you have re-implemented the AGPL code yourself.
That is also false scaremongering. You always have the option to simply cease distributing until you have re-implemented the AGPL code yourself.
I doubt "turn off Google Maps until we reimplement it from scratch" is an acceptable business continuity risk.
And most companies do resourcing months in advance on top of that. AGPL could have solved all of this with an explicit redress clause that wasn't effectively unbounded downside risk.
Google could certainly afford to implement a stub replacement library as a contingency plan, in case they really would be that worried about it.
The obvious solution is to completely reimplement the AGPL-ed software on your own, as a stub, in case the AGPL-ed software you want to use goes nuclear on you. Surely this will not cost a lot of developer time.
Unfortunately, many software companies obtain their revenue through the exchange of money for their software. This is like asking McDonals do stop serving food (and possibly recall all of the eaten burgers?).
A company which sells that much software can certainly afford to re-implement an AGPL component; or at least implement a good enough stub implementation to make the software run acceptably. Especially if, as Chris DiBona of Google claims, all AGPL software is useless and unneeded.
However, the point was that releasing the proprietary (oh so secret) source code is never the only option, and it is indeed false scaremongering to claim that it is.
However, the point was that releasing the proprietary (oh so secret) source code is never the only option, and it is indeed false scaremongering to claim that it is.
> afford to re-implement an AGPL component
> good enough stub implementation to make the software run acceptably
This is what the company I work for does, and most that I've heard about do, but preemptively.
> good enough stub implementation to make the software run acceptably
This is what the company I work for does, and most that I've heard about do, but preemptively.
Great! You, and all who do so, are then protected from ever having to face any problems from AGPL.
> A company which sells that much software can certainly afford to re-implement an AGPL component; or at least implement a good enough stub implementation to make the software run acceptably.
If you ever work at a software company, you'll understand that you never have enough time to do what you want, and you have to pick and choose the most valuable tasks and go with those. Rewriting perfectly working code is never valuable.
If you ever work at a software company, you'll understand that you never have enough time to do what you want, and you have to pick and choose the most valuable tasks and go with those. Rewriting perfectly working code is never valuable.
> If you ever work at a software company
No personal attacks, please.
I do, in fact, work at a tech company, and do, in fact, write a lot of code to do my job. However, it is not a software company, as it does not sell proprietary software directly.
> Rewriting perfectly working code is never valuable.
It might be far more valuable than the other option, i.e. releasing the proprietary software under a free software license. An AGPL licensing issue will only ever, in a worst case scenario, force you to choose one of those two options, no more.
No personal attacks, please.
I do, in fact, work at a tech company, and do, in fact, write a lot of code to do my job. However, it is not a software company, as it does not sell proprietary software directly.
> Rewriting perfectly working code is never valuable.
It might be far more valuable than the other option, i.e. releasing the proprietary software under a free software license. An AGPL licensing issue will only ever, in a worst case scenario, force you to choose one of those two options, no more.
Every GPL violation that I've ever heard about remedied was remedied over time often months to years. If you never create derivative works you don't intend to share you will never have an issue. If you do clearly and obviously conspire to break the law you can probably still negotiate yourself enough time to comply with the law and retain the rights to your own software after having tried to get away with breaking the law.
Having worked for a software producer who all but owns one segment of the industry, while they do discuss with their potential clients modifications to the contract, it is fair to say that the terms discussed all relate to fees. There are certain things with respect to IP that are totally not up for discussion.
Additionally, every use or purchase of software undergoes strict legal review, and there are some licenses that are flat not accepted.
This is not propaganda, and it is not in particular motivated to do anything economic to the FLOSS commmunity.
Additionally, every use or purchase of software undergoes strict legal review, and there are some licenses that are flat not accepted.
This is not propaganda, and it is not in particular motivated to do anything economic to the FLOSS commmunity.
Google doesn't really care that much about the FLOSS community's contributions - they have in house projects to do everything (even a kernel or two!) just because they have so many engineers. Pretty sure the main reason they don't just ban the use of open source software internally is because it would cause their developers to riot, and the cost savings are a secondary factor.
If anything, Google probably would like to see more software released under AGPL just to screw with Amazon.
If anything, Google probably would like to see more software released under AGPL just to screw with Amazon.
The further you deviate from using a standard stack the more you have to spend on training.
Google doesn't really use any of the "standard stack". They use open source libraries for things like SSL but when it comes to the things that matter for quickly ramping up - source control, build/test infra, release management, linters, etc - basically the only thing that isn't in-house is the languages themselves, unless you're using Go or Dart, and the text editor, unless you're using their internal web-based ide.
> All these contracts are "unchallenged in court", by definition, because they are entirely custom.
They do, however, very often use existing language, and custom language is minimized.
> Another type of custom and complex contract is employment.
Where contracts are often almost entirely standard per-company, and often standard between companies. And very rarely is the company in danger from the non-boilerplate clauses.
If you want an example of such a clause, consider Google's own IP clause in its contracts, which contend that Google owns basically all of your IP while you work at Google, unless you take steps to declare ownership of it in advance (and Google approves).
Will this clause entirely hold up in court? Probably not. Do you want to be the one to test it with your multi-billion dollar startup on the line?
The risk of using AGPL software is significantly higher than not, and the benefits are relatively small.
They do, however, very often use existing language, and custom language is minimized.
> Another type of custom and complex contract is employment.
Where contracts are often almost entirely standard per-company, and often standard between companies. And very rarely is the company in danger from the non-boilerplate clauses.
If you want an example of such a clause, consider Google's own IP clause in its contracts, which contend that Google owns basically all of your IP while you work at Google, unless you take steps to declare ownership of it in advance (and Google approves).
Will this clause entirely hold up in court? Probably not. Do you want to be the one to test it with your multi-billion dollar startup on the line?
The risk of using AGPL software is significantly higher than not, and the benefits are relatively small.
> They do, however, very often use existing language, and custom language is minimized.
Guess what, AGPL does that too. Its only 1 paragraph different than GPL.
> Where contracts are often almost entirely standard per-company
"standard per-company", means custom and used used throughout the company. That doesn't make it less risky, and its not like these things don't constantly change and are hugely complicated, just look at privacy policies. AGPL is standard for all companies.
> And very rarely is the company in danger from the non-boilerplate clauses.
Citation needed.
Guess what, AGPL does that too. Its only 1 paragraph different than GPL.
> Where contracts are often almost entirely standard per-company
"standard per-company", means custom and used used throughout the company. That doesn't make it less risky, and its not like these things don't constantly change and are hugely complicated, just look at privacy policies. AGPL is standard for all companies.
> And very rarely is the company in danger from the non-boilerplate clauses.
Citation needed.
> Guess what, AGPL does that too. Its only 1 paragraph different than GPL.
Yes, and the point is that paragraph is particularly risky and untested.
> Citation needed.
I gave an example.
Yes, and the point is that paragraph is particularly risky and untested.
> Citation needed.
I gave an example.
The point people keep talking about here as risky are: what is a derivative work, and what constitutes complete and complete corresponding source definition. Both of those things HAVE been tested. complete corresponding source definition is the same in gplv3, almost exactly the same in gplv2. Derivative work is a general copyright thing tested in many cases. The extra paragraph doesn't have anything to do with them. To recap: 99% of the license is tested, and the "risk" everyone is discussing are about the parts that have already been tested. Basically, what Drew wrote is true.
Derivative work and complete corresponding source has not been tested w.r.t. Google's monorepo (or similar situations), because under the terms of the gplv2/3, Google doesn't distribute any software.
There's an entire class of tooling to make sure that GPL-tainted software isn't distributed (https://opensource.google/docs/thirdparty/licenses/#restrict...), but because the class of software that Google distributes under the GPL is limited (can you think of any?), this is workable, and such things can be isolated.
That doesn't work if the definition of "distribution" is broadened significantly. Then the derivative work questions (which aren't as cut and dry as you claim) do suddenly matter a lot more.
There's an entire class of tooling to make sure that GPL-tainted software isn't distributed (https://opensource.google/docs/thirdparty/licenses/#restrict...), but because the class of software that Google distributes under the GPL is limited (can you think of any?), this is workable, and such things can be isolated.
That doesn't work if the definition of "distribution" is broadened significantly. Then the derivative work questions (which aren't as cut and dry as you claim) do suddenly matter a lot more.
> There's an entire class of tooling to make sure that GPL-tainted software isn't distributed
Amazing the lengths people go to in order to avoid sharing and treating others well! Imagine if they did the opposite: imagine if they just freely shared their source code.
Amazing the lengths people go to in order to avoid sharing and treating others well! Imagine if they did the opposite: imagine if they just freely shared their source code.
I mean, there's some amount of code Google really doesn't want to share (it's not shared with me and I and I work there) for various reasons including security. So I imagine there would be downsides ( and not a whole lot of up, much of the useful stuff is already shared)
Wouldn't it be a good idea to "fix" the AGPL in order to make it clearer?
It seems to me that every time there is a discussion around GNU licenses many people have no idea how to interpret them and then decide not to use them out of fear. It does not seem to me that this is in the interest of the GNU project. Why not fix this?
It seems to me that every time there is a discussion around GNU licenses many people have no idea how to interpret them and then decide not to use them out of fear. It does not seem to me that this is in the interest of the GNU project. Why not fix this?
Well, for one that would require GPLv4. And another one is that if you "fix" it down too much some smart-aleck comes around and says "but I was actually just running it and the results of the computation were beamed into people's brains, so they never knew about the software I was using and so I shouldn't have to release my source code". That being said, I think they should really update their Q&A; one personal one that I would really like revisited is the GPL and the App Store.
EXACTLY.
Instead people waste time trying to defend something that neither side can prove. And business / Startup doesn't want to risk anything when there are always an alternatives.
Instead people waste time trying to defend something that neither side can prove. And business / Startup doesn't want to risk anything when there are always an alternatives.
> AGPL is unchallenged in court
What would be the cheapest way to settle this? Can I found a SaaS company that uses AGPL code, grow to ~100 usd/month and basically ask the FSF to sue me? Even if the legal fees alone amount to tens of thousand dollars, that should be low enough that a small company or a motivated (and financially secure) individual could try.
What would be the cheapest way to settle this? Can I found a SaaS company that uses AGPL code, grow to ~100 usd/month and basically ask the FSF to sue me? Even if the legal fees alone amount to tens of thousand dollars, that should be low enough that a small company or a motivated (and financially secure) individual could try.
Bit harder than that mostly because the court system is designed to avoid universally "resolved" issues as much as possible.
The first hurdle is to get it into federal court (since you probably want this tested beyond your current state). To do that, you'll need someone from out of state to sue you.
The next hurdle is how to get this case resolved in other federal courts. You could either setup the same scenario for each district (requiring that your 2 parties have businesses in 2 states in each of the districts) or you could try to appeal all the way to the supreme court. Tricky, because this really isn't likely to be a case that the SC would take up (it'd need the lower courts to disagree with each other. Further, they'll usually not do it unless the district courts also disagree).
Overall, the whole thing would be super expensive to pull off.
The first hurdle is to get it into federal court (since you probably want this tested beyond your current state). To do that, you'll need someone from out of state to sue you.
The next hurdle is how to get this case resolved in other federal courts. You could either setup the same scenario for each district (requiring that your 2 parties have businesses in 2 states in each of the districts) or you could try to appeal all the way to the supreme court. Tricky, because this really isn't likely to be a case that the SC would take up (it'd need the lower courts to disagree with each other. Further, they'll usually not do it unless the district courts also disagree).
Overall, the whole thing would be super expensive to pull off.
Corresponding source has the exact same definition in GPLv3 and almost exactly the same in GPLv2, so all this "its completely untested" thing is completely disingenuous. Google uses Borg to control gplv3 code that they also distribute, so, exactly the same case and its complete BS you are spreading. Lawyers are actually pretty good at spreading FUD about GPL, they always have been.
AGPLv3 is exactly the same as GPLv3 except that it adds 1 paragraph. That paragraph has nothing to do with corresponding source or what a derivative is. Google ships distros with Gplv3 to customers GCP, so Borg and GCP stuff would be equally affected by the "risk to Borg" and other server side code, so, I don't believe that the claimed legal risk is real, just FUD.
By this reasoning, if I run some AGPL software on GCP, wouldn't that place all of GCP under AGPL? I've written "scripts to control" the AGPL software, so my stuff is AGPL and Google's cloud offering is to run my code automatically so all of GCP is a "script to control".
That's unlikely. You're falling into the common trap of assuming laws and computer source code work the same way -- you have a set of instructions that you evaluate from top to bottom until you get an answer. The law doesn't really work that way; there are laws, but there are also reasonable humans deeply embedded in the process. So in your case, you'd have to be the author of some AGPL software, have some third party install it on GCP, and then sue Google to get the GCP source code. Google would send a representative that says "this is a generic platform where anyone can run any computer program they want; we don't suggest that users run this AGPL program, and we have no way to detect that they're running it; this is an issue between Company X and the author." The judge and jury would then see that Google has absolutely no control over that license infringement, and would probably not award you their source code. It would just be unreasonable to any normal person for Google to be involved in your contract; they took no action to enter into a contract with you, after all. No cloud platform could ever exist if they automatically became parties to random software contracts. The legal system would take all of that into account when deciding how to make you whole.
Similar arguments would involve suing Intel for copyright infringement because their memory controller copied copyrighted information from RAM into cache. That's copying! But ultimately, Intel is just infrastructure; some user got the copyrighted data into RAM and knew full well that CPUs copy it into cache from time to time. That doesn't make Intel a party to your copyright infringement lawsuit, even though they did instruct the infringer's device to make a copy without your permission. It simply isn't reasonable -- no efficient CPUs could be manufactured if you won your lawsuit. So it's unlikely a court would hold Intel responsible.
Finally, there is the classic "if you read this, you owe me $50." You just did! But any court would find that an unenforceable contract because you didn't really consent to it. So I won't be suing you for $50. The world couldn't function if I could do things like this. So contract law exists without that particular contract being valid.
Similar arguments would involve suing Intel for copyright infringement because their memory controller copied copyrighted information from RAM into cache. That's copying! But ultimately, Intel is just infrastructure; some user got the copyrighted data into RAM and knew full well that CPUs copy it into cache from time to time. That doesn't make Intel a party to your copyright infringement lawsuit, even though they did instruct the infringer's device to make a copy without your permission. It simply isn't reasonable -- no efficient CPUs could be manufactured if you won your lawsuit. So it's unlikely a court would hold Intel responsible.
Finally, there is the classic "if you read this, you owe me $50." You just did! But any court would find that an unenforceable contract because you didn't really consent to it. So I won't be suing you for $50. The world couldn't function if I could do things like this. So contract law exists without that particular contract being valid.
Thank you for taking the time to spell this out.
Some companies do read the AGPL that broadly. That's why Square requires its own customers to not use AGPL software. https://squareup.com/us/en/legal/general/pos
Wow, that "under any circumstance" is dangerously broad as a prohibition... Courts could very well read that phrase to override the assumption that otherwise might exist that actions unrelated to the services purchased from Square are outside of scope of the contract. It shouldn't jeopardize a company's ability to use Square if an employee plays with MongoDB on their corporate workstation. I realize enforcement wouldn't target this in practice, but the wording is sloppy enough to arguably bring it into scope.
Also very weird is that the Canadian terms are dramatically different and don't mention this restriction at all. In fact the whole long list of prohibited stuff in section 3.II.B is absent, even though both countries' terms cover the Online Store service in which the US terms include this wording.
Given that, maybe the true cause of the wording is boilerplate wording from their US lawyers which their Canadian lawyers don't have in their boilerplate? It's not simply about Square Canada being less of a liability risk than Square Inc, as most provisions of the Canadian terms do have Square Inc as the contracting party.
Also very weird is that the Canadian terms are dramatically different and don't mention this restriction at all. In fact the whole long list of prohibited stuff in section 3.II.B is absent, even though both countries' terms cover the Online Store service in which the US terms include this wording.
Given that, maybe the true cause of the wording is boilerplate wording from their US lawyers which their Canadian lawyers don't have in their boilerplate? It's not simply about Square Canada being less of a liability risk than Square Inc, as most provisions of the Canadian terms do have Square Inc as the contracting party.
It would mean that because GCP is not itself under AGPL, you are not complying with the license, so you could be sued by the maker of the software for copying it to GCP. You are doing the copying, you are breaking the copyrights.
“The company might have to release the source for everything!” isn't a downside for some people. The FSF's philosphy is that all source code should be opened. What you're describing as a bug (for a company), is (I think) a feature for the FSF.
Yes but on the other hand:
> In truth, Google was never going to buy your software.
So what difference does it make? Stop making stuff for Google for free if they won’t contribute back. It’s that simple.
> In truth, Google was never going to buy your software.
So what difference does it make? Stop making stuff for Google for free if they won’t contribute back. It’s that simple.
Honestly I'm not a big fan of using *GPLvX and I didn't even know what Google was thinking about it.
It's more about the bothersome of the question what the actual legal implications are.
I would love if such licenses ship with a long list of positive and negative examples which if they exactly fit you overrule any interpretation of the rest of the contract...
EDIT: To clarify my opinion in this context is about cases where the AGPL is in something like a library position. AGPL on software which is used as a service seems to be quite reasonable without much legal surprises.
It's more about the bothersome of the question what the actual legal implications are.
I would love if such licenses ship with a long list of positive and negative examples which if they exactly fit you overrule any interpretation of the rest of the contract...
EDIT: To clarify my opinion in this context is about cases where the AGPL is in something like a library position. AGPL on software which is used as a service seems to be quite reasonable without much legal surprises.
[deleted]
I have had the same experience and the same feedback.
It’s much, much, much worse in the embedded world. I think the author is being quite disingenuous on his take.
It’s much, much, much worse in the embedded world. I think the author is being quite disingenuous on his take.
I agree that random engineers should have the humility to listen to feedback from lawyers. And IANAL.
Here's the sentence with "scripts to control":
> The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities.
That being said, it feels like a stretch to me that the particular orchestration infrastructure your company uses could be considered part of this. Borg is clearly not "needed to... run the object code and to modify the work" (PostGIS), which you could easily demonstrate by running and modifying PostGIS without Borg--as every other user of PostGIS does.
Here's the sentence with "scripts to control":
> The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities.
That being said, it feels like a stretch to me that the particular orchestration infrastructure your company uses could be considered part of this. Borg is clearly not "needed to... run the object code and to modify the work" (PostGIS), which you could easily demonstrate by running and modifying PostGIS without Borg--as every other user of PostGIS does.
It's perfectly possible that binaries that google runs on Borg cannot run on a vanilla Linux system.
Not only possible, it’s a fact. Borg executables make many assumptions about available runtime services and cannot operate in their absence. It’s probably impossible to derive and operate the same artifact Google is running without a complete Google architecture in place and operating, from Chubby on up.
How does one comply with the AGPL in that scenario? “Rearchitect a not stupid way” is probably the answer here, so it’s a nonstarter.
How does one comply with the AGPL in that scenario? “Rearchitect a not stupid way” is probably the answer here, so it’s a nonstarter.
The AGPL virality is considered such a big risk, and the "scripts to control" clause is considered so sweeping and vague, that Google has its own internal version of R that won't download AGPL libraries from CRAN, because just looking looking at the performance stats from production services in R using an AGPL library could taint the source code of the service itself. Nobody knows.
> because just looking looking at the performance stats from production services in R using an AGPL library could taint the source code of the service itself
I think this is what is being referred to as "FUD". Anyone can go after you for some sort of supposed license issue, but at some point you need to consider that many of these are extremely far-fetched and serve only to quite literally add FUD around AGPL.
I think this is what is being referred to as "FUD". Anyone can go after you for some sort of supposed license issue, but at some point you need to consider that many of these are extremely far-fetched and serve only to quite literally add FUD around AGPL.
The error is using a pejorative term of FUD to identify uncertainties that are routine in every legal review ever performed. What you’re saying is you have a different risk assessment for your business and you’d take the advice and proceed anyway. That’s your prerogative. That does not extend to “different assessments from my own are objectively wrong,” which is what calling them FUD implies.
Engineers seek hard truth, which is why the malleable truth of contract and license law is ever elusive. They’re different takes on truth.
Engineers seek hard truth, which is why the malleable truth of contract and license law is ever elusive. They’re different takes on truth.
When working for eBay I've asked our legal department "So if we do this, are when then safe?" - The answer was always "The court decides, before that noone knows."
Right. That's really the issue -- it's not that the risk isn't there, it's that the risk is always there, so it's an isolated demand for rigor.
For example, here's the Windows 10 license:
> c. Restrictions. The device manufacturer or installer and Microsoft reserve all rights (such as rights under intellectual property laws) not expressly granted in this agreement. For example, this license does not give you any right to, and you may not:
...
> (v) 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;
With people staying home because of COVID-19, a lot of companies with Windows desktops (with all their line of business software on them) have been having their employees access them from home, exclusively remotely with no local users. Are they now in violation of the license? Do you want to have to find out in court?
It's an excuse which is present anywhere for any non-trivial terms and used as FUD in contexts where someone wants to scare others away from something.
For example, here's the Windows 10 license:
> c. Restrictions. The device manufacturer or installer and Microsoft reserve all rights (such as rights under intellectual property laws) not expressly granted in this agreement. For example, this license does not give you any right to, and you may not:
...
> (v) 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;
With people staying home because of COVID-19, a lot of companies with Windows desktops (with all their line of business software on them) have been having their employees access them from home, exclusively remotely with no local users. Are they now in violation of the license? Do you want to have to find out in court?
It's an excuse which is present anywhere for any non-trivial terms and used as FUD in contexts where someone wants to scare others away from something.
> Are they now in violation of the license?
Maybe they are. But not doing that would have killed the company, so the uncertainty was likely considered acceptable.
The punishment for violating a Microsoft license is paying Microsoft more money. The cost of not doing that would have likely been more.
The punishment for building your SaaS on AGPL code and having court decide on the virality on a non-favorable way is much more severe, and cannot in general be immediately solved with a little extra money transferred between two companies.
It's all risk management.
Maybe they are. But not doing that would have killed the company, so the uncertainty was likely considered acceptable.
The punishment for violating a Microsoft license is paying Microsoft more money. The cost of not doing that would have likely been more.
The punishment for building your SaaS on AGPL code and having court decide on the virality on a non-favorable way is much more severe, and cannot in general be immediately solved with a little extra money transferred between two companies.
It's all risk management.
> The punishment for building your SaaS on AGPL code and having court decide on the virality on a non-favorable way is much more severe, and cannot in general be immediately solved with a little extra money transferred between two companies.
This is also FUD. There's no guarantee that Microsoft wouldn't stand on their rights, demand their statutory $50k/infringement, and refuse to sell you any more licenses going forward. It's not likely they'd do that - but it's not likely that the author of an AGPL library would do it either.
This is also FUD. There's no guarantee that Microsoft wouldn't stand on their rights, demand their statutory $50k/infringement, and refuse to sell you any more licenses going forward. It's not likely they'd do that - but it's not likely that the author of an AGPL library would do it either.
There's rarely a singular author of an AGPL library, and that's part of the problem -- the business is not likely to have someone to negotiate with. Microsoft is much more of a known quantity, and the likely risk can be put into dollars relatively easily, compared to the AGPL situation.
I'm not sure that actually helps you? If you license a library from Microsoft, anyone could claim to hold a copyright on it; you might be able to get Microsoft to refund what you paid for it, but you're still liable for whatever distribution you did. I don't think library licencors normally indemnify you against that, and if anything you have less ability to defend yourself from trolls since you're unlikely to get a full VCS history the way you usually would with an AGPL library.
RDP and other remote desktop technologies has been in use enterprise for decades and it has never been a legal concern. That clause is meant to prevent people from doing unlicensed workarounds of terminal server, and it's not a concern for people doing remote access to a single-user desktop PC.
From the same EULA:
> (v) Remote access. No more than once every 90 days, you may designate a single user who physically uses the licensed device as the licensed user. The licensed user may access the licensed device from another device using remote access technologies. Other users, at different times, may access the licensed device from another device using remote access technologies, but only on devices separately licensed to run the same or higher edition of this software
From the same EULA:
> (v) Remote access. No more than once every 90 days, you may designate a single user who physically uses the licensed device as the licensed user. The licensed user may access the licensed device from another device using remote access technologies. Other users, at different times, may access the licensed device from another device using remote access technologies, but only on devices separately licensed to run the same or higher edition of this software
You're just making the same argument as the article -- that it doesn't really mean that.
The clause you're referring to says you can designate a user, but that could have to be the same user who uses the machine locally, and then they can also use it remotely. The first clause still proscribes use "on a device for use only by remote users" -- so maybe remote use is only allowed when local use is also present. Has this theory been tested in court? Do you want to be the one to test it?
And common practice doesn't save you. Lots of companies use [A]GPL software too. Look what the Federal Circuit did with API copyrightability -- everybody had been assuming that wasn't the case forever. And maybe they're right to, if another court overrules it or narrows it into nothing or a new law is passed before it matters for anybody else, or maybe not.
Uncertainty is the default. Which is terrible, but nonetheless.
The clause you're referring to says you can designate a user, but that could have to be the same user who uses the machine locally, and then they can also use it remotely. The first clause still proscribes use "on a device for use only by remote users" -- so maybe remote use is only allowed when local use is also present. Has this theory been tested in court? Do you want to be the one to test it?
And common practice doesn't save you. Lots of companies use [A]GPL software too. Look what the Federal Circuit did with API copyrightability -- everybody had been assuming that wasn't the case forever. And maybe they're right to, if another court overrules it or narrows it into nothing or a new law is passed before it matters for anybody else, or maybe not.
Uncertainty is the default. Which is terrible, but nonetheless.
A PC at a desk with a keyboard and mouse is very clearly not a device "device for use only by remote users". The person used their PC when they were in office, and would be using it if not for the current pandemic.
If the device is sitting in a rack in a closet, that is a device intended for use only by remote users.
If the device is sitting in a rack in a closet, that is a device intended for use only by remote users.
You still seem to be missing the point that your arguments are irrelevant since you would have to make them in court which is fraught with uncertainty and unreasonably burdensome even if you win.
And I doubt Microsoft would agree to the premise that you could avoid the "no servers" restriction just by putting the server at a desk and plugging in a keyboard and mouse that nobody has touched in months.
And I doubt Microsoft would agree to the premise that you could avoid the "no servers" restriction just by putting the server at a desk and plugging in a keyboard and mouse that nobody has touched in months.
At least Microsoft is not Oracle, who are famouse for their horrible license audits where a whole consulting industry [1] sprung up to survive them, but yes I agree.
[1] e.g. "Founded in 2011, Palisade is the leading independent provider of Oracle contract advisory services."
[1] e.g. "Founded in 2011, Palisade is the leading independent provider of Oracle contract advisory services."
Until recently, it was "extremely far-fetched" that copyright law prevents you from independently reimplementing an API. Google has particularly good reason to be paranoid about this stuff.
> Until recently, it was "extremely far-fetched" that copyright law prevents you from independently reimplementing an API.
No, it really wasn't far-fetched; quite the opposite.
Don't confuse legal opinions with advocacy. Unless you're paying someone, what you read and hear online is advocacy. Attorneys in the FOSS community are no less guilty of pretending that their advocacy is the letter of the law than anti-FOSS attorneys.
I believe celebrity FOSS legal scholar, Lawrence Lessig, for example, has lost on the merits every major copyright case (as listed on Wikipedia) he got behind. (And other ones, too, like the two major election law cases mentioned there.) But all his books and articles preceding those cases, and sometimes even afterwards, made his position sound like a simple application of well established law. It was a simple application of law, alright, but of the law he and many others desired, not the law as it existed or was likely to exist when subject to the scrutiny of the court system.
While U.S. courts seem to have begun more rigorously scrutinizing pro-patent holder arguments, the opposite is true when it comes to copyright. U.S. courts are increasingly kinder to a very broad and strict (i.e. fewer defenses) application of copyright law. It's a real shame, and we could lament all day how they're "getting the law wrong", but people should set their expectations accordingly. For example, don't expect SCOTUS to overturn Oracle v. Google, at least not to the extent that it supports Google's original defense that APIs aren't copyrightable. There's a reason the judge's original opinion siding with Google was so exceptionally long and detailed--he was trying to bend the law in a different direction than it's most recent trajectory. He did an admirable job, but his interpretation was sadly but firmly in the minority.
No, it really wasn't far-fetched; quite the opposite.
Don't confuse legal opinions with advocacy. Unless you're paying someone, what you read and hear online is advocacy. Attorneys in the FOSS community are no less guilty of pretending that their advocacy is the letter of the law than anti-FOSS attorneys.
I believe celebrity FOSS legal scholar, Lawrence Lessig, for example, has lost on the merits every major copyright case (as listed on Wikipedia) he got behind. (And other ones, too, like the two major election law cases mentioned there.) But all his books and articles preceding those cases, and sometimes even afterwards, made his position sound like a simple application of well established law. It was a simple application of law, alright, but of the law he and many others desired, not the law as it existed or was likely to exist when subject to the scrutiny of the court system.
While U.S. courts seem to have begun more rigorously scrutinizing pro-patent holder arguments, the opposite is true when it comes to copyright. U.S. courts are increasingly kinder to a very broad and strict (i.e. fewer defenses) application of copyright law. It's a real shame, and we could lament all day how they're "getting the law wrong", but people should set their expectations accordingly. For example, don't expect SCOTUS to overturn Oracle v. Google, at least not to the extent that it supports Google's original defense that APIs aren't copyrightable. There's a reason the judge's original opinion siding with Google was so exceptionally long and detailed--he was trying to bend the law in a different direction than it's most recent trajectory. He did an admirable job, but his interpretation was sadly but firmly in the minority.
It meets the literal definition for each of fear, uncertainty, and doubt. That is true. But the uncertainty is the point. Why risk something as valuable as Google's proprietary source code over something with as little utility as some random CRAN package?
The definition of FUD is that you are spreading fear, uncertainty and doubt as a tactic not that you yourself are afraid, uncertain or have any doubts.
I think the “spreading” aspect is overstated. These are clearly Google’s internal docs that just happen to be accessible to the public.
The article:
> Ask yourself: why is documentation of internal-facing decisions like what software licenses to use being published in a public place? The answer is straightforward: to influence the public.
> Ask yourself: why is documentation of internal-facing decisions like what software licenses to use being published in a public place? The answer is straightforward: to influence the public.
Quite a leap. Much more likely explanation is someone asked someone else to publish the open source docs and they did the minimum amount of censorship needed to get it out the door.
So Google is wrong for being secretive when not sharing, and wrong when they're not because clearly it's a ruse?
Heads I win, tails you lose. With that logic you can fit any action into what you already "know".
Heads I win, tails you lose. With that logic you can fit any action into what you already "know".
Where is anyone accusing Google of being secretive wrt AGPL decisions? The leap to try to accuse people of some kinda weird hypocrisy is a reach.
The true misrepresentation is:
> Anyone can go after you for some sort of supposed license issue
Suppose the software in question is MIT licensed. There are certain requirements, none of them involve users having to decide between releasing their source code or paying fees. Remedying most MIT project license violations usually involves adding a disclosure somewhere in the website.
As a whole, for reasonably large companies it's a lot easier to just pick a non-AGPL project (and make one if it doesn't exist) than to bother with these questions.
> Anyone can go after you for some sort of supposed license issue
Suppose the software in question is MIT licensed. There are certain requirements, none of them involve users having to decide between releasing their source code or paying fees. Remedying most MIT project license violations usually involves adding a disclosure somewhere in the website.
As a whole, for reasonably large companies it's a lot easier to just pick a non-AGPL project (and make one if it doesn't exist) than to bother with these questions.
That depend on the industry they are in and how much of an monopoly position they got.
Ask what would happen if a email project at google that was estimated to be released this year got delayed an additional year. How much would that impact their revenue and stock values, or even the general market share of gmail?
Then take a an high competition area where multiple companies are in heavy competition. How much of developers focus can you shift away from the main product in order to re-implement code that is already written and could be used today?
Companies in a low competition market that are large enough to already be in a dominant position can just re-implementing AGPL code. Being risk averse might also be an effective strategy, and having higher costs and slow development won't cause any direct harm to the core part of the company. In worst case they will just scrap the project and cut their losses.
In a high competition industries you can not afford that. Every single advantage that can give you an edge will be used unless it goes against the core business model. Unsurprising this is also the places where I personally have seen the least amount of license purity. The most extreme examples are from the game industry which tend to use what ever software they can get their hand on in their games and support systems as long it does not prevent the core business model.
Ask what would happen if a email project at google that was estimated to be released this year got delayed an additional year. How much would that impact their revenue and stock values, or even the general market share of gmail?
Then take a an high competition area where multiple companies are in heavy competition. How much of developers focus can you shift away from the main product in order to re-implement code that is already written and could be used today?
Companies in a low competition market that are large enough to already be in a dominant position can just re-implementing AGPL code. Being risk averse might also be an effective strategy, and having higher costs and slow development won't cause any direct harm to the core part of the company. In worst case they will just scrap the project and cut their losses.
In a high competition industries you can not afford that. Every single advantage that can give you an edge will be used unless it goes against the core business model. Unsurprising this is also the places where I personally have seen the least amount of license purity. The most extreme examples are from the game industry which tend to use what ever software they can get their hand on in their games and support systems as long it does not prevent the core business model.
Well, that's simply because most MIT licensed projects don't choose to insist on the copyright infringement damages to which they're entitled with respect to past non-compliance. They could insist on statutory damages (assuming they've registered their copyright), or actual damages/profits of course, without offering the option to remedy past violations.
Most such rights holders simply don't do this as a practical matter given their own goals.
Most such rights holders simply don't do this as a practical matter given their own goals.
Both license violations can involve a fee. The point is that on a going-forward basis it is sufficient to appropriately disclose use of MIT licensed software. On a going-forward basis, an AGPL violation will require either a release of the entire source tree or a replacement of the AGPL software with an alternative
If we're looking at a going-forward basis as the primary motivator of the different attitude, companies like Google would be more allergic to the regular GPLv2 than they are. The GPLv2 license automatically terminates for a given licensee upon violation, requiring the rights holder to take action to prospectively restore their license if they want to be able to legally distribute the software in the future.
Nobody avoids GPLv2 software due to this clause. Affero's original version of the AGPL (v1) based on the GPLv2 has the same clause, nothing harsher. The currently common version of the AGPL (v3) published directly by GNU/FSF shares the GPLv3's much less harsh termination provision, and indeed companies like Google do sometimes allow use of GPLv3 code. (Those companies like Apple which are opposed to GPLv3 have issues with different provisions, not this one.)
The difference between the MIT license and the AGPL, whether it's unreasonable FUD or reasonable caution by lawyers, is not about the difference in how violators are treated going forward.
By the way, in my reading as a non-lawyer who nevertheless previously attended part of law school including the contract law course, the AGPL doesn't give any specific right to _demand_ the source code of any party any more than the GPL does. It just forces the parties who act outside the license to accept treatment as copyright infringers, as with any other unilateral license, including the damages and injunctions (and sometimes criminal convictions) that can lead to. Companies can pick their poison.
Maaaybe some jurisdictions would analyze this differently as a contract that the company agreed to, with the option to order specific performance of releasing source code. I'm not 100% sure. Again, I'm not a lawyer. I don't view this as likely if the company doesn't somehow indicate to the licensor / court / public that it agrees to the license, beyond the mere fact of acting in a way that would otherwise infringe copyright.
Nobody avoids GPLv2 software due to this clause. Affero's original version of the AGPL (v1) based on the GPLv2 has the same clause, nothing harsher. The currently common version of the AGPL (v3) published directly by GNU/FSF shares the GPLv3's much less harsh termination provision, and indeed companies like Google do sometimes allow use of GPLv3 code. (Those companies like Apple which are opposed to GPLv3 have issues with different provisions, not this one.)
The difference between the MIT license and the AGPL, whether it's unreasonable FUD or reasonable caution by lawyers, is not about the difference in how violators are treated going forward.
By the way, in my reading as a non-lawyer who nevertheless previously attended part of law school including the contract law course, the AGPL doesn't give any specific right to _demand_ the source code of any party any more than the GPL does. It just forces the parties who act outside the license to accept treatment as copyright infringers, as with any other unilateral license, including the damages and injunctions (and sometimes criminal convictions) that can lead to. Companies can pick their poison.
Maaaybe some jurisdictions would analyze this differently as a contract that the company agreed to, with the option to order specific performance of releasing source code. I'm not 100% sure. Again, I'm not a lawyer. I don't view this as likely if the company doesn't somehow indicate to the licensor / court / public that it agrees to the license, beyond the mere fact of acting in a way that would otherwise infringe copyright.
This entire thread has really sold me on AGPL.
The "scripts to control" clause as you say is in all versions of the GPL, exactly the same in GPLv3, and slightly different I presume in GPLv2. It has been tested in court, and its been found to not be expansive like the fud you are spreading.
Can you link to the relevant cases?
The GPLv2 version of the clause says:
> For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.
> For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.
If you accidentially add a GPL or AGPL library to your codebase your codebase doesn't automatically become GPL or AGPL. GPL and AGPL are just licenses that add restrictions that must be satisfied in order to be allowed to use the software. The worst thing a license can do is deny you the ability to use the software. If your application is not licensed under the GPL/AGPL your application is violating the copyright of the GPL/AGPL library and the author can sue you for copyright infringement which is a pretty good reason to avoid using GPL/AGPL software in a commercial setting but it has absolutely nothing to do with "tainting source code". That's just fear mongering. If what you said was the truth I'd be more worried about software licenses that force you to do absurd things like kill people. "I accidentally added a kill your wife licensed library to our company internal fork of PostGIS".
The holy war could be avoided if Google simply paid authors of AGPL code they wanted to use instead of going on a tirade against the license.
I think half the reason it exists is to make it deliberately risky for FAANGs etc. because they're exactly the ones who SHOULD be ponying up to support the open source ecosystem they rely upon.
I think half the reason it exists is to make it deliberately risky for FAANGs etc. because they're exactly the ones who SHOULD be ponying up to support the open source ecosystem they rely upon.
Well, this is the heart of the issue. Chris DiBona has publicly stated that AGPL software just isn't valuable enough to care about. The authors of such software tend to overestimate its utility.
https://www.theregister.com/2011/03/31/google_on_open_source...
https://www.theregister.com/2011/03/31/google_on_open_source...
"Person who benefits monetarily from developers avoiding AGPL suggests developers should avoid AGPL".
I'm surprised Googlers don't have betters ways to spend their time than having such furious debates about the licensing of supposedly worthless software. Google fear AGPL so much that they used to ban you from using it for projects hosted on Google Code: https://www.theregister.com/2010/09/13/google_code_accepts_a...
I'm surprised Googlers don't have betters ways to spend their time than having such furious debates about the licensing of supposedly worthless software. Google fear AGPL so much that they used to ban you from using it for projects hosted on Google Code: https://www.theregister.com/2010/09/13/google_code_accepts_a...
Chris DiBona is paid to care about exactly this issue. Compliance is his job description and AGPL policy companywide is comfortably in that portfolio. That you disagree with him does not indict Google nor create an alternative universe where Googlers are setting out unprompted to screw the free software world that gave them 50% of their infrastructure for no reason other than fear.
You underestimate the rigor required in compliance. We are talking about FAANG compliance, too, which holds nary a candle toward compliance in other verticals. This thread should illustrate why compliance decisions are largely made independently of engineering.
You underestimate the rigor required in compliance. We are talking about FAANG compliance, too, which holds nary a candle toward compliance in other verticals. This thread should illustrate why compliance decisions are largely made independently of engineering.
Though they try to hide it it does seem that ideology is driving this at Google - not practicality.
I mean, Google code banning AGPL kind of gives the game away. That, and him saying that Apache (most liberal) is really his favorite license. Oh and "we never really wanted any of the AGPL code it's all crap anyway".
None of those things are about rigor in compliance. Those are about a corporation stamping its feet.
I mean, Google code banning AGPL kind of gives the game away. That, and him saying that Apache (most liberal) is really his favorite license. Oh and "we never really wanted any of the AGPL code it's all crap anyway".
None of those things are about rigor in compliance. Those are about a corporation stamping its feet.
> Chris DiBona is paid to care about exactly this issue.
Right, which doesn't really address the point being made above, which is that Chris DiBona is paid to care about the issue, has a position on it, and now has a reason to claim that AGPL code is not useful.
Right, which doesn't really address the point being made above, which is that Chris DiBona is paid to care about the issue, has a position on it, and now has a reason to claim that AGPL code is not useful.
If they don't want to use AGLP software anyway, then they have nothing to complain about.
I'm a fan of the GPL etc, but in this article he is saying that in 2011, most of the complex AGPL software that would be useful to Google has a substantially similar version already implemented inside of Google. That's something I could believe about Google, especially 9 years ago.
"MongoDB is probably the most prominent AGPL project, he said, but it replicates software already used within the Google back-end infrastructure. Google uses a proprietary custom-built distributed database known as BigTable. The company has repeatedly indicated that it will not open source BigTable, but it has published a research paper on the platform, and its basic ideas are now used in open source platforms such as Hadoop HBase and Cassandra.
In similar fashion, the company has not open sourced core platforms such as the Google File System (GFS), its distributed file system, and MapReduce, its distributed number-crunching platform."
He also made this quote:
""If you look at the interior of Google and how we make software, we don't launch a lot of software to the outside world," he said. "With the AGPL, you have to be very, very careful with how it is expressed. Otherwise you have to invoke the sharing in many different places. [The ban] is really about saving engineering time."
This part sounds like a partial truth and a partial lie. I'm sure it does save a little on engineering time, but it seems odd not to acknowledge the elephant in the room that they may have to share software they don't want to.
"MongoDB is probably the most prominent AGPL project, he said, but it replicates software already used within the Google back-end infrastructure. Google uses a proprietary custom-built distributed database known as BigTable. The company has repeatedly indicated that it will not open source BigTable, but it has published a research paper on the platform, and its basic ideas are now used in open source platforms such as Hadoop HBase and Cassandra.
In similar fashion, the company has not open sourced core platforms such as the Google File System (GFS), its distributed file system, and MapReduce, its distributed number-crunching platform."
He also made this quote:
""If you look at the interior of Google and how we make software, we don't launch a lot of software to the outside world," he said. "With the AGPL, you have to be very, very careful with how it is expressed. Otherwise you have to invoke the sharing in many different places. [The ban] is really about saving engineering time."
This part sounds like a partial truth and a partial lie. I'm sure it does save a little on engineering time, but it seems odd not to acknowledge the elephant in the room that they may have to share software they don't want to.
> the elephant in the room that they may have to share software they don't want to
This is certainly not a controversial topic for anyone working in a software company. There are always pieces of software that a commercial entity is not willing to share freely with the whole world.
This is certainly not a controversial topic for anyone working in a software company. There are always pieces of software that a commercial entity is not willing to share freely with the whole world.
Oh absolutely, but it does seem like they prefer to genuflect to open source / free software ideas and it seems less distasteful to give a more tactical answer.
I release my open-source software under the AGPL with the option for different licensing upon discussion or negotiation, partly for this reason. The other reason is that common open-source licenses are generally incompatible with one another, and I'm happy to overcome those incompatibilities via alternative licensing for other open-source projects.
Google is in the position to just use non-AGPL alternatives or build their own. That an open source library exists doesn't obligate Google to use it.
They do, but it requires the existance of a dual license for that project, which usually requires copyright reassignment was put in place from the project's inception.
The current maintainer can't just sell a copy under non-AGPL if there are other copyright holders (contributors).
The current maintainer can't just sell a copy under non-AGPL if there are other copyright holders (contributors).
Free as in beer with the expectation of Venmo, is it?
Joke aside, given Stallman’s writings about large businesses and their practices, characterizing a policy document as a “tirade” is a strange position. They’re not exactly buying airtime to advocate against the license. They’ve chosen to make a policy open access, something we’d normally applaud.
Joke aside, given Stallman’s writings about large businesses and their practices, characterizing a policy document as a “tirade” is a strange position. They’re not exactly buying airtime to advocate against the license. They’ve chosen to make a policy open access, something we’d normally applaud.
Under the same meeting ask the lawyer about the linux kernel and where the border is for its license. They will likely give a similar answer, through if the company relies on selling devices with a linux kernel the risk vs reward will result in a very different decision in the end.
GPL 2 has been tried in courts many times, and there is a consensus that Linux kernel's license applies to the kernel (publish your patches) and not applications that use the kernel. E.g. Go is shipped under a BSD license, not GPL, and sidesteps libc for quite a few APIs.
The Linux kernel explicitly has a user-space exception written into its license, which is why the requirement of reciprocity stops there.
AGPL software isn't designed to be used as a dependency to a proprietary system. It's designed to be used in an open ecosystem. That's kind of the point.
* If you expect your code to be used as a dependency to a proprietary system, don't use the AGPL.
* If you are building a stand-alone system, or tools for an open ecosystem, use the AGPL.
That's a question of suitability-to-purpose. Although this use is permitted, AGPL simply isn't a good license for PostGIS (which is correctly licensed under the GPL). It is a great license for end-user applications. It's also nice for dual-licensing.
Licenses aren't something to get ideological about; it's more of a right-tool-for-the-right-job kind of thing. If you use a hammer with screws, you'll get hurt. Same thing with using BSD where AGPL fits, or AGPL where BSD fits.
* If you expect your code to be used as a dependency to a proprietary system, don't use the AGPL.
* If you are building a stand-alone system, or tools for an open ecosystem, use the AGPL.
That's a question of suitability-to-purpose. Although this use is permitted, AGPL simply isn't a good license for PostGIS (which is correctly licensed under the GPL). It is a great license for end-user applications. It's also nice for dual-licensing.
Licenses aren't something to get ideological about; it's more of a right-tool-for-the-right-job kind of thing. If you use a hammer with screws, you'll get hurt. Same thing with using BSD where AGPL fits, or AGPL where BSD fits.
I agree with what you're saying, but it contradicts the source article, which insists that Google is spreading FUD by saying it can't use AGPL dependencies in its proprietary systems.
Yeah, it's complex:
* The article is right that Google IS spreading FUD. They're making legal statements which are probably false to minimize usage of the AGPL outside of Google.
* Google came to a sensible conclusion, that THEY shouldn't use the AGPL
* Google's articulated reasons don't hold legal water, and following Google's lead and interpretation causes many companies to mislicense their code
It's a right tool for the right job kind of thing, and AGPL is not the right tool for Google's job.
I've used all sorts of license in projects I've worked on. It's always a pragmatic evaluation. Right now, I'm working on a project which, pending legal review, should be AGPL. Any other license would be business suicide. AGPL gets us the ecosystem we'll need, without having to unfairly compete with our own code.
* The article is right that Google IS spreading FUD. They're making legal statements which are probably false to minimize usage of the AGPL outside of Google.
* Google came to a sensible conclusion, that THEY shouldn't use the AGPL
* Google's articulated reasons don't hold legal water, and following Google's lead and interpretation causes many companies to mislicense their code
It's a right tool for the right job kind of thing, and AGPL is not the right tool for Google's job.
I've used all sorts of license in projects I've worked on. It's always a pragmatic evaluation. Right now, I'm working on a project which, pending legal review, should be AGPL. Any other license would be business suicide. AGPL gets us the ecosystem we'll need, without having to unfairly compete with our own code.
You write this as if it summarizes the discussion, but of course the discussion we can all read here says the opposite: Google's legal concerns are probably not false, and are concerns for multiple other organizations; not only that, but Google has ample reason to be particularly concerned about these kinds of IP issues.
I think it's possible have "Google has concerns about the AGPL for itself" and "Google would like you to not use the AGPL by making you afraid of it".
The first statement is almost certainly true. The second is supposition.
Possibly, but I think it is fairly clear how it would help Google to do the second. (To be explicit: I'm not saying they are doing this. But there are others here arguing that this is just not something they could be doing, which is absurd.)
You're describing supposition. That's fine! It's fine if we just agree.
Maybe I'm misunderstanding. It sounds like you agree that companies with proprietary code can't link GPL libraries, and Google's statements don't suggest any problem for companies which don't care about keeping their code proprietary.
> It sounds like you agree that companies with proprietary code can't link GPL libraries
No. This is incorrect. One cannot create derivative works with AGPL code. Linking does not necessarily create a derivative work. Whether or not it does depends on the specific case, and the degree to which the code intertwines. If I have an AGPL back-end and a proprietary front-end for an online photoeditor, that's probably a problem. If I have an AGPL database and a proprietary web app using it, that's generally not a problem.
Even in the photoeditor case, it only becomes a problem at distribution. For an internal tool, AGPL+proprietary is often okay (depending on who the internal team is). AGPL means a consumer-facing web app becomes a problem.
There is a sensible decision path for avoiding linking, but it has nothing to do with this. The arguments are:
1) Engineers aren't lawyers. For a big company, it's easier to have a hard rule (no AGPL) than to train engineers to be lawyers. For small companies, more nuance is okay.
2) AGPL is as much a legal mechanism as a social signaling mechanism. If I'm using a tool not the way the authors intended for me to use -- in an open ecosystem -- that creates its own problems.
No. This is incorrect. One cannot create derivative works with AGPL code. Linking does not necessarily create a derivative work. Whether or not it does depends on the specific case, and the degree to which the code intertwines. If I have an AGPL back-end and a proprietary front-end for an online photoeditor, that's probably a problem. If I have an AGPL database and a proprietary web app using it, that's generally not a problem.
Even in the photoeditor case, it only becomes a problem at distribution. For an internal tool, AGPL+proprietary is often okay (depending on who the internal team is). AGPL means a consumer-facing web app becomes a problem.
There is a sensible decision path for avoiding linking, but it has nothing to do with this. The arguments are:
1) Engineers aren't lawyers. For a big company, it's easier to have a hard rule (no AGPL) than to train engineers to be lawyers. For small companies, more nuance is okay.
2) AGPL is as much a legal mechanism as a social signaling mechanism. If I'm using a tool not the way the authors intended for me to use -- in an open ecosystem -- that creates its own problems.
Google's interpretation implies their belief that if their PostgreSQL server uses AGPL code, then every service using that PostgreSQL server must also be AGPL.
The article points out that that is not the case.
If you are using AGPL code as a library, however, then your application as a whole must be under an AGPL-compatible license. It's just that connecting to a server does not constitute linking in the GPL, and the AGPL doesn't change that.
The article points out that that is not the case.
If you are using AGPL code as a library, however, then your application as a whole must be under an AGPL-compatible license. It's just that connecting to a server does not constitute linking in the GPL, and the AGPL doesn't change that.
The article points out that Drew believes it isn't the case. Until this stuff is tested in court, there isn't a lawyer worth the name who would guarantee that. The language isn't precise enough to be 100% sure how courts will interpret it, and the downside risk is monumentally huge for a company like Google if the ruling goes against them.
> downside risk is monumentally huge for a company like Google if the ruling goes against them
The downside risk is damages. Those usually aren't monumentally huge. There's a calculation, but they're based on how much damage was done:
1) How much did Google profit from the code?
2) How much did the other party lose?
3) Are statutory damages greater?
Pick the highest of the three. If it's intentional -- and in this case it isn't -- you triple it. You might toss in legal fees.
#1 is the relative cost to going with an alternative solution (build in-house, license, etc.). #2 is usually zero for AGPL code. #3 is pocket change for Google. So you're likely to go with the cost of not having gone with AGPL in the first place, twice (once in damages, and once for the migration).
The downside risk is damages. Those usually aren't monumentally huge. There's a calculation, but they're based on how much damage was done:
1) How much did Google profit from the code?
2) How much did the other party lose?
3) Are statutory damages greater?
Pick the highest of the three. If it's intentional -- and in this case it isn't -- you triple it. You might toss in legal fees.
#1 is the relative cost to going with an alternative solution (build in-house, license, etc.). #2 is usually zero for AGPL code. #3 is pocket change for Google. So you're likely to go with the cost of not having gone with AGPL in the first place, twice (once in damages, and once for the migration).
Plus the cost of rewriting the project with a different dependency.
I don't think that's a fair interpretation of what Google said. Their reference to "accessed over a remote network" is about triggering the virality provisions in the first place, since the AGPL doesn't require you to distribute anything if you're just running a program by yourself without sharing it.
> This is the problem: I've fought with IP lawyers we've had on retainer who always boil it down to:
And I think most engineers would rather be doing other things than arguing with their employer's legal team. Their legal opinions may or may not be correct, but it doesn't really matter either way, because you are unlikely to change their mind. If Legal says "AGPL is not allowed", you don't waste your time arguing with them or begging for an exception, you just go look for an alternative component with a license they'll accept.
(If, hypothetically, one's employer's legal team were saying things completely outside the norm of the industry, it might be worth making an issue of it – but, banning AGPL is certainly well within the norm of the industry.)
And I think most engineers would rather be doing other things than arguing with their employer's legal team. Their legal opinions may or may not be correct, but it doesn't really matter either way, because you are unlikely to change their mind. If Legal says "AGPL is not allowed", you don't waste your time arguing with them or begging for an exception, you just go look for an alternative component with a license they'll accept.
(If, hypothetically, one's employer's legal team were saying things completely outside the norm of the industry, it might be worth making an issue of it – but, banning AGPL is certainly well within the norm of the industry.)
I've seen the same phobia to a lesser degree around the plain old GPL. Lawyers think, and not unreasonably, in terms of risk. Is there a risk you might be dragged into court? If so, that's a very expensive risk. Is the library or application worth this risk? If not, then ditch it.
It's not an unreasonable fear either given past events like the SCO/Linux lawsuit. IBM had deep enough pockets to fight it and win. Anyone else would have folded or been ruined.
It makes it hard to be anything but 100% "libre" (almost public domain) or commercial and closed source.
Being 100% libre means someone big can (and sometimes does) just take your work and put their name on it and monetize it. This wasn't much of a problem years ago, but it's a growing issue now. Being 100% commercial is of course the opposite. We're excluding the middle, to great detriment, and we really need a workable legal solution that won't scare lawyers.
It's not an unreasonable fear either given past events like the SCO/Linux lawsuit. IBM had deep enough pockets to fight it and win. Anyone else would have folded or been ruined.
It makes it hard to be anything but 100% "libre" (almost public domain) or commercial and closed source.
Being 100% libre means someone big can (and sometimes does) just take your work and put their name on it and monetize it. This wasn't much of a problem years ago, but it's a growing issue now. Being 100% commercial is of course the opposite. We're excluding the middle, to great detriment, and we really need a workable legal solution that won't scare lawyers.
I agree with this analysis, and I think that dual licensing can help here. That is, something is free is you want to use it in a copyleft-compatible fashion, and costs serious money for a commercial license if you want to go proprietary.
Even SQLite, which is public domain, offers a commercial "warranty of title" [1] if your company requires a guarantee that there can't be a lawsuit regarding the use of this software.
[1]: https://www.hwaci.com/cgi-bin/license-step1
Even SQLite, which is public domain, offers a commercial "warranty of title" [1] if your company requires a guarantee that there can't be a lawsuit regarding the use of this software.
[1]: https://www.hwaci.com/cgi-bin/license-step1
That makes a good deal of sense, since not all countries recognize the existence of public domain as a concept or the right of authors to dedicate their work to it before copyright expiration. (These cases are both mentioned on the link you provided.)
That's the reason why the original MIT license (X Consortium license) came into being. The developers wanted to get rid of headaches associated with the proprietary license but at least one of the companies involved wouldn't touch making the code public domain. So MIT's lawyers came up with the MIT license.
Lawyers run businesses, and drafting custom contracts/licence are a big part of their business.
GPL and standardized licences destroy this part of their business.
Also who pays a lawyers to read the thousands of page of licences for say Microsoft software (all the version of all the software deployed)? Where I work no one is able to know what Microsoft licence we need to buy, even when we ask licence sellers they mostly don't answer, and it changes all the time.
IIRC early Microsoft Visual C++ licences did not authorize the diffusion of debug compiled executables (don't know if it's still the case). How many violation of this?
GPL and standardized licences destroy this part of their business.
Also who pays a lawyers to read the thousands of page of licences for say Microsoft software (all the version of all the software deployed)? Where I work no one is able to know what Microsoft licence we need to buy, even when we ask licence sellers they mostly don't answer, and it changes all the time.
IIRC early Microsoft Visual C++ licences did not authorize the diffusion of debug compiled executables (don't know if it's still the case). How many violation of this?
Embedded is generally quite serious about this.
It's not even whether you comply, the issue is that if your company is getting bought you do NOT want the deal to get hung up over software licenses.
It's not even whether you comply, the issue is that if your company is getting bought you do NOT want the deal to get hung up over software licenses.
But isn't the middle ground requiring copyright assignment and then dual licensing?
Oh dear, your company's lawyers are afraid of the AGPL? Well then pay the project for a commercial license.
Oh dear, your company's lawyers are afraid of the AGPL? Well then pay the project for a commercial license.
Back-in-the-days MySQL had the view of GPL that if your application strictly required MySQL database, the GPL license would extend to it. Even if the app would only connected to the database over network.
”A license is required if [...] You have a commercial application that ONLY works with MySQL and ships the application with the MySQL server. This is because we view this as linking even if it is done over the network.”[1]
Not sure if they ever actually enforced this rule.
I wrote this just to point out that different companies can view these licenses differently. If company chooses AGPL, they clearly want to block certain use cases. I would be cautious when trying to dance around the limitations.
[1] http://ww2.cs.lamar.edu/doc/mysql/manual_Licensing_and_Suppo...
”A license is required if [...] You have a commercial application that ONLY works with MySQL and ships the application with the MySQL server. This is because we view this as linking even if it is done over the network.”[1]
Not sure if they ever actually enforced this rule.
I wrote this just to point out that different companies can view these licenses differently. If company chooses AGPL, they clearly want to block certain use cases. I would be cautious when trying to dance around the limitations.
[1] http://ww2.cs.lamar.edu/doc/mysql/manual_Licensing_and_Suppo...
>This is the problem: I've fought with IP lawyers we've had on retainer who always boil it down to: "It doesn't matter. We're not going to court to find out."
That's not really an argument, the lawyers are just pulling rank on you.
That's not really an argument, the lawyers are just pulling rank on you.
ddevault(4)
Disclaimer - As a CTO of a company I have to take a stance on these issues. As a matter of fact, as you raise money, part of the due diligence is to audit the libraries that you use to make sure that you don't use libraries that can jeopardize the future of the company.
Using an AGPL library for a Saas company will be flagged as a risk by lawyers during the due diligence process.
At Truework, we love open source and try to contribute when we can, but the reality is that if a library is AGPL, I'll ask my team to not use it. It's just not worth it to risk so much for a single library. Yes, it's unlikely that you will have to go to court because you use that one library, but if you do... well that's bad news for you.
If you build a business, it's about making sure that there there is a reasonable ROI for risks that you take. APGL tilts the balance towards "we shouldn't use this, it's too risky". Make your own decisions, but keep that in mind.
Using an AGPL library for a Saas company will be flagged as a risk by lawyers during the due diligence process.
At Truework, we love open source and try to contribute when we can, but the reality is that if a library is AGPL, I'll ask my team to not use it. It's just not worth it to risk so much for a single library. Yes, it's unlikely that you will have to go to court because you use that one library, but if you do... well that's bad news for you.
If you build a business, it's about making sure that there there is a reasonable ROI for risks that you take. APGL tilts the balance towards "we shouldn't use this, it's too risky". Make your own decisions, but keep that in mind.
And if you rely on large companies as clients they will have a line asking about GPL/AGPL library use during contracting for similar risk reasons.
It's the same when you go through M&A.
Hello,
While I'm employed to develop an agpl software, and I fond of this license, it's clear that with the wrong actors it can be a threat to some businesses.
I'll tell you a little story that happened around 10 years ago:
I got a call from a representative of Oracle, he asked me if we where using MySQL, and if I could described him how, because he wanted to help us make Better use of this tool.
We where pretty happy about MySQL at the time, and I went into deep details about how we used it. At the end, he told me point blank that the PHP's MySQL driver was licenced under the GPL and that we had to licence our whole codebase under the GPL since it was contaminating our code as a whole. (Even if we had encapsulated all the accesses to the driver around a single class)
The alternative was to pay the right to use it under a non GPL contaminating way.
Oracle then called and threatened us many times.
The argument that made them stop was when we told us that we where hosting the applications. This argument would not have been sufficient with the agpl.
There claim was unfonded but I can assure you that I didn't sleep well for a while!
I'll tell you a little story that happened around 10 years ago:
I got a call from a representative of Oracle, he asked me if we where using MySQL, and if I could described him how, because he wanted to help us make Better use of this tool.
We where pretty happy about MySQL at the time, and I went into deep details about how we used it. At the end, he told me point blank that the PHP's MySQL driver was licenced under the GPL and that we had to licence our whole codebase under the GPL since it was contaminating our code as a whole. (Even if we had encapsulated all the accesses to the driver around a single class)
The alternative was to pay the right to use it under a non GPL contaminating way.
Oracle then called and threatened us many times.
The argument that made them stop was when we told us that we where hosting the applications. This argument would not have been sufficient with the agpl.
There claim was unfonded but I can assure you that I didn't sleep well for a while!
Your story is a good reminder that these license questions aren't just about some holy war or ideology campaign. These are real people with real problems. We need to be more sensitive about how to structure licenses such as the AGPL.
I find I don't want even to use the GPL at times. Why? Not because I want to give away free stuff to Google. Rather, because I don't want to force others to use the same license that I use. You can use MIT code from a GPL code base, for example. I want to be nice. If Google uses it without paying me, that's fine, too. Honestly I'd probably feel pretty proud of myself at that point.
I find I don't want even to use the GPL at times. Why? Not because I want to give away free stuff to Google. Rather, because I don't want to force others to use the same license that I use. You can use MIT code from a GPL code base, for example. I want to be nice. If Google uses it without paying me, that's fine, too. Honestly I'd probably feel pretty proud of myself at that point.
Yes and no:
I currently work for the editor of iTop (an open source ITSM software).
Providing the software under an open source licence was a very early choice. But what if a rogue concurrent decided to fork and hire engineers to provide it's own, better version of the soft while keeping it closed source?
The only open source licence providing protection that I'm aware of is the AGPL.
When you throw on the project your lifetime savings, it is quite a reassuring licence.
Providing the software under an open source licence was a very early choice. But what if a rogue concurrent decided to fork and hire engineers to provide it's own, better version of the soft while keeping it closed source?
The only open source licence providing protection that I'm aware of is the AGPL.
When you throw on the project your lifetime savings, it is quite a reassuring licence.
You're doing proprietary software! You want to control it, you want to be the only person able to make money off it, and you magnanimously allow others to have the source under terms forbidding them from threatening your monopolies.
I know we all have to eat; I'm not a zealot who thinks all software should be open either. But I don't see how developers exercising a monopoly in order to extract rent is software freedom. I just want some rectification of names.
I know we all have to eat; I'm not a zealot who thinks all software should be open either. But I don't see how developers exercising a monopoly in order to extract rent is software freedom. I just want some rectification of names.
Stories like this are the reason I tell everyone to never touch MySQL and anything related to Oracle. If you need a relational DB, look no further than PostgreSQL.
Alternatively, if arbitrary, highly-litigious vendors start probing your private business activities, politely roll them to voicemail and your spam folder.
Unless you are already under contract or other legal order to do so, you do not have to tell anyone anything regarding the nature of your business. Every piece of information you give to one of those assholes is something that will be used against you in a lawsuit. Don't make things harder on yourself.
Unless you are already under contract or other legal order to do so, you do not have to tell anyone anything regarding the nature of your business. Every piece of information you give to one of those assholes is something that will be used against you in a lawsuit. Don't make things harder on yourself.
or MariaDB. or is oracle also going after MariaDB users, since they own a good amount of its code?
> The argument that made them stop was when we told us that we where hosting the applications.
I didn't get that, can you please rephrase?
I didn't get that, can you please rephrase?
The GPL only applies when you distribute software. The person you're distributing it to can request (and you must provide) source for GPL-derived works.
A service provider who hosts applications does not distribute software. They use it internally to provide the service. Thus, they do not trigger the distribution part of the GPL.
So Oracle can't say "you have to distribute source to your GPL-derived work or pay us lots of money" because you didn't distribute binaries for your GPL-derived work.
A service provider who hosts applications does not distribute software. They use it internally to provide the service. Thus, they do not trigger the distribution part of the GPL.
So Oracle can't say "you have to distribute source to your GPL-derived work or pay us lots of money" because you didn't distribute binaries for your GPL-derived work.
> Obligatory: I’m not a lawyer; this is for informational purposes only
That's the main point, though. You aren't, in fact, a lawyer. And this is not, in fact legal advice. You are presumably expert in a non-legal field, and you are giving expert opinion on something you are not an expert on.
The GPL is tested. The LGPL less so, but lawyers seem to be more comfortable with it.
There's the extra complexity that Google compiles its binaries statically.
You're calling Google liars. There's an alternative interpretation of events where a whole legal department, with great lawyers, and backed by great engineers to clarify the technical aspects for the lawyers, come to a different conclusion than yours.
And you just dismiss that as lies. I don't think that's fair at all. You wouldn't want a lawyer to come and say "bah, you should just make that inherently NP problem complete fast for all inputs. How hard could it be? If you say it's hard then you're lying.".
> this is for informational purposes only
This is pretty arrogant. "I'm not a lawyer, but here are the real legal facts to ACTUALLY educate you".
You should say it's "for speculation purposes only", or "for entertainment purposes only".
> Don’t be afraid to use the AGPL, and don’t be afraid to use software which uses the AGPL.
This is ignoring one big problem though. Agree or not, call them liars or not, but Google and it's employees will NOT touch your software. Not only will you not get Google as users (though if you dual-license yes in fact Google DOES buy software, if they can buy it as non-AGPL), you will not get Google employees as contributors.
That's the main point, though. You aren't, in fact, a lawyer. And this is not, in fact legal advice. You are presumably expert in a non-legal field, and you are giving expert opinion on something you are not an expert on.
The GPL is tested. The LGPL less so, but lawyers seem to be more comfortable with it.
There's the extra complexity that Google compiles its binaries statically.
You're calling Google liars. There's an alternative interpretation of events where a whole legal department, with great lawyers, and backed by great engineers to clarify the technical aspects for the lawyers, come to a different conclusion than yours.
And you just dismiss that as lies. I don't think that's fair at all. You wouldn't want a lawyer to come and say "bah, you should just make that inherently NP problem complete fast for all inputs. How hard could it be? If you say it's hard then you're lying.".
> this is for informational purposes only
This is pretty arrogant. "I'm not a lawyer, but here are the real legal facts to ACTUALLY educate you".
You should say it's "for speculation purposes only", or "for entertainment purposes only".
> Don’t be afraid to use the AGPL, and don’t be afraid to use software which uses the AGPL.
This is ignoring one big problem though. Agree or not, call them liars or not, but Google and it's employees will NOT touch your software. Not only will you not get Google as users (though if you dual-license yes in fact Google DOES buy software, if they can buy it as non-AGPL), you will not get Google employees as contributors.
> You're calling Google liars. There's an alternative interpretation of events where a whole legal department, with great lawyers, and backed by great engineers to clarify the technical aspects for the lawyers, come to a different conclusion than yours.
Google claims that they care about your privacy. Entire teams of engineers and lawyers will say the same thing. But when you look at it, you can plainly see that they are probably just saying that because their main business is collecting data about you. Similarly, Google runs many projects with a closed-source server-side component, and using the AGPL would not let them do that. Do you see why it is not surprising they would come to a different conclusion?
Google claims that they care about your privacy. Entire teams of engineers and lawyers will say the same thing. But when you look at it, you can plainly see that they are probably just saying that because their main business is collecting data about you. Similarly, Google runs many projects with a closed-source server-side component, and using the AGPL would not let them do that. Do you see why it is not surprising they would come to a different conclusion?
So your legal interpretation as a lawyer (I assume) is an ad hominem on Google for unrelated reasons?
And Microsoft said all GPL was a cancer and unamerican and viral and disallowed it from about 50k engineer's computers due to "legal risk of GPL virality", and this was when they were by far the biggest software company. Wait, they lied? It was all FUD and really about threatening their business model. They changed their policies and actually said publicly they were wrong. Is it so hard to believe?
Right. So because MS used the wrong strategy that is evidence that Google's lawyers are deriving incorrect legal conclusions?
Is that your argument?
So because MS was wrong once, Google is wrong other times of your choosing?
Is that your argument?
So because MS was wrong once, Google is wrong other times of your choosing?
Awesome article! I was in an organization which had an AGPL ban. After a couple of months with lawyers, it's now a major AGPL supporter. AGPL lets you build ecosystems around your software, where everyone contributes, and no one can parasitically compete with you. It's absolutely the right tool for a lot of uses.
I'm no longer with the organization, but it had:
* Hundreds of open-source contributors
* Millions of users, mostly paying
* Zero direct competitors using the software. With equal ground for technology, it'd be almost impossible to overcome first-mover and branding advantage unless the organization really messed up
* Hundreds of major open source users doing interesting things with the software and using it in non-competing contexts. That translated into product enhancements.
With GPL or BSD, it almost certainly would have played out as lots of competitors doing an extend-and-proprietize, and instead of a successful open company, it would have been a dead organization.
So many misconceptions abound.
The flip side, though, isn't that everyone should use the AGPL. You should have the right license for the right context.
I'm no longer with the organization, but it had:
* Hundreds of open-source contributors
* Millions of users, mostly paying
* Zero direct competitors using the software. With equal ground for technology, it'd be almost impossible to overcome first-mover and branding advantage unless the organization really messed up
* Hundreds of major open source users doing interesting things with the software and using it in non-competing contexts. That translated into product enhancements.
With GPL or BSD, it almost certainly would have played out as lots of competitors doing an extend-and-proprietize, and instead of a successful open company, it would have been a dead organization.
So many misconceptions abound.
The flip side, though, isn't that everyone should use the AGPL. You should have the right license for the right context.
I find this comment puzzling. You're arguing from an IP owner's perspective. Whether you support using AGPL for your own software is completely orthogonal to whether you should use someone else's AGPL code in your proprietary product (assuming being proprietary is a done decision).
(Btw, one can argue that you have a vested interest in strengthening AGPL so that other companies would more readily choose your AGPL software and then be locked in to your ecosystem, so you're knowingly minimizing the associated risks on this thread.
You see what I did there? Yeah, attack on your integrity based on speculations, exactly like TFA.)
(Btw, one can argue that you have a vested interest in strengthening AGPL so that other companies would more readily choose your AGPL software and then be locked in to your ecosystem, so you're knowingly minimizing the associated risks on this thread.
You see what I did there? Yeah, attack on your integrity based on speculations, exactly like TFA.)
The simple solution there is to not make a proprietary product to begin with. Sorry, not trying to be snarky, but that (among other things) is the price you pay for that decision. It's baffling to me how some companies are so resistant to having to conduct legal reviews to use open source, which in a lot of cases will directly make them money, but at the same time these companies will gladly wave a giant NDA at someone just to start a negotiation.
Evidently, it's even simpler, easier, and more profitable to not use an AGPL project instead.
It's not always a choice. There are people who cannot open source their software due to other legal, organizational, or practical factors.
That is still a choice. It may just be that your boss is ignoring your input and making the choice for you, which is a different problem.
No, there are plenty of circumstances where there laws and/or contractual obligations other than software licenses become involved in software development which can conflict. See healthcare, government, finance, regulated industries, etc.
I've worked in several of those industries. Oddly enough, open source was always easier there. I'd challenge you to find a regulation which prevents open source in any of those industries.
I think the one exception -- and this was an extreme example -- was the firmware of a medical device which could endanger human lives if modified. Things were locked down.
But generically? I'm batting maybe 75% with open source in highly-regulated industries.
I think the one exception -- and this was an extreme example -- was the firmware of a medical device which could endanger human lives if modified. Things were locked down.
But generically? I'm batting maybe 75% with open source in highly-regulated industries.
ITAR? Any contract work under an NDA? Sensitive government work? Any code that implements trade secrets? Any custom enterprise software with hard-coded exceptions for controlled data?
You can certainly use open source in regulated industries -- the question is, can they risk the legal possibility of being forced to open source the rest of their stack if the a court determines AGPL requires it.
You can certainly use open source in regulated industries -- the question is, can they risk the legal possibility of being forced to open source the rest of their stack if the a court determines AGPL requires it.
I'm not saying everything done is open source. I'm saying it's less common in regulated industries.
NDA / sensitive government work -> FOIA makes restrictions tough. I can request government source code.
Trade secrets -> The government can't really keep trade secrets. I guess if I were working with classified code?
Hard-coded exceptions -> Not specific to regulated industries but bad design.
Legal possibility -> This is not a legal possibility. A legal possibility is paying damages. It's the same if I break a proprietary license too (for example, accidentally ship out a copy of a library I paid for just one license with my product).
NDA / sensitive government work -> FOIA makes restrictions tough. I can request government source code.
Trade secrets -> The government can't really keep trade secrets. I guess if I were working with classified code?
Hard-coded exceptions -> Not specific to regulated industries but bad design.
Legal possibility -> This is not a legal possibility. A legal possibility is paying damages. It's the same if I break a proprietary license too (for example, accidentally ship out a copy of a library I paid for just one license with my product).
FOIA has a substantial list of exemptions, and many of them would apply to a lot of code that the government uses.
Above, I was referring to trade secrets in the private sector, but actually, that is one of the FOIA exemptions too.
Also, a lot of code running in production is poorly designed. I'd bet the vast majority of it is poorly designed.
Damages are one part of it, but you also have to return to compliance, which means you either have to follow the license or stop using the code. Given that the AGPL doesn't have linking exceptions, the concern is that might be all of an organization's code.
That's not to say that you can't use open source in industries where these might be concerns -- almost all other common open source licenses don't have this problem.
Above, I was referring to trade secrets in the private sector, but actually, that is one of the FOIA exemptions too.
Also, a lot of code running in production is poorly designed. I'd bet the vast majority of it is poorly designed.
Damages are one part of it, but you also have to return to compliance, which means you either have to follow the license or stop using the code. Given that the AGPL doesn't have linking exceptions, the concern is that might be all of an organization's code.
That's not to say that you can't use open source in industries where these might be concerns -- almost all other common open source licenses don't have this problem.
And that is still a choice, but your lawmakers have made it for you. Alternatively, you can choose not to develop for those industries.
I think you'll find few people who are willing to make changes to those things just to implement an AGPL library --- and even fewer who would call it a "simple solution".
I don't disagree with that. My point is that historically, it's been their choice and as a result it's been mostly their loss. When there is will to use the software, but they refuse to take the time to understand the licensing or dismiss it as not being simple enough, the other corporate entities behind it will gladly overcharge them for some kind of proprietary license or legal consultancy scheme.
Proprietary licenses aren't the only alternative to the risk of the AGPL (whether real or perceived). For example: I've never heard of a corporate lawyer having finding issue with an MIT or Apache license.
I've run into lots of libraries over my career with vague, conflicting, or otherwise questionable licenses. So far, 100% of the time I've been able to easily find an alternative open source project with a better, more clear, license. If both get the job done, I'll pick the one that doesn't keep me up at night every time.
I've run into lots of libraries over my career with vague, conflicting, or otherwise questionable licenses. So far, 100% of the time I've been able to easily find an alternative open source project with a better, more clear, license. If both get the job done, I'll pick the one that doesn't keep me up at night every time.
> After a couple of months with lawyers, it's now a major AGPL supporter
I had a similar experience. I took exams on patent and copyright law with IP lawyers as teachers during my degree.
Then I worked in well known tech companies and had the opportunity to attend meetings with lawyers, business people, read contracts, etc. and oh boy!
Misconceptions abound terribly. The average techie overestimates his/her understanding of law and business.
"permissive" licenses are stupidly lenient. Companies never sign similar contracts between each other when exchanging goods or services. Contracts have hundreds of defensive clauses to mitigate risks or ensure fairness.
I had a similar experience. I took exams on patent and copyright law with IP lawyers as teachers during my degree.
Then I worked in well known tech companies and had the opportunity to attend meetings with lawyers, business people, read contracts, etc. and oh boy!
Misconceptions abound terribly. The average techie overestimates his/her understanding of law and business.
"permissive" licenses are stupidly lenient. Companies never sign similar contracts between each other when exchanging goods or services. Contracts have hundreds of defensive clauses to mitigate risks or ensure fairness.
Anyone have guesses to the organization here, since they’re pointedly not mentioning it? I find that a bit confusing since their code is probably publicly available under the AGPL, which is really all this comment discusses.
I have significant responsibility for setting open-source policy at my company. We require specific review on a facts-and-circumstances basis of any AGPL usage.
Why? Because for most open-source licenses, it's clear how to avoid any license controversy entirely by simply never conveying the licensed work. If I don't ship you ("convey to you") any binaries, I have no obligations to you under GPL (or MIT or Apache, obviously). For the most part, we don't ship anyone outside the company binaries, so compliance (both in fact and in provability of that fact) is relatively easy. Not so with AGPL.
If there was critically useful code only licensed under AGPL, we'd consider it, of course. But it would get a lot more review than a typical Apache/MIT/GPL license situation. I have no philosophical objection to AGPL; I just find it a much less practical license than most of the other, much more commonly used, licenses.
Why? Because for most open-source licenses, it's clear how to avoid any license controversy entirely by simply never conveying the licensed work. If I don't ship you ("convey to you") any binaries, I have no obligations to you under GPL (or MIT or Apache, obviously). For the most part, we don't ship anyone outside the company binaries, so compliance (both in fact and in provability of that fact) is relatively easy. Not so with AGPL.
If there was critically useful code only licensed under AGPL, we'd consider it, of course. But it would get a lot more review than a typical Apache/MIT/GPL license situation. I have no philosophical objection to AGPL; I just find it a much less practical license than most of the other, much more commonly used, licenses.
It's neither more nor less practical in general. It's less practical for your company.
It depends on what you're trying to accomplish. If your goal is to build a low-friction library for others to adopt (e.g. JQuery), it's a horrible, horrible license. If you're trying to build an ecosystem around an end-user tool (e.g. I'm making a web-based competitor to Adobe Illustrator), it can be an awesome license. Lots of open source tools aren't intended to be integrated into other systems, but used stand-alone. That's where licenses like the AGPL really shine.
It depends on what you're trying to accomplish. If your goal is to build a low-friction library for others to adopt (e.g. JQuery), it's a horrible, horrible license. If you're trying to build an ecosystem around an end-user tool (e.g. I'm making a web-based competitor to Adobe Illustrator), it can be an awesome license. Lots of open source tools aren't intended to be integrated into other systems, but used stand-alone. That's where licenses like the AGPL really shine.
I haven't commented on HN in a while, but this article actually pretty much complains about me, since I wrote the text in question and enabled the policy to be released.
So i'm just going to say:
1. The author claims the Google states something, then doesn't actually quote anything google stated, but instead writes their own interpretation of the words and a made up example. That's not a good start.
2. Having set up their own example, the author then proceeds to say it's wrong because of an appeal to authority, asserting no reasonable disagreement is possible - when not only is it possible, but large numbers of IP lawyers disagree on what the AGPL requires. It's true that someone wrote it, and there are FAQ's, but depending when and where, their opinion on what it means is not as relevant as one might think.
In truth, lots of people disagree over interpretation of the AGPL - many more than disagree about GPL interpretation or LGPL interpretation (which are fairly settled at this point). Searches over any legal licensing list in existence will you this.
When I wrote the interpretation you see here, it was the best available info at the time, guided not just by own views, but by listening to a lot of smart lawyers, counterparts at other companies, etc.
Even if you ignore all the lawyers and whatever as useless, the author has the huge problem that There are people who make AGPL software that take the view listed in the google policy
So it's not just Google or lawyers, it's software authors. Not just a few, either.
While companies are generally happy to ignore one or two people whose interpretation is outside the norm (and just not use their software), that's much harder when there is such widespread difference in view of the AGPL.
3. For no particular reason at all, the author then decides to assert a tremendous amount of bad faith in interpretation of the AGPL and reasons for publishing such policies.
We published our policies because over the years I (and others) were repeatedly asked by counterparts at other companies, various communities, and others to understand what our policies look like, for a variety of reasons (to understand for themselves, to use as a template, etc)
Period. That's the whole reason. It even says this: https://opensource.google/docs/
The author here has decided that's clearly all lies or deliberate misinformation, without even bothering to even ask anybody.
So i'm just going to say:
1. The author claims the Google states something, then doesn't actually quote anything google stated, but instead writes their own interpretation of the words and a made up example. That's not a good start.
2. Having set up their own example, the author then proceeds to say it's wrong because of an appeal to authority, asserting no reasonable disagreement is possible - when not only is it possible, but large numbers of IP lawyers disagree on what the AGPL requires. It's true that someone wrote it, and there are FAQ's, but depending when and where, their opinion on what it means is not as relevant as one might think.
In truth, lots of people disagree over interpretation of the AGPL - many more than disagree about GPL interpretation or LGPL interpretation (which are fairly settled at this point). Searches over any legal licensing list in existence will you this.
When I wrote the interpretation you see here, it was the best available info at the time, guided not just by own views, but by listening to a lot of smart lawyers, counterparts at other companies, etc.
Even if you ignore all the lawyers and whatever as useless, the author has the huge problem that There are people who make AGPL software that take the view listed in the google policy
So it's not just Google or lawyers, it's software authors. Not just a few, either.
While companies are generally happy to ignore one or two people whose interpretation is outside the norm (and just not use their software), that's much harder when there is such widespread difference in view of the AGPL.
3. For no particular reason at all, the author then decides to assert a tremendous amount of bad faith in interpretation of the AGPL and reasons for publishing such policies.
We published our policies because over the years I (and others) were repeatedly asked by counterparts at other companies, various communities, and others to understand what our policies look like, for a variety of reasons (to understand for themselves, to use as a template, etc)
Period. That's the whole reason. It even says this: https://opensource.google/docs/
The author here has decided that's clearly all lies or deliberate misinformation, without even bothering to even ask anybody.
I can confirm what Danny says here.
It's a shame the original article has such flaws in its argumentation, because at the core of it I think there are some good points. Notably, other people don't have to blindly follow Google's example and reasoning. In fact, as discussed here, there are good reasons not to. For one, because Google is so highly integrated (with Borg and its monorepo, not to mention custom approaches to security), it's harder to use AGPL software without risking linking. Most other users outside Google would just apt-get a package or the like. And of course the business risk to Google is large simply because of their scale.
You can even disagree with Google's decision not to use AGPL, but they have openly explained their reasoning, and I think that adds to the discourse.
Disclosure: I used to work at Google, and was fairly actively involved with open-source activities in different capacities while I was there. I am also on record as sharply criticizing Google when I believe that is warranted. This is just not one of those times.
It's a shame the original article has such flaws in its argumentation, because at the core of it I think there are some good points. Notably, other people don't have to blindly follow Google's example and reasoning. In fact, as discussed here, there are good reasons not to. For one, because Google is so highly integrated (with Borg and its monorepo, not to mention custom approaches to security), it's harder to use AGPL software without risking linking. Most other users outside Google would just apt-get a package or the like. And of course the business risk to Google is large simply because of their scale.
You can even disagree with Google's decision not to use AGPL, but they have openly explained their reasoning, and I think that adds to the discourse.
Disclosure: I used to work at Google, and was fairly actively involved with open-source activities in different capacities while I was there. I am also on record as sharply criticizing Google when I believe that is warranted. This is just not one of those times.
Thanks for having publiished these policies publicly! You gave a pretty clear summary of Google's motivations for banning AGPL on HN five and three years ago two of the previous times this came up, and having worked at Google 2011-2015 (including some interactions there with you), your public explanations of why from back then are extremely credible and rational given the logistics of what's easy and hard inside Google.
https://news.ycombinator.com/item?id=9956542
https://news.ycombinator.com/item?id=13979443
Not that I'm surprised, as you've always been pretty forthright and honest. Thanks for continuing to be that way.
https://news.ycombinator.com/item?id=9956542
https://news.ycombinator.com/item?id=13979443
Not that I'm surprised, as you've always been pretty forthright and honest. Thanks for continuing to be that way.
Of course. I appreciate the thoughts.
I try my best to be transparent and straightforward.
I actually do think it's reasonable to expect companies to re-evaluate every few years (at a minimum) because the world changes. At some point, the reasoning from X years ago will not make sense anymore.
One of the top rules of sane policy making is to write into the policy the conditions that should cause you to re-evaluate it, whether it's time, or change in evidence you relied on, or ...
You want people to understand your rationale and what might change your mind, otherwise you shouldn't expect them to go along with it.
Even though such a rationale exists in various emails, etc, I actually failed to do that in the resulting police here, unfortunately (the internal version is not any better in this respect). That one is on me and I think would be a more legitimate complaint here.
I don't think it would have changed yet (if anything, the AGPL has become more contentious as the economy has gone south), but that's just an at-a-glance view.
I actually do think it's reasonable to expect companies to re-evaluate every few years (at a minimum) because the world changes. At some point, the reasoning from X years ago will not make sense anymore.
One of the top rules of sane policy making is to write into the policy the conditions that should cause you to re-evaluate it, whether it's time, or change in evidence you relied on, or ...
You want people to understand your rationale and what might change your mind, otherwise you shouldn't expect them to go along with it.
Even though such a rationale exists in various emails, etc, I actually failed to do that in the resulting police here, unfortunately (the internal version is not any better in this respect). That one is on me and I think would be a more legitimate complaint here.
I don't think it would have changed yet (if anything, the AGPL has become more contentious as the economy has gone south), but that's just an at-a-glance view.
> Google states that if, for example, Google Maps used PostGIS as its data store, and PostGIS used the AGPL, Google would be required to release the Google Maps code. This is not true. They would be required to release their PostGIS patches in this situation. AGPL does not extend the GPL in that it makes the Internet count as a form of linking which creates a derivative work, as Google implies, but rather that it makes anyone who uses the the software via the Internet entitled to its source code.
Is there an existing national court case which supports this assertion? Otherwise it's a valid concern given that lawsuits and judges may have different interpretations than engineers. Just look at the Oracle vs. Google debacle over Java.
Is there an existing national court case which supports this assertion? Otherwise it's a valid concern given that lawsuits and judges may have different interpretations than engineers. Just look at the Oracle vs. Google debacle over Java.
Eben Moglen wrote the AGPL. There's a standard process courts use to figure this stuff out. Intent fits into it. Eben Moglen clearly states what he meant in many talks. Courts favor intended interpretation of a contract. That makes the risk pretty small.
In the case of ambiguity in a contract, courts look at the intent of the parties to the contract. In almost all cases Moglen will not be a party, and at least one of the actual parties will not be aware of those talks or their content, so Moglen's talks on the matter won't really be of much use.
Courts will also look at the bargaining power of the parties. If the party offering the contract is a lot more powerful than the party accepting the contract, they will tend to favor the accepting party when it comes to ambiguous terms.
Courts will also look at the bargaining power of the parties. If the party offering the contract is a lot more powerful than the party accepting the contract, they will tend to favor the accepting party when it comes to ambiguous terms.
It's a little more complex than that. The intent of the parties /drafting/ the contract do matter. Public writings clarifying the intent do as well.
This is probably one of the reasons why the Free Software Foundation has such an extensive FAQ, because it's the easiest way for them to document their intent.
Indeed. It's hard to go back and argue a different interpretation later in court, if the intended interpretation is so clearly stated and defined.
Intent of whom? Eben Moglen is not the owner of the copyright but merely the writer of the license. If Oracle, for example, uses AGPL would it not be their intent in using the license which actually matters?
I don't think this really supports your point? Eben Moglen has indeed clearly stated what he meant; he thinks free software ideals are very important and tried to write GPL-family licenses so that developers would be compelled to respect them.
So. From the POW of a total lay person as far as it comes to law.
Someone writes a blog post with an 'IANAL' disclaimer on top saying that what Google's army of lawyers have gathered from reading a legal document is false, and I should favor his interpretation instead. I don't know, I'm not exactly convinced.
Someone writes a blog post with an 'IANAL' disclaimer on top saying that what Google's army of lawyers have gathered from reading a legal document is false, and I should favor his interpretation instead. I don't know, I'm not exactly convinced.
>Someone writes a blog post with an 'IANAL' disclaimer on top saying that what Google's army of lawyers have gathered from reading a legal document is false, and I should favor his interpretation instead. I don't know, I'm not exactly convinced.
Microsoft with their giant army of lawyers also said GPL is a cancer and they promoted this idea a lot but today Microsoft "loves" GPL. I think you can conclude that you should use your own brain to decide and not let a giant company decide for you, they might have a huge financial interest to promote a certain narrative. It is clear in this case that Google would prefer their employees won't work on their free time on AGPL code.
Microsoft with their giant army of lawyers also said GPL is a cancer and they promoted this idea a lot but today Microsoft "loves" GPL. I think you can conclude that you should use your own brain to decide and not let a giant company decide for you, they might have a huge financial interest to promote a certain narrative. It is clear in this case that Google would prefer their employees won't work on their free time on AGPL code.
I was not actually talking about the totality of Google's verdict about AGPL. For some projects in some companies it might just be the right license to use. Rather, I was talking about the particular example of Google Maps and PostGIS.
Google's army of lawyers say: If PostGIS 'this' => Google Maps must be 'this'. And the author says, 'no, that's false'. Someone must be wrong here. And if I had to place a bet on which side is more likely to have gotten it the way a court of law might interpret it, I'd put my bet on a bunch of people with law degrees.
Google's army of lawyers say: If PostGIS 'this' => Google Maps must be 'this'. And the author says, 'no, that's false'. Someone must be wrong here. And if I had to place a bet on which side is more likely to have gotten it the way a court of law might interpret it, I'd put my bet on a bunch of people with law degrees.
I would be careful about that. People with law degrees rarely provide useful generic guidance. They're paid not to, and there's a lot of downsides for them to do so.
Consequently, always treat guidance from folks with law degrees with a degree of skepticism. Do your own research and ideally get your own person with a law degree to develop an opinion you can trust.
Consequently, always treat guidance from folks with law degrees with a degree of skepticism. Do your own research and ideally get your own person with a law degree to develop an opinion you can trust.
> you should use your own brain to decide
I think you mean "your own lawyers". And my experience says that the AGPL opinion among these experts are about as one-sided as scientists and climate change.
But you're suggesting to armchair lawyer it?
I think you mean "your own lawyers". And my experience says that the AGPL opinion among these experts are about as one-sided as scientists and climate change.
But you're suggesting to armchair lawyer it?
Only if your decide you need a lawyer.
:-P
It's OK to drive drunk, as long as you put a blindfold on so you can't see that you're drunk?
It's OK to drive drunk, as long as you put a blindfold on so you can't see that you're drunk?
I mean use your judgement, say you want to do npm install X, do you call your lawyers all the time or use your judgement?
Don't do X because Google is doing it, think for yourself and if you consider that you are not sure then ask for an expert. My point is if Microsoft says GPL is evil and you believe that and later when MS is open sourcing stuff and contributing to Linux you will have to admit that maybe MS had a giant interest to say that. those interests changed so MS changed, you should have never listen to MS without thinking for yourself and considering what MS interests are.
Don't do X because Google is doing it, think for yourself and if you consider that you are not sure then ask for an expert. My point is if Microsoft says GPL is evil and you believe that and later when MS is open sourcing stuff and contributing to Linux you will have to admit that maybe MS had a giant interest to say that. those interests changed so MS changed, you should have never listen to MS without thinking for yourself and considering what MS interests are.
> I mean use your judgement, say you want to do npm install X, do you call your lawyers all the time or use your judgement?
Before starting to use code for my business, I'd check the license, yes. Almost all the time it's a standard one, so I know approximately that yes BSD, MIT, GPL, etc… means. Though I have to be careful about BSD with advertising clause.
Before starting to depend on code for my business, yes I would make sure that I am not violating a license.
Your "only if you decide you need a lawyer" seems to be saying that your opinion is necessarily right. You don't decide if you need a lawyer, you either do or you don't. And you make the right choice or you don't. (and their guidance is right or it isn't)
> Don't do X because Google is doing it, think for yourself and if you consider that you are not sure then ask for an expert.
Sure. You can peruse the AGPL, and if you think your amateur interpretation of this legally untested license does not add unacceptable risk, then you can choose to go ahead with it.
Google got sued for reimplementing an API. And they may lose (currently awaiting the supreme court).
People have been suing much smaller companies for GPL violations. It's a matter of time before someone sues for perceived AGPL violation due to what Google's lawyers are describing.
> My point is if Microsoft says GPL is evil and you believe that and later when MS is open sourcing stuff and contributing to Linux you will have to admit that maybe MS had a giant interest to say that.
Yup. That doesn't mean they're factually wrong. But yes there's the aspect of "It's hard to make someone understand that they are wrong when their income depends on them not understanding it".
But just because someone has a reason to do something, doesn't mean they did it. It's not an argument about correctness.
Before starting to use code for my business, I'd check the license, yes. Almost all the time it's a standard one, so I know approximately that yes BSD, MIT, GPL, etc… means. Though I have to be careful about BSD with advertising clause.
Before starting to depend on code for my business, yes I would make sure that I am not violating a license.
Your "only if you decide you need a lawyer" seems to be saying that your opinion is necessarily right. You don't decide if you need a lawyer, you either do or you don't. And you make the right choice or you don't. (and their guidance is right or it isn't)
> Don't do X because Google is doing it, think for yourself and if you consider that you are not sure then ask for an expert.
Sure. You can peruse the AGPL, and if you think your amateur interpretation of this legally untested license does not add unacceptable risk, then you can choose to go ahead with it.
Google got sued for reimplementing an API. And they may lose (currently awaiting the supreme court).
People have been suing much smaller companies for GPL violations. It's a matter of time before someone sues for perceived AGPL violation due to what Google's lawyers are describing.
> My point is if Microsoft says GPL is evil and you believe that and later when MS is open sourcing stuff and contributing to Linux you will have to admit that maybe MS had a giant interest to say that.
Yup. That doesn't mean they're factually wrong. But yes there's the aspect of "It's hard to make someone understand that they are wrong when their income depends on them not understanding it".
But just because someone has a reason to do something, doesn't mean they did it. It's not an argument about correctness.
>But just because someone has a reason to do something, doesn't mean they did it. It's not an argument about correctness.
Exactly, Google using or not using a license or some shady practice does not mean it is correct. It sucks that in US you have this weird thing where until someone is brought to court you are not sure what the rules actually are interpreted, from what the other comments mentioned the author(a lawyer) responded to this concerns and clarified things but yeah, we might need to forever wait or find some more courage
Exactly, Google using or not using a license or some shady practice does not mean it is correct. It sucks that in US you have this weird thing where until someone is brought to court you are not sure what the rules actually are interpreted, from what the other comments mentioned the author(a lawyer) responded to this concerns and clarified things but yeah, we might need to forever wait or find some more courage
Big corporations avoiding AGPL like the plague makes it a much better "don't be evil" license than any other attempts at making one of those. If anything, I'd love to see some dual license scheme where a different license is available only to small developers or non-profits, rather rather than corporations with bags of cash. I wonder how that can be enforced - perhaps some sort of a CLA that only gives limited rights to relicense instead of just handing over the copyright entirely.
And yeah, this goes entirely counter to making profit, but hey, I think we're privileged enough to afford to try ideas like this.
And yeah, this goes entirely counter to making profit, but hey, I think we're privileged enough to afford to try ideas like this.
Truth or falsehoods aside, the reason one of the places I have worked (large 10's of k's of employees, big legal staff) refused to let us use AGPL is that it had never been decided in court, and they didn't want to be the ones to foot that bill.
"No" is pretty cheap, and they were pretty good at it.
"No" is pretty cheap, and they were pretty good at it.
> "No" is pretty cheap
Now, is it really? Paying a team of software engineers to recreate every AGPL project surely isn't…
Now, is it really? Paying a team of software engineers to recreate every AGPL project surely isn't…
Nobody is using every AGPL project and there aren't that many AGPL projects to begin with.
The problem is not just the risk associated with AGPL, it's also that the benefit is actually quite small. I think most companies would be a lot more willing to use AGPL, if there were any compelling projects using it.
The problem is not just the risk associated with AGPL, it's also that the benefit is actually quite small. I think most companies would be a lot more willing to use AGPL, if there were any compelling projects using it.
But using a non-AGPL project is a cheap and easy solution for just about every use-case out there. If there was something special that was AGPL licensed it might matter, but there isn't so it is easy to avoid.
> Any derivative works of AGPL-licensed software must also use the AGPL.
TBH, I'm interpreting this statement just like Google is:
> Google states that if, for example, Google Maps used PostGIS as its data store, and PostGIS used the AGPL, Google would be required to release the Google Maps code.
What's the definition of 'derivative work' here?
TBH, I'm interpreting this statement just like Google is:
> Google states that if, for example, Google Maps used PostGIS as its data store, and PostGIS used the AGPL, Google would be required to release the Google Maps code.
What's the definition of 'derivative work' here?
Eben Moglen talks about this at length (author of the license). The rough lines are drawn as per how closely the works couple and interdepend on each other.
For example, if I build an extension which works with Chrome and Firefox, over a well-defined API, that's an independent work. AGPL/GPL/LGPL does not apply.
If I have two pieces of code which mutually rely on each other and form a common system, and for example call back-and-forth, or have APIs specific to each other, that generally does form a derivative work.
There's a lot of literature out there about static versus dynamic versus microservice abstraction. That's mostly nonsense. Lawyers don't care about that. You can't get around the AGPL (or even the original GPL) that way, by isolating the GPLed code into a corner over a network service.
(disclaimer: not legal advice, get a laywer if you want legal advice).
For example, if I build an extension which works with Chrome and Firefox, over a well-defined API, that's an independent work. AGPL/GPL/LGPL does not apply.
If I have two pieces of code which mutually rely on each other and form a common system, and for example call back-and-forth, or have APIs specific to each other, that generally does form a derivative work.
There's a lot of literature out there about static versus dynamic versus microservice abstraction. That's mostly nonsense. Lawyers don't care about that. You can't get around the AGPL (or even the original GPL) that way, by isolating the GPLed code into a corner over a network service.
(disclaimer: not legal advice, get a laywer if you want legal advice).
> For example, if I build an extension which works with Chrome and Firefox, over a well-defined API, that's an independent work. AGPL/GPL/LGPL does not apply.
> If I have two pieces of code which mutually rely on each other and form a common system, and for example call back-and-forth, or have APIs specific to each other, that generally does form a derivative work.
So why does the LGPL/Linking Exception exist at all? Software which links against libc doesn't have a mutual dependency; libc is quite happy to run crt0 as long as there's a main symbol somewhere, and yet apparently linking against libc would be enough to constitute a derivative work were it not for the exceptions in the LGPL.
> If I have two pieces of code which mutually rely on each other and form a common system, and for example call back-and-forth, or have APIs specific to each other, that generally does form a derivative work.
So why does the LGPL/Linking Exception exist at all? Software which links against libc doesn't have a mutual dependency; libc is quite happy to run crt0 as long as there's a main symbol somewhere, and yet apparently linking against libc would be enough to constitute a derivative work were it not for the exceptions in the LGPL.
Wrt. GPLv2 what counts as derived work is a mess.
LGPL mainly exists because statically linking a library into a binary (especially with link time optimizations enabled) will somewhat modify the binary code of the linked library in the way it is placed in which some lawyers use to argue that static linking is always a derived work.
So LGPL let's you rest in peace if you need static linking.
(I also have read arguments that even dynamic linking is derived work or that it's totally independent of the linking method but on how the linked code is used. All from lawyers, through not all from US lawyers. Also that was quite a while ago, some curt might have clarified such aspects.)
LGPL mainly exists because statically linking a library into a binary (especially with link time optimizations enabled) will somewhat modify the binary code of the linked library in the way it is placed in which some lawyers use to argue that static linking is always a derived work.
So LGPL let's you rest in peace if you need static linking.
(I also have read arguments that even dynamic linking is derived work or that it's totally independent of the linking method but on how the linked code is used. All from lawyers, through not all from US lawyers. Also that was quite a while ago, some curt might have clarified such aspects.)
I think that RMS was fairly clear that he thought that linked code was a derived work as far as the GPL was concerned, and that’s why the LGPL was created.
A license and its drafters can't decide or change what is considered derived work - that's a core concept of copyright law where any nuances could be dependent on the jurisdiction but not on any particular licence.
What LGPL can do is to reassure people by providing specific permission to use the code in some resulting work, no matter if it turns out that it actually is derived work (in which case the licence would grant you the rights you need) or not, in which case you don't need the permission, but it doesn't hurt to have it.
What LGPL can do is to reassure people by providing specific permission to use the code in some resulting work, no matter if it turns out that it actually is derived work (in which case the licence would grant you the rights you need) or not, in which case you don't need the permission, but it doesn't hurt to have it.
> So why does the LGPL/Linking Exception exist at all?
Because RMS wanted a long time ago to have a bright line in the sand that differentiated between a single derivative work and two works that simply communicate with each other. As the story goes he initially thought that linking was two works communicating with each other, but after consulting with a lawyer, the lawyer presented the following scenario. A person goes in front of a judge and say: this piece of software which can not start without my work, (if statically linked) can't be compiled, can't do anything useful by itself, is not an independent work. What will the judge say?
RMS then agreed with that scenario and decided that this served as a good line for enforcing the GPL, and for projects like the standard library and similar tools an exception was needed.
Because RMS wanted a long time ago to have a bright line in the sand that differentiated between a single derivative work and two works that simply communicate with each other. As the story goes he initially thought that linking was two works communicating with each other, but after consulting with a lawyer, the lawyer presented the following scenario. A person goes in front of a judge and say: this piece of software which can not start without my work, (if statically linked) can't be compiled, can't do anything useful by itself, is not an independent work. What will the judge say?
RMS then agreed with that scenario and decided that this served as a good line for enforcing the GPL, and for projects like the standard library and similar tools an exception was needed.
It's hard to draw a line. Considering that google3 is a massive monorepo, where linking a library into any binary (or library) is just a matter of a single line in the BUILD file, a lawyer could argue that such binary is a derivative work (or, it could be a lot of work to argue that it isn't).
Also considering the internal-only patches to OSS libraries, it'd be at least a pain, and quite possibly a wide avenue for trade secrets to leak (not to mention that most of those are so specific to Google's highly specialized production stack that are useless to anyone outside).
Also considering the internal-only patches to OSS libraries, it'd be at least a pain, and quite possibly a wide avenue for trade secrets to leak (not to mention that most of those are so specific to Google's highly specialized production stack that are useless to anyone outside).
For what it's worth, the license doesn't use the term "Derivative Work". Rather, it explicitly prohibits bundling AGPL software with other software that you aren't able to license under AGPL:
> You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:
> [...]
> c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
This is a requirement which is common to many GPL-like licenses, and one which some developers object to (the later requirements for use over the network notwithstanding).
That said, I don't believe the above terms would apply to the hypothetical Google Maps example above, as the license's requirements for making the software controllable over a network seem to be significantly less restrictive:
> 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.
In that situation, the question of what constitutes a "derivative work" might come into play.
Disclaimer: I'm not a lawyer and this isn't legal advise, just my own interpretation based on my reading of the license.
> You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:
> [...]
> c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
This is a requirement which is common to many GPL-like licenses, and one which some developers object to (the later requirements for use over the network notwithstanding).
That said, I don't believe the above terms would apply to the hypothetical Google Maps example above, as the license's requirements for making the software controllable over a network seem to be significantly less restrictive:
> 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.
In that situation, the question of what constitutes a "derivative work" might come into play.
Disclaimer: I'm not a lawyer and this isn't legal advise, just my own interpretation based on my reading of the license.
GPL would be perfect if it had "and, you are not allowed to exercise any other permissions granted to for this work except for ones granted by this licence, even if you have separately received it or guaranteed by any higher authority, nor is the copyright holder allowed to grant such additional permissions to other such users." instead of "but it does not invalidate such permission if you have separately received it.".
A derivative work of PostGIS would be a fork or patches to PostGIS (i.e, a set database extensions for geographic/spatial queries). A mapping application that used PostGIS is not a derivative work of PostGIS, in the same way that a C program linked against glibc is not a derivative work of glibc.
At least, that's my layperson's understanding of it.
At least, that's my layperson's understanding of it.
> in the same way that a C program linked against glibc is not a derivative work of glibc
I believe this is only as a result of the linking exception; I don't know if this has ever been tested, but my understanding was that linking (either statically or dynamically) against a library was generally considered enough to be a derivative work.
I believe this is only as a result of the linking exception; I don't know if this has ever been tested, but my understanding was that linking (either statically or dynamically) against a library was generally considered enough to be a derivative work.
My last heads up a fiew years ago was:
Legally people can't decide which form of linkage count as deriving and if the linkage form even matter, but static linking with LTO is most times seen as causing a derivative to be produced.
Legally people can't decide which form of linkage count as deriving and if the linkage form even matter, but static linking with LTO is most times seen as causing a derivative to be produced.
You're conflating "talking to a server over a socket" with "linking to a library".
The former, as a general rule, does not create a derivative work. It's specifically called out in the GPL FAQ as something that does not create a derivative work. (Another case that doesn't is fork/exec of a separate program.)
The latter, linking a library, is why the distinction between the GPL and LGPL exists. As a general rule, if you link to a GPLed library, you do need to provide your source under a GPL-compatible license. (glibc is LGPLed.)
But people wouldn't use PostGIS by linking to a library, they'd use it by talking to a server.
The former, as a general rule, does not create a derivative work. It's specifically called out in the GPL FAQ as something that does not create a derivative work. (Another case that doesn't is fork/exec of a separate program.)
The latter, linking a library, is why the distinction between the GPL and LGPL exists. As a general rule, if you link to a GPLed library, you do need to provide your source under a GPL-compatible license. (glibc is LGPLed.)
But people wouldn't use PostGIS by linking to a library, they'd use it by talking to a server.
> The former, as a general rule, does not create a derivative work. It's specifically called out in the GPL FAQ as something that does not create a derivative work.
Could you point me in the direction of a court ruling establishing this general rule? I couldn't find anything after a quick search.
You didn't mention this part of the GPL FAQ (directly after the part you talked about):
> But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
Determining what constitutes "intimiate enough" sounds pretty difficult and open to interpretation: what's a "complex internal data structure"? If PostGIS is serialising its (presumably complex) representations of data and sending them over a socket to your program (and vice versa), then does that count?
I think it's also worth noting that "derivative work" is an established legal term; if it comes to a lawsuit, it's probably more likely that the judge will fall back on established precedent on what constitutes a derivative work and enforce the literal terms of the license as opposed to looking at FAQs written by someone who is not a party to the contract.
Could you point me in the direction of a court ruling establishing this general rule? I couldn't find anything after a quick search.
You didn't mention this part of the GPL FAQ (directly after the part you talked about):
> But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
Determining what constitutes "intimiate enough" sounds pretty difficult and open to interpretation: what's a "complex internal data structure"? If PostGIS is serialising its (presumably complex) representations of data and sending them over a socket to your program (and vice versa), then does that count?
I think it's also worth noting that "derivative work" is an established legal term; if it comes to a lawsuit, it's probably more likely that the judge will fall back on established precedent on what constitutes a derivative work and enforce the literal terms of the license as opposed to looking at FAQs written by someone who is not a party to the contract.
> I think it's also worth noting that "derivative work" is an established legal term
The last case I could find that substantially attacks the question of what constitutes a "derivative work" in the case of software was in 1994 (!), and I can't find any case that tries to answer it in the case of software libraries (whose only purpose is to be used in larger works). There are tests for determining "derivative work", but a) minor circuit split there and b) they're difficult to apply. In the context of what we're talking about here, it is not an established legal term. In such cases, courts are going to lean more heavily on consensus interpretation.
There's a not-well-understood interplay here between the rights of authors to control derivative works; extending analogies copyrightable and non-copyrightable elements of literary works (well-established) to software (far less so); fair use; and general contract principles (specifically, selling a product confers necessary rights to use it). Our current legal understanding of the situation is almost entirely based on an informal consensus rather than any case law, and there is wide potential for a single oddball case completely wrecking everything... like Google v Oracle.
> Determining what constitutes "intimiate enough" sounds pretty difficult and open to interpretation
I read that generally as suggesting a mens rea approach: if you're building IPC in such a way as to specifically avoid meeting license obligations, you should be considered in violation. If instead you're using it in a more well-defined and sanctioned API boundary, you're probably okay.
The last case I could find that substantially attacks the question of what constitutes a "derivative work" in the case of software was in 1994 (!), and I can't find any case that tries to answer it in the case of software libraries (whose only purpose is to be used in larger works). There are tests for determining "derivative work", but a) minor circuit split there and b) they're difficult to apply. In the context of what we're talking about here, it is not an established legal term. In such cases, courts are going to lean more heavily on consensus interpretation.
There's a not-well-understood interplay here between the rights of authors to control derivative works; extending analogies copyrightable and non-copyrightable elements of literary works (well-established) to software (far less so); fair use; and general contract principles (specifically, selling a product confers necessary rights to use it). Our current legal understanding of the situation is almost entirely based on an informal consensus rather than any case law, and there is wide potential for a single oddball case completely wrecking everything... like Google v Oracle.
> Determining what constitutes "intimiate enough" sounds pretty difficult and open to interpretation
I read that generally as suggesting a mens rea approach: if you're building IPC in such a way as to specifically avoid meeting license obligations, you should be considered in violation. If instead you're using it in a more well-defined and sanctioned API boundary, you're probably okay.
Courts also generally consider things like long-standing precedent and decades of industry practice, as well as estoppel. It's a practice that everyone in an industry has done for decades, which matches the general consensus understanding throughout the FOSS developer community, in addition to being the interpretation of the authors of the license.
As I understand it, the rationale for that FAQ entry was that a blanket statement that communication over a socket never creates a derivative work would allow for things like "what if we built a stub that just moves a shared library out-of-process and copies memory back and forth over a socket", or other similar tricks.
Of course, if Oracle v. Google holds as case law (which we'll find out any month now), then the software world turns upside-down and inside-out, and much of the industry will have cases against each other over "API copyrights"; in that world, I have no idea where this would fall.
As I understand it, the rationale for that FAQ entry was that a blanket statement that communication over a socket never creates a derivative work would allow for things like "what if we built a stub that just moves a shared library out-of-process and copies memory back and forth over a socket", or other similar tricks.
Of course, if Oracle v. Google holds as case law (which we'll find out any month now), then the software world turns upside-down and inside-out, and much of the industry will have cases against each other over "API copyrights"; in that world, I have no idea where this would fall.
> Of course, if Oracle v. Google holds as case law (which we'll find out any month now)
The case won't be heard until Oct 7, and I would think a decision unlikely before January.
The case won't be heard until Oct 7, and I would think a decision unlikely before January.
"any month now" was very much meant as tongue-in-cheek, yes.
A program using PostGIS via TCP is no more a derivative work of PostGIS than a program storing data in its underlying database is derived from PostgreSQL.
I can't imagine the tortuous logic one would need to arrive at a different conclusion.
I can't imagine the tortuous logic one would need to arrive at a different conclusion.
> PostGIS via TCP
From a legal perspective I'm unaware of any ruling which establishes a difference between components communicating via TCP and components communicating through function calls at the ABI level (e.g. linked libraries); the latter is apparently enough to constitute a derivative work (see the LGPL/Linking Exception). There are obvious technical differences, but it's not clear that they should be treated any differently from a legal perspective.
From a legal perspective I'm unaware of any ruling which establishes a difference between components communicating via TCP and components communicating through function calls at the ABI level (e.g. linked libraries); the latter is apparently enough to constitute a derivative work (see the LGPL/Linking Exception). There are obvious technical differences, but it's not clear that they should be treated any differently from a legal perspective.
The LGPL linking exception mainly exist because static linking does modify the included binary in the way it links. At least with LTO enabled.
Note that there is a specific exception for that case: https://en.wikipedia.org/wiki/GPL_linking_exception
But saying Goole Maps derives from a database extension which stores cordinates is kinda unrealistic.
It's like saying a public transportation company derives from a specific model of trains they use.
Sure the storage system enables Google Maps to work but any storage system with similar functionality would.
It's like saying a public transportation company derives from a specific model of trains they use.
Sure the storage system enables Google Maps to work but any storage system with similar functionality would.
> Google states that if, for example, Google Maps used PostGIS as its data store, and PostGIS used the AGPL, Google would be required to release the Google Maps code. This is not true. They would be required to release their PostGIS patches in this situation. AGPL does not extend the GPL in that it makes the Internet count as a form of linking which creates a derivative work, as Google implies, but rather that it makes anyone who uses the the software via the Internet entitled to its source code.
I don't really follow this.
The fact that the linking exception and the LGPL exist at all is enough to infer that the FSF/license authors consider linking against or otherwise using a piece of software as a component of a larger system is enough to make that larger system a derivative work of the smaller component, thus "tainting" (I use this work non-disparagingly) it with the copyleft provisions of the license.
If Google Maps (that is the suite of software running on Google's servers) uses PostGIS as its data store then it seems that without a judicial ruling on whether there's a legal difference between interfacing with a software component by linking against it and interfacing with a software component by using some other software interface, it's not possible to be so certain that there isn't an issue here.
I don't really follow this.
The fact that the linking exception and the LGPL exist at all is enough to infer that the FSF/license authors consider linking against or otherwise using a piece of software as a component of a larger system is enough to make that larger system a derivative work of the smaller component, thus "tainting" (I use this work non-disparagingly) it with the copyleft provisions of the license.
If Google Maps (that is the suite of software running on Google's servers) uses PostGIS as its data store then it seems that without a judicial ruling on whether there's a legal difference between interfacing with a software component by linking against it and interfacing with a software component by using some other software interface, it's not possible to be so certain that there isn't an issue here.
"The Google page about the AGPL details inaccurate (but common1) misconceptions about the obligations of the AGPL that don’t follow from the text."
"The reason they spread these misconceptions is straightforward: they want to discourage people from using the AGPL, because they cannot productize such software effectively."
"Ask yourself: why is documentation of internal-facing decisions like what software licenses to use being published in a public place?"
To be perfectly clear, your claim is:
- Google internally knows they can comply with the AGPL without trouble
- Has consciously chosen to write policies prohibiting it based on misleading reasons
- Google adheres to that policy
- Most importantly: they are doing this because they believe that the influence this would have in discouraging use of the AGPL is valuable enough to substantially benefit Google
Have I understood correctly?
"The reason they spread these misconceptions is straightforward: they want to discourage people from using the AGPL, because they cannot productize such software effectively."
"Ask yourself: why is documentation of internal-facing decisions like what software licenses to use being published in a public place?"
To be perfectly clear, your claim is:
- Google internally knows they can comply with the AGPL without trouble
- Has consciously chosen to write policies prohibiting it based on misleading reasons
- Google adheres to that policy
- Most importantly: they are doing this because they believe that the influence this would have in discouraging use of the AGPL is valuable enough to substantially benefit Google
Have I understood correctly?
I don't know exactly what the author of this post means, but it doesn't have be a "conscious" decision on the part of Google to spread misleading information for their own benefit. It's very easy (I contend) for humans to believe things that are poorly supported by the evidence but which are beneficial for them.
So even if it's obvious that the AGPL doesn't have the effects that Google's policy suggests it does, it doesn't require active deception on the part of Google for them to believe it does. It just requires that they be deluding themselves for their own benefit - which I think is a very common practice for humans.
So even if it's obvious that the AGPL doesn't have the effects that Google's policy suggests it does, it doesn't require active deception on the part of Google for them to believe it does. It just requires that they be deluding themselves for their own benefit - which I think is a very common practice for humans.
This is a good point. My two thoughts are:
1. I don't find it easy to read the original post as implying Google is honestly convinced of its viewpoint.
2. It's a huge difference in meaning. Assume for the sake of argument that Drew is right about the interpretation of AGPL.
How should we interpret Google's actions? If they're paranoid, and afraid that the AGPL might require them to open-source their entire code base, that's unfortunate. You might still call them greedy assholes making open source worse, but it is a real fear that most commercial entities would be concerned about if it's realistic.
But if they knew better, and were lying, that's a completely different level of shitty behavior. If there's any ambiguity about that in Drew's post, it ought to be resolved.
1. I don't find it easy to read the original post as implying Google is honestly convinced of its viewpoint.
2. It's a huge difference in meaning. Assume for the sake of argument that Drew is right about the interpretation of AGPL.
How should we interpret Google's actions? If they're paranoid, and afraid that the AGPL might require them to open-source their entire code base, that's unfortunate. You might still call them greedy assholes making open source worse, but it is a real fear that most commercial entities would be concerned about if it's realistic.
But if they knew better, and were lying, that's a completely different level of shitty behavior. If there's any ambiguity about that in Drew's post, it ought to be resolved.
Not the article author, but:
> - Google internally knows they can comply with the AGPL without trouble
No, and I don't know where you got that. The article is talking about how start-ups can typically comply with AGPL without trouble. cic48 claims that all software running on Borg needs to be extensively modified and then can only be compiled using Google's proprietary tool-chain. If that's true, then they can't run AGPL on Borg without releasing the code for the tool-chain.
> - Has consciously chosen to write policies prohibiting it based on misleading reasons
No. Has written policies prohibiting it for rational self-interest (GPL, MIT, etc licenses allow them to sell access via the Internet without any cost to them, AGPL does not). After writing these policies, they've provided an alternative justification.
> - Google adheres to that policy
Outside of Google Legal, who would know whether or not they adhere to their own internal policies? If they used AGPL software internally, they would have no legal obligation to disclose that (because they'd be fully in compliance).
> - Most importantly: they are doing this because they believe that the influence this would have in discouraging use of the AGPL is valuable enough to substantially benefit Google
Why "substantially"? I would imagine the cost of saying "don't use AGPL" and then publishing an article about it was very low. A couple person-weeks of work at the most? It's hard to imagine what wouldn't be worth that investment.
But I think you didn't understand the article, because the main thrust of it was to encourage businesses to not be afraid of the AGPL, not to determine whether Google is acting maliciously or not.
> - Google internally knows they can comply with the AGPL without trouble
No, and I don't know where you got that. The article is talking about how start-ups can typically comply with AGPL without trouble. cic48 claims that all software running on Borg needs to be extensively modified and then can only be compiled using Google's proprietary tool-chain. If that's true, then they can't run AGPL on Borg without releasing the code for the tool-chain.
> - Has consciously chosen to write policies prohibiting it based on misleading reasons
No. Has written policies prohibiting it for rational self-interest (GPL, MIT, etc licenses allow them to sell access via the Internet without any cost to them, AGPL does not). After writing these policies, they've provided an alternative justification.
> - Google adheres to that policy
Outside of Google Legal, who would know whether or not they adhere to their own internal policies? If they used AGPL software internally, they would have no legal obligation to disclose that (because they'd be fully in compliance).
> - Most importantly: they are doing this because they believe that the influence this would have in discouraging use of the AGPL is valuable enough to substantially benefit Google
Why "substantially"? I would imagine the cost of saying "don't use AGPL" and then publishing an article about it was very low. A couple person-weeks of work at the most? It's hard to imagine what wouldn't be worth that investment.
But I think you didn't understand the article, because the main thrust of it was to encourage businesses to not be afraid of the AGPL, not to determine whether Google is acting maliciously or not.
Companies like MongoDB release a 'free' version using AGPL and a commercial version under no such provision, and use this in marketing material to convince commercial users to buy licensing so they can incorporate their DB into web based products.
If this distinction is without merit for those simply using MongoDB as an unmodified DB, this seems like it wouldn't actually work so well as a sales tool.
If this distinction is without merit for those simply using MongoDB as an unmodified DB, this seems like it wouldn't actually work so well as a sales tool.
Current versions of MongoDB are not available under an AGPL at all. It is effectively no longer open source.
Older, (unpatched) versions are still AGPL, but there were no commercial restrictions at that stage.
Older, (unpatched) versions are still AGPL, but there were no commercial restrictions at that stage.
The current free license has this interesting snippet:
13. Offering the Program as a Service. If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version.
“Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.
I know a bunch of startups using Mongo... i wonder if i could make them give me their systems source, given this clause.
13. Offering the Program as a Service. If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version.
“Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.
I know a bunch of startups using Mongo... i wonder if i could make them give me their systems source, given this clause.
> Google states that if, for example, Google Maps used PostGIS as its data store, and PostGIS used the AGPL, Google would be required to release the Google Maps code.
I can’t see that statement, or anything like it, in the linked article. Am I missing something?
I can’t see that statement, or anything like it, in the linked article. Am I missing something?
You're not. The author writes "Google states" and then follows it with his own example/interpretation of Google's policy. That's really not "Google states" at all, it's "My example of Google's policy is...".
The nearest statement in TFA is the sentence beginning "Because Google’s core products are services that users interact with over a remote network interface (Search, Gmail, Maps, YouTube)...".
The nearest statement in TFA is the sentence beginning "Because Google’s core products are services that users interact with over a remote network interface (Search, Gmail, Maps, YouTube)...".
After much consideration we finally released our core software (https://github.com/kiprotect/kiprotect - a privacy & security engineering toolkit) under the AGPL. In the past we've released other software under more permissive licenses like the BSD-3 or MIT licenses, but we've decidedly picked the AGPL for our toolkit, for the following reasons:
- We want to encourage people and organizations to use the software as a data processing & protection tool, just like they use other Linux/Unix tools.
- Using the software does not require integrating it into a software project as a library (though you can do that).
- We want to ensure that any extensions and modifications of the software (e.g. new anonymization or pseudonymization methods that people would implement) will make it back into the main software as open-source, so that everyone can benefit from them.
- We want to keep potential competitors from being able to just resell our software as a SaaS offering or integrate it into a commercial, closed-source product.
For me, the AGPL fits this bill quite nicely, and that it deters organizations to use the software for free in their closed-source projects is actually a bonus. We offer dual-licensing by the way, so organizations can just buy a commercial license if they want to integrate our tool into their closed-source software. That at least should allow us to refuse such a license to a potential competitor and the funding we (hopefully) will generate via the commercial licenses will help us fund the development for everyone. Win win.
- We want to encourage people and organizations to use the software as a data processing & protection tool, just like they use other Linux/Unix tools.
- Using the software does not require integrating it into a software project as a library (though you can do that).
- We want to ensure that any extensions and modifications of the software (e.g. new anonymization or pseudonymization methods that people would implement) will make it back into the main software as open-source, so that everyone can benefit from them.
- We want to keep potential competitors from being able to just resell our software as a SaaS offering or integrate it into a commercial, closed-source product.
For me, the AGPL fits this bill quite nicely, and that it deters organizations to use the software for free in their closed-source projects is actually a bonus. We offer dual-licensing by the way, so organizations can just buy a commercial license if they want to integrate our tool into their closed-source software. That at least should allow us to refuse such a license to a potential competitor and the funding we (hopefully) will generate via the commercial licenses will help us fund the development for everyone. Win win.
> - We want to ensure that any extensions and modifications of the software (will make it back into the main software as open-source, so that everyone can benefit from them.
isn't that a contradiction with
> We offer dual-licensing by the way
since dual licensing requires every contributor to agree to a CLA and not merely contributing the code under the terms of the AGPL?
isn't that a contradiction with
> We offer dual-licensing by the way
since dual licensing requires every contributor to agree to a CLA and not merely contributing the code under the terms of the AGPL?
Maybe, but I don't think so. In general we plan to have every contributor sign a CLA as we want to make sure we can keep control over the development of the project, in case we will have to change its license later.
Some companies don't want to contribute back to open-source software and that's fine, if they pay a license fee instead we can use that money to pay ourselves and build new features for the open-source version, so everyone benefits. I'd even say that maybe open-source software is licensed too liberally these days. Right now for-profit companies make boatloads of money on the back of open-source software, without giving back much. I think if more projects were to use contagious licenses like the (A)GPL it might actually benefit the whole open-source ecosystem. Imagine what we could build if just 1-5 % of the largest companies would pay a small license fees for the open-source libraries they use.
Some companies don't want to contribute back to open-source software and that's fine, if they pay a license fee instead we can use that money to pay ourselves and build new features for the open-source version, so everyone benefits. I'd even say that maybe open-source software is licensed too liberally these days. Right now for-profit companies make boatloads of money on the back of open-source software, without giving back much. I think if more projects were to use contagious licenses like the (A)GPL it might actually benefit the whole open-source ecosystem. Imagine what we could build if just 1-5 % of the largest companies would pay a small license fees for the open-source libraries they use.
I think that the AGPL is a fine language in cases where the code being released is a complete system, that you want many people/organizations to use and improve it, but you don't want anyone cloning it as their own standalone product.
I understand why Google would not want to use it, and also other large companies.
For individuals and smaller companies I think the AGPL can make good sense, especially for complete web applications.
I understand why Google would not want to use it, and also other large companies.
For individuals and smaller companies I think the AGPL can make good sense, especially for complete web applications.
> I think that the AGPL is a fine language in cases where the code being released is a complete system, that you want many people/organizations to use and improve it, but you don't want anyone cloning it as their own standalone product.
Yup. In the same way that you could have a license that requires people to publicly criticize <Politician> to use your software.
You'll get some. But most will just not agree to your terms.
Yup. In the same way that you could have a license that requires people to publicly criticize <Politician> to use your software.
You'll get some. But most will just not agree to your terms.
The author makes the following claims:
> In truth, the terms of the AGPL are pretty easy to comply with. The basic obligations of the AGPL which set it apart from other licenses are as follows:
> - Any derivative works of AGPL-licensed software must also use the AGPL.
> - Any users of such software are entitled to the source code under the terms of the AGPL, including users accessing it over the network such as with their web browser or via an API or internet protocol.
That first claim is debatable at best. Nowhere in the entire document will you find the term "derivative work." Instead, the AGPL forces on the reader a bunch of other terms that may or may not add up to "derivative works."
Other licenses have no problem coming out and using the term. Doing so connects those licenses to a well-understood body of intellectual property law. Not so with AGPL. See the discussion in the book by Rosen (an actual lawyer) for more [1].
So right out of the gate, the AGPL is not easy to comply with.
[1] https://www.rosenlaw.com/oslbook.htm
> In truth, the terms of the AGPL are pretty easy to comply with. The basic obligations of the AGPL which set it apart from other licenses are as follows:
> - Any derivative works of AGPL-licensed software must also use the AGPL.
> - Any users of such software are entitled to the source code under the terms of the AGPL, including users accessing it over the network such as with their web browser or via an API or internet protocol.
That first claim is debatable at best. Nowhere in the entire document will you find the term "derivative work." Instead, the AGPL forces on the reader a bunch of other terms that may or may not add up to "derivative works."
Other licenses have no problem coming out and using the term. Doing so connects those licenses to a well-understood body of intellectual property law. Not so with AGPL. See the discussion in the book by Rosen (an actual lawyer) for more [1].
So right out of the gate, the AGPL is not easy to comply with.
[1] https://www.rosenlaw.com/oslbook.htm
Yeah. People often resort to some fear-mongering when it comes to AGPL. When we released our software under AGPL, one developer of a somewhat competing app didn't find anything better but to claim that 'AGPL license makes it a useless toy'. Well, we don't agree.
Sorry, this isn't really the case. The AGPL can be used in a predatory fashion. Projects that are AGPL'd are often dual licensed, with a commercial license for commercial applications and AGPL for experiments. I once negotiated for a couple of weeks to pay for an open source package that was dual licensed under the AGPL. I wanted to make small modifications to the source. The commercial terms were available on request, and I requested and got sort of tangential answers until finally the company's lawyer told me that I'd be liable for 15% of all revenue connected to the library in any way. If I had used the library first and asked for the terms later, I could have been in a very serious situation.
It reminds me of the story I heard around a campfire once, about a programmer who decided to fix a bug in a single AGPL module, and they were forced to make their entire code open source. Even today, long after the bankruptcy, they say you can still hear the screams in the shuttered, decaying boardroom. And the bug somehow got unfixed. It’s out there now, waiting ... for its next victim.
Is this a story lawyers tell around the campfire to scare new law school grads?
Not quite. That version ends with the line: “and their lawyers ... never got paid.”
Yeah, making some of my recent projects AGPL truly scares away contributions from Googlers (as their internal, low friction patching process doesn't apply to AGPL software, and they have to go through explicit approval). Fun.
> Ask yourself: why is documentation of internal-facing decisions like what software licenses to use being published in a public place? The answer is straightforward: to influence the public. This is propaganda.
Or maybe it's just something that many people have asked about? And why wouldn't they publish it?
Or maybe it's just something that many people have asked about? And why wouldn't they publish it?
The blogger is reading way too much into the existence of this page. The site is clearly just a wholesale export of internal Google documentation. It is not generally intended for the public audience and I don't think you can read intent into specific pages being here. Look at this page for example. Nothing on it is relevant to you outside Google. You can't reach "go/" pages, you can't check out //third_party from their repo, etc.
https://opensource.google/docs/thirdparty/r/
https://opensource.google/docs/thirdparty/r/
Agree that some of the examples cited are misrepresentations of what the AGPL requires, but I think, for many companies, just the requirement to publish changes (if any) would be a showstopper. Which is unfortunate, but I think is the reality of the situation.
I think the author is misreading Google's policy (https://opensource.google/docs/using/agpl-policy/). They're not saying that communications over the internet constitute a linkage, they're saying that:
* Because of free and open development practices within Google, it's impractical for developers to be constantly aware of what libraries get linked into their binaries. (This is exacerbated because of their monorepo, but even in a multi-repo setup it's very easy to end up with random libraries in your dependency chain.)
* If an AGPL library did end up linked, because all Google's services are accessible through a remote network, the virality provisions kick in and they might have a legal duty to distribute the entire binary.
* Therefore, they have to ban AGPL libraries so that no core service developer accidentally depends on one.
* Because of free and open development practices within Google, it's impractical for developers to be constantly aware of what libraries get linked into their binaries. (This is exacerbated because of their monorepo, but even in a multi-repo setup it's very easy to end up with random libraries in your dependency chain.)
* If an AGPL library did end up linked, because all Google's services are accessible through a remote network, the virality provisions kick in and they might have a legal duty to distribute the entire binary.
* Therefore, they have to ban AGPL libraries so that no core service developer accidentally depends on one.
Back when I was a postdoc I talked to my advisor about GPL and BSD. The advisor (who was a supremely intelligent person) said the simplest, clearest possible thing I could imagine: "I wouldn't license software under GPL because I read the GPL license and couldn't understand what it was saying. I read the BSD license and it was totally clear. I want to license something using a license that makes technical sense to me."
The fact that we see pages and pages of hackers arguing over what the implications of a license family (GPL and AGPL) are based on the legal text suggests that many people don't understand the GPL.
The fact that we see pages and pages of hackers arguing over what the implications of a license family (GPL and AGPL) are based on the legal text suggests that many people don't understand the GPL.
Yep, this is precisely why I refuse to use GPL or AGPL, but am completely comfortable with BSD.
If I'm going to be bound by T's and C's, I need to be able to understand the implications - there is just too much ambiguity and room for bad actors (e.g. Oracle) with GPL and AGPL.
If I'm going to be bound by T's and C's, I need to be able to understand the implications - there is just too much ambiguity and room for bad actors (e.g. Oracle) with GPL and AGPL.
> Any users of such software are entitled to the source code under the terms of the AGPL, including users accessing it over the network such as with their web browser or via an API or internet protocol
That doesn't seem to be quite right. It makes it sound like the source code entitlement applies to all users. The "including users accessing it over the network" is redundant then because they are a subset of all users.
What's actually in the text of the license is:
> 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.
The user source entitlement only applies to users remotely interacting with the software through a computer network.
That doesn't seem to be quite right. It makes it sound like the source code entitlement applies to all users. The "including users accessing it over the network" is redundant then because they are a subset of all users.
What's actually in the text of the license is:
> 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.
The user source entitlement only applies to users remotely interacting with the software through a computer network.
> That doesn't seem to be quite right. It makes it sound like the source code entitlement applies to all users. The "including users accessing it over the network" is redundant then because they are a subset of all users.
The AGPL is written in the context of the gpl, where user is someone who runs the software. The AGPL extends this to someone who uses the software over the network.
You're right that that kind of means "all users" - but let's take the example of a GPS appliance - if you buy the device, and run software on in, you're a "gpl user". If the appliance is a server that runs a web application - the person operating the appliance is a "gpl user", the one interacting with it via the web is not - but they are an "AGPL user". If you relay directions to someone (say as a passenger/navigator in a car) - you could argue the driver also "uses" the software - but only the passenger would be considered an "AGPL user".
All this must be seen in light of the four freedoms, and who it applies to (who is a user).
The AGPL extends freedom zero (the freedom to run the software) - to those accessing it over the network - in short, it grants the right to self-host and run the code.
The AGPL is written in the context of the gpl, where user is someone who runs the software. The AGPL extends this to someone who uses the software over the network.
You're right that that kind of means "all users" - but let's take the example of a GPS appliance - if you buy the device, and run software on in, you're a "gpl user". If the appliance is a server that runs a web application - the person operating the appliance is a "gpl user", the one interacting with it via the web is not - but they are an "AGPL user". If you relay directions to someone (say as a passenger/navigator in a car) - you could argue the driver also "uses" the software - but only the passenger would be considered an "AGPL user".
All this must be seen in light of the four freedoms, and who it applies to (who is a user).
The AGPL extends freedom zero (the freedom to run the software) - to those accessing it over the network - in short, it grants the right to self-host and run the code.
Surely the user source entitlement also applies if I interact with the software without a network in between? Otherwise, that would make AGPL a strangely more-but-also-less permissive license than GPL…
It is almost literally GPLv3 with the interactive remote network source obligation added in.
If you diff GPLv3 and AGPLv3, the differences are (ignoring differences that are just in the name of the license):
1. The preamble has a few differences where they describe why they wrote each license and what ills they are trying to address.
2. In the actual terms and conditions, the first 13 sections and last 4 sections are identical (except for the name of the license). Only section 13 is different.
In AGPLv3, 13 is the section about remote network user source access, and about how AGPLv3 and GPLv3 interact.
In GPLv3, 13 is about how GPLv3 and AGPLv3 interact.
Finally, after the T&Cs is a section on how to apply the license to your programs. That has differences, such as including in the AGPLv3 version a reminder that you have to handle your section 13 obligations for remote network users.
If you diff GPLv3 and AGPLv3, the differences are (ignoring differences that are just in the name of the license):
1. The preamble has a few differences where they describe why they wrote each license and what ills they are trying to address.
2. In the actual terms and conditions, the first 13 sections and last 4 sections are identical (except for the name of the license). Only section 13 is different.
In AGPLv3, 13 is the section about remote network user source access, and about how AGPLv3 and GPLv3 interact.
In GPLv3, 13 is about how GPLv3 and AGPLv3 interact.
Finally, after the T&Cs is a section on how to apply the license to your programs. That has differences, such as including in the AGPLv3 version a reminder that you have to handle your section 13 obligations for remote network users.
Then I guess I am confused by this statement:
> The user source entitlement only applies to users remotely interacting with the software through a computer network.
It applies to all users under the GPLv3 as well, is certainly more than just those interacting with it over a computer network, right?
> The user source entitlement only applies to users remotely interacting with the software through a computer network.
It applies to all users under the GPLv3 as well, is certainly more than just those interacting with it over a computer network, right?
GPLv3 does not have a source entitlement for users of the software. Its source entitlement is for people the work has been conveyed to. It defines "convey" thusly:
> To "convey" a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying
and propagate is:
> To "propagate" a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well
Using software does not necessarily involve conveying the software to the user.
A good example is given in the GPL FAQ [1]:
> Does GPLv3 require that voters be able to modify the software running in a voting machine?
> No. Companies distributing devices that include software under GPLv3 are at most required to provide the source and Installation Information for the software to people who possess a copy of the object code. The voter who uses a voting machine (like any other kiosk) doesn't get possession of it, not even temporarily, so the voter also does not get possession of the binary software in it.
This is what makes AGPL so different from previous licenses. As far as I know it is the only free software license that has a source entitlement that triggers on mere use. The others trigger on distribution or possession of copies.
[1] https://www.gnu.org/licenses/gpl-faq.en.html#v3VotingMachine
> To "convey" a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying
and propagate is:
> To "propagate" a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well
Using software does not necessarily involve conveying the software to the user.
A good example is given in the GPL FAQ [1]:
> Does GPLv3 require that voters be able to modify the software running in a voting machine?
> No. Companies distributing devices that include software under GPLv3 are at most required to provide the source and Installation Information for the software to people who possess a copy of the object code. The voter who uses a voting machine (like any other kiosk) doesn't get possession of it, not even temporarily, so the voter also does not get possession of the binary software in it.
This is what makes AGPL so different from previous licenses. As far as I know it is the only free software license that has a source entitlement that triggers on mere use. The others trigger on distribution or possession of copies.
[1] https://www.gnu.org/licenses/gpl-faq.en.html#v3VotingMachine
For fans of AGPL I suggest checking out EUPL. Half the length of AGPL. Changing/removing portions of the license is allowed.
More info: you may have seen this on Hacker News recently: https://www.arp242.net/license.html.
More info: you may have seen this on Hacker News recently: https://www.arp242.net/license.html.
> Changing/removing portions of the license is allowed.
Note that licenses that can have random bits changed or removed have the issue that you need to read them in their entirety each time you encounter them.
Note that licenses that can have random bits changed or removed have the issue that you need to read them in their entirety each time you encounter them.
My problem with GPL is that the term "derived" is defined to vague or not in the way I like it, which in turn opens up all kind of legal uncertainty.
(I don't know if this also applies for AGPL.)
I would love to hear that AGPL legal reliably works like he describes (or there is a different license which does).
(I don't know if this also applies for AGPL.)
I would love to hear that AGPL legal reliably works like he describes (or there is a different license which does).
None of the V3 licenses say "derived".
Derivation is a specific concept in US copyright law, so in fact it doesn't need to be derived in the license. But it also doesn't apply elsewhere.
So the V3 licenses use the term "modify", which they define to specifically include the more internationally-understood concept of adaptation.
Where things get more complex is in each license's concept of linking. But that's only a problem if you want to be a free rider. Like Apple or Google.
Derivation is a specific concept in US copyright law, so in fact it doesn't need to be derived in the license. But it also doesn't apply elsewhere.
So the V3 licenses use the term "modify", which they define to specifically include the more internationally-understood concept of adaptation.
Where things get more complex is in each license's concept of linking. But that's only a problem if you want to be a free rider. Like Apple or Google.
GPLv2 does use that wording.
It's still widely used.
AGPL is also originally based on GPLv2.
Through there is the GNU AGPL license which is often abbreviated as AGPLv3 which is based on GPLv3.
GPLv3 makes many things more clear but not necessary better. It also includes some cases I would explicitly not include as "derived work" (or more explicit wok which will need to be GPLv3 compatible as yes the terminology changed).
> But that's only a problem if you want to be a free rider. Like Apple or Google.
No, it's a problem for many other use-cases which have nothing to do with free riding but protection of trade secrets and similar.
If you want to make sure your software is FOSS sure go ahead, but why force all the software directly around it to be FOSS, too?
I mean it makes sense for complete services and similar (like a database or the Linux kernel). But it IMHO is not very good for any kind of library.
In my opinion forceful open source is good for modifications and extensions of a given service (in the very general CS definition of a service which includes most kinds of libraries). But should be avoid to extend to any user of a service independent of the way the service is interacted with (static linkage, dynamic linkage, etc.) with an additional exception wrt. LTO.
Sure you can't sell such software well. But most FOSS software isn't meant to be sold. What is sold are products like support, service and maintenance around it and similar. There are very view companies which had success with a selling software based on a GPL vs. proprietary dual license schema as far as I know. I think, and might as well be wrong about it, that it's better to then have a license like mentioned above but restrict commercial use in some way with the option to pay to lift the restriction.
It's still widely used.
AGPL is also originally based on GPLv2.
Through there is the GNU AGPL license which is often abbreviated as AGPLv3 which is based on GPLv3.
GPLv3 makes many things more clear but not necessary better. It also includes some cases I would explicitly not include as "derived work" (or more explicit wok which will need to be GPLv3 compatible as yes the terminology changed).
> But that's only a problem if you want to be a free rider. Like Apple or Google.
No, it's a problem for many other use-cases which have nothing to do with free riding but protection of trade secrets and similar.
If you want to make sure your software is FOSS sure go ahead, but why force all the software directly around it to be FOSS, too?
I mean it makes sense for complete services and similar (like a database or the Linux kernel). But it IMHO is not very good for any kind of library.
In my opinion forceful open source is good for modifications and extensions of a given service (in the very general CS definition of a service which includes most kinds of libraries). But should be avoid to extend to any user of a service independent of the way the service is interacted with (static linkage, dynamic linkage, etc.) with an additional exception wrt. LTO.
Sure you can't sell such software well. But most FOSS software isn't meant to be sold. What is sold are products like support, service and maintenance around it and similar. There are very view companies which had success with a selling software based on a GPL vs. proprietary dual license schema as far as I know. I think, and might as well be wrong about it, that it's better to then have a license like mentioned above but restrict commercial use in some way with the option to pay to lift the restriction.
[deleted]
Rather heavily editorialized title? Original says: "The falsehoods of anti-AGPL propaganda"
I use software with GPL and AGPL, and may even contribute, but when I write my own software, I make it to be the public domain instead, because I don't like copyright, and because public domain will make it we don't have to worry about the license conditions, in case it may be confusing.
I have a program which links with AGPL software. My program is itself public domain, and is released only as source code, but I would think if anyone distributes it, or makes it available to access over the network, that they would have to do so in a way which is not contrary to AGPL. If you know how it is work, then hopefully you can comment too, to say what parts I did wrong, I suppose.
I have a program which links with AGPL software. My program is itself public domain, and is released only as source code, but I would think if anyone distributes it, or makes it available to access over the network, that they would have to do so in a way which is not contrary to AGPL. If you know how it is work, then hopefully you can comment too, to say what parts I did wrong, I suppose.
[deleted]
I can't comment on the "true" motivation for releasing these documents, but I noticed the same site includes
https://opensource.google/docs/thirdparty/oneversion/
which is a very Google-internal-only kind of problem, complete with broken links to Google-internal-only tools and processes (rosie and lsc). That page at least is definitely just a dump of the internal documentation.
> Network use is distribution
I use the Open Software License for this same reason, I dont think companies should be able to get the benefit of open source libraries with the cost of publishing any modifications, regardless if its a webapp or desktop app. I am curious the difference though:
https://choosealicense.com/appendix
seems to only be different with regard to trademarks?
I use the Open Software License for this same reason, I dont think companies should be able to get the benefit of open source libraries with the cost of publishing any modifications, regardless if its a webapp or desktop app. I am curious the difference though:
https://choosealicense.com/appendix
seems to only be different with regard to trademarks?
Even as an individual user, I try to avoid using software licensed under GPL or its derivatives.
I'm against copyright laws, and any second that I have to spend thinking about how to comply with them is a second wasted to me.
BSD and MIT make me waste the minimum practically possible amount of time.
I like knowing that I have the freedom to not care about infringing on anyone's copyright as long as I only develop software using permissive licenses.
I'm against copyright laws, and any second that I have to spend thinking about how to comply with them is a second wasted to me.
BSD and MIT make me waste the minimum practically possible amount of time.
I like knowing that I have the freedom to not care about infringing on anyone's copyright as long as I only develop software using permissive licenses.
BSD and MIT maximize freedom for developers, which seems to be your primary concern so that's totally understandable. You're right that they're much easier for developers to comply with than the GPL family.
GPL and AGPL maximize freedom for both direct and indirect downstream users, such that users of any software derived from that GPL/AGPL software are guaranteed strong rights to be able to understand / modify / pay others to modify their software. BSD/MIT allow proprietary derivatives which withhold this freedom from users.
Both are pretty valid concerns, even if they're opposed to each other. But for cases where you're a pure user and not a developer, there's no compliance hassle involved with either the BSD/MIT family of licenses or the GPL family.
GPL and AGPL maximize freedom for both direct and indirect downstream users, such that users of any software derived from that GPL/AGPL software are guaranteed strong rights to be able to understand / modify / pay others to modify their software. BSD/MIT allow proprietary derivatives which withhold this freedom from users.
Both are pretty valid concerns, even if they're opposed to each other. But for cases where you're a pure user and not a developer, there's no compliance hassle involved with either the BSD/MIT family of licenses or the GPL family.
I love the AGPL, and I love that it is more and more used by larger and larger projects. For example, the widely used Overleaf. This is a good world.
The new title is misleading. It is a charitable interpretation of a half-screed/half conspiracy theory.
> The reason they spread these misconceptions is straightforward: they want to discourage people from using the AGPL, because they cannot productize such software effectively.
Statements like this can be encompassed by its original title, as the author intended.
> The reason they spread these misconceptions is straightforward: they want to discourage people from using the AGPL, because they cannot productize such software effectively.
Statements like this can be encompassed by its original title, as the author intended.
> Any derivative works of AGPL-licensed software must also use the AGPL.
That's why people don't use AGPL, and why I personally don't release any code under (A)GPL. If you want to make free software, make free software and release your code under Apache or MIT. And if you really care about attribution, use CC BY 3.0. Legally, you don't want to deal with the burden of constantly checking if you're complying with some license that a dependency of a dependency of a dependency is using.
> By discouraging the use of AGPL in the broader community, Google hopes to create a larger set of free- and open-source software that they can take for their own needs without any obligations to upstream...
This is true, and I don't see much wrong with it. I don't like the idea of other code mandating how I should release my code. What if I just don't feel like up-streaming? Free is meant to be free, and (A)GPL does incur a cost -- at the bare minimum an ideological one.
A lot of reactionary down-voting going on; I'm quite open to debate. Why are you so passionate about AGPL?
That's why people don't use AGPL, and why I personally don't release any code under (A)GPL. If you want to make free software, make free software and release your code under Apache or MIT. And if you really care about attribution, use CC BY 3.0. Legally, you don't want to deal with the burden of constantly checking if you're complying with some license that a dependency of a dependency of a dependency is using.
> By discouraging the use of AGPL in the broader community, Google hopes to create a larger set of free- and open-source software that they can take for their own needs without any obligations to upstream...
This is true, and I don't see much wrong with it. I don't like the idea of other code mandating how I should release my code. What if I just don't feel like up-streaming? Free is meant to be free, and (A)GPL does incur a cost -- at the bare minimum an ideological one.
A lot of reactionary down-voting going on; I'm quite open to debate. Why are you so passionate about AGPL?
> Legally, you don't want to deal with the burden of constantly checking if you're complying with some license that a dependency of a dependency of a dependency is using.
If you're not modifying that dependency, you don't need to do anything since your dependencies are handling it. Especially with GPL, since it's likely that your dependency's dependency will make it GPL as well–but you should be doing this anyways, of course.
> I don't like the idea of other code mandating how I should release my code. What if I just don't feel like up-streaming?
Then you're just not in agreement with how GPL works. It's meant to be an explicit guard against people taking projects, forking them, and never contributing back.
If you're not modifying that dependency, you don't need to do anything since your dependencies are handling it. Especially with GPL, since it's likely that your dependency's dependency will make it GPL as well–but you should be doing this anyways, of course.
> I don't like the idea of other code mandating how I should release my code. What if I just don't feel like up-streaming?
Then you're just not in agreement with how GPL works. It's meant to be an explicit guard against people taking projects, forking them, and never contributing back.
> Then you're just not in agreement with how GPL works. It's meant to be an explicit guard against people taking projects, forking them, and never contributing back.
I'm definitely not in agreement with it, I just don't like that it tries to present itself as some kind of purist "free software" license, but in reality it mandates how code can be released. How is that free? To take a page out of the blog post, it sure sounds like propaganda to me.
I'm definitely not in agreement with it, I just don't like that it tries to present itself as some kind of purist "free software" license, but in reality it mandates how code can be released. How is that free? To take a page out of the blog post, it sure sounds like propaganda to me.
GPL is about freedom for software users, not for software authors. It places restrictions on what software authors can do in order to give users more privileges. (Which I personally believe is the right trade-off, as users are usually in lesser-privileged positions to begin with.)
>I don't like the idea of other code mandating how I should release my code. What if I just don't feel like up-streaming?
Then don't use the software that's AGPL. Problem solved.
If somebody licences their code with AGPL then it probably means that they either don't want that or they want a cut of any commercial use of the code (dual license) - which is fair, no?
>Free is meant to be free
There are two types of free (beer and speech) and it kind of feels like you're deliberately confusing them.
Then don't use the software that's AGPL. Problem solved.
If somebody licences their code with AGPL then it probably means that they either don't want that or they want a cut of any commercial use of the code (dual license) - which is fair, no?
>Free is meant to be free
There are two types of free (beer and speech) and it kind of feels like you're deliberately confusing them.
It sounds like you are arguing against a different point than Drew is making here. He is saying that the AGPL is no more viral than the GPL, and that its added restrictions aren't particularly onerous. You seem to be arguing against the whole GPL family of licenses, which is a perfectly valid opinion to have, but doesn't really speak to what Drew is talking about.
> This is true, and I don't see much wrong with it. I don't like the idea of other code mandating how I should release my code.
I would suggest taking another look at Drew's argument for the AGPL:
> The reason they spread these misconceptions is straightforward: they want to discourage people from using the AGPL, because they cannot productize such software effectively. 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. Google is an Internet company, and they offer Internet services. The original GPL doesn’t threaten their scheme because their software is accessed over the Internet, not distributed to end-users directly.
Whether or not this is true of Google in particular, it is true that if you are a company writing open-source software that is accessed over the internet, the AGPL makes it more difficult for competitors to benefit from your work while keeping their improvements secret. If it was GPL-licensed, competitors could use it however they want without releasing their modified source so long as the software isn't "distributed".
> This is true, and I don't see much wrong with it. I don't like the idea of other code mandating how I should release my code.
I would suggest taking another look at Drew's argument for the AGPL:
> The reason they spread these misconceptions is straightforward: they want to discourage people from using the AGPL, because they cannot productize such software effectively. 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. Google is an Internet company, and they offer Internet services. The original GPL doesn’t threaten their scheme because their software is accessed over the Internet, not distributed to end-users directly.
Whether or not this is true of Google in particular, it is true that if you are a company writing open-source software that is accessed over the internet, the AGPL makes it more difficult for competitors to benefit from your work while keeping their improvements secret. If it was GPL-licensed, competitors could use it however they want without releasing their modified source so long as the software isn't "distributed".
> It sounds like you are arguing against a different point than Drew is making here. He is saying that the AGPL is no more viral than the GPL, and that its added restrictions aren't particularly onerous. You seem to be arguing against the whole GPL family of licenses, which is a perfectly valid opinion to have, but doesn't really speak to what Drew is talking about.
Maybe I misunderstood his post, but he specifically compares AGPL to MIT in the last paragraph, which actually motivated me to write my reply, as the difference between the two licences is night and day.
Maybe I misunderstood his post, but he specifically compares AGPL to MIT in the last paragraph, which actually motivated me to write my reply, as the difference between the two licences is night and day.
Perhaps you're getting downvoted because it's 2020, and your analysis makes zero mention of what some would call the most important group of people involved in any software project: the end users. There's little left to debate - this particular dead horse is well kicked - but your comment omits any sign you're willing to acknowledge the "freedoms for whom?" aspect of the issue.
> Perhaps you're getting downvoted because it's 2020, and your analysis makes zero mention of what some would call the most important group of people involved in any software project: the end users.
This is a fair point. I guess I think the protected class in the context of open source should be the developers -- because they're the ones putting in the actual work. So I'd always favor their freedom over the end users'. Even if the "developer" might be a Fortune 500 company.
Plenty of MIT-sourced projects blew up because Google or Facebook started using them. And, I'm no fan of huge Fortune 500 companies, but let's be fair: they often contribute back.
This is a fair point. I guess I think the protected class in the context of open source should be the developers -- because they're the ones putting in the actual work. So I'd always favor their freedom over the end users'. Even if the "developer" might be a Fortune 500 company.
Plenty of MIT-sourced projects blew up because Google or Facebook started using them. And, I'm no fan of huge Fortune 500 companies, but let's be fair: they often contribute back.
>This is true, and I don't see much wrong with it. I don't like the idea of other code mandating how I should release my code. What if I just don't feel like up-streaming? Free is meant to be free, and (A)GPL does incur a cost -- at the bare minimum an ideological one.
You don't need to go upstream - you just need to provide source to users. I explained this in the article, and it's not especially onerous. You've also fallen for a common misconception: the "free" in free software is not about cost, it's about "freedom". The GPL family of licenses are designed to ensure the freedom of the user, not the developer, to view and modify and improve and redistribute the source code for programs that they use.
You don't need to go upstream - you just need to provide source to users. I explained this in the article, and it's not especially onerous. You've also fallen for a common misconception: the "free" in free software is not about cost, it's about "freedom". The GPL family of licenses are designed to ensure the freedom of the user, not the developer, to view and modify and improve and redistribute the source code for programs that they use.
You write this as if the whole debate wasn't about what the definition of the "source" that needed to be provided was. The concern is that the AGPL is written in a way that admits to an expansive definition of that source.
I think we should have a standardized MIT license that require paying above a certain market cap or something. An anti-sassfiy license too. That's what AGPL is used for currently but it focuses on contribution and openness rather than monetization.
Many of new database projects and infrastructure tools come up with their own licenses to protect themselves from such problems. A standardized approach would work better for everyone.
Many of new database projects and infrastructure tools come up with their own licenses to protect themselves from such problems. A standardized approach would work better for everyone.
Beware: the approach you describe qualifies as neither "open source" nor "free software". It might be worthwhile to develop such licenses and experiment with this distribution model - but please call it something else, like "source available" or "fair source".
I am aware. The problem is many companies won't contribute to open source with code but might pay up if they have no choice. Why can't monetary compensation be counted as contribution?
The core point of OSS is freedom to the users, not big companies. MIT provide more freedom to users than AGPL and so does money by empowering contributors to keep working on it. I think there is a case that this should be open source.
The core point of OSS is freedom to the users, not big companies. MIT provide more freedom to users than AGPL and so does money by empowering contributors to keep working on it. I think there is a case that this should be open source.
Monetary contribution certainly can be considered contribution. But FOSS is not about "contribution" at all.
Big companies are users, too.
Big companies are users, too.
> Big companies are users, too.
I think we disagree here. Big companies aren't users in the same way I am. People have different power dynamics in the real world. I won't treat rich people the same for stealing food the way I treat poor people for stealing food. One can afford it but still chooses to steal.
I think we disagree here. Big companies aren't users in the same way I am. People have different power dynamics in the real world. I won't treat rich people the same for stealing food the way I treat poor people for stealing food. One can afford it but still chooses to steal.
That's fine, everyone knows that many people don't like the (A)GPL. Not sure we need to have that discussion at every mention of it though? (I assume the latter is the source of at least some of the downvotes)
Great explanation, and I hope people get the message. I've tried to explain this to people and companies before, but Drew does it better.
Thanks!
Thanks!
[deleted]
I see a lot of reflections from a business point of view.
I guess if your sole purpose is to conjure money out of thinware then yes, AGPL is going to be poison to your wallet. Capitalism and AGPL simply does not mix well.
But we tend to forget, that the end of the day we're all users and have to consume what we've cooked.
As a user I tend to lean towards AGPL alternatives, It's comfty and let's me relax my legal muscle after the hard workout of summarizing this thread.
I guess if your sole purpose is to conjure money out of thinware then yes, AGPL is going to be poison to your wallet. Capitalism and AGPL simply does not mix well.
But we tend to forget, that the end of the day we're all users and have to consume what we've cooked.
As a user I tend to lean towards AGPL alternatives, It's comfty and let's me relax my legal muscle after the hard workout of summarizing this thread.
[deleted]
Why should I listen to the cigarette salesman talking about the harmlessness of smoking?
rydre(1)
I release my software under AGPL whenever possible—even if it couldn't conceivably be used to provide services over a network—because it means that Googlers aren't allowed to use it on their work machines. If Google ever changes their policy on AGPL, then I'll either switch to the JSON license or a custom one that will arbitrarily exclude companies and people that I don't like.
and
> Google states that if, for example, Google Maps used PostGIS as its data store, and PostGIS used the AGPL, Google would be required to release the Google Maps code. This is not true. They would be required to release their PostGIS patches in this situation. AGPL does not extend the GPL in that it makes the Internet count as a form of linking which creates a derivative work, as Google implies, but rather that it makes anyone who uses the the software via the Internet entitled to its source code.
This is the problem: I've fought with IP lawyers we've had on retainer who always boil it down to: "It doesn't matter. We're not going to court to find out."
Is it FUD? Yes. But I am also not a lawyer, and I can only do so much to fight upwards as an IC. I've seen this exact mindset at every company I've ever worked for or with.
The real fear is that once you have an AGPL dependency, it's _possible_ that it makes it way into something you really don't want to release publicly, and now you have a huge mess of a problem. The easy solution: don't use software with that license.
(FWIW I hate this, and fully believe competent developers can not shoot themselves in the foot so extravagantly, but alas.)