I released software under both of these licenses and would indeed chose between these based on the target ecosystem and potential for code-reuse. Apache-2.0 I released my latest project under...
I released software under both of these licenses and would indeed chose between these based on the target ecosystem and potential for code-reuse.
Apache-2.0
I released my latest project under Apache 2.0 because I wanted to allow anyone to take pieces of it and reuse them as they see fit with little restrictions. This project does not really have potential commercial value, so I'm not worried about a company forking it and selling it, but I hope other projects can benefit from the experiments we're running.
Apache 2.0 is the least permissive of the permissive licenses, so it can use MIT and BSD dependencies, and I chose Apache 2.0 because clause 5 gives me peace of mind as a weekend-maintainer:
Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions.
GPL-3.0-only
I have zero trust in the FSF anymore, but I'm happy to claim death of the author and use that license, because it's pretty good! To shield yourself from future GPLv4 drama, make sure you specify GPL-3.0-only instead of the default GPL-3.0-or-later license.
That's the license I'd use for any "end-user" software, that would not really benefit from being split into reusable pieces. Because GPLv3 has been written to be compatible with Apache 2.0, it can use almost any lib, read the license compatibility wikipedia article for more info.
Mixed-license project
Because GPLv3 software can depend on Apache 2.0 libraries, you could decide to release the "backend" of your app as Apache, and the frontend as GPLv3. The final binary will be in GPLv3, but you can open others to reuse its backend, if that's what you wish. You don't even need to have separate repositories, just make sure that the files have the right SPDX headers (and ideally put these in separate folders). If someone reaches out, you can do the work of releasing that part separately, but don't need to incur the cost upfront.
Relicensing
As long as you are the only contributor, you are free to change the license at any time, as long as it's compatible with the dependencies that you're using. Once you accepted contributions, it's more complex:
At any point, you are free to relicense Apache 2.0 code into GPLv3
You cannot go the other way around without consent from all contributors though
Contributor License Agreements were a seductive way to keep flexibility, but they have been weaponized by companies like mongo, elastic and hashicorp to go proprietary, so you should not sign any CLA, or ask contributors to sign one
I'd advise AGPL, especially for anything that is to be hosted, as it's an even stronger version providing protections against say Amazon or Microsoft going "yoink" and undermining any chance you...
I'd advise AGPL, especially for anything that is to be hosted, as it's an even stronger version providing protections against say Amazon or Microsoft going "yoink" and undermining any chance you have of monetizing hosting yourself.
OPs' project is a desktop app, so the AGPL would not add anything relevant. Also, while the AGPL got some corporate lawyers spooked, it's not the anti-Amazon bullet that some people claim it is,...
OPs' project is a desktop app, so the AGPL would not add anything relevant.
Also, while the AGPL got some corporate lawyers spooked, it's not the anti-Amazon bullet that some people claim it is, or Mongo would have kept it instead of writing the SAPL. While AWS would need to Open-Source all modifications to the software itself, the AGPL would not virally apply to all the control plane and management services around it. This is what the non-Open-Source SSPL tries to address, but in terms that are so vague that it's uncertain whether it applies to the motherboard BIOS.
Desktop apps can be accessed through a thin client on someone else's computer. The underlying business logic may also be relevant in a business context. IMO the question is "why not AGPL?"
OPs' project is a desktop app, so the AGPL would not add anything relevant.
Desktop apps can be accessed through a thin client on someone else's computer. The underlying business logic may also be relevant in a business context. IMO the question is "why not AGPL?"
Disclaimer: IANAL. If we have any IP lawyers here, I'd welcome their corrections. The AGPL doesn't necessarily prevent that. I think that's a common misconception because, in practice, SaaS...
Disclaimer: IANAL. If we have any IP lawyers here, I'd welcome their corrections.
The AGPL doesn't necessarily prevent that. I think that's a common misconception because, in practice, SaaS companies tend to avoid AGPL-licensed software like the plague. AGPL's surprisingly limited history in the courts make those companies' lawyers take an extremely cautious position on the ambiguities of (1) what constitutes "remote network interaction" and (2) to what extent do its copy-left terms apply to the other software behind their services?
To this layman, the plain meaning is a lot less cataclysmic than that. But I digress.
To guard against what you've described (another company offering your software as their service), you'd need something like the SSPL, which is itself based on the AGPL.
In fact, the only substantial difference between the Terms and Conditions of the GPLv3, AGPLv3, and SSPL is in each one's Section 13:
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.
If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version.
“Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.
I released software under both of these licenses and would indeed chose between these based on the target ecosystem and potential for code-reuse.
Apache-2.0
I released my latest project under Apache 2.0 because I wanted to allow anyone to take pieces of it and reuse them as they see fit with little restrictions. This project does not really have potential commercial value, so I'm not worried about a company forking it and selling it, but I hope other projects can benefit from the experiments we're running.
Apache 2.0 is the least permissive of the permissive licenses, so it can use MIT and BSD dependencies, and I chose Apache 2.0 because clause 5 gives me peace of mind as a weekend-maintainer:
GPL-3.0-only
I have zero trust in the FSF anymore, but I'm happy to claim death of the author and use that license, because it's pretty good! To shield yourself from future GPLv4 drama, make sure you specify
GPL-3.0-onlyinstead of the defaultGPL-3.0-or-laterlicense.That's the license I'd use for any "end-user" software, that would not really benefit from being split into reusable pieces. Because GPLv3 has been written to be compatible with Apache 2.0, it can use almost any lib, read the license compatibility wikipedia article for more info.
Mixed-license project
Because GPLv3 software can depend on Apache 2.0 libraries, you could decide to release the "backend" of your app as Apache, and the frontend as GPLv3. The final binary will be in GPLv3, but you can open others to reuse its backend, if that's what you wish. You don't even need to have separate repositories, just make sure that the files have the right SPDX headers (and ideally put these in separate folders). If someone reaches out, you can do the work of releasing that part separately, but don't need to incur the cost upfront.
Relicensing
As long as you are the only contributor, you are free to change the license at any time, as long as it's compatible with the dependencies that you're using. Once you accepted contributions, it's more complex:
I'd advise AGPL, especially for anything that is to be hosted, as it's an even stronger version providing protections against say Amazon or Microsoft going "yoink" and undermining any chance you have of monetizing hosting yourself.
OPs' project is a desktop app, so the AGPL would not add anything relevant.
Also, while the AGPL got some corporate lawyers spooked, it's not the anti-Amazon bullet that some people claim it is, or Mongo would have kept it instead of writing the SAPL. While AWS would need to Open-Source all modifications to the software itself, the AGPL would not virally apply to all the control plane and management services around it. This is what the non-Open-Source SSPL tries to address, but in terms that are so vague that it's uncertain whether it applies to the motherboard BIOS.
Desktop apps can be accessed through a thin client on someone else's computer. The underlying business logic may also be relevant in a business context. IMO the question is "why not AGPL?"
Disclaimer: IANAL. If we have any IP lawyers here, I'd welcome their corrections.
The AGPL doesn't necessarily prevent that. I think that's a common misconception because, in practice, SaaS companies tend to avoid AGPL-licensed software like the plague. AGPL's surprisingly limited history in the courts make those companies' lawyers take an extremely cautious position on the ambiguities of (1) what constitutes "remote network interaction" and (2) to what extent do its copy-left terms apply to the other software behind their services?
To this layman, the plain meaning is a lot less cataclysmic than that. But I digress.
To guard against what you've described (another company offering your software as their service), you'd need something like the SSPL, which is itself based on the AGPL.
In fact, the only substantial difference between the Terms and Conditions of the GPLv3, AGPLv3, and SSPL is in each one's Section 13:
GPLv3
source
Just clarifies how the GPLv3 and AGPLv3 interact.
AGPLv3
source
Server Side Public License (SSPL)
source
This isn't specific to Apache 2.0, right? Doesn't it apply to MIT and the other permissive licenses?
Probably not indeed, you'd need to check library compatibity on a case-by-case basis.