Expand the default set of licenses in PREFERRED_LICENSES

[wolftune]

Currently, PREFERRED_LICENSES lists only Apache-2.0 and MIT

I imagine that comes from an opinion from some parts of the developer community that opposes copyleft licensing. However, it would be more neutral for Gitea to start with a full set of the common licenses from https://choosealicense.com/ (which is linked anyway), and if particular Gitea instances want to limit the preferences, they can do so.

I suggest the default be AGPL-3.0-or-later,GPL-3.0-or-later,LGPL-3.0-or-later,Apache-2.0,MIT,BSD-3-Clause,CC-BY-SA-4.0,CC-BY-4.0,CC0-1.0

That list is a set of licenses that are all officially recognized as free by the main organizations in this space (FSF, OSI, CC, and others), they are all the latest versions, and this particular set is all compatible (any mix of repos using any of these licenses can be combined in derivatives). This list is close to the one at https://choosealicense.com/licenses/ (and in comparable order) with https://choosealicense.com/non-software/ added to the end. I omitted the MPL (compatibility issues) and added BSD-3 (just common use) and didn't include Boost (not sure why choosealicense highlights it, I guess the point is like MIT but zero requirement of license notice for binaries) or Unlicense.

Whatever the final choice, I think the default file should not be only Apache and MIT.

[sthagen]

Adding I think is good.
Not so sure on some of the presented.
For source code I do not see any CC like licenses to be a common or safe choice.

In any case, as a user I expect such list ordered alphabetically.

Also, as long as we are not the FSF itself we should be able to select GPL-2.0 and possibly LGPN-2.1.

So maybe (for code, we should no mix a list that confuses):

1. AGPL-3.0-or-later
2. Apache-2.0
3. BSD-3-Clause
4. GPL-2.0-only
5. GPL-3.0-or-later
6. LGPL-3.0-or-later
7. MIT

Update: Fixed GPL-2.0 as GPL-2.0-only (I did not look up the SPDX terms ... best effort from memory) in sync with the Codeberg ticket at https://codeberg.org/Codeberg/Community/issues/1393#issuecomment-1410179

[wolftune]

CC licenses are indeed not for executable code, but people use Git repos for things other than code. CC licenses are the correct choice for things in natural language.

I think semantic and related order is better than alphabetic as long as the list is short enough. But also, if it is short enough, then it doesn't really matter about the order. But like I support having the free CC licenses and putting them at the end.

On GPL-2.0, I won't get into discussing the perspectives here, but making it GPL-2.0-or-later would seem appropriate given a goal of copyleft with still maximizing compatibility.

To avoid some drawn-out licensing discussion, I will emphasize that choosealicense had its own extensive discussion to end up where it is, and leaning toward defaulting to its set of suggested licenses is a good neutral approach.

[sthagen]

@wolftune I fixed my naive use of the GPLv2 code to the intended GPL-2.0-only (which would be compatible with eg. the "Linux kernel" position). GPL-2.0-or-later to me non-lawyer is (at least in 2023-or-later) only a GPL-3.0-in-disguise. As others have hinted: Licensing is not a topic well decided or dominantly steered by simply lobbying a specific list of candidates.

To be clear: Offering only two licenses is clearly not very user friendly, so the proposal to add more licenses to me is very welcome.

[wolftune]

@sthagen GPL-2.0-or-later is perfectly compatible with the Linux kernel. Any code under that license can be used in Linux. The complete package is GPL-2.0-only, and the part licensed GPL-2.0-or-later is code that is allowed to be itself used in a GPL-3.0 project. GPL-2.0-or-later covers all the cases of maximizing the capacity to use the code in derivative works (while still being copyleft at all). GPL-2.0-only means the same in terms of usability in the kernel but would block the use of the same code within some GPL-3.0 project.

So, it's not true that GPL-2.0-or-later is GPL-3.0 in disguise. GPL-3.0 cannot be used in the kernel.

[sthagen]

@wolftune maybe I was unclear. Sorry, for that. GPL-3.0 is different from GPL-2.0 which disguises what we usually make explicit by giving a different name not faking "upgrade" by a version number increase.

Any repository granting a license GPL-2.0-or-later is ambiguous which in my understanding a license grant should not be.

Sometimes people argue that you should even use GPL-3.0-or-later (albeit no v4 exists yet) to "receive" upgrades automatically from the upstream group that might push out a GPL-4.0 ...
I do not think anyone should want automatic upgrades on licenses done by others they themselves grant. But there is a lot of diversity in the world ...

In my little world there is no need nor use for clever license texts to defend against enterprise or corporations as propaganda states. It is all people.

A license should be simple, short, and immutable.

Sometimes we forget that everything we give, we also let go.
That, to me is the essence for open source development.

So, when someone says: "I issue my code under the GPL-2.0 and I do so because this is tit for tat", than this becomes reality, no matter what some writer of the GPL-2.0 thought or felt or intended while forming the text.

People use things not only what the supplier of the thing intended it for, but instead where they think these are useful for.

[wolftune]

@sthagen your views are based on a fundamental (though very common) misunderstanding.

"I issue my code under the GPL-2.0 and I do so because this is tit for tat"

