License clarification in the new TOS and minor translation cleanup #20

curtisy commented 2022年02月12日 12:47:36 +01:00

First things first, IANAL so please take everything with a grain of salt. It's more of a nit than an actual issue anyway but I thought I'd address it nonetheless.

There has been a minor change in wording regarding allowed licenses on Codeberg that I think needs more clarification. The previous TOS stated

Our service is open for all projects working under a license compatible with either the Open-Source-License definition of the Free Software Foundation (FSF) or the Open Source Initiative (OSI).

This implies that other licenses compatible with FSF and/or OSI license terms are allowed and can be used for Codeberg repositories.

The new TOS changed this to

1. Repository content shall be licensed under an open-source license approved by the Free Software Foundation (see list of the FSF) or the Open Source Initiative (see list of the OSI).

The important change is the word shall here which - to my understanding - makes FSF and/or OSI approved licenses mandatory.

Furthermore, the word shall is apparently not legally binding when meaning to say must (I know, that's US jurisdiction but I can imagine German court would come to the same conclusion).
Another such take from plainlanguage.

It also indirectly excludes other compatible licenses such as some from the polyform project and those by Kyle E. Mitchell since none of these are listed/approved by OSI and/or FSF.

I can understand this is a legal precaution in case something violating any license/patent claims should get uploaded to Codeberg but the current wording is either a bit too soft or too hard, depending on the actual intent of shall in this context.

As such, I suggest rephrasing it to either

1. Repository content must be licensed under an open-source license approved by the Free Software Foundation (see list of the FSF) or the Open Source Initiative (see list of the OSI).

or

1. Repository content must be licensed under an open-source license compatible with the Free Software Foundation (see list of the FSF) or the Open Source Initiative (see list of the OSI) definitions of Open-Source Licenses.

---

Also, while we're at it, the word "mobbing" does not really convey the meaning of harassment in English. So unless you wanted to prevent building a mob, I'd also suggest changing

• Mobbing, stalking, doxxing (exposing someone's personal information), brigading (inciting a group to spam a specific place for any reason), threatening and harassment, as well as encouraging others to do those things.

to

• Bullying, stalking, doxxing (exposing someone's personal information), brigading (inciting a group to spam a specific place for any reason), threatening and harassment, as well as encouraging others to do those things.

I can create a PR for the second change if you want as it's a rather simple change. The first proposal should probably be thoroughly discussed but once you give it your go, I'll spin up a PR for it as well, if required.

First things first, IANAL so please take everything with a grain of salt. It's more of a nit than an actual issue anyway but I thought I'd address it nonetheless. There has been a minor change in wording regarding allowed licenses on Codeberg that I think needs more clarification. The previous TOS stated > Our service is open for all projects working under a license compatible with either the Open-Source-License definition of the Free Software Foundation (FSF) or the Open Source Initiative (OSI). This implies that other licenses compatible with FSF and/or OSI license terms are allowed and can be used for Codeberg repositories. The new TOS changed this to > 1. Repository content shall be licensed under an open-source license approved by the Free Software Foundation ([see list of the FSF](https://www.gnu.org/licenses/license-list.html)) or the Open Source Initiative ([see list of the OSI](https://opensource.org/licenses/)). The important change is the word _shall_ here which - to my understanding - makes FSF and/or OSI approved licenses mandatory. Furthermore, the word shall is apparently [not legally binding when meaning to say must](https://www.sealfaqs.com/?p=1254) (I know, that's US jurisdiction but I can imagine German court would come to the same conclusion). [Another such take from plainlanguage](https://www.plainlanguage.gov/guidelines/conversational/shall-and-must/). It also indirectly excludes other compatible licenses such as some from the [polyform project](https://polyformproject.org/licenses/) and those by [Kyle E. Mitchell](https://writing.kemitchell.com/) since none of these are listed/approved by OSI and/or FSF. I can understand this is a legal precaution in case something violating any license/patent claims should get uploaded to Codeberg but the current wording is either a bit too soft or too hard, depending on the actual intent of _shall_ in this context. As such, I suggest rephrasing it to either > > 1. Repository content **must** be licensed under an open-source license approved by the Free Software Foundation ([see list of the FSF](https://www.gnu.org/licenses/license-list.html)) or the Open Source Initiative ([see list of the OSI](https://opensource.org/licenses/)). or > 1. Repository content **must** be licensed under an open-source license **compatible with** the Free Software Foundation ([see list of the FSF](https://www.gnu.org/licenses/license-list.html)) or the Open Source Initiative ([see list of the OSI](https://opensource.org/licenses/)) [definitions of Open-Source Licenses](https://opensource.org/osd). --- Also, while we're at it, the word "mobbing" does not really convey the meaning of harassment in English. So unless you wanted to prevent building a mob, I'd also suggest changing > - Mobbing, stalking, doxxing (exposing someone's personal information), brigading (inciting a group to spam a specific place for any reason), threatening and harassment, as well as encouraging others to do those things. to > - **Bullying**, stalking, doxxing (exposing someone's personal information), brigading (inciting a group to spam a specific place for any reason), threatening and harassment, as well as encouraging others to do those things. I can create a PR for the second change if you want as it's a rather simple change. The first proposal should probably be thoroughly discussed but once you give it your go, I'll spin up a PR for it as well, if required.

momar commented 2022年02月13日 21:11:55 +01:00

I have created a branch "tos-next" where we can collect changes for the next ToS iteration - you can choose that as a taget branch for all ToS-related changes now.

I definitely agree to the second point.

The intention of the word "shall" is to give people a tiny bit of leeway: repos under an OSI/FSF license will never be removed due to their license, for others we can remove them due to the license. In most cases that would happen with previous notice. Also, it's actually planned to have a list of additional "Codeberg-approved" licenses that people can use.
Especially as the next sentences implies that exceptions are only acceptable under certain circumstances, I think the "shall" without the "compatible with" is just the middle ground between "must" (and thus only having a hard list) and "must + compatible with" (and thus having lots of additional legal work comparing licenses).

If that paragraph is changed, it's probably a bigger change than just a few words I'd say, and I'd like to incorporate a possible Codeberg-approved license list into that.

I have created a branch "tos-next" where we can collect changes for the next ToS iteration - you can choose that as a taget branch for all ToS-related changes now. I definitely agree to the second point. The intention of the word "shall" is to give people a tiny bit of leeway: repos under an OSI/FSF license will never be removed due to their license, for others we *can* remove them due to the license. In most cases that would happen with previous notice. Also, it's actually planned to have a list of additional "Codeberg-approved" licenses that people can use. Especially as the next sentences implies that exceptions are only acceptable under certain circumstances, I think the "shall" without the "compatible with" is just the middle ground between "must" (and thus *only* having a hard list) and "must + compatible with" (and thus having lots of additional legal work comparing licenses). If that paragraph is changed, it's probably a bigger change than just a few words I'd say, and I'd like to incorporate a possible Codeberg-approved license list into that.

andreas-roehler commented 2022年02月16日 11:31:35 +01:00

My thanks and respect endavouring such a task. However, your ToS look pretty kitchen-made. Do you invent English yourself? Warum nicht auf Deutsch?

Just to give an example, the current beginning:

"Welcome to Codeberg. We would like to invite you to join us in our journey to build and maintain a productive, safe and enduring platform for the collaborative development and maintenance of Open-Source Software and Documentation."

Thats not related to a ToS at all.

Unfortunatly next version of ToS reads even worst, plain of creative Zeitgeist, which will turn into cruft with some probability.

My thanks and respect endavouring such a task. However, your ToS look pretty kitchen-made. Do you invent English yourself? Warum nicht auf Deutsch? Just to give an example, the current beginning: "Welcome to Codeberg. We would like to invite you to join us in our journey to build and maintain a productive, safe and enduring platform for the collaborative development and maintenance of Open-Source Software and Documentation." Thats not related to a ToS at all. Unfortunatly next version of ToS reads even worst, plain of creative Zeitgeist, which will turn into cruft with some probability.

curtisy commented 2022年02月20日 16:18:12 +01:00

I have created a branch "tos-next" where we can collect changes for the next ToS iteration - you can choose that as a taget branch for all ToS-related changes now.

Will do, thanks!

I definitely agree to the second point.

The intention of the word "shall" is to give people a tiny bit of leeway: repos under an OSI/FSF license will never be removed due to their license, for others we can remove them due to the license. In most cases that would happen with previous notice. Also, it's actually planned to have a list of additional "Codeberg-approved" licenses that people can use.

That makes sense. Thank you for clarifying. I agree having a list of "Codeberg-approved" licenses is a change that would further clarify licensing details. It also has the nice side-effect of finding new licenses that people might find interesting

---

My thanks and respect endavouring such a task. However, your ToS look pretty kitchen-made. Do you invent English yourself? Warum nicht auf Deutsch?

You have a point but Codeberg isn't only used by German speaking people. Making the English version the default seems to be the best approach if you ask me. Nevertheless, there should also be a German/[insert other language here] version available.

I also can't speak for the team around Codeberg but I'm pretty sure most of them aren't that into law either, so looking "kitchen-made" is - in a way - to be expected. That's why there's a community to address issues with the current ToS and help improve it.

Thats not related to a ToS at all.

Yes and no. Pinterest or Basecamp also have some kind of introductory sentence. They're just hiding it a bit better. I personally prefer reading something other than the usual "You hereby agree to the following terms ..." because it doesn't make you feel like you're dealing with some big corporation.

> I have created a branch "tos-next" where we can collect changes for the next ToS iteration - you can choose that as a taget branch for all ToS-related changes now. Will do, thanks! > I definitely agree to the second point. > > The intention of the word "shall" is to give people a tiny bit of leeway: repos under an OSI/FSF license will never be removed due to their license, for others we *can* remove them due to the license. In most cases that would happen with previous notice. Also, it's actually planned to have a list of additional "Codeberg-approved" licenses that people can use. That makes sense. Thank you for clarifying. I agree having a list of "Codeberg-approved" licenses is a change that would further clarify licensing details. It also has the nice side-effect of finding new licenses that people might find interesting ___ > My thanks and respect endavouring such a task. However, your ToS look pretty kitchen-made. Do you invent English yourself? Warum nicht auf Deutsch? You have a point but Codeberg isn't only used by German speaking people. Making the English version the default seems to be the best approach if you ask me. Nevertheless, there should also be a German/[insert other language here] version available. I also can't speak for the team around Codeberg but I'm pretty sure most of them aren't _that_ into law either, so looking "kitchen-made" is - in a way - to be expected. That's why there's a community to address issues with the current ToS and help improve it. > Thats not related to a ToS at all. Yes and no. [Pinterest](https://policy.pinterest.com/en/terms-of-service) or [Basecamp](https://basecamp.com/about/policies/terms) also have some kind of introductory sentence. They're just hiding it a bit better. I personally prefer reading something other than the usual "You hereby agree to the following terms ..." because it doesn't make you feel like you're dealing with some big corporation.

MrRawes commented 2022年05月03日 11:53:21 +02:00

IMO the license list should be the SPDX list

IMO the license list should be the [SPDX list](https://spdx.org/licenses/)

LoganDark commented 2022年07月20日 09:01:56 +02:00

GPLv3 / AGPLv3 is allowed by these new terms right? I've read conflicting opinions online about whether or not it's a "real" open-source license, and if I'm not allowed to use it on Codeberg that would kill most of my interest in the platform.

GPLv3 / AGPLv3 is allowed by these new terms right? I've read conflicting opinions online about whether or not it's a "real" open-source license, and if I'm not allowed to use it on Codeberg that would kill most of my interest in the platform.

fnetX commented 2022年07月20日 14:02:12 +02:00

We accept all licenses that are considered "Free" by the FSF or OSI. The GPL is among the most common, and you can find other compatible licenses here: https://www.gnu.org/licenses/license-list.html (the AGPL is listed there, too). So yes.

We accept all licenses that are considered "Free" by the FSF or OSI. The GPL is among the most common, and you can find other compatible licenses here: https://www.gnu.org/licenses/license-list.html (the AGPL is listed there, too). So yes.

lngns commented 2022年10月04日 02:57:51 +02:00

Hi!
What is the current attitude towards licences that have not yet been reviewed by the OSI and FSF, but otherwise allow everything the reviewed ones do?
For example I think it would be cool to allow the licensezero family (Parity, Charity, Prosperity) and friends (Maximaleft, ...).
For a concrete case, I'd really like to use the RPL, which is OSI-approved, but it wants me to live in Colorado, which is several thousand kilometers and an ocean away from where I am, so I'd ideally use a different one.

Hi! What is the current attitude towards licences that have not yet been reviewed by the OSI and FSF, but otherwise allow everything the reviewed ones do? For example I think it would be cool to allow the licensezero family ([Parity](https://github.com/licensezero/parity-public-license), [Charity](https://github.com/licensezero/charity-public-license), [Prosperity](https://github.com/licensezero/prosperity-public-license)) and friends ([Maximaleft](https://github.com/berneout/maximaleft), ...). For a concrete case, I'd really like to use the [RPL](https://opensource.org/licenses/RPL-1.5), which is OSI-approved, but it wants me to live in Colorado, which is several thousand kilometers and an ocean away from where I am, so I'd ideally use a different one.

jacobwillden commented 2023年06月03日 20:48:02 +02:00

Also, it's actually planned to have a list of additional "Codeberg-approved" licenses that people can use.

I'm curious about where potential additional "Codeberg-approved" licenses should be discussed, since there are licenses that, while not yet approved by the OSI or the FSF, appear to provide the Four Freedoms of free software (like the Blue Oak Model License, which its authors believe are compatible with the GPL).

> Also, it's actually planned to have a list of additional "Codeberg-approved" licenses that people can use. I'm curious about where potential additional "Codeberg-approved" licenses should be discussed, since there are licenses that, while not yet approved by the OSI or the FSF, appear to provide the [Four Freedoms of free software](https://en.wikipedia.org/wiki/Free_software#Definition) (like the [Blue Oak Model License](https://blueoakcouncil.org/license/1.0.0), which [its authors believe are compatible with the GPL](https://blueoakcouncil.org/license-faq)).

Ghost commented 2023年09月02日 23:05:43 +02:00

Hi all,

FSF-approved and/or OSI-approved is great for source code, however there might be other stuff that is very relevant for open source projects, but not covered by either: E.g. documentation -- like e.g. the TOS themselves -- is often shared under the terms of some form of Creative Commons license -- which has not been approved by OSI as open source.

Is this discussed somewhere? If not should it being an issue on its own or is this a good place?

edit: found Codeberg/Community#630

Hi all, FSF-approved and/or OSI-approved is great for source code, however there might be other stuff that is very relevant for open source projects, but not covered by either: E.g. documentation -- like e.g. the TOS themselves -- is often shared under the terms of some form of Creative Commons license -- which has not been approved by OSI as open source. Is this discussed somewhere? If not should it being an issue on its own or is this a good place? edit: found https://codeberg.org/Codeberg/Community/issues/630