Where I work[1], AGPL software is strictly and unconditionally forbidden to use for anything, even things that are completely internal and will never see a public user.

The fear that our lawyers have is that, since putting up the software in a service counts as a derived work, our whole software stack (including the stuff we don't open source) will have to be opened along with it. There have to be clear service boundaries between the AGPL software and the stuff we write ourselves, and the lawyers don't trust us to write in appropriate boundaries.

It's really kinda tragic, because we actually do submit source code upstream when we make changes to open source software that we run internally. As in, if it's an OSS product that we just use for some dumb internal automation thing, we'll submit patches if the license is BSD or MIT, but as soon as GPL (especially AGPL) hits anything suddenly the lawyers get paranoid because of what constitutes a "derived work", which can be interpreted as anything that links against the software to make a complete product.

The upshot of this is, if the OSS software is on an unrestrictive license like BSD or apache, we contribute upstream. If it's GPL or especially AGPL, we simply don't touch it, ever.

[1] A very, very well known technology company.

That's often not an unwelcome side-effect. If you're at a large technology company, making sure companies like yours don't use the free version is a common motivation. Aerospike sells a commercial enterprise license; in that kind of a "dual-license" setup, the GPL/AGPL can function as a useful poison pill to keep from cannibalizing enterprise sales with the free version (where a common alternative would be to just not open-source at all, for fear of that cannibalization).

A lawyers job is to think about all the things that could go wrong and to prepare for that possibility. Their job is to think what would happen if the company goes under, or what if the newly bought property would burn down, or what if the business partnership you just signed up for went sourer. Their job is not do cost-benefit analysis, or even consider how high risk something actually is. Their job is to handle the what-if's.

So the reaction you are talking about is natural behavior of lawyers being exposed to legal documents and contracts. If there is anything that could be interpreted to impact the company, their job is to consider it and think "what-if".

The question comes down to, what is a healhty way to handle the result of lawyers paranoia. Best-practice is to do a cost-benefit analysis and balance the benefits with the insight of the legal advice. Second-worst is to avoid anything with a risk, regardless of benefits, in order to avoid it. Worst choice is to ignore the lawyers. Most companies, including the "very well known technology companies", pick the second-worst option for anything that is not critical to the company survival. Its clearly not the best option, but it keeps the status quo.

I can't see it being an issue. As mentioned in the useful MongoDB link you shared, the licence will require sharing only when modifying the database code, but not require automatic sharing of the rest of the software stack.

Have there been any court cases involving AGPL violations? I wonder if some of Gil Yehuda's fears are partly out of lack of clarity on where the reach of the AGPL ends? For example claiming the MongoDB drivers 'violate the AGPL license', I´d prefer to see a response from GNU on this.

I seem to recall neo4j (could be it was another nosql db/company) had some strange ideas about the agpl. Of course if the drivers are covered by agpl and linked into your application, then you might have to create a new api "border" (eg:HTTP REST) between whatever code you want to license differently and the agpl server. I don't think the agpl should be a problem in most cases - at any rate you don't have to contribute patches up-stream, only to those of your users that ask for the code (if any). Unless upstream is also using your service, that is.

A perhaps more interesting question is how they manage contributions and pull requests - if i'm using the server under agpl, it seems natural to contribute code under agpl. But now that code can't be used in the commercially licensed upstream "fork" unless that fork is sold under the agpl... So either contributors will have to donate code, or sell code to upstream for use in the "closed" project.

I could see that get a bit hairy with user-contributed bug fixes?

So far, AGPL has not been tested in court. GPL has. The scope of Derivative Works (reach) has as well (but the case law in this area is more complicated than most open source developers are aware of since copyright law is understood differently based on which federal circuit court hears the case). The more challenging consideration for me is the AGPL/Apache (DB/Driver) method that these companies are using -- and especially when you have Apache licensed community contributions (these apparently violates AGPL's own terms). I see this as an area that can backfire against the open source community -- and indeed I'd also like to know if FSF, SFLC, or GPL-violations takes a position on the use of Apache drivers to AGPL DBs. If so, it would be best for the open source community to know about this soon rather than after many have placed themselves in a position where their best option is to pay the vendors that have somehow managed to achieve lock-in. Ironically, this is the opposite of the goals that many in the open source community endorse. So if FSF takes a strict position on AGPL, it could accidentally result in the opposite of the freedoms we have been working for.

I'm also fascinated when companies use a license and then state in their FAQ that they didn't really mean all the terms of the license. If this comes up in court, the judge might take the FAQ into account and interpret the intent of the licensor, or might just look at the license text itself. It'll be interesting to see what happens. My advice for now is to assume the text of the license to be what the licensor intended and my hope is that companies that use open source licenses simply use the licenses that match what they mean. If they really mean that they want you to pay, they should just be clear about it and people can decide if they want to pay.

Well in the case of companies like Google or Facebook, they might actually modify the database for various of reasons (e.g. internal policy, speed, etc). I don't have first hand experience with modifying databases so I thought I would ask :)

If someone modified the database and deployed it publicly (or as part of a webapp that was deployed publicly), they'd need to share the modified source, yes. AGPL is roughly GPL but where the traditional definition of "shipping software" is expanded to include deploying on a network.

My guess is that they have two motivations, both of which are fairly traditional GPL motivations: 1) sell AGPL exceptions to commercial licensees; and 2) prevent a competitor from making a private commercial fork, where the competitor improve the DB and licenses their version to clients, without sharing the source to their improvements.