Despite Torvalds and others asserting this, it is wrong both legally and in terms of the intent of the license. If it were a tit-for-tat license, then it would be more sensible to argue that GPL-3.0 is something else. But GPL-2.0 is not tit-for-tat. You can go read it again and see.

If you give me code under GPLv2, I have no obligation under the license to share with anyone any changes I make. I also, I no obligation to share any changes with you even if I do share them with others. The obligation I have is that I must pass on the freedoms via the license and source code to anyone who I choose to share any of the software with.

The entire GPL suite are strictly pass-it-forward licenses, and those clauses only apply if I convey the software to others. I am allowed to keep my changes private.

The argument about whether to trust GNU and FSF in terms of future potential GPLv4 changes is not affected by your misunderstanding, but your sense that they betrayed trust in the roll-out of GPLv3 is rooted in your misunderstanding. There was nothing sneaky or faked in GPLv3, it simply addressed issues that GPLv2 had, reinforcing the original intention of GPLv2 which was always explicit in the direct text of GPLv2 itself. It fixed ambiguities and issues, in the same way that updated versions of Creative Commons licenses have done, while keeping the intended meaning all along.

no need nor use for clever license texts to defend against enterprise or corporations as propaganda states

Without getting into the politics of this assertion or the practical questions of power and law and whatever, the GPL suite does not discriminate in any way against any institutions, there is no limitations that treat enterprises, corporations, or states differently from anyone else. This is equally true for all GPL versions.

People use things not only what the supplier of the thing intended it for, but instead where they think these are useful for.

Yes, and so the misunderstanding of GPL as tit-for-tat is sort of sensible because despite it explicitly not being the intention nor the manner of operation, it usually (but not always) works that you might have some way of getting back upstream changes that others make and share downstream. A company might modify Linux kernel in their product, and product customers get the mofications under GPL, and someone could find out about it and find a way to get the changes and then submit them back to mainline kernel, but this is not guaranteed or required by the license and it does not always happen.

Another example you aren't describing: companies use GPL knowing that their customers would like to be freed from the pass-forward requirements, and so they offer a proprietary license instead if people pay for it (and to keep the power to do this, they use a CLA for any outside GPL contributions). This practice uses the license but goes against the intention of the license. If somehow GPLv4 found some legal way to block that style of non-free-software dual-licensing, those companies could argue that it was a totally different license and violates what GPL stood for, but they would just be wrong. That use of GPL is not what it ever stood for. At any rate, that's just rhetorical because I don't think there is possible any way to block that type of dual licensing in an otherwise free license.

Indeed, it's not crazy to say that GPL-2.0-only makes sense for "I'm using this as tit-for-tat even though that's not really how it works, and I don't care about freedom for end-users" and GPL-N-or-later makes sense for "I support the FSF/GNU style care about protecting freedom for users". And it's feasible to argue that the former is just as valid a position for someone to hold. It would be good not to stretch it too far into arguing that allowing Tivoization is a stronger position for freedom, but there is a somewhat dogmatic, principled, and inherently consistent anti-copyright version of licensing opinions that opposes copyleft entirely, as exemplified by https://copyfree.org/

[sthagen]

@wolftune:

[...] Indeed, it's not crazy to say that GPL-2.0-only makes sense for "I'm using this as tit-for-tat even though that's not really how it works, and I don't care about freedom for end-users" [...]

Sure. We can agree on that and thus (without the trailing "and I don't care about freedom for end-users" propaganda) this is the essence what makes the text of the GPL-2.0 for some still a valid choice in the real world.

Thus, the rest of the text in #28661 (comment) to me is covered already by:

People use things not only what the supplier of the thing intended it for, but instead where they think these are useful for.

I am curious how the gitea/forgejo people evolve their project but I have no real stakes in that.

[wolftune]

@sthagen specifically on this licensing question, there's this issue then: for those who want the imperfect alternate use of GPLv2 for a goal of tit-for-tat, using -or-later does mean that if someone puts their derivative under GPLv3, then that is less effective tit-for-tat (they can't bring that back into the GPL-2.0-or-later project without changing the project to GPLv3 overall). That doesn't mean anything about GPLv3 being a different license rather than a revision or anything else, it just acknowledges that license compatibility is an issue. And that is a problem with copyleft in general, and one of the arguments from the copyfree people on their position.

Quite simply, it is a sensible enough position to suggest including GPL-2.0-only as a preferred license if the goal is to support people using it in a tit-for-tat manner and wanting compatibility with specific GPL-2.0-only projects. However, even for tit-for-tat, AGPLv3 is stronger. If the motivation is true tit-for-tat, there exist non-free licenses that say that all changes must be shared upstream and not even allowing changes to stay private. FWIW, I'm more okay with the rhetoric of saying some people's main goal is tit-for-tat than the rhetoric that argues that tit-for-tat is about freedom.

In terms of -or-later in general, it does involve trust and has some risk there, but the trustworthiness has been kept when it comes to GNU prioritizing freedom. So, someone who cares about users in the world having software freedom can reasonably go with -or-later more than someone whose priority is tit-for-tat for developers. Maybe "don't care" is exaggerated, but when Torvalds says he supports Tivoization rather than opposes it, he is taking a stance on prioritizing corporate power over the users having freedom with their devices. He cares about Linux getting Tivo's code updates. He doesn't seem to care about Tivo owners being able to modify their Tivos.