Live data from Hacker News

The terms of the AGPL are pretty easy to comply with

drewdevault.com

191–200 of 341 posts

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

#191

Earlier quoted context omitted.

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

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

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

#192
post #83
post #58

Earlier quoted context omitted.

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

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.

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

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

#193
post #165

Earlier quoted context omitted.

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

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.

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

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

#194

Earlier quoted context omitted.

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

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.

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

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

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

#196
post #126
post #91

Earlier quoted context omitted.

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…

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…

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

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

#197

Earlier quoted context omitted.

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.

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

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

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

#198

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

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.

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

#199
post #101

Earlier quoted context omitted.

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

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

It's not always a choice. There are people who cannot open source their software due to other legal, organizational, or practical factors.

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

#200
post #140

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

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

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.

Post reply on HN