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).

The FSF recommends Apache 2.0 for small projects where the hassle of free software is not worth it.

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.

> When it is run on your router, they (vendor) shall give you the source code, but may not allow you to modify it.

not at all true.. not being able to easily modify the binaries on your router is not the same as modifying the code which they distributed to you..

it is a license for the source code - not the runtime application of the source code.

> not at all true.. not being able to easily modify the binaries on your router is not the same as modifying the code which they distributed to you..

> it is a license for the source code - not the runtime application of the source code.

That is a fundamental difference between "open source" and "free software".

See https://www.gnu.org/philosophy/free-sw.en.html, specifically the explanation of freedom 1.

You're right of course. I should have said "the hassle of copyleft".

That is not what the FSF writes.

According to https://www.gnu.org/licenses/license-recommendations.html :

> It is not worth the trouble to use copyleft for most small programs.

and they recommend Apache 2.0. What are you disagreeing with?

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.

The "wall of legalese" that is the Apache 2.0 license does not inspire confidence in me. I feel like I would need a law degree to understand it.

I like the MIT/BSD licenses. Short, clear, understandable.

> 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.

The linked post tries to channel the views of business, as I see them. My personal views on the licenses differ.

It's up to every publisher of open source software to weight business, community, personal, political, and other preferences to their taste in picking a form license. I tried to make big-co preferences more accessible, in a distilled form. Not to elevate them above all other concerns.

I agree. I always feel that the AGPL maintains the "spirit" of the GPL, namely that (external) users get the complete source code for the software they are using. In the past, external users physically got the software, hence the GPL's clause kicking in on "distribution", but the rise of SaaS means many don't, so the licence adapted.

Now there are those who always preferred the BSD-style over the GPL-style, which is fine. But I find it strange to prefer the GPL over the AGPL...

Except AGPL has very few resources and is incredibly unclear on what it actually covers. Mainly because of the huge conflict of interest that the few adopters have with their commercial dual-license.

E.g.

- I have a database.

- I have a closed-source website that uses this database

- I have an APGL service that uses this database

Do I have to opensource the website? APGL companies say yes.

MongoDB is the exception that says "no".

Every hypothetical I've seen addressed with the AGPL involves a company running a server for users and then modifying that server and having to give the code to those users. But rarely is anything that clear: if I have a task queue that processes internal jobs, do I need to provide the code to end-users? Or are the "clients" just my app and the queue workers? If I don't, can't the whole AGPL be trivially circumvented with a reverse proxy?

I would give the AGPL more than three "?"s.

I thought the AGPL only applied to modifications of the AGPL'd software? E.g. you'd have to open source any modifications of the AGPL service you make.

Yes, but to "modify" under the definition of GPL (which AGPL extends) includes linking.

Which is why the weaker LGPL excludes linking, AGPL is stronger, so definitely includes linking.

How does the concept of linking translates to a deployed database that is interfaced using some SQL endpoint or REST service?

Except those pioneering web-services companies which provide AGPL code for their services but require copyright attribution to contribute to the main tree and at the same time maintain a proprietary paid version. In this case, they essentially prohibit anyone else from running a similar business - since the founders will have the leading edge on the 'main fork', and competitors can't maintain their own private paid versions, business competition will always be playing catch up to them.

This particular use case is where the implicit dualism of GPL software-centricity (vs people-centricity) falls apart/becomes absurd in my opinion - yes, the OSS version of the software is 'always free as in libre', but it is also always controlled by a creating entity who is using the license to create a defacto monopoly on it's commercial use, so the people are always beholden in some sense to the original code owners.

Free software is not about the right to contribute to the main tree or about the right to compete with businesses on equal footing, it's about the rights of the user to use, modify and distribute the software and derivatives as they see fit.