[deleted]
The terms of the AGPL are pretty easy to comply with
11–20 of 341 posts
Re: The terms of the AGPL are pretty easy to comply with
#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 linking which creates a derivative work, as Google implies, but rather that it makes anyone who uses the the software via the Internet entitled to its source code.
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."
Is it FUD? Yes. But I am also not a lawyer, and I can only do so much to fight upwards as an IC. I've seen this exact mindset at every company I've ever worked for or with.
The real fear is that once you have an AGPL dependency, it's _possible_ that it makes it way into something you really don't want to release publicly, and now you have a huge mess of a problem. The easy solution: don't use software with that license.
(FWIW I hate this, and fully believe competent developers can not shoot themselves in the foot so extravagantly, but alas.)
Re: The terms of the AGPL are pretty easy to comply with
#13> 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?
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 call back-and-forth, or have APIs specific to each other, that generally does form a derivative work.
There's a lot of literature out there about static versus dynamic versus microservice abstraction. That's mostly nonsense. Lawyers don't care about that. You can't get around the AGPL (or even the original GPL) that way, by isolating the GPLed code into a corner over a network service.
(disclaimer: not legal advice, get a laywer if you want legal advice).
Re: The terms of the AGPL are pretty easy to comply with
#14> 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?
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.
Re: The terms of the AGPL are pretty easy to comply with
#15> 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…
> Legally, you don't want to deal with the burden of constantly checking if you're complying with some license that a dependency of a dependency of a dependency is using.
If you're not modifying that dependency, you don't need to do anything since your dependencies are handling it. Especially with GPL, since it's likely that your dependency's dependency will make it GPL as well–but you should be doing this anyways, of course.
> 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 you're just not in agreement with how GPL works. It's meant to be an explicit guard against people taking projects, forking them, and never contributing back.
Re: The terms of the AGPL are pretty easy to comply with
#16> 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?
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.
Note that there is a specific exception for that case: https://en.wikipedia.org/wiki/GPL_linking_exception
Re: The terms of the AGPL are pretty easy to comply with
#17> 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 linking which creates a derivative work, as Google implies, but rather that it makes anyone who uses the the software via the Internet entitled to its source code.
Is there an existing national court case which supports this assertion? Otherwise it's a valid concern given that lawsuits and judges may have different interpretations than engineers. Just look at the Oracle vs. Google debacle over Java.
Re: The terms of the AGPL are pretty easy to comply with
#18> 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?
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.
> in the same way that a C program linked against glibc is not a derivative work of glibc
I believe this is only as a result of the linking exception; I don't know if this has ever been tested, but my understanding was that linking (either statically or dynamically) against a library was generally considered enough to be a derivative work.
Re: The terms of the AGPL are pretty easy to comply with
#19Truth 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.
Re: The terms of the AGPL are pretty easy to comply with
#20I have significant responsibility for setting open-source policy at my company. We require specific review on a facts-and-circumstances basis of any AGPL usage. Why? Because for most open-source licenses, it's clear how to avoid any license controversy entirely by simply never conveying the licensed work. If I don't ship you ("convey to you") any binaries, I have no obligations to you under GPL (or MIT or Apache, obv…
It's neither more nor less practical in general. It's less practical for your company.
It depends on what you're trying to accomplish. If your goal is to build a low-friction library for others to adopt (e.g. JQuery), it's a horrible, horrible license. If you're trying to build an ecosystem around an end-user tool (e.g. I'm making a web-based competitor to Adobe Illustrator), it can be an awesome license. Lots of open source tools aren't intended to be integrated into other systems, but used stand-alone. That's where licenses like the AGPL really shine.