Live data from Hacker News

The terms of the AGPL are pretty easy to comply with

drewdevault.com

251–260 of 341 posts

Re: The terms of the AGPL are pretty easy to comply with

#251

Earlier quoted context omitted.

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.)

>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 i…

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.

Re: The terms of the AGPL are pretty easy to comply with

#252
post #214
post #187

Earlier quoted context omitted.

"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...

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 require…

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.

Re: The terms of the AGPL are pretty easy to comply with

#253

Earlier quoted context omitted.

> 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.

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.

Re: The terms of the AGPL are pretty easy to comply with

#254

Earlier quoted context omitted.

> 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 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 com…

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.

Re: The terms of the AGPL are pretty easy to comply with

#255

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…

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 Goog…

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.

Re: The terms of the AGPL are pretty easy to comply with

#256

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 happ…

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.

Re: The terms of the AGPL are pretty easy to comply with

#257

Earlier quoted context omitted.

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 blank…

> 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.

"any month now" was very much meant as tongue-in-cheek, yes.

Re: The terms of the AGPL are pretty easy to comply with

#258

Earlier quoted context omitted.

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.

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".

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.

Re: The terms of the AGPL are pretty easy to comply with

#260
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

Post reply on HN