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

21–30 of 341 posts

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

#21

Post by taldo »

lxe wrote: post #5

> Any derivative works of AGPL-licensed software must also use the AGPL. TBH, I'm interpreting this statement just like Google is: > Google states that if, for example, Google Maps used PostGIS as its data store, and PostGIS used the AGPL, Google would be required to release the Google Maps code. What's the definition of 'derivative work' here?

It's hard to draw a line. Considering that google3 is a massive monorepo, where linking a library into any binary (or library) is just a matter of a single line in the BUILD file, a lawyer could argue that such binary is a derivative work (or, it could be a lot of work to argue that it isn't).

Also considering the internal-only patches to OSS libraries, it'd be at least a pain, and quite possibly a wide avenue for trade secrets to leak (not to mention that most of those are so specific to Google's highly specialized production stack that are useless to anyone outside).

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

#22

Post by rydre »

If you use GPL or a variant (i.e: AGPL) I'm just going to create an MIT version of your product and give it away for free (if it does not give me direct commercial benefit but is a part/component/library used in our product). If you're working on free software make it free. Otherwise if you want to offer source, ask people to buy the source without licensing the redistribution rights.

No jumping though silly hoops of GPL/Stallman type creepy old commie ideological men.

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

#23

Post by pydry »

dvt wrote: post #6

> Any derivative works of AGPL-licensed software must also use the AGPL. That's why people don't use AGPL, and why I personally don't release any code under (A)GPL. If you want to make free software, make free software and release your code under Apache or MIT. And if you really care about attribution, use CC BY 3.0. Legally, you don't want to deal with the burden of constantly checking if you're complying with some…

>I don't like the idea of other code mandating how I should release my code. What if I just don't feel like up-streaming?

Then don't use the software that's AGPL. Problem solved.

If somebody licences their code with AGPL then it probably means that they either don't want that or they want a cut of any commercial use of the code (dual license) - which is fair, no?

>Free is meant to be free

There are two types of free (beer and speech) and it kind of feels like you're deliberately confusing them.

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

#24

Post by ddevault »

xyzzy_plugh wrote: post #12

> Obligatory: I’m not a lawyer; this is for informational purposes only. and > Google states that if, for example, Google Maps used PostGIS as its data store, and PostGIS used the AGPL, Google would be required to release the Google Maps code. This is not true. They would be required to release their PostGIS patches in this situation. AGPL does not extend the GPL in that it makes the Internet count as a form of linki…

>This is the problem: I've fought with IP lawyers we've had on retainer who always boil it down to: "It doesn't matter. We're not going to court to find out."

This is incredibly stupid. By this logic your business can't do literally anything. The AGPL simply does not do what Google states it does, and a basic reading of the AGPL text readily and clearly confirms this fact.

A more realistic explanation for why Google shouldn't use AGPL software is because of their giant monorepo development style. If they import a third-party codebase into their monorepo and don't put big shouty warnings next to it, it seems really easy for it to start to leak into other modules. So maybe the following is true: if you use monorepos, and you vendor third-party code into them, then using AGPL'd software is risky. But this statement does not (and should not, monorepos are dumb) apply to most companies.

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

#25

Post by searchableguy »

dvt wrote: post #6

> Any derivative works of AGPL-licensed software must also use the AGPL. That's why people don't use AGPL, and why I personally don't release any code under (A)GPL. If you want to make free software, make free software and release your code under Apache or MIT. And if you really care about attribution, use CC BY 3.0. Legally, you don't want to deal with the burden of constantly checking if you're complying with some…

I think we should have a standardized MIT license that require paying above a certain market cap or something. An anti-sassfiy license too. That's what AGPL is used for currently but it focuses on contribution and openness rather than monetization.

Many of new database projects and infrastructure tools come up with their own licenses to protect themselves from such problems. A standardized approach would work better for everyone.

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

#26

Post by woofie11 »

xyzzy_plugh wrote: post #12

