Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The terms of the AGPL are pretty easy to comply with

drewdevault.com

Post reply on HN
Print view View original

171–180 of 341 posts

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

#171

Post by simion314 »

jgilias wrote: post #34

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.

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.

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

#172

Post by belorn »

p0llard wrote: post #66
woofie11 wrote: post #13

Earlier quoted context omitted.

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

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

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

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

#173

Post by tptacek »

debiandev wrote: post #120
cic48 wrote: post #33

Earlier quoted context omitted.

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

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

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.

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

#174

Post by evgen »

saagarjha wrote: post #109
michaelcampbell wrote: post #19

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 Now, is it really? Paying a team of software engineers to recreate every AGPL project surely isn't…

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.

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

#175

Post by tptacek »

woofie11 wrote: post #56
SpicyLemonZest wrote: post #28

Earlier quoted context omitted.

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

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.

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

#176

Post by tptacek »

ddevault wrote: post #49
objclxt wrote: post #41

Earlier quoted context omitted.

> a basic reading of the AGPL text readily and clearly confirms this fact. But that reading has never been tested in court, so from counsel’s perspective why risk it? No competent lawyer would take the AGPL at prima facie, they’re going to look for case law - and there isn’t any.

Why risk anything? On the grand scale of things, effectively nothing has been tested in court. This is no grounds for making baseless statements about a license which are unsupported by its text.

The statements you're responding to were, taking the commenter at their word, informed by lawyers, while yours, taking you at your word, were not. We need to revisit the definition of the word "baseless".

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

#177

Post by joshuamorton »

ran3824692 wrote: post #166
joshuamorton wrote: post #158

Earlier quoted context omitted.

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

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

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

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

#178

Post by jkaplowitz »

TAForObvReasons wrote: post #162
jkaplowitz wrote: post #154

Earlier quoted context omitted.

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

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.

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

#179

Post by ThePhysicist »

CodesInChaos wrote: post #152
ThePhysicist wrote: post #123

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…

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

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.

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

#180

Post by Andrew_nenakhov »

n0n0n4t0r wrote: post #62

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.
Post reply on HN