Open Source License Helper Tool

http://copyfree.org/

and usually release stuff under the Copyfree Open Innovation License (COIL)

http://coil.apotheon.org/

And FSF's preferred interpretations of the GPL, and various ambiguous things in it (especially with respect to dynamic linking and implementations of standard interfaces) make it even less "nice and simple".

Let's take an example: Django is a web framework that, among its components, includes an ORM. The ORM is mostly agnostic when it comes to what database you use (I say "mostly" because the core team has always had a preference for PostgreSQL, so there are some bundled things that either only work with PostgreSQL or become more featureful if you choose to use PostgreSQL); it comes with built-in backends that speak the SQL dialects of PostgreSQL, Oracle, MySQL and SQLite. There are third-party backends available that speak the SQL dialects of other databases.

To actually use it, you have to pair it with a DB driver module implementing PEP 249, the standard Python database API. A SQLite driver ships in Python's standard library; drivers for PostgreSQL, Oracle and MySQL are available third party.

Django's bundled MySQL backend expects to talk to a MySQL Python driver module. All currently-available Python driver modules for MySQL are GPL'd. Does the fact that the backend module for MySQL attempts to load a MySQL driver mean Django has to be GPL'd? Django and the driver will be sharing address space, after all, and FSF uses that as a clear indication of a "combined work" that must be GPL'd.

Now, the usual way around this is to point out that Django simply wants something implementing a standard API, and doesn't know in advance which implementation you'll choose to actually use; if you had some other library implementing the same standard API, it would work just as well as the GPL'd implementation. This has worked out in other domains to avoid accidentally GPL'ing things that just want to use a standard API implemented by multiple competing libraries.

But... the standard Python database API doesn't quite cover everything you might need to implement full-featured database access, especially when it comes to interrogating the version and supported features of the actual database you're talking to. Luckily these things can almost all be found out through DB-specific queries, but if Django has to hit a non-standardized bit of the driver's API to get some of that information, and if the driver is GPL'd, does that require Django to be GPL'd? And everything everyone's ever developed using Django?

As far as I can tell, the only thing used by Django's MySQL backend that isn't standardized in PEP 249 is a set of constants that label MySQL's internal column-type identifiers to allow introspection (i.e., so you can query for a table's column list and figure out that column type 7 is a TIMESTAMP, or column type 252 is a BLOB). Is that enough to GPL the entire Django ecosystem? What if FSF decides tomorrow that it is, and comes after us? What if we just copy/paste the integer values over into a file in Django? Does that list of constants even meet the requirements for copyright protection in the first place?

There is nothing "nice" or "simple" about having to navigate this. It's only "nice" if your definition of the term includes deliberately inflicting pain on people who are developing software that meets the FSF's definition of Free but which does not happen to be distributed under the FSF's preferred license. Personally I don't find that to be "nice" at all.

https://www.gnu.org/licenses/license-recommendations