> 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.
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.
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.
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.
> 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.
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
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.
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.
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.
> your arguments are irrelevant since you would have to make them in court
This is simply not the case. Relationship matters a LOT here.
Microsoft's license is not like the GPL/AGPL in that there can be many random parties to it. There's not 10,000 forks of Windows each with a different rights owner who might hop out of the woodwork looking for a quick buck. The only relevant parties to their EULA are you and MS. If you are an enterprise doing existing business with MS (i.e. you aren't already pirating Windows), you simply aren't going to end up in court over some contract technicality taken out of context.
The danger to the AGPL is that there's unclarity in the language AND some rando you don't know and don't do any business with could potentially exploit it.
But now your argument has nothing to do with the AGPL at all and everything to do with not doing business with disagreeable people.
And many free software projects require copyright assignment (e.g. the FSF requires this), so in all of those cases you're not dealing with 10,000 different parties, only the one. If that party is litigious then it doesn't really matter which license they use, they'll still be able to find an excuse to cause you grief.
> But now your argument has nothing to do with the AGPL at all and everything to do with not doing business with disagreeable people.
The ability for anyone to contribute is an inherent and intended feature of the AGPL, and it's something unique when compared to a traditional EULA for commercial software. The potential risks to this model might not be intentional, but they are nonetheless a result of the design.
>And many free software projects require copyright assignment (e.g. the FSF requires this), so in all of those cases you're not dealing with 10,000 different parties, only the one
To your point about arguments having nothing to do with the AGPL -- this is not part of the AGPL, and many AGPL projects do not have a copyright assignment agreement.
The bottom line of my point is -- risk is amplified by uncertainty.
[A little bit of uncertainty] * [a bunch of organizations who DGAF about us at all] = [possibly a significant concern]
[A little bit of uncertainty] * [one organization with a profitable, existing, and predictable relationship] = [disagreements are probably being settled by an invoice not a lawsuit]
Historically Microsoft has been an offensively litigious actor that paid as much attention to the rule of law and ethics in the scope of their area of business as the average drug dealer does in theirs.
If relationship counts then surely the fact that you will be dealing with one of the worst actors in IT doesn't help your argument much.
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."
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.
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.
> 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.
> 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.
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.
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.
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.