Choosing an open source license for my up to now commercial project

Question

I'm about to re-license my desktop application as open source software. For several years now, the application is published and sold under a commercial license. While working on a new version (including a complete code rewrite, even using a different programming language), I decided to release the new version as open source. (I also intend to release the source code of the previous versions as open source, but that's not important here, I think.)

For the open source release, I have to find an appropriate license.

My main goals are:

• I want a copyleft license. It'd be very easy for a company to add some simple features and sell it as a better application, without providing those features back to the project if it'd be under a permissive license.
• I want to easily attract users and contributors. I initially intended to use the GNU AGPL as the "most modern" license, but learned that users (especially in companies) may have restrictions regarding AGPL, one example being Google: https://opensource.google/documentation/reference/using/agpl-policy
• I want to retain control over the name and the logo of the application. The software is sold now for several years under this name and as such is connected with me. So, I want to make sure the name is only used for releases I authorize. Forks using another name would be fine, of course. (I have no registered trademark for the name.)

As far as I understand, the GPL v3 would support these goals. Is this correct?

There's one additional goal as I'm based in Germany:

• I want to be compatible with German law. AFAIK, the GPL v3 clause "16. Limitation of Liability" conflicts with some part of German law, which basically says that General Terms and Conditions (in German: AGB – Allgemeine Geschäftsbedingungen) may not contain surprising clauses or restrict rights that are granted by law. Thus, some lawyers in Germany suggest to add a clause to the GPL that clarifies this, but I think such a changed GPL could discourage contributors. OTOH, there are lawyers saying that's not a problem at all as the liability restrictions of the GPL would just be invalid and the default liability clauses of the German law would be in place.

Some additional information:

• I'm the sole developer so far
• The new application is written in Python 3.x, using wxPython as its GUI toolkit and SQLite as the internal data storage
• The old application uses C++ and FLTK

As I'm only using software that has a license that's compatible with commercial licensing, it should all be compatible with the GPL, right?

Given my current knowledge, I'd use the unaltered GPL v3 for my application. Do you see anything that would lead to use a different license?

Answer 1

The GPLv3 covers most of the goals you mentioned and is a good choice.

The goal it doesn't cover is the one about the name and logo of the application. Who can use that name and/or logo is a matter of trademark law and not copyright law. For that reason, a copyright license (like the GPLv3) does not affect who can use your program's name and/or logo.

If you find it important that you retain control of the name/logo and that forks must change those, then I recommend you look into registering a trademark for your program's name and logo.

Regarding the compatibility with German law, clause 16 of the GPLv3 is denying liability to the extent allowed by law. If German law states that, for example, you are liable to give a money-back guarantee in certain cases, then the GPLv3 does not prevent your users from claiming that liability. Also, such warranty and liability disclaimers are fairly common in open-source licenses (and I would expect also in closed-source EULAs), so I don't think it can be classified as a surprising clause either.

Answer 2

I'd still suggest considering AGPL

You say:

I [...] learned that users [...] may have restrictions regarding AGPL, one example being Google

But you also say:

It'd be very easy for a company to add some simple features and sell it as a better application, without providing those features back to the project

Therefore... Weigh up how important it is to you:

• for users to be able to use your software in (probably) commercial environments that are prevented from using AGPL software, versus
• for you to be able to prevent someone making a cloud-based spin-off of your product, which they would be able to modify to their heart's content and never have to release to anyone under the GPL

Although you've said your product is a desktop application, making it less likely such a cloud-based spin-off would arise, I think these days, FOSS proponents should assume this treatment can happen to any project. If your project includes any significant "calculation" or "logic" component that does something non-trivial and useful, people will look to use that in their projects; but even if not, GUIs can be wrapped, or at the most basic level someone can just set up some kind of web-accessible desktop "emulator" or remote display. And these days, there are a lot of consumers that don't understand either FOSS or the cloud and are perfectly happy to use whatever SaaS someone is selling as long as it does what they want.

Under GPL, anyone who feels they have something to gain could potentially benefit from your product in this way without giving anything in return. Under AGPL, they can't.

What about dual-licensing?

If you release your product under AGPL and you retain full ownership of the IP, you can of course provide users with a choice between receiving your product under AGPL, or agreeing to a proprietary license of your choice (whether this is paid or free-beer).

However, this is probably not what you want to do. Users like Google that ban the use of AGPL software as a matter of policy would be just as unlikely to go with your proprietary license (even if it's free-beer), and meanwhile, going this route would alienate potential users, because it signals that you will go full commercial at some point and screw them over (as this has happened so many times in recent history).

If you want to keep copyleft long-term, the best policy is to encourage outside contributions without using a CLA, such that over time your product becomes owned more and more collectively by a diverse group of people / legal entities. That way, it becomes impractical for anyone (including you) to relicense the software in future, and this will attract users who want a product that they believe will remain maintained into the future without any surprising license changes.

Note that this all applies regardless of whether you go with GPL or AGPL.