That is true, but "frog" is still definitely not the definition of "animal", even though a frog is an animal.

The red-eyed tree frog [1] is an animal, but it is a noncentral example of an animal, i.e., it is not the typical thing you think of when you think "animal". To the_mitsuhiko, the AGPL is a noncentral example of an open source license.

The term comes from the noncentral fallacy [2], which is about abusing noncentral examples.

[1] https://en.wikipedia.org/wiki/Agalychnis_callidryas

[2] http://lesswrong.com/lw/e95/the_noncentral_fallacy_the_worst...

This is an interesting example for the difference between "reading by the word" and "reading by the meaning" (there's not a good English word for this, but in Germany we call this "sinnentnehmendes Lesen".)

I also believe it makes sense. Perhaps i can restate it. the_mitsuhiko made five assertions:

1. The AGPL is not just an updated GPL, but expands the scope of the GPL's 'infective' property considerably.

2. Some people are uncertain about what exactly the consequences of using AGPL'd software are.

3. Because of this uncertainty, there are companies which will not use AGPL'd software.

4. The AGPL is an open source license, but it is neither the only nor the most representative open source license.

5. Some people wish to license their software in a way which maximises the number of people who can use it. That means not using the AGPL, because of point 3.

Or freedom to combine with software using any other non-copyleft, open source license.

Which non-copyleft OSI-approved license are you having difficulty combing with AGPL?

Well, sure, but 10th- and 16th-most common (1% and <1%, respectively) isn't actually very common at all[0]. Which applies to the AGPL as well.

The potential for conflict between EPL and AGPL, or CDDL and AGPL, code in projects is tiny.

For that matter, the GPL was around first, and is the 2nd most popular license. Shouldn't the EPL and CDDL have been modified to be GPL compatible (the Apache Software Foundation managed to work this out with the FSF, over the Apache v2.0 and GPL v3.0 licenses, after all[1]).

[0] https://www.blackducksoftware.com/top-open-source-licenses

[1] http://www.informationweek.com/enterprise/apache-foundation-...

But that "to combine" is exactly "to use", especially if it is a software library.

The developer who wants to combine with closed source can contact us and work out a special deal. It's only fair. They want to be compensated for spending their time, then so do we.

I don't know of anyone using agpl'd code to build software people use.

> For example, imagine Digital Ocean using MongoDB to store server configurations. AGPL would force them to open-source their whole infrastructure. All of it. Or pay to get a different license.

AGPL licenses aren't transitive, things that touch AGPL'ed software over the network aren't suddenly required to be AGPL licensed (otherwise the whole purpose of it would fall apart, since a large chunk of the initial design was for Free Software web-applications which could still be run in proprietary web browsers).

AGPL means if you decide to fork a project and add new features, then sell it as a hosted service ala AWS/Azure then you also have to provide anyone that connects to it your modified source code. I'm actually debating using the license right now in a couple of projects I've been prototyping - I don't want to prevent people from being able to make money offering hosted services, but at the same time I don't want hostile SaaS forks that could rip off my work without contributing their changes back (I like the BSD license for libraries, but I'm starting to appreciate the GPL/AGPL more for applications for community-related reasons rather than free software righteousness).

That is not necessarily true in the case of the database due to how the drivers work. This would need to be tested in court. It's unclear by the license terms alone.

[0] https://www.mongodb.com/blog/post/the-agpl

> 13. Remote Network Interaction; Use with the GNU General Public License. > > Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph. > > Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License.

Users interacting with the modified program over the network have a right to access the modified source, there's absolutely nothing about the client software (database drivers, web browsers, etc) accessing it being considered part of a combined work. You can access a AGPL licensed database or whatever from a proprietary application with absolutely no issue, you just can't modify the AGPL'ed work, expose it to users other than yourself, and not share your modifications.

Do yourself a favor, grab https://www.gnu.org/licenses/gpl-3.0.txt and https://www.gnu.org/licenses/agpl-3.0.txt and run `diff` on them, this is literally the only substantive difference in the entire license text.

No, but there is a definition of corresponding source which includes code beyond the direct scope of the AGPL in case of mongodb: "Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work."

This is one point of contention that was brought up by multiple people in the past because it puts client libraries into the scope.

Literally the only delta between the GPL and AGPL is the Remote Network Interaction section, it doesn't extend the reach of the GPL license in regards to database drivers, etc.

https://github.com/mongodb/mongo-c-driver/blob/master/COPYIN...

  [they] violate their own license

The worry with RethinkDB was (at least mine and people I talked to) that it can become a liability if the AGPL turns out to be an issue since some third party owns the original copyright and then who knows what happens with future contributions.

For example, imagine Digital Ocean using MongoDB to store server configurations. AGPL would force them to open-source their whole infrastructure. All of it. Or pay to get a different license.

I don't have a moral argument to make here -- just making sure people realize the actual trade-offs. AGPL is theoretically for a world where closed source software is simply not allowed to co-exist with opensource, even if you don't distribute it, but simply run it / host it / use it. But that world doesn't exist, so it does the opposite: it is actually used to make sure some of your users have to pay. It enables a business model.

I don't think that's correct. From MongoDB the company[0]:

> Note however that it is NOT required that applications using mongo be published. The copyleft applies only to the mongod and mongos database programs. This is why Mongo DB drivers are all licensed under an Apache license. You application, even though it talks to the database, is a separate program and “work”.

[0] https://www.mongodb.com/blog/post/the-agpl

Citation needed.