Live data from Hacker News

The terms of the AGPL are pretty easy to comply with

drewdevault.com

211–220 of 341 posts

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

#211
post #204
post #193

Earlier quoted context omitted.

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

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.

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

#212
post #69

Earlier quoted context omitted.

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.

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

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.

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

#213

Earlier quoted context omitted.

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

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.

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

#214
post #187

Earlier quoted context omitted.

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

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

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

#215

Earlier quoted context omitted.

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.

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

#216

Earlier quoted context omitted.

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

So your legal interpretation as a lawyer (I assume) is an ad hominem on Google for unrelated reasons?

Google is not even a human to apply an ad hominem to, fanboy

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

#217

Earlier quoted context omitted.

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.

And that is still a choice, but your lawmakers have made it for you. Alternatively, you can choose not to develop for those industries.

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

#218

Earlier quoted context omitted.

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

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

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.

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

#219

Earlier quoted context omitted.

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

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.

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

#220
post #211
post #204

Earlier quoted context omitted.

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

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

Post reply on HN