Update PREFERRED_LICENSES and full license list to match Codeberg's Terms and Docs #1393

wolftune commented 2023年12月30日 17:29:19 +01:00

https://codeberg.org/repo/create currently shows a massive list of licenses to pick from in the dropdown for the License field.

That list starts with Apache-2.0 and MIT because those are the two items listed in PREFERRED_LICENSES which is inherited from Gitea.

Forgejo discussion at forgejo/forgejo#1404 mentions also the issue of what other licenses are listed (if any) after the preferred ones.

This updated to preferred licenses could be resolved at Forgejo (or even upstream at Gitea, https://github.com/go-gitea/gitea/issues/28661).

However, it is essential for Codeberg to fix this directly in order to (A) align with Codeberg's own Terms and documentation and (B) unambiguously pass the GNU criteria to get listed with a B grade at https://www.gnu.org/software/repo-criteria-evaluation.html (Codeberg review for official GNU endorsement is currently under way)

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

This list matches the the suggestions at https://docs.codeberg.org/getting-started/licensing

Also, this list is all completely compatible (anything with these licenses can be legally combined). Also, Codeberg would be downgraded by GNU if it recommended GNU-N-only versions or recommended other licenses over GPL.

https://codeberg.org/repo/create currently shows a massive list of licenses to pick from in the dropdown for the License field. That list starts with Apache-2.0 and MIT because those are the two items listed in `PREFERRED_LICENSES` which is inherited from Gitea. Forgejo discussion at https://codeberg.org/forgejo/forgejo/issues/1404 mentions also the issue of what other licenses are listed (if any) after the preferred ones. This updated to preferred licenses *could* be resolved at Forgejo (or even upstream at Gitea, https://github.com/go-gitea/gitea/issues/28661). However, it is essential for Codeberg to fix this directly in order to (A) align with Codeberg's own Terms and documentation and (B) unambiguously pass the GNU criteria to get listed with a B grade at https://www.gnu.org/software/repo-criteria-evaluation.html (Codeberg review for official GNU endorsement is currently under way) I suggest the listing be `AGPL-3.0-or-later,GPL-3.0-or-later,LGPL-3.0-or-later,Apache-2.0,MIT,CC-BY-SA-4.0,CC-BY-4.0,CC0-1.0` This list matches the the suggestions at https://docs.codeberg.org/getting-started/licensing Also, this list is all completely compatible (anything with these licenses can be legally combined). Also, Codeberg would be downgraded by GNU if it recommended GNU-N-only versions or recommended other licenses *over* GPL.

sthagen commented 2023年12月30日 18:04:43 +01:00

I think Apache-2.0 and MIT are indeed the most simple to understand for people creating a repository and having no idea what license to pick. I think suggesting to such users highly intrusive licenses as the GPL-3.0-or-later and friends should not be our business. Some person picking randomly the GPL-3.0-or-later and then trying to revise that later - would that have been good advice?

I commented on the gitea issue "Expand the default set of licenses in PREFERRED_LICENSES #28661" (reported by @wolftune I assume) and for ease of reference my suggested / amended list for a source code centered offering like Codeberg I repeat here:

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

On the to me new endeavor to get some kind of an FSF rating for Codeberg as a service:

Question: Are we really sure, that we as Codeberg e.V. do want to change to match some ideals of the FSF (which we are definitely not and we may not share the ideas)?

I see sourcehut for example with a B rating "there" and to me "irritating" reasons on why not grade as "A" e.g. at https://www.gnu.org/software/repo-criteria-evaluation.html#sr-ht

Service description mentions: "Runs fully virtualised builds on various Linux distros and BSDs."

instead of

Service description mentions: "Runs fully virtualised builds on various GNU/Linux distros and BSDs."

So IMO, the "problems" that block us from being grade "B" by that other organization (or server thereof) remind me of hours spent by software engineers to purely please some prescribed linters in the daily enterprise madness.

I am only one part of Codeberg e.V. but that little part does not want to be doing marketing for the FSF (as an organization).
I was once a member of the FSF, not any more, but I am a happy member of Codeberg e.V.

Update: Fixed GPL-2.0 as GPL-2.0-only (I did not look up the SPDX terms ... best effort from memory)

I think Apache-2.0 and MIT are indeed the most simple to understand for people creating a repository and having no idea what license to pick. I think suggesting to such users highly intrusive licenses as the GPL-3.0-or-later and friends should not be our business. Some person picking randomly the GPL-3.0-or-later and then trying to revise that later - would that have been good advice? I commented on the gitea issue "[Expand the default set of licenses in PREFERRED_LICENSES #28661](https://github.com/go-gitea/gitea/issues/28661#issuecomment-1872563199)" (reported by @wolftune I assume) and for ease of reference my suggested / amended list for a source code centered offering like Codeberg I repeat here: 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 On the to me new endeavor to get some kind of an FSF rating for Codeberg as a service: Question: Are we really sure, that we as Codeberg e.V. do want to change to match some ideals of the FSF (which we are definitely not and we may not share the ideas)? I see sourcehut for example with a B rating "there" and to me "irritating" reasons on why not grade as "A" e.g. at <https://www.gnu.org/software/repo-criteria-evaluation.html#sr-ht> > Service description mentions: "Runs fully virtualised builds on various Linux distros and BSDs." instead of >Service description mentions: "Runs fully virtualised builds on various GNU/Linux distros and BSDs." So IMO, the "problems" that block us from being grade "B" by that other organization (or server thereof) remind me of hours spent by software engineers to purely please some prescribed linters in the daily enterprise madness. I am only one part of Codeberg e.V. but that little part does not want to be doing marketing for the FSF (as an organization). I was once a member of the FSF, not any more, but I am a happy member of Codeberg e.V. Update: Fixed GPL-2.0 as GPL-2.0-only (I did not look up the SPDX terms ... best effort from memory)

wolftune commented 2023年12月30日 18:14:00 +01:00

@sthagen while I am assisting the FSF/GNU in some of this work, I am an independent volunteer and happen to agree with you about the pickiness of some of the criteria. I argued for the picky terminology being more tolerant or at least at the A+ level not the A level and so on. (E.g. I personally use "FLO" for "Free/Libre/Open" for everything I'm involved in, despite FSF/RMS not liking that; I've also argued against RMS' use of non-free ND licenses for his writings). I do not think Codeberg should have any absolute deference to FSF, but considering the points and accommodating FSF/GNU is still a good practice in solidarity, and some of the values are very strongly overlapping.

we as Codeberg e.V. do want to change to match some ideals of the FSF (which we are definitely not and we may not share the ideas)?

Put simply, I do not necessarily think Codeberg should change to match FSF ideals in cases where there's disagreement. The decisions should be primarily based on what is ethical and good and not on blind deference. But where it is trivial and presents no conflicts to be accommodating, it can be worthwhile to do.

At any rate, it is already the case that Codeberg does not (and I suggest ought not) take a position of directing people to prefer Apache or MIT.

https://docs.codeberg.org/getting-started/licensing/ is excellent and starts with helping people understand the question of whether they want licenses that ensure the freedoms are maintained.

It makes sense for the dropdown list to mirror the Codeberg documentation. This is about consistency with Codeberg's already-decided values as much or more than deferring to FSF. For any item in the GNU criteria, if Codeberg consciously disagrees (e.g. keeping using the term"open source" in places), that is different from just not considering something. In this issue here, there's no disagreement.

This issue here is not a place to debate preference for copyleft licenses or argue that we should steer people toward Apache and MIT. Codeberg already has boldly stated and agreed as an organization to prefer copyleft and to support exactly the list of licenses I mentioned at the top here, and in that order as well. The issue here is merely a matter of making the UI match the existing position of the organization.

@sthagen while I am assisting the FSF/GNU in some of this work, I am an independent volunteer and happen to agree with you about the pickiness of some of the criteria. I argued for the picky terminology being more tolerant or at least at the A+ level not the A level and so on. (E.g. I personally use "FLO" for "Free/Libre/Open" for everything I'm involved in, despite FSF/RMS not liking that; I've also argued against RMS' use of non-free ND licenses for his writings). I do not think Codeberg should have any absolute deference to FSF, but considering the points and accommodating FSF/GNU is still a good practice in solidarity, and some of the values are very strongly overlapping. > we as Codeberg e.V. do want to change to match some ideals of the FSF (which we are definitely not and we may not share the ideas)? Put simply, I do not necessarily think Codeberg should change to match FSF ideals in cases where there's disagreement. The decisions should be primarily based on what is ethical and good and not on blind deference. But where it is trivial and presents no conflicts to be accommodating, it can be worthwhile to do. At any rate, it is already the case that Codeberg does *not* (and I suggest ought not) take a position of directing people to prefer Apache or MIT. https://docs.codeberg.org/getting-started/licensing/ is excellent and starts with helping people understand the question of whether they want licenses that ensure the freedoms are maintained. It makes sense for the dropdown list to mirror the Codeberg documentation. This is about consistency with Codeberg's already-decided values as much or more than deferring to FSF. For any item in the GNU criteria, if Codeberg *consciously* disagrees (e.g. keeping using the term"open source" in places), that is different from just not considering something. In *this* issue here, there's no disagreement. This issue here is *not* a place to debate preference for copyleft licenses or argue that we should steer people toward Apache and MIT. Codeberg already has *boldly* stated and agreed as an organization to *prefer* copyleft and to support exactly the list of licenses I mentioned at the top here, and *in that order* as well. The issue here is merely a matter of making the UI match the existing position of the organization.

sthagen commented 2023年12月30日 18:18:14 +01:00

@wolftune:

[...]
At any rate, it is already the case that Codeberg does not (and I suggest ought not) take a position of directing people to prefer Apache or MIT.

https://docs.codeberg.org/getting-started/licensing/ is excellent and starts with helping people understand the question of whether they want licenses that ensure the freedoms are maintained.
[...]

The other points OK, but these two, I do object to, and there is still discussion on the https://docs.codeberg.org/getting-started/licensing/ page as it exposes an agenda which I do not see as a Codeberg e.V. agenda.

@wolftune: > [...] > At any rate, it is already the case that Codeberg does *not* (and I suggest ought not) take a position of directing people to prefer Apache or MIT. > > https://docs.codeberg.org/getting-started/licensing/ is excellent and starts with helping people understand the question of whether they want licenses that ensure the freedoms are maintained. > [...] The other points OK, but these two, I do object to, and there is still discussion on the <https://docs.codeberg.org/getting-started/licensing/> page as it exposes an agenda which I do not see as a Codeberg e.V. agenda.

fnetX commented 2023年12月30日 18:34:24 +01:00

This comment represents my own opinion:

In my eyes, the licensing topic is far more complex than the dropdown. I think we can go ahead and modify the dropdown, either by adding preferred licenses on the top (I'd vote for copyleft licenses here), and restricting non-free ones (including CC-x-NC/ND). Config pulls can go to https://codeberg.org/Codeberg-Infrastructure/build-deploy-forgejo/.

I recently fixed a bug with this specific setting in forgejo/forgejo#1888, and decided against immediately applying a different set for Codeberg, mostly because licensing is something that needs good understanding.

At Codeberg, we reach out to people when we notice that a repository has no correct free license. What people do then is that they add a (random) license. But sometimes, the code is technically still proprietary, because it is copied from somewhere. The funniest thing was that we recently investigated an abusive repo where the copyright holder in the license file was a well-known member of the Codeberg community. Why? Because after being flagged for missing a license, they probably opened a random repository from the explore tab and copied the file over, including the copyright holder.

We do not want spammers etc to quickly add a license when creating the repo. After all, it does not prevent ambiguous licensing. We want to educate people about how to properly apply a license and have it unambiguously cover all part of the work, ideally promoting the use of REUSE.

This requires good education. Recently, there was the idea to revamp the repo creation screen, and I'd be in favour of implementing reuse compliance monitoring for a repo instead of adding a new license picker that just slams a file in the repo, which people will even use when they copy code from somewhere.

This comment represents my own opinion: In my eyes, the licensing topic is far more complex than the dropdown. I think we can go ahead and modify the dropdown, either by adding preferred licenses on the top (I'd vote for copyleft licenses here), and restricting non-free ones (including CC-x-NC/ND). Config pulls can go to https://codeberg.org/Codeberg-Infrastructure/build-deploy-forgejo/. I recently fixed a bug with this specific setting in https://codeberg.org/forgejo/forgejo/pulls/1888, and decided against immediately applying a different set for Codeberg, mostly because licensing is something that needs good understanding. At Codeberg, we reach out to people when we notice that a repository has no correct free license. What people do then is that they add a (random) license. But sometimes, the code is technically still proprietary, because it is copied from somewhere. The funniest thing was that we recently investigated an abusive repo where the copyright holder in the license file was a well-known member of the Codeberg community. Why? Because after being flagged for missing a license, they probably opened a random repository from the explore tab and copied the file over, including the copyright holder. We do not want spammers etc to quickly add a license when creating the repo. After all, it does not prevent ambiguous licensing. We want to educate people about how to properly apply a license and have it unambiguously cover all part of the work, ideally promoting the use of REUSE. This requires good education. Recently, there was the idea to revamp the repo creation screen, and I'd be in favour of implementing reuse compliance monitoring for a repo instead of adding a new license picker that just slams a file in the repo, which people will even use when they copy code from somewhere.

wolftune commented 2023年12月30日 18:49:23 +01:00

It seems ideal to me that there be a managed set of licensing-related items such as:

• Terms
• Docs
• PREFERRED_LICENSES for the dropdown

And any other I don't know about

And whatever happens with licensing discussions and decisions into the future, it would be good to know what areas to keep maintained for consistency. Right now, Terms and Docs are consistent, and this issue is about bringing the UI into alignment.

It seems ideal to me that there be a managed set of licensing-related items such as: - Terms - Docs - PREFERRED_LICENSES for the dropdown And any other I don't know about And *whatever* happens with licensing discussions and decisions into the future, it would be good to know what areas to keep maintained for consistency. Right now, Terms and Docs are consistent, and this issue is about bringing the UI into alignment.

n0toose commented 2023年12月31日 20:52:37 +01:00

Also, this list is all completely compatible (anything with these licenses can be legally combined). Also, Codeberg would be downgraded by GNU if it recommended GNU-N-only versions or recommended other licenses over GPL.

From my perspective GNU-N-only or or-later is basically about how much control and trust you'd give to the GNU project. I am not sure if Codeberg should tell users to make that decision blindly, but I would be much more receptive towards a link to the documentation that explains the difference, mentions this perspective and why the GNU project recommends the practices it does (and who doesn't) and let users make a calculated decision. I would even consider building such an explanation into the UI.

I think that this solution would align with our goals - we have an implicit role in educating people how to choose what works best for them instead of choosing it for them, no matter if it's GNU vs. MIT or "N-only" or "later". However, personally, I would still keep the "N-only" variant on the simple basis that it is allowed on the platform. Do you think that this would be an acceptable middle ground?

An explicit downgrade of "N-only" in favor of "later" as a one-off-exception should presumably require internal discussions and possibly a vote, which are a lot of resources on our end.

> Also, this list is all completely compatible (anything with these licenses can be legally combined). Also, Codeberg would be downgraded by GNU if it recommended GNU-N-only versions or recommended other licenses over GPL. From my perspective `GNU-N-only` or `or-later` is basically about how much control and trust you'd give to the GNU project. I am not sure if Codeberg should tell users to make that decision blindly, but I would be much more receptive towards a link to the documentation that explains the difference, mentions this perspective and why the GNU project recommends the practices it does (and who doesn't) and let users make a calculated decision. I would even consider building such an explanation into the UI. I think that this solution would align with our goals - we have an implicit role in educating people how to choose what works best for them instead of choosing it for them, no matter if it's GNU vs. MIT *or* "N-only" or "later". However, personally, I would still keep the "N-only" variant on the simple basis that it is allowed on the platform. Do you think that this would be an acceptable middle ground? An explicit downgrade of "N-only" in favor of "later" as a one-off-exception should presumably require internal discussions and possibly a vote, which are a lot of resources on our end.

wolftune commented 2023年12月31日 21:59:16 +01:00

we have an implicit role in educating people how to choose what works best for them instead of choosing it for them

I would adapt that. The implicit role is indeed in educating people but not on "what works best for them" but on what is most ethical for society. That does not mean compelling them to make certain choices, it does not mean choosing it for them necessarily. But the role is not whatever is best for the isolated interest of each user. If what works "best for them" is a proprietary license, Codeberg's role is to educate them about the importance of software freedom and supporting a pro-social attitude that cares about what choices are good for the world. Educating people about why they should choose free licensing instead.

You might fully agree with me already, I'm not assuming what you think. However, there are people who do indeed use "best for them" arguments to defend the idea that organizations should be neutral on all these things. Like true neutral-point-of-view, just stating the raw facts of what licenses are etc. And some of those people take this neutral position in order to defend the choice to use proprietary licenses. Codeberg is not neutral on these things. Codeberg has an explicit stance for software freedom.

Codeberg does not block repos from using GNU-N-only licensing, the question is whether to present it as equally recommended as -or-later versions. The GNU project explicitly asks Codeberg to prefer -or-later. Codeberg as a community can grant that request or reject it or take some nuanced middle-ground. [EDIT: and however the docs got written, that decision was aligned with GNU, so some decision of that sort has already happened, though it could be changed obviously, though I would not support changing it]

My suggestion is that PREFERRED_LICENSES include the -or-later versions only but the full license list (which itself needs updating to at least conform to Codeberg Terms should include -n-only versions.

I'm personally more neutral on the inclusion of GPL-2.0-or-later in preferred (as opposed to only listing GPL-3.0-or-later). Suggesting that people consider 2.0 is awkward in terms of taking a position against GPLv3 (which I see no basis for; the only people, like Linus Torvalds, who oppose GPLv3 are doing so because they don't like the way it favors user freedom over business goals) — but it is sensible if based on the focus of compatibility, highlighting GPL-2-or-later because it is more backwards-compatible with older projects that use GPLv2. So, I would suggest that if GPLv2 of any sort is included in a recommended list, it be explicitly stated as for the sake of backwards-compatibility.

At any rate, https://docs.codeberg.org/getting-started/licensing/ does not recommend GPLv2 nor any -n-only licensing right now, and changing that is a different issue, a different topic, than making the PREFERRED_LICENSES list match the Codeberg docs. Again, whatever happens, if the positions change, these parts of the system should be changed consistently together. We shouldn't use the fact that one part got attention and the other is merely inherited from Gitea as a place to debate the whole overall topic. We can separate site-consistency from the question of licensing preferences.

> we have an implicit role in educating people how to choose what works best for them instead of choosing it for them I would adapt that. The implicit role is indeed in educating people but *not* on "what works best for them" but on what is most ethical for society. That does not mean compelling them to make certain choices, it does not mean choosing it for them necessarily. But the role is not whatever is best for the isolated interest of each user. If what works "best for them" is a proprietary license, Codeberg's role is to educate them about the importance of software freedom and supporting a pro-social attitude that cares about what choices are good for the world. Educating people about why they should choose free licensing instead. You might fully agree with me already, I'm not assuming what you think. However, there are people who do indeed use "best for them" arguments to defend the idea that organizations should be neutral on all these things. Like true neutral-point-of-view, just stating the raw facts of what licenses are etc. And some of those people take this neutral position in order to defend the choice to use proprietary licenses. Codeberg is *not* neutral on these things. Codeberg has an *explicit* stance for software freedom. Codeberg does not block repos from using GNU-N-only licensing, the question is whether to present it as equally recommended as -or-later versions. The GNU project explicitly asks Codeberg to prefer -or-later. Codeberg as a community can grant that request or reject it or take some nuanced middle-ground. [EDIT: and however the docs got written, that decision was *aligned* with GNU, so some decision of that sort has already happened, though it could be changed obviously, though I would not support changing it] My suggestion is that `PREFERRED_LICENSES` include the -or-later versions only *but* the full license list (which itself needs updating to at least conform to Codeberg Terms should include -n-only versions. I'm personally more neutral on the inclusion of GPL-2.0-or-later in preferred (as opposed to only listing GPL-3.0-or-later). Suggesting that people consider 2.0 is awkward in terms of taking a position against GPLv3 (which I see no basis for; the only people, like Linus Torvalds, who oppose GPLv3 are doing so because they don't like the way it favors user freedom over business goals) — but it is *sensible* if based on the focus of *compatibility*, highlighting GPL-2-or-later because it is more backwards-compatible with older projects that use GPLv2. So, I would suggest that *if* GPLv2 of any sort is included in a recommended list, it be explicitly stated as for the sake of backwards-compatibility. At any rate, **https://docs.codeberg.org/getting-started/licensing/ does not recommend GPLv2 nor any -n-only licensing right now**, and changing that is a different issue, a different topic, than making the `PREFERRED_LICENSES` list match the Codeberg docs. Again, whatever happens, if the positions change, these parts of the system should be changed consistently together. We shouldn't use the fact that one part got attention and the other is merely inherited from Gitea as a place to debate the whole overall topic. We can separate site-consistency from the question of licensing preferences.

sthagen commented 2023年12月31日 22:15:39 +01:00

Just to ensure the obvious is stated (risking to be perceived as repetitive): https://www.youtube.com/watch?v=PaKIZ7gJlRU the answer of Linus to the question at the beginning (after ads of course) - the transcript is kind of OK to read.

GPL-2.0 is an OSI approved license and very popular.

GPL-2.0-only solely deprecates the SPDX identifier GPL-2.0 because of clarity (I assume).

Not necessarily important to others, but I do share the assessment of Linus Tovalds in his above linked "videographed" answer to an audience question: FSF should have never claimed GPL-3.0 is a version upgrade to GPL-2.0, when instead it is a completely different license. They should have chosen a new name.

Let us not suggest a fictitious but well named "positive" YES-2.0 license can be made into a "negative" YES-3.0 license that requires fundamental aspects on the contrary. We would have expected an honest NO-1.0 instead.

To me the GNU tools were brought to us by open and creative software developers, not by lawyers or organizations.

Any service offering code hosting that would suggest to not license our projects as the Linux Kernel to me would exclude part of an open and creative community as many implementations we provide are based on linux kernel, linux distributions, and the binary compatibility per libc/musil.

Just to ensure the obvious is stated (risking to be perceived as repetitive): <https://www.youtube.com/watch?v=PaKIZ7gJlRU> the answer of Linus to the question at the beginning (after ads of course) - the transcript is kind of OK to read. [GPL-2.0](https://opensource.org/license/gpl-2-0/) is an OSI approved license and very popular. [GPL-2.0-only](https://spdx.org/licenses/GPL-2.0-only.html) solely deprecates the SPDX identifier [GPL-2.0](https://spdx.org/licenses/GPL-2.0.html) because of clarity (I assume). Not necessarily important to others, but I do share the assessment of Linus Tovalds in his above linked "videographed" answer to an audience question: FSF should have never claimed GPL-3.0 is a version upgrade to GPL-2.0, when instead it is a completely different license. They should have chosen a new name. Let us not suggest a fictitious but well named "positive" YES-2.0 license can be made into a "negative" YES-3.0 license that requires fundamental aspects on the contrary. We would have expected an honest NO-1.0 instead. To me the GNU tools were brought to us by open and creative software developers, not by lawyers or organizations. Any service offering code hosting that would suggest to not license our projects as the Linux Kernel to me would exclude part of an open and creative community as many implementations we provide are based on linux kernel, linux distributions, and the binary compatibility per libc/musil.

wolftune commented 2023年12月31日 22:29:28 +01:00

There is no discussion about whether GPL-2.0 fits the accepted Terms. The question brought up here (though not the focus of this issue ticket) is only whether to promote it as a preferred license.

GPL-3.0 was developed by the same people who authored GPL-2.0 and it was updated specifically to respond to uses of GPL-2.0 that were not forseen such as Tivoization. The fact is, Torvalds does not think Tivoization is a problem because he explicitly does not particularly care about whether freedom reaches the downstream end-users. Torvalds explicitly likes that GPL is practically (though not strictly) functioning to bring changes back upstream so that developers get access to code changes. He cares about whether Linux gets updated code to pull back into the kernel. He doesn't care whether Tivo owners have control over their products. We can argue about the license details in themselves, but GPLv3 is very clearly an update to GPLv2 made by the same people (and same lawyers and organizations). The GNU tools are not the same thing as the GNU licenses.

For an organization to prefer GPLv3 is effectively for the org to say that they do care about blocking things like Tivoization, and perhaps that they wish Torvalds and others shared that ethical value. In order to indeed not exclude or be incompatible with Linux licensing, there is a reasonable position to support GPLv2 for the sake of inclusion but not because Torvald's arguments for it are correct. In fact, he is just flat-out-wrong about his understanding of GPLv2, it is not legally (nor intended to be) a license about sharing changes back upstream, it was always about passing the freedoms on downstream. He is just simply factually wrong here. Incidentally, I was in the room at the time of that video with Torvalds...

There is no discussion about whether GPL-2.0 fits the accepted Terms. The question brought up here (though not the focus of this issue ticket) is only whether to promote it as a preferred license. GPL-3.0 was developed by the same people who authored GPL-2.0 and it was updated *specifically* to respond to uses of GPL-2.0 that were not forseen such as Tivoization. The fact is, Torvalds does not think Tivoization is a problem because he explicitly does not particularly care about whether freedom reaches the downstream end-users. Torvalds explicitly likes that GPL is practically (though not strictly) functioning to bring changes back *upstream* so that developers get access to code changes. He cares about whether Linux gets updated code to pull back into the kernel. He doesn't care whether Tivo owners have control over their products. We can argue about the license details in themselves, but GPLv3 is very clearly an update to GPLv2 made by the same people (and same lawyers and organizations). The GNU tools are not the same thing as the GNU licenses. For an organization to prefer GPLv3 is effectively for the org to say that they *do* care about blocking things like Tivoization, and perhaps that they wish Torvalds and others shared that ethical value. In order to indeed not exclude or be incompatible with Linux licensing, there is a reasonable position to support GPLv2 *for the sake of inclusion* but not because Torvald's arguments for it are correct. In fact, he is just flat-out-wrong about his understanding of GPLv2, it is *not* legally (nor intended to be) a license about sharing changes back upstream, it was *always* about passing the freedoms on downstream. He is just simply factually wrong here. Incidentally, I was *in the room* at the time of that video with Torvalds...

sthagen commented 2023年12月31日 22:36:00 +01:00

@n0toose:

we have an implicit role in educating people how to choose what works best for them instead of choosing it for them

@wolftune

I would adapt that. The implicit role is indeed in educating people but not on "what works best for them" but on what is most ethical for society. [...]

A license is a grant from an owner to others. "Ethical for society" we may have world-wide working concepts in a century or never but I do see the only person deciding on the license the owner. When the license does not match the Codeberg e.V. statutes she will have to host her code elsewhere.

[...] Suggesting that people consider 2.0 is awkward in terms of taking a position against GPLv3 (which I see no basis for; the only people, like Linus Torvalds, who oppose GPLv3 are doing so because they don't like the way it favors user freedom over business goals) [...]

See my comment on YES-3.0 vs NO-1.0 and I perceive especially the part "the only people, like Linus Torvalds, who oppose GPLv3 are doing so because they don't like the way it favors user freedom over business goals" (cited) of the statement simply wrong and misleading.

Developer experience I see as the most important aspect in a world that is built on software created from real people often unsupported because they were bored, they could, or they "had to do it" for maintaining tools open to empower everyone to build on that or tailor to their needs.

— but it is sensible if based on the focus of compatibility, highlighting GPL-2-or-later because it is more backwards-compatible with older projects that use GPLv2. So, I would suggest that if GPLv2 of any sort is included in a recommended list, it be explicitly stated as for the sake of backwards-compatibility.
[...]

Please let us not mislead people asking for guidance into the thought, that GPL-2.0-or-later is anything else but YES-or-NO.

At any rate, https://docs.codeberg.org/getting-started/licensing/ does not recommend GPLv2 nor any -n-only licensing right now, and changing that is a different issue, a different topic, than making the PREFERRED_LICENSES list match the Codeberg docs. Again, whatever happens, if the positions change, these parts of the system should be changed consistently together. We shouldn't use the fact that one part got attention and the other is merely inherited from Gitea as a place to debate the whole overall topic. We can separate site-consistency from the question of licensing preferences.

My proposal is to keep as is and fix the narrow document on Codeberg e.V. pages that does offer GPLv3 but not GPLv2 (and also sells Apache-2.0 and MIT) as if these latter three were not perfectly legit, OSI compliant licenses that may be the best for the project they will grant rights and obligations to use for.

@n0toose: > > we have an implicit role in educating people how to choose what works best for them instead of choosing it for them @wolftune > I would adapt that. The implicit role is indeed in educating people but *not* on "what works best for them" but on what is most ethical for society. [...] A license is a grant from an owner to others. "Ethical for society" we may have world-wide working concepts in a century or never but I do see the only person deciding on the license the owner. When the license does not match the Codeberg e.V. statutes she will have to host her code elsewhere. > [...] Suggesting that people consider 2.0 is awkward in terms of taking a position against GPLv3 (which I see no basis for; the only people, like Linus Torvalds, who oppose GPLv3 are doing so because they don't like the way it favors user freedom over business goals) [...] See my comment on YES-3.0 vs NO-1.0 and I perceive especially the part "*the only people, like Linus Torvalds, who oppose GPLv3 are doing so because they don't like the way it favors user freedom over business goals*" (cited) of the statement simply wrong and misleading. Developer experience I see as the most important aspect in a world that is built on software created from real people often unsupported because they were bored, they could, or they "had to do it" for maintaining tools open to empower everyone to build on that or tailor to their needs. > — but it is *sensible* if based on the focus of *compatibility*, highlighting GPL-2-or-later because it is more backwards-compatible with older projects that use GPLv2. So, I would suggest that *if* GPLv2 of any sort is included in a recommended list, it be explicitly stated as for the sake of backwards-compatibility. > [...] Please let us not mislead people asking for guidance into the thought, that GPL-2.0-or-later is anything else but YES-or-NO. > At any rate, **https://docs.codeberg.org/getting-started/licensing/ does not recommend GPLv2 nor any -n-only licensing right now**, and changing that is a different issue, a different topic, than making the `PREFERRED_LICENSES` list match the Codeberg docs. Again, whatever happens, if the positions change, these parts of the system should be changed consistently together. We shouldn't use the fact that one part got attention and the other is merely inherited from Gitea as a place to debate the whole overall topic. We can separate site-consistency from the question of licensing preferences. My proposal is to keep as is and fix the narrow document on Codeberg e.V. pages that does offer GPLv3 but not GPLv2 (and also sells Apache-2.0 and MIT) as if these latter three were not perfectly legit, OSI compliant licenses that may be the best for the project they will grant rights and obligations to use for.

sthagen commented 2023年12月31日 22:48:30 +01:00

@wolftune when I say YES today and NO tomorrow, this update is clearly brought by the same person.

Different place of changes: I am in favor of promoting MIT, APACHE-2.0, LGPL-2.1-only, GPL-2.0-only, and GPL-3.0-or-later and in that order 😀

In our case here I suggest to keep the two indisputable licenses on that selection list and postpone any action here on a decision at the other place.

I do not believe anyone moving their code from not-Codeberg to Codeberg services will stop that migration because we have only an FSF C-rating instead of a B-rating (especially when reading the criteria distinguishing between the grades).

So, I propose to close the issue without further action (in that regard) and only reopen a new one in case agreement is found on the documentation on licenses at Codeberg.

Sometimes consistency is pushing a well-formed coalition out of consensus as it explicates statements better left for discussion only in the event they occur.

@wolftune when I say YES today and NO tomorrow, this update is clearly brought by the same person. Different place of changes: I am in favor of promoting MIT, APACHE-2.0, LGPL-2.1-only, GPL-2.0-only, and GPL-3.0-or-later and in that order 😀 In our case here I suggest to keep the two indisputable licenses on that selection list and postpone any action here on a decision at the other place. I do not believe anyone moving their code from not-Codeberg to Codeberg services will stop that migration because we have only an FSF C-rating instead of a B-rating (especially when reading the criteria distinguishing between the grades). So, I propose to close the issue without further action (in that regard) and only reopen a new one in case agreement is found on the documentation on licenses at Codeberg. Sometimes consistency is pushing a well-formed coalition out of consensus as it explicates statements better left for discussion only in the event they occur.

wolftune commented 2023年12月31日 23:27:09 +01:00

@sthagen the status quo is where a pop-up shows an enormous list of licenses including non-free ones that aren't even allowed here. That needs to be fixed. The sensible default is to make the pop-up show a list somewhere on the continuum of

• all-allowed-licenses
• all-allowed-relatively-updated-popular licenses (excluding stuff like old versions of CC and random obscure things)
• the licenses recommended in the docs plus a few others selected for common popularity and compatibility
• just the licenses in the recommended docs

Until this is fixed, the issue should not be closed.

Given that imported repos need not go through the new-repo UI at all, importing is irrelevant. This UI only shows up for starting new repos.

Anyone can put licenses in repos whether or not they are in the UI drop-down.

I suggest still that the docs and UI should match. If the community agrees to make GPL-2.0-only a prominent choice for new repos, it should be in both the UI and the docs. Similar for any other agreement.

If my docs-UI-matching suggestion is accepted, the first step is just updating the UI, and to mark somewhere that they should both be updated whenever the community wants to change things. I don't think we should push for changing the docs as a prerequisite to fixing the UI. The docs already got attention to get to where they are now, and the UI has not been updated.

If one of the other levels is preferred for the UI (showing more licenses than the docs discuss), then that is the decision to figure out here.

@sthagen the status quo is where a pop-up shows an enormous list of licenses including non-free ones that aren't even allowed here. That needs to be fixed. The sensible default is to make the pop-up show a list somewhere on the continuum of - all-allowed-licenses - all-allowed-relatively-updated-popular licenses (excluding stuff like old versions of CC and random obscure things) - the licenses recommended in the docs plus a few others selected for common popularity and compatibility - just the licenses in the recommended docs Until this is fixed, the issue should not be closed. Given that imported repos need not go through the new-repo UI *at all*, importing is irrelevant. This UI only shows up for starting new repos. Anyone can put licenses in repos whether or not they are in the UI drop-down. I suggest still that the docs and UI should match. If the community agrees to make GPL-2.0-only a prominent choice for new repos, it should be in both the UI and the docs. Similar for any other agreement. If my docs-UI-matching suggestion is accepted, the first step is just updating the UI, and to mark somewhere that they should both be updated whenever the community wants to change things. I don't think we should push for changing the *docs* as a prerequisite to fixing the UI. The docs already got attention to get to where they are now, and the UI has not been updated. If one of the other levels is preferred for the UI (showing more licenses than the docs discuss), then that is the decision to figure out here.

sthagen commented 2024年01月01日 00:58:27 +01:00

I do not see a pressing need for consistency in a user interface that clearly only gives a head start for few and is not even noticed of most (importing I guess is the main way to Codeberg for now).

I see no convincingly better UI implementation than just offering a lot to pick than is wanted and rather as @fnetX suggested weed out the unwanted. We do not want unauthentic licenses and we do not want to further ease spammers to abuse our tools.

Final feedback (why not repeat?):

Sometimes consistency is pushing a well-formed coalition out of consensus as it explicates statements better left for discussion only in the event they occur.

I do not see a pressing need for consistency in a user interface that clearly only gives a head start for few and is not even noticed of most (importing I guess is the main way to Codeberg for now). I see no convincingly better UI implementation than just offering a lot to pick than is wanted and rather as @fnetX suggested weed out the unwanted. We do not want unauthentic licenses and we do not want to further ease spammers to abuse our tools. Final feedback (why not repeat?): > Sometimes consistency is pushing a well-formed coalition out of consensus as it explicates statements better left for discussion only in the event they occur.

n0toose commented 2024年01月01日 01:12:32 +01:00

The GNU project explicitly asks Codeberg to prefer -or-later. Codeberg as a community can grant that request or reject it or take some nuanced middle-ground.

My suggestion is that PREFERRED_LICENSES include the -or-later versions only but the full license list (which itself needs updating to at least conform to Codeberg Terms should include -n-only versions.

At any rate, https://docs.codeberg.org/getting-started/licensing/ does not recommend GPLv2 nor any -n-only licensing right now,

I hear you. We basically agree on most things and I see potential for a middle ground, but it would make sense to fix 95% of the problem before dealing with this fine detail - I honestly don't get it 100%, but I think that debating this to death until all of us get burned out is really not worth it.

Let's just fix 95% of the problem and then deal with the rest later. (I'm acknowledging that you actively tried to shift the focus away from the *-only problem and engaged back in response to the both of us continuously bringing it up.)

> The GNU project explicitly asks Codeberg to prefer -or-later. Codeberg as a community can grant that request or reject it or take some nuanced middle-ground. > My suggestion is that PREFERRED_LICENSES include the -or-later versions only but the full license list (which itself needs updating to at least conform to Codeberg Terms should include -n-only versions. > At any rate, https://docs.codeberg.org/getting-started/licensing/ does not recommend GPLv2 nor any -n-only licensing right now, I hear you. We basically agree on most things and I see potential for a middle ground, but it would make sense to fix 95% of the problem before dealing with this fine detail - I honestly don't get it 100%, but I think that debating this to death until all of us get burned out is really not worth it. Let's just fix 95% of the problem and then deal with the rest later. (I'm acknowledging that you actively tried to shift the focus away from the *-only problem and engaged back in response to the both of us continuously bringing it up.)

wolftune commented 2024年11月15日 21:33:27 +01:00

Coming back later to this still-unresolved issue...

I urge the positive step of limiting the drop-down menu to any list such that every license in the list is allowed by the Codeberg Terms. The first step in getting this whole issue resolved is to not suggest in the drop-down any licenses which Codeberg does not actually allow. Even just a big list in alphabetic order that omits any licenses which are not allowed by the Terms would be a positive move.

I still think the best list to go with for now should be one that matches whatever is being suggested in the Docs. And I think anyone with an opinion about what the Docs are suggesting should discuss that in context of the Docs, not in the context of the drop-down menu UI.

Coming back later to this still-unresolved issue... I urge the positive step of limiting the drop-down menu to *any* list such that every license in the list is *allowed* by the Codeberg Terms. The first step in getting this whole issue resolved is to not suggest in the drop-down any licenses which Codeberg does not actually allow. Even just a big list in alphabetic order that omits any licenses which are not allowed by the Terms would be a positive move. I still think the best list to go with for now should be one that matches whatever is being suggested in the Docs. And I think anyone with an opinion about what the Docs are suggesting should discuss that in context of the Docs, not in the context of the drop-down menu UI.

sthagen commented 2024年11月22日 19:49:53 +01:00

A drop-down list leaving out compatible licenses could trick the user into using a license they do not want to make their content available under. I think removing Codeberg-"verboten" licenses is the only unbiased way to go.

A drop-down list leaving out compatible licenses could trick the user into using a license they do not want to make their content available under. I think removing Codeberg-"verboten" licenses is the only unbiased way to go.