> Obligatory: I’m not a lawyer; this is for informational purposes only. and > Google states that if, for example, Google Maps used PostGIS as its data store, and PostGIS used the AGPL, Google would be required to release the Google Maps code. This is not true. They would be required to release their PostGIS patches in this situation. AGPL does not extend the GPL in that it makes the Internet count as a form of linki…

AGPL software isn't designed to be used as a dependency to a proprietary system. It's designed to be used in an open ecosystem. That's kind of the point.

* If you expect your code to be used as a dependency to a proprietary system, don't use the AGPL.

* If you are building a stand-alone system, or tools for an open ecosystem, use the AGPL.

That's a question of suitability-to-purpose. Although this use is permitted, AGPL simply isn't a good license for PostGIS (which is correctly licensed under the GPL). It is a great license for end-user applications. It's also nice for dual-licensing.

Licenses aren't something to get ideological about; it's more of a right-tool-for-the-right-job kind of thing. If you use a hammer with screws, you'll get hurt. Same thing with using BSD where AGPL fits, or AGPL where BSD fits.

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

#27

Post by tonyg »

dvt wrote: post #6

> Any derivative works of AGPL-licensed software must also use the AGPL. That's why people don't use AGPL, and why I personally don't release any code under (A)GPL. If you want to make free software, make free software and release your code under Apache or MIT. And if you really care about attribution, use CC BY 3.0. Legally, you don't want to deal with the burden of constantly checking if you're complying with some…

Perhaps you're getting downvoted because it's 2020, and your analysis makes zero mention of what some would call the most important group of people involved in any software project: the end users. There's little left to debate - this particular dead horse is well kicked - but your comment omits any sign you're willing to acknowledge the "freedoms for whom?" aspect of the issue.

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

#28

Post by SpicyLemonZest »

woofie11 wrote: post #26
xyzzy_plugh wrote: post #12

> Obligatory: I’m not a lawyer; this is for informational purposes only. and > Google states that if, for example, Google Maps used PostGIS as its data store, and PostGIS used the AGPL, Google would be required to release the Google Maps code. This is not true. They would be required to release their PostGIS patches in this situation. AGPL does not extend the GPL in that it makes the Internet count as a form of linki…

AGPL software isn't designed to be used as a dependency to a proprietary system. It's designed to be used in an open ecosystem. That's kind of the point. * If you expect your code to be used as a dependency to a proprietary system, don't use the AGPL. * If you are building a stand-alone system, or tools for an open ecosystem, use the AGPL. That's a question of suitability-to-purpose. Although this use is permitted, A…

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.

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

#29

Post by q3k »

rydre wrote: post #22

If you use GPL or a variant (i.e: AGPL) I'm just going to create an MIT version of your product and give it away for free (if it does not give me direct commercial benefit but is a part/component/library used in our product). If you're working on free software make it free. Otherwise if you want to offer source, ask people to buy the source without licensing the redistribution rights. No jumping though silly hoops of…

Where's that MIT version of Linux you've been working on?

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

#30

Post by ddevault »

searchableguy wrote: post #25
dvt wrote: post #6

> Any derivative works of AGPL-licensed software must also use the AGPL. That's why people don't use AGPL, and why I personally don't release any code under (A)GPL. If you want to make free software, make free software and release your code under Apache or MIT. And if you really care about attribution, use CC BY 3.0. Legally, you don't want to deal with the burden of constantly checking if you're complying with some…

I think we should have a standardized MIT license that require paying above a certain market cap or something. An anti-sassfiy license too. That's what AGPL is used for currently but it focuses on contribution and openness rather than monetization. Many of new database projects and infrastructure tools come up with their own licenses to protect themselves from such problems. A standardized approach would work better…

Beware: the approach you describe qualifies as neither "open source" nor "free software". It might be worthwhile to develop such licenses and experiment with this distribution model - but please call it something else, like "source available" or "fair source".
Post reply on HN