To be pedantic: deployed it a an external service, not necessarily a public service (I suppose to a legal entity that would not normally share license rights, such as an inividual not part of the organisation or to another organisation). Those external users would have to be given an option to access the full source with modifications.

As for the "part of a web service"-bit, I'm not sure what the agpl's actual "reach" is. My understanding is that with a (modified) db under agpl powering eg a web app runing in php, the end users (accessing only the web server) would not be entitled to the db source. If the agpl covered the web srrver itself or a php library on the other hand, the users would be entitled to that code?

Similarly if one sold a modified db-as-a-service, modifications would be covered by the agpl.

While its interesting to theorize about databases and AGPL, I am rather sure there hasn't been any actually case or a legal reason to think that the database would become a derivative work when used together with a webserver.

If it was, the EULA for SQL server and oracle would have to include copyright permission for derivative works. That we do not see that should be a clear sign that the scope of copyright has not reached that far yet.

Matt Asay of MongoDB, Inc. (disclosure takes care of Asayroll Rule<tm>) responded to that openstack-dev posting, FWIW: http://lists.openstack.org/pipermail/openstack-dev/2014-Marc...

AGPL is essentially the "corporate coward" license. They want to capture all of your private changes to basically get free (legally mandated, zero "community good will") development resources. Companies think it's "safer" than BSD or straight up GPL because lawyers feel "omgz, source codes, zero cost IP copies, instant competition!"

The next step after AGPL will probably be BrainGPL requiring you to publish all thoughts you have about any code you look at ever.

You could just pay for a license if you're that paranoid. It's remarkable to what extent people will complain about free not being "free enough". I assume you haven't contributed a line of code to the project, so it's a bit presumptuous to knock it.

> I assume you haven't contributed a line of code to the project, so it's a bit presumptuous to knock it.

It's not that simple. Even if you're a company that wants to use the software and contribute changes upstream, it's still a dumb idea to use AGPL software.

Because of the loose definition of what constitutes a derived work, modifying AGPL software (even if you put those modifications upstream) means you might have to open source your entire software stack. The AGPL is not like the LGPL, it doesn't contain any exceptions for linking against it in an overall product. Unless you have clear service boundaries, you are creating a derived work every time you use AGPL software in a service.

In my company, our lawyers outright forbid the use of AGPL software altogether for this reason. Even software that's only used internally. As _delirium mentioned above[1], that's not entirely an unwanted thing from the licenser's perspective: they typically do this so you'll buy their commercial license. But don't assume the only people who don't like AGPL are non-contributing freeloaders.

We submit tons of stuff upstream on a regular basis at my company, but we simply can't do it with AGPL software. Seeing any reference at all that our company (which has some of the deepest pockets in the planet) uses AGPL software anywhere in its stack will open ourselves up to lawsuits immediately. So we just don't touch it, ever.

[1] https://news.ycombinator.com/item?id=8095024

You make it sound like it would be better not to open source code at all.

Frankly speaking I wouldn't care if I can read code and learn something new ....