Many, many years ago there were already FSFE presentations by lawyers who encouraged everyone to prefer AGPL to GPL, because in most applications this is closer to what you actually want.
- GPL wants to care about the users, but actually cares only about those who install the software on their computer. Back then, these groups were identical, but in the time of remote applications (web apps, services, etc.) this means: The owner of the server, not the end user, receives the rights granted by GPL.
- AGPL actually does care about the users, no matter how they interact with your application. The rights given by the AGPL are granted to everybody down the chain.
Of course, this line of thinking only applies if you want a strong copyleft license. If you want non-copyleft, e.g. for very small projects, just stick with the ISC license (which is a more modern and slightly shorter version of MIT license).
Sorry to be nit-picky, but software released under the Apache 2.0 _is_ also free/libre software. Free software ≠ copylefted software (the latter is, approximately, a subset of the former). In most cases (vast majority?), Open Source software (as defined by the OSI) is also Free (as defined by the FSF).
> In most cases (vast majority?), Open Source software (as defined by the OSI) is also Free (as defined by the FSF).
It is a bit tricky here. Based on the situation, the same software can be some times be open source AND free software, or open source only (ie, not free software).
Eg: Linux kernel. When it is run on your computer, usually it is mostly free-software (linux-libre would be fully free). When it is run on your router, they (vendor) shall give you the source code, but may not allow you to modify it. This is violation of freedom 1 (The freedom to study how the program works, and change it so it does your computing as you wish). Then it won't be a free software, but just open source. You can't even confirm whether the source code they gave corresponds to the binary run in the router.
Thanks for the reference, I missed that section! 300 lines, so mostly scripts that this recommendation applies to. That's not 'small projects' if you ask me.
Rare exceptions include CC0 and WTFPL, which are not OSI-approved and thus are free software licenses but maybe not open source licenses, and Artistic 1.0, which is not FSF-approved and thus open source but not free software.
> I like the MIT/BSD licenses. Short, clear, understandable.
We might think short lines are clear and understandable and the best. But that is just for us. When it comes to law(yers), it might be interpreted in extremely insane ways.
So the terms has to be explicit, and this is why GPL/Apache have very long lines, stating each detail explicitly.
Have you ever seen any serious EULA for any proprietary software (or service) short and clear?
The "wall of legalese" is what ensures that you are protected from lawsuits. MIT/BSD licenses are shorter because they are more vague. That vagueness means they are easier to read, but harder to understand the implications of.
- GPL wants to care about the users, but actually cares only about those who install the software on their computer. Back then, these groups were identical, but in the time of remote applications (web apps, services, etc.) this means: The owner of the server, not the end user, receives the rights granted by GPL.
- AGPL actually does care about the users, no matter how they interact with your application. The rights given by the AGPL are granted to everybody down the chain.
Of course, this line of thinking only applies if you want a strong copyleft license. If you want non-copyleft, e.g. for very small projects, just stick with the ISC license (which is a more modern and slightly shorter version of MIT license).