Mention private repo / note-taking rule:
A user on Mastodon asked about private repos? We should mention that private repos are possible (re-link to the FAQ which explains this, but people only looking at the licensing guide will overlook the clarification in the FAQ and the section in the Terms of Use)
How to apply:
People might wonder how to apply a license to your code. AFAICT, it's usually considered okay to just put a file next to your code, but to properly license code and avoid any legal uncertainty, it should be explicitly stated that the code is under this license, right? Ideally, every file should include a license header.
It might be good to give good and precise instructions on how to actually change the license, especially since the full license texts are sometimes hard to copy into a easily readable file (so maybe tell people what's necessary to reference a file that lives outside etc).
A place where someone was hit by the "adding a file is enough" is in Codeberg/Community#407, and I agree that the Gitea UI kinda suggests that using the license dialog is everything you need.
Reasoning:
Some people might wonder why a repo needs a license. Some hints are kinda hidden, but they might be made more prominently.
Not specifying a license for your code does not automatically mean you've made it available without restrictions; you are still its copyright holder and must explicitly make the code free by choosing a free license.
Please do not use custom licenses, they are usually a bad idea and might result in legal uncertainty.
@michielappelman are you interested in fixing this up once more? No obligation of course, your first version is already very nice, these are just some improvements I can think of by now.
Just some additions to the recently added article from #173 (https://docs.codeberg.org/getting-started/licensing/)
Mention private repo / note-taking rule:
A user on Mastodon asked about private repos? We should mention that private repos are possible (re-link to the FAQ which explains this, but people only looking at the licensing guide will overlook the clarification in the FAQ and the section in the Terms of Use)
How to apply:
People might wonder how to apply a license to your code. AFAICT, it's usually considered *okay* to just put a file next to your code, but to properly license code and avoid any legal uncertainty, it should be explicitly stated that the code is under this license, right? Ideally, every file should include a license header.
It might be good to give good and precise instructions on how to actually change the license, especially since the full license texts are sometimes hard to copy into a easily readable file (so maybe tell people what's necessary to reference a file that lives outside etc).
A place where someone was hit by the "adding a file is enough" is in Codeberg/Community#407, and I agree that the Gitea UI kinda suggests that using the license dialog is everything you need.
Reasoning:
Some people might wonder *why* a repo needs a license. Some hints are kinda hidden, but they might be made more prominently.
> Not specifying a license for your code does not automatically mean you've made it available without restrictions; you are still its copyright holder and must explicitly make the code free by choosing a free license.
> Please do not use custom licenses, they are usually a bad idea and might result in legal uncertainty.
---
@michielappelman are you interested in fixing this up once more? No obligation of course, your first version is already very nice, these are just some improvements I can think of by now.
The article should also mention FSF-approved licenses. Now there is only the OSI. The view of the FSF fits much better in our context. They have a clear focus on ethical aspects, so do we. We promote copyleft, so does the FSF. The OSI has a very questionable position in this regard: Their main sponsor is Google (https://opensource.org/corporate-sponsors-support). Google is very strong in advocating temporarily-open licences (aka 'permissive', such as the Apache licence), Google internally even has a ban on the AGPL (https://opensource.google/docs/using/agpl-policy/).
To understand licenses and copyleft, it is necessary to have a basic understanding of copyright. A short introduction with some examples could make sense. Or a link to such a thing.
For non-code licences it might be good to also mention the GNU Free Documentation License (GFDL), since it belongs somehow into the GPL ecosystem.
I started liking the terms 'temporarily-open' (non-copyleft) and 'forever-open' (copyleft). In my experience it is easy to get mislead as a lay person by the terms 'permissive' and 'copyleft'. The terms are widely established but are not descriptive.
I might eventually work this into the text. Sofar I was not active in contributing to the docs and don't know who is curating them.
So let me know if there are any objections.
Just some more thoughts:
* The article should also mention FSF-approved licenses. Now there is only the OSI. The view of the FSF fits much better in our context. They have a clear focus on ethical aspects, so do we. We promote copyleft, so does the FSF. The OSI has a very questionable position in this regard: Their main sponsor is Google (https://opensource.org/corporate-sponsors-support). Google is very strong in advocating *temporarily-open* licences (aka 'permissive', such as the Apache licence), Google internally even has a *ban* on the AGPL (https://opensource.google/docs/using/agpl-policy/).
* To understand licenses and copyleft, it is necessary to have a basic understanding of copy*right*. A short introduction with some examples could make sense. Or a link to such a thing.
* For non-code licences it might be good to also mention the GNU Free Documentation License (GFDL), since it belongs somehow into the GPL ecosystem.
* I started liking the terms 'temporarily-open' (non-copyleft) and 'forever-open' (copyleft). In my experience it is easy to get mislead as a lay person by the terms 'permissive' and 'copyleft'. The terms are widely established but are not descriptive.
I might eventually work this into the text. Sofar I was not active in contributing to the docs and don't know who is curating them.
So let me know if there are any objections.
AFAICT, it's usually considered okay to just put a file next to your code, but to properly license code and avoid any legal uncertainty, it should be explicitly stated that the code is under this license, right? Ideally, every file should include a license header.
I'm not an expert, but I actually consider the headers even more important because
files are kind-of atomic units
there could be files with differenc licences in the same repository
> AFAICT, it's usually considered okay to just put a file next to your code, but to properly license code and avoid any legal uncertainty, it should be explicitly stated that the code is under this license, right? Ideally, every file should include a license header.
I'm not an expert, but I actually consider the headers even more important because
* files are kind-of atomic units
* there could be files with differenc licences in the same repository
As a reference: https://www.gnu.org/licenses/gpl-howto.en.html
Thank you for your feedback. The article about proper licensing is very important IMHO, because it's what we want to promote here and is a really important thing for us as a software forge, to give contributors at hand. So any improvement very welcome!
There is the lax rule of waiting for about two approvements before merging, less for less-important changes or when there is simply no more feedback after a while.
I think that personals views can make it into the licensing article, but I'd ask everyone to stay as objective as possible and to cover multiple perspectives. There are things people have fought war over, we should just quickly mention different arguments (e.g. copyleft vs temporarily open; license headers vs. one central place (promotion of the reuse project could also be an option), ...).
Thank you for your feedback. The article about proper licensing is very important IMHO, because it's what we want to promote here and is a really important thing for us as a software forge, to give contributors at hand. So any improvement very welcome!
There is the lax rule of waiting for about two approvements before merging, less for less-important changes or when there is simply no more feedback after a while.
I think that personals views can make it into the licensing article, but I'd ask everyone to stay as objective as possible and to cover multiple perspectives. There are things people have fought war over, we should just quickly mention different arguments (e.g. copyleft vs temporarily open; license headers vs. one central place (promotion of the reuse project could also be an option), ...).
Not a pull-request yet because it is late-night work. Just for reference and input to the discussion.
https://codeberg.org/tok/codeberg-documentation/commit/8f109fe51de563a5019dcb61a43ee480ed279f39
Not a pull-request yet because it is late-night work. Just for reference and input to the discussion.
Another thought:
We should highlight that the licence is also about protecting the user from being sued for copyright or even patent infringement (as long as it relates to the licenced work). Especially the MIT licence basically allows that code can be used without copyright infringement but nevertheless the copyright owner can sue the user for patent infringement related to the licenced work. As a user this is good to know. Not sure if that happens often, though. So for this reason we should think about promoting the Apache Licence before the MIT licence.
Another thought:
We should highlight that the licence is also about protecting the user from being sued for copyright or even patent infringement (as long as it relates to the licenced work). Especially the MIT licence basically allows that code can be used without copyright infringement but nevertheless the copyright owner can sue the user for *patent* infringement related to the licenced work. As a user this is good to know. Not sure if that happens often, though. So for this reason we should think about promoting the Apache Licence before the MIT licence.
Already checked out your commit from the explore view :)
Why did you switch from the OSI list to the FSF list in line 32/41? I don't know why the other one was listed there, though, maybe it's worth linking both as in the current no-license reminder inside the repos?
To the patent thing: It would be great to have resources if this happens, I have never heard of such a thing. It would also be very hard to claim patents if something was released for free use without mentioning the patent, I doubt this works in a court actually. But still, an interesting thought, that could be theoretically mentioned if no such evidence can be found.
Already checked out your commit from the explore view :)
Why did you switch from the OSI list to the FSF list in line 32/41? I don't know why the other one was listed there, though, maybe it's worth linking both as in the current no-license reminder inside the repos?
To the patent thing: It would be great to have resources if this happens, I have never heard of such a thing. It would also be very hard to claim patents if something was released for free use without mentioning the patent, I doubt this works in a court actually. But still, an interesting thought, that could be theoretically mentioned if no such evidence can be found.
Why did you switch from the OSI list to the FSF list in line 32/41?
I switched to the FSF list for following reasons:
For consistency. We start introducing free software on the foundation of gnu.org. There are quite some links to gnu.org. Also we promote the GPL family quite clearly. Both are tightly related to the FSF. So it only makes sense to then link to the list of licences by the FSF and not the OSI.
The FSF seems more aligned with our mission. They put a clear focus on ethical aspects and on the general public. The OSI seems to be more focused on coorporate aspects. They do promote non-copyleft licences (https://opensource.org/licenses). The most solid reference I can currently provide is the list of sponsors. The 'anchor' sponsor of the OSI is Google followed other big technology companies (https://opensource.org/corporate-sponsors-support). I strongly believe that an 'anchor' sponsor will have a influence on the OSI. The FSF looks very different with 'patrons' like Purism and Savoir-Faire Linux (both I see aligned with our mission, the others I don't know) (https://www.fsf.org/patrons).
We can indeed link to both. But I'd then also write a short explanation who they are (as objective as possible). I think it could be confusing otherwise.
> Why did you switch from the OSI list to the FSF list in line 32/41?
I switched to the FSF list for following reasons:
* For consistency. We start introducing free software on the foundation of gnu.org. There are quite some links to gnu.org. Also we promote the GPL family quite clearly. Both are tightly related to the FSF. So it only makes sense to then link to the list of licences by the FSF and not the OSI.
* The FSF seems more aligned with our mission. They put a clear focus on ethical aspects and on the general public. The OSI seems to be more focused on coorporate aspects. They do promote non-copyleft licences (https://opensource.org/licenses). The most solid reference I can currently provide is the list of sponsors. The 'anchor' sponsor of the OSI is Google followed other big technology companies (https://opensource.org/corporate-sponsors-support). I strongly believe that an 'anchor' sponsor will have a influence on the OSI. The FSF looks very different with 'patrons' like Purism and Savoir-Faire Linux (both I see aligned with our mission, the others I don't know) (https://www.fsf.org/patrons).
We can indeed link to both. But I'd then also write a short explanation who they are (as objective as possible). I think it could be confusing otherwise.
To the patent thing: It would be great to have resources if this happens, I have never heard of such a thing. It would also be very hard to claim patents if something was released for free use without mentioning the patent, I doubt this works in a court actually. But still, an interesting thought, that could be theoretically mentioned if no such evidence can be found.
The FSF on the X11 Licence and also Expat Licence (often called "the MIT licence"):
we recommend the Apache 2.0 license since it protects users from patent treachery.
I'm not an expert on that, but maybe that's an interesting read:
However, the specific license grants under the GPLv2, the
BSD and the MIT licenses were drafted using concepts derived mainly from copyright law
and not patent law.2 By way of example, the express license grants under the GPLv2 concern
only the exclusive rights of a copyright holder, namely copying, modification and distribution
of the code.3 The exclusive rights of a patent holder as enumerated in 35 U.S.C. Sec. 271(a),
i.e. the rights to make, use, sell, offer for sale and import, are not mentioned within the license
The existence and scope of any patent license grants in popular open
source licenses is, to date, unresolved
As the article states, there seems to be unclarity.
Based on this I conclude that there's no guarantee that such software licences also give the user a licence to use a patent under the same conditions.
I believe that this can be avoided using licences with a 'patent clause' like the GPLv3 or Apache-2.0 do. Not only does this protect the user but it also protects the project from 'trojan' contributions.
Imagine Android would be licenced under the X11/Expat/MIT licence without a patent clause. It would be possible that somebody maliciously sneaks in a patented contribution and then later sues Google for patent infringement.
> To the patent thing: It would be great to have resources if this happens, I have never heard of such a thing. It would also be very hard to claim patents if something was released for free use without mentioning the patent, I doubt this works in a court actually. But still, an interesting thought, that could be theoretically mentioned if no such evidence can be found.
The FSF on the X11 Licence and also Expat Licence (often called "the MIT licence"):
> we recommend the Apache 2.0 license since it protects users from patent treachery.
https://www.gnu.org/licenses/license-list.en.html#X11License
I'm not an expert on that, but maybe that's an interesting read:
> However, the specific license grants under the GPLv2, the
> BSD and the MIT licenses were drafted using concepts derived mainly from copyright law
> and not patent law.2 By way of example, the express license grants under the GPLv2 concern
> only the exclusive rights of a copyright holder, namely copying, modification and distribution
> of the code.3 The exclusive rights of a patent holder as enumerated in 35 U.S.C. Sec. 271(a),
> i.e. the rights to make, use, sell, offer for sale and import, are not mentioned within the license
>
> grants of the GPLv2.
>
https://international.vlex.com/vid/free-and-open-source-739218105
Also
> The existence and scope of any patent license grants in popular open
source licenses is, to date, unresolved
As the article states, there seems to be unclarity.
Based on this I conclude that there's no guarantee that such software licences also give the user a licence to use a patent under the same conditions.
I believe that this can be avoided using licences with a 'patent clause' like the GPLv3 or Apache-2.0 do. Not only does this protect the user but it also protects the project from 'trojan' contributions.
Imagine Android would be licenced under the X11/Expat/MIT licence without a patent clause. It would be possible that somebody maliciously sneaks in a patented contribution and then later sues Google for patent infringement.
Do we want to have an opinion, recommendation or even terms-of-use regarding contributor licence agreements (CLA)?
I remember projects being licenced under an free and open-source licence but they required contributors to sign a CLA. The CLA basically said that the contributor transfers the copyright ownership to the project owner.
Such methods can be used as 'backdoors' to turn copyleft into non-copyleft or even proprietary code: If you are the only copyright owner of a software, then you can change the licence at will.
Yet another thought:
Do we want to have an opinion, recommendation or even terms-of-use regarding contributor licence agreements (CLA)?
I remember projects being licenced under an free and open-source licence but they required contributors to sign a CLA. The CLA basically said that the contributor transfers the copyright ownership to the project owner.
Such methods can be used as 'backdoors' to turn copyleft into non-copyleft or even proprietary code: If you are the only copyright owner of a software, then you can change the licence at will.
See for example https://en.wikipedia.org/wiki/Contributor_License_Agreement#Examples.
This page is made by Github and must be assumed to reflect interests of Microsoft. I suspect that there is a bias which is not aligned with ours (GPL comes last). And they keep silent about the missing patent clause in the MIT licence (on the front page).
The wording "I want it simple and permissive" sounds to be crafted to make people favour the MIT licence (not clear which one of X11, Expat, there is confusion). Of course, laypeople will want to have legal things simple, and "permissive" even sounds like fair and good.
More ideas & comments:
I think, Codeberg can have its own recommendation of licences indeed (similar to what there is already).
However, I suggest to move this section more towards the top of the document and then later on go into explanations. I'm afraid, many people will not read the full text anyway.
In the US: license = noun, to license = verb
Everywhere else: licence = noun, to license = verb
Since codeberg.org is located in Germany, I suggest to use the latter spelling. (I was not being consistent myself, but will try from now on)
Comment on **choosealicense.com**
* This page is made by Github and must be assumed to reflect interests of Microsoft. I suspect that there is a bias which is not aligned with ours (GPL comes last). And they keep silent about the missing patent clause in the MIT licence (on the front page).
* The wording "I want it simple and permissive" sounds to be crafted to make people favour the MIT licence (not clear which one of X11, Expat, there is confusion). Of course, laypeople will want to have legal things simple, and "permissive" even sounds like fair and good.
More ideas & comments:
I think, Codeberg can have its own recommendation of licences indeed (similar to what there is already).
However, I suggest to move this section more towards the top of the document and then later on go into explanations. I'm afraid, many people will not read the full text anyway.
About **spelling**: https://prowritingaid.com/art/492/Licence-vs--License%3A-Which-One-is-Right.aspx (trackers there)
In the US: licen**s**e = noun, to licen**s**e = verb
Everywhere else: licen**c**e = noun, to licen**s**e = verb
Since codeberg.org is located in Germany, I suggest to use the latter spelling. (I was not being consistent myself, but will try from now on)
I'm afraid I only scanned through your comments. Feel free to just go ahead and realize them. We are happy about every contribution, and the current state does in no way reflect an official stance or anything, but is simply a very first contribution we received and allowed us to make licensing more clear to our users than it has been before. There is always a lot of room for improvements.
I'm afraid I only scanned through your comments. Feel free to just go ahead and realize them. We are happy about every contribution, and the current state does in no way reflect an official stance or anything, but is simply a very first contribution we received and allowed us to make licensing more clear to our users than it has been before. There is always a lot of room for improvements.
I had extensive offline discussions with @tok. Below are some of the thoughts which emerged:
the page should provide some practical recommendations about specific licences and recommend in the first place licences which guarantee a perpetual openness of the code (copyleft/forever-open licences). It should not reinvent the wheel, but it should redirect to external well-established references whenever possible, like the extensive catalogation of licences made by GNU/FSF.
the page should warn about the patent issue of certain licences (patent treachery)
the page should contain text which is concise and simple to undererstand. It should provide a basic legal background about copyright law. It should explain the difference between forever-open licences (copyleft) and temporarily-open licences (permissive)
the page should explain how to add a licence in practice by redirecting to dedicated pages, such as https://reuse.software
the page should be structured in paragraphs for a) software projects, b) hardware projects, c) other projects (text, artwork, etc) since they all have different licence requirements
the page should promote selected best practices (e.g. avoid the use of too many licences. i.e. the proliferation of licences)
as an indepedent association which further promotes awareness on social and philosophical issues (see statute), Codeberg should warn about existing conflict of interests of other entities (e.g. Microsoft/GitHub/Choosealicense)
warn about CLA and provide recommendations
append an FAQ (what about private repos?, ...)
about the way to begin the page:
In the statute of Codeberg is written that:
The purpose of the association is to promote the creation, collection, dissemination and preservation of Free Content (Open Content, Free Cultural Work) and Free and Open Source Software (FOSS), and their documentation in selfless activity, thereby enabling equal opportunities in access to knowledge and education. To this end, it also aims to raise awareness of the related social and philosophical issues.
but in the current licencing page is written that:
Codeberg's mission is to support the development and creation of Free Software, thus we only allow those repos licensed under an OSI/FSF-approved license.
The two should be consistent. Maybe rather than trying to deduce from abstract principles it is enought to state that term of use of codeberg requires the use of an open-source licence for all project. One can later explain why this is important.
I had extensive offline discussions with @tok. Below are some of the thoughts which emerged:
1. the page should provide some practical recommendations about specific licences and recommend in the first place licences which guarantee a perpetual openness of the code (copyleft/forever-open licences). It should not reinvent the wheel, but it should redirect to external well-established references whenever possible, like the extensive catalogation of licences made by GNU/FSF.
2. the page should warn about the patent issue of certain licences (patent treachery)
3. the page should contain text which is concise and simple to undererstand. It should provide a basic legal background about copyright law. It should explain the difference between forever-open licences (copyleft) and temporarily-open licences (permissive)
4. the page should explain how to add a licence in practice by redirecting to dedicated pages, such as https://reuse.software
5. the page should be structured in paragraphs for a) software projects, b) hardware projects, c) other projects (text, artwork, etc) since they all have different licence requirements
6. the page should promote selected best practices (e.g. avoid the use of too many licences. i.e. the proliferation of licences)
7. as an indepedent association which further promotes awareness on social and philosophical issues (see statute), Codeberg should warn about existing conflict of interests of other entities (e.g. Microsoft/GitHub/Choosealicense)
8. warn about CLA and provide recommendations
9. append an FAQ (what about private repos?, ...)
10. about the way to begin the page:
In the statute of Codeberg is written that:
```txt
The purpose of the association is to promote the creation, collection, dissemination and preservation of Free Content (Open Content, Free Cultural Work) and Free and Open Source Software (FOSS), and their documentation in selfless activity, thereby enabling equal opportunities in access to knowledge and education. To this end, it also aims to raise awareness of the related social and philosophical issues.
```
but in the current licencing page is written that:
```txt
Codeberg's mission is to support the development and creation of Free Software, thus we only allow those repos licensed under an OSI/FSF-approved license.
```
The two should be consistent. Maybe rather than trying to deduce from abstract principles it is enought to state that term of use of codeberg requires the use of an open-source licence for all project. One can later explain why this is important.
Thank you for this easier-to-read list of points. We could even convert this into ToDo-Boxes ([ ]) and ask people to pick one (some) of them.
I think we should keep repetition as low as possible, but having some extra paragraphs that mention exceptions / differences for other kinds of content sounds like a good idea.
&
rather link to it, please
This page was mainly a blocker for licence reminders to spread awareness, and is thus mainly linked there. So the most important thing is to make people understand why a FLOSS licence is the thing we all want in their repo, not "just because it's in the Terms of Use". Whoever is going to rework this, please keep in mind that people might read the article without even fully understanding what this spirit means. I know many people who literally thought that they are contributing to Open Source because they put their code into a publicly accessible space (like a Git(Hub) repo). Those will be redirected to this article, and they should be caring about FLOSS afterwards ๐
Thank you for this easier-to-read list of points. We could even convert this into ToDo-Boxes (`[ ]`) and ask people to pick one (some) of them.
5) I think we should keep repetition as low as possible, but having some extra paragraphs that mention exceptions / differences for other kinds of content sounds like a good idea.
&
9) rather link to it, please
10) This page was mainly a blocker for licence reminders to spread awareness, and is thus mainly linked there. So the most important thing is to make people understand *why* a FLOSS licence is the thing we all want in their repo, not "just because it's in the Terms of Use". Whoever is going to rework this, please keep in mind that people might read the article without even fully understanding what this spirit means. I know many people who literally thought that they are contributing to Open Source because they put their code into a publicly accessible space (like a Git(Hub) repo). Those will be redirected to this article, and they should be caring about FLOSS afterwards ๐
@fnetX Ah, I did not fully get that people will be mainly redirected there with the licence reminder. Thanks!
I had in mind to start like this:
Code without licence imposes legal uncertainty about its use and distribution. Therefore the Terms of Use of Codeberg requires that all projects should be published with an open-source licence. This can be motivated as follows:
For projects published without a licence or an equivalent agreement, copyright law grants to the authors (whether they are known publicly or not) the exclusive right for use and distribution of their work.
In other words: in the absence of a permission from the copyright holder, copyright law forbids anybody else than the copyright holder to use or distribute (for example to copy or sell, either directly or though third parties) the work. A licence is a legal statement which grants others the rights to use the protected work, eventually under some conditions.
Providing a licence is not the unique way to grant the rights to use or distribute a protected work, but is a very practical one and it is the only way which has worked so far in practice in the developement of Free Software.
@fnetX Ah, I did not fully get that people will be mainly redirected there with the licence reminder. Thanks!
I had in mind to start like this:
> Code without licence imposes legal uncertainty about its use and distribution. Therefore the [Terms of Use](https://codeberg.org/codeberg/org/src/branch/main/TermsOfUse.md) of Codeberg requires that all projects should be published with an open-source licence. This can be motivated as follows:
For projects published without a licence or an equivalent agreement, copyright law grants to the authors (whether they are known publicly or not) the exclusive right for use and distribution of their work.
In other words: in the absence of a permission from the copyright holder, copyright law forbids anybody else than the copyright holder to use or distribute (for example to copy or sell, either directly or though third parties) the work. A *licence* is a legal statement which grants others the rights to use the protected work, eventually under some conditions.
Providing a licence is not the unique way to grant the rights to use or distribute a protected work, but is a very practical one and it is the only way which has worked so far in practice in the developement of Free Software.
Copy from the original issue, I think this is the part not yet implemented but proposed in the now-closed issue.
clarify some common issues with licences, e.g. clarifying how to apply them properly and unmistakably (also see Codeberg/Community#407, chosing -ONLY vs. -OR-LATER variants must be done by the user for example)
Copy from the original issue, I think this is the part not yet implemented but proposed in the now-closed issue.
> clarify some common issues with licences, e.g. clarifying how to apply them properly and unmistakably (also see Codeberg/Community#407, chosing -ONLY vs. -OR-LATER variants must be done by the user for example)
For a public domain equivalent license, we recommend using 0BSD instead of other licenses. I think it would be beneficial to explain why: it has better reception and recognition from companies.
For a public domain equivalent license, we recommend using 0BSD instead of other licenses. I think it would be beneficial to explain why: it has better reception and recognition from companies.
Relevant comment on choosealicence.com: https://github.com/github/choosealicense.com/issues/805#issuecomment-799220564
Found this issue via Community repo: Codeberg/Community#624 I apologize if this should be a separate issue or in a different tracker; this is my best guess.
Currently the new repo page still links to https://choosealicense.com/ where MIT license is prominently and favorably described as mentioned previously.
I would suggest that when this is fixed, the drop down list should correspond to the names given on the provided documentation.
This libre license advocated by the linked page is "GNU GPLv3". If I type "GNU" into the drop down I get gnu-javamail-exception and gnu-plot. Type "GPL" and there are about 2 dozen options. "GPLv3" shows nothing but there are 4x variations under GPL-3.0-. In my browser the drop down only show 3 lines at a time so it is not easy to find that v3 is described as -3.0-.. you need to hunt a lot if you don't already know that. Then, I don't know which one actually is the same one I want.
It's fine to have the long extensive list for those who wish to use it, but the first items should be exactly the same wording as whatever documentation is provided. In this case, the top item should be GNU GPLv3, followed, I guess, by MIT.
Found this issue via Community repo: https://codeberg.org/Codeberg/Community/issues/624 I apologize if this should be a separate issue or in a different tracker; this is my best guess.
Currently the new repo page still links to https://choosealicense.com/ where MIT license is prominently and favorably described as mentioned previously.
I would suggest that when this is fixed, the drop down list should correspond to the names given on the provided documentation.
This libre license advocated by the linked page is "GNU GPLv3". If I type "GNU" into the drop down I get `gnu-javamail-exception` and `gnu-plot`. Type "GPL" and there are about 2 dozen options. "GPLv3" shows nothing but there are 4x variations under `GPL-3.0-`. In my browser the drop down only show 3 lines at a time so it is not easy to find that `v3` is described as `-3.0-`.. you need to hunt a lot if you don't already know that. Then, I don't know which one actually is the same one I want.
It's fine to have the long extensive list for those who wish to use it, but the first items should be exactly the same wording as whatever documentation is provided. In this case, the top item should be `GNU GPLv3`, followed, I guess, by `MIT`.
I'm in favour of promoting https://writefreesoftware.org/ from Codeberg, replacing Choose a license where applicable. WriteFreeSoftware aligns better with our mission, is more approachable in my opinion, and covers more than "simply choosing a license". Because writing Free Software does not end with picking a choice from a checkbox alone.
I'm in favour of promoting https://writefreesoftware.org/ from Codeberg, replacing Choose a license where applicable. WriteFreeSoftware aligns better with our mission, is more approachable in my opinion, and covers more than "simply choosing a license". Because writing Free Software does not end with picking a choice from a checkbox alone.
I am guessing you would link directly to Choosing a license? If yes I think it is a huge improvement over the existing link. It very succinctly touches on a range of issues to consider.
With regards to my previous comment about the licenses being findable in the list, I think the change of link should be made irregardless.
But I would like to point out that of the libre licenses recommended, none of them are findable. (Both the MIT and BSD licenses are findable though.)
The problem is that abbreviations are being used instead of the full names. Also, the GPL abbreviations have different word orders than the full names on this website. So they are not located in the expected alphabetical order.
On my desktop browser, this drop down shows up with a fancy type-to-find widget that should make obtaining the correct item from the long list pretty fast. Yes none of them are findable this way; you really have to scroll through the list which only shows 3 lines at a time.
The solution could be to list the full name along with abbreviations. For example, replace "MPL-2.0" with "Mozilla Public License 2.0 (MPL-2.0)". Assuming other browsers work the same way mine does, this would still allow people who know the abbreviation they are looking for to locate easily (typing "mpl").
Idk if there is some other reason why the listings are abbreviation-only. Internationalization?
I am guessing you would link directly to [Choosing a license](https://writefreesoftware.org/learn/participate/choose-a-license/)? If yes I think it is a huge improvement over the existing link. It very succinctly touches on a range of issues to consider.
With regards to my previous comment about the licenses being findable in the list, I think the change of link should be made irregardless.
But I would like to point out that of the libre licenses recommended, none of them are findable. (Both the MIT and BSD licenses *are* findable though.)
The problem is that abbreviations are being used instead of the full names. Also, the GPL abbreviations have different word orders than the full names on this website. So they are not located in the expected alphabetical order.
On my desktop browser, this drop down shows up with a fancy type-to-find widget that should make obtaining the correct item from the long list pretty fast. Yes none of them are findable this way; you really have to scroll through the list which only shows 3 lines at a time.
The solution could be to list the full name along with abbreviations. For example, replace "MPL-2.0" with "Mozilla Public License 2.0 (MPL-2.0)". Assuming other browsers work the same way mine does, this would still allow people who know the abbreviation they are looking for to locate easily (typing "mpl").
Idk if there is some other reason why the listings are abbreviation-only. Internationalization?
The list is autogenerated from SPDX license data, but I'm pretty sure that someone could make adjustments to this process to allow the format "Full Name (Short Name)".
Could you try to propose your changes to the license chooser to https://codeberg.org/forgejo/forgejo?
The list is autogenerated from SPDX license data, but I'm pretty sure that someone could make adjustments to this process to allow the format "Full Name (Short Name)".
I've had this issue pinned as I was trying to articulate a request in https://codeberg.org/forgejo/forgejo as requested. But I couldn't get it very concise.
Now I see the linked documentation has been changed to https://docs.codeberg.org/getting-started/licensing. For me, I like the new one. I finally know which license to select from the list (AGPL 3.0 or later). I honestly couldn't figure it out before.
I feel that the document might be a little complicated for someone who isn't already framiliar with the concepts though. Maybe it's just impossible to explain in a way that's both reasonably accurate/nuanced and also extremely brief.
I am curious:
1: are the effects measurable?
Are there any metrics available describing how many people actually select a license at the "create repo" page and if it changes over time? Especially if it can be correlated with viewing the explainer document.
Hope it doesn't come across as excessively taylorist or snooping.
2: flowchart flow
Is the intention to make the "flowchart" section visually clearer? I am not framiliar with eleventy. Without adding a bunch of complexity to the whole repo would it be possible to add some more hints to help follow the narrative? Such as borders on the left side, highlight on mouse over? Like this (tiny on purpose to show structure not content):
3: easy input license into form
Would it be possible to have links next to each license name that brings you to the new repo page with that form filled? Could look like this:
With that URL being https://codeberg.org/repo/create?license=AGPL-3.0-or-later and clicking it does this:
Not sure if it would/could go back to the previous tab the user arrived from or if it just opens a fresh one.
It might sound excessively hand-holding but remembering a long code to find it in a list among a bunch of other nearly-identical long codes is kind of hard if you don't already have a familiarity with what they are designating.
If it can't be done by magic, then having an option to copy the exact and complete name as it appears in the drop down list would be a good alternative. Like how code snippets often have the little "copy" button in the top-right corner.
4: other ways to make license choosing easier
The easier it is the more likely it will happen.
Allow user/organization to configure default license for new repos. Then you are not faced with re-reading the guidance document every time. Make a thoughtful decision once and revisit it only when needed.
Provide a page showing an overview of licenses of all repos for user/organization. Like https://codeberg.org/username?tab=repositories there could be a search filter/sort for license, and for needs-a-license. This would let people check easily if they forgot somewhere. For repos which are public, it would encourage accountability as other poeple could easily see an overview.
Have some toggle for the list on new repo page to be abbreviated on an opt-in basis. Most people do not need all these choices. Being able to click "Short list" or something and have everything but the most up to date and popular 5-10 options go away would make it easier if you are trying to jog your memory.
Somewhat conversely, I still think the full names would be worthwhile including in addition to the abbreviations. Previously I was trying to search for "gnu" instead of GPL which gets you like "GNU-compiler-exception". Other commonly-used name someone might want like mozilla or creative commons are likewise not findable.
There should be a link on the new repo page to wherever the licenses are stored. I assume in their own repo somewhere. So that the full text can be read by anyone so inclined prior to accepting it.
I do not find a way to add the license after the repo is created. If it exists it's hard to find. If it doesn't exist it would be nice. In the settings have an "add license" section. Even if it is literally just a link to wherever the license are kept and instructions on how to do it manually. But better if it's magic of course. I think it's reasonable that you might want to work on something a little before deciding on a license.
Sorry there's so many things. It's a bit of a bike shed type thing probably but thought I'd throw them out there in case any of them sound like a good fit.
I've had this issue pinned as I was trying to articulate a request in https://codeberg.org/forgejo/forgejo as requested. But I couldn't get it very concise.
Now I see the linked documentation has been changed to https://docs.codeberg.org/getting-started/licensing. For me, I like the new one. I finally know which license to select from the list (AGPL 3.0 or later). I honestly couldn't figure it out before.
I feel that the document might be a little complicated for someone who isn't already framiliar with the concepts though. Maybe it's just impossible to explain in a way that's both reasonably accurate/nuanced *and also* extremely brief.
I am curious:
**1: are the effects measurable?**
Are there any metrics available describing how many people actually select a license at the "create repo" page and if it changes over time? Especially if it can be correlated with viewing the explainer document.
Hope it doesn't come across as excessively taylorist or snooping.
**2: flowchart flow**
Is the intention to make the "flowchart" section visually clearer? I am not framiliar with eleventy. Without adding a bunch of complexity to the whole repo would it be possible to add some more hints to help follow the narrative? Such as borders on the left side, highlight on mouse over? Like this (tiny on purpose to show structure not content):
**3: easy input license into form**
Would it be possible to have links next to each license name that brings you to the new repo page with that form filled? Could look like this:
> - No --> We recommend using the AGPL-3.0-or-later licence [๎ create repo with this license](https://codeberg.org/repo/create?license=AGPL-3.0-or-later)
With that URL being `https://codeberg.org/repo/create?license=AGPL-3.0-or-later` and clicking it does this:
Not sure if it would/could go back to the previous tab the user arrived from or if it just opens a fresh one.
It might sound excessively hand-holding but remembering a long code to find it in a list among a bunch of other nearly-identical long codes is kind of hard if you don't already have a familiarity with what they are designating.
If it can't be done by magic, then having an option to copy the *exact* and *complete* name as it appears in the drop down list would be a good alternative. Like how code snippets often have the little "copy" button in the top-right corner.
**4: other ways to make license choosing easier**
The easier it is the more likely it will happen.
- Allow user/organization to configure default license for new repos. Then you are not faced with re-reading the guidance document every time. Make a thoughtful decision once and revisit it only when needed.
- Provide a page showing an overview of licenses of all repos for user/organization. Like https://codeberg.org/username?tab=repositories there could be a search filter/sort for license, and for needs-a-license. This would let people check easily if they forgot somewhere. For repos which are public, it would encourage accountability as other poeple could easily see an overview.
- Have some toggle for the list on new repo page to be abbreviated on an opt-in basis. Most people do not need all these choices. Being able to click "Short list" or something and have everything but the most up to date and popular 5-10 options go away would make it easier if you are trying to jog your memory.
- Somewhat conversely, I still think the full names would be worthwhile including in addition to the abbreviations. Previously I was trying to search for "gnu" instead of GPL which gets you like "GNU-compiler-exception". Other commonly-used name someone might want like mozilla or creative commons are likewise not findable.
- There should be a link on the new repo page to wherever the licenses are stored. I assume in their own repo somewhere. So that the full text can be read by anyone so inclined prior to accepting it.
- I do not find a way to add the license after the repo is created. If it exists it's hard to find. If it doesn't exist it would be nice. In the settings have an "add license" section. Even if it is literally just a link to wherever the license are kept and instructions on how to do it manually. But better if it's magic of course. I think it's reasonable that you might want to work on something a little before deciding on a license.
Sorry there's so many things. It's a bit of a bike shed type thing probably but thought I'd throw them out there in case any of them sound like a good fit.
I feel that the document might be a little complicated for someone who isn't already framiliar with the concepts though. Maybe it's just impossible to explain in a way that's both reasonably accurate/nuanced and also extremely brief.
Idea: Fork Choose a License and carry over the essential points of the current article ("our perspective") onto that tool?
> I feel that the document might be a little complicated for someone who isn't already framiliar with the concepts though. Maybe it's just impossible to explain in a way that's both reasonably accurate/nuanced and also extremely brief.
Idea: Fork [Choose a License](https://choosealicense.com/) and carry over the essential points of the current article ("our perspective") onto that tool?
Codeberg.org: removed quote, because spam user was deleted
Do you mean formatting of license texts, or formatting of the licensing guide, or formatting of documents in projects? For the latter, REUSE would define some sort of formatting which is even machine readable.
(Honestly, this post reads like a advertisement for this commercial service which is probably not interesting for this community.)
> Codeberg.org: removed quote, because spam user was deleted
Do you mean formatting of license texts, or formatting of the licensing guide, or formatting of documents in projects? For the latter, REUSE would define some sort of formatting which is even machine readable.
(Honestly, this post reads like a advertisement for this commercial service which is probably not interesting for this community.)
> (Honestly, this post reads like a advertisement for this commercial service which is probably not interesting for this community.)
Yes it does sound like that. @moderation
Just some additions to the recently added article from #173 (https://docs.codeberg.org/getting-started/licensing/)
Mention private repo / note-taking rule:
A user on Mastodon asked about private repos? We should mention that private repos are possible (re-link to the FAQ which explains this, but people only looking at the licensing guide will overlook the clarification in the FAQ and the section in the Terms of Use)
How to apply:
People might wonder how to apply a license to your code. AFAICT, it's usually considered okay to just put a file next to your code, but to properly license code and avoid any legal uncertainty, it should be explicitly stated that the code is under this license, right? Ideally, every file should include a license header.
It might be good to give good and precise instructions on how to actually change the license, especially since the full license texts are sometimes hard to copy into a easily readable file (so maybe tell people what's necessary to reference a file that lives outside etc).
A place where someone was hit by the "adding a file is enough" is in Codeberg/Community#407, and I agree that the Gitea UI kinda suggests that using the license dialog is everything you need.
Reasoning:
Some people might wonder why a repo needs a license. Some hints are kinda hidden, but they might be made more prominently.
@michielappelman are you interested in fixing this up once more? No obligation of course, your first version is already very nice, these are just some improvements I can think of by now.
Just some more thoughts:
I might eventually work this into the text. Sofar I was not active in contributing to the docs and don't know who is curating them.
So let me know if there are any objections.
I'm not an expert, but I actually consider the headers even more important because
As a reference: https://www.gnu.org/licenses/gpl-howto.en.html
Thank you for your feedback. The article about proper licensing is very important IMHO, because it's what we want to promote here and is a really important thing for us as a software forge, to give contributors at hand. So any improvement very welcome!
There is the lax rule of waiting for about two approvements before merging, less for less-important changes or when there is simply no more feedback after a while.
I think that personals views can make it into the licensing article, but I'd ask everyone to stay as objective as possible and to cover multiple perspectives. There are things people have fought war over, we should just quickly mention different arguments (e.g. copyleft vs temporarily open; license headers vs. one central place (promotion of the reuse project could also be an option), ...).
tok/codeberg-documentation@8f109fe51dNot a pull-request yet because it is late-night work. Just for reference and input to the discussion.
Another thought:
We should highlight that the licence is also about protecting the user from being sued for copyright or even patent infringement (as long as it relates to the licenced work). Especially the MIT licence basically allows that code can be used without copyright infringement but nevertheless the copyright owner can sue the user for patent infringement related to the licenced work. As a user this is good to know. Not sure if that happens often, though. So for this reason we should think about promoting the Apache Licence before the MIT licence.
Already checked out your commit from the explore view :)
Why did you switch from the OSI list to the FSF list in line 32/41? I don't know why the other one was listed there, though, maybe it's worth linking both as in the current no-license reminder inside the repos?
To the patent thing: It would be great to have resources if this happens, I have never heard of such a thing. It would also be very hard to claim patents if something was released for free use without mentioning the patent, I doubt this works in a court actually. But still, an interesting thought, that could be theoretically mentioned if no such evidence can be found.
I switched to the FSF list for following reasons:
We can indeed link to both. But I'd then also write a short explanation who they are (as objective as possible). I think it could be confusing otherwise.
The FSF on the X11 Licence and also Expat Licence (often called "the MIT licence"):
https://www.gnu.org/licenses/license-list.en.html#X11License
I'm not an expert on that, but maybe that's an interesting read:
https://international.vlex.com/vid/free-and-open-source-739218105
Also
As the article states, there seems to be unclarity.
Based on this I conclude that there's no guarantee that such software licences also give the user a licence to use a patent under the same conditions.
I believe that this can be avoided using licences with a 'patent clause' like the GPLv3 or Apache-2.0 do. Not only does this protect the user but it also protects the project from 'trojan' contributions.
Imagine Android would be licenced under the X11/Expat/MIT licence without a patent clause. It would be possible that somebody maliciously sneaks in a patented contribution and then later sues Google for patent infringement.
Yet another thought:
Do we want to have an opinion, recommendation or even terms-of-use regarding contributor licence agreements (CLA)?
I remember projects being licenced under an free and open-source licence but they required contributors to sign a CLA. The CLA basically said that the contributor transfers the copyright ownership to the project owner.
Such methods can be used as 'backdoors' to turn copyleft into non-copyleft or even proprietary code: If you are the only copyright owner of a software, then you can change the licence at will.
See for example https://en.wikipedia.org/wiki/Contributor_License_Agreement#Examples.
Comment on choosealicense.com
More ideas & comments:
I think, Codeberg can have its own recommendation of licences indeed (similar to what there is already).
However, I suggest to move this section more towards the top of the document and then later on go into explanations. I'm afraid, many people will not read the full text anyway.
About spelling: https://prowritingaid.com/art/492/Licence-vs--License%3A-Which-One-is-Right.aspx (trackers there)
In the US: license = noun, to license = verb
Everywhere else: licence = noun, to license = verb
Since codeberg.org is located in Germany, I suggest to use the latter spelling. (I was not being consistent myself, but will try from now on)
I'm afraid I only scanned through your comments. Feel free to just go ahead and realize them. We are happy about every contribution, and the current state does in no way reflect an official stance or anything, but is simply a very first contribution we received and allowed us to make licensing more clear to our users than it has been before. There is always a lot of room for improvements.
I had extensive offline discussions with @tok. Below are some of the thoughts which emerged:
In the statute of Codeberg is written that:
but in the current licencing page is written that:
The two should be consistent. Maybe rather than trying to deduce from abstract principles it is enought to state that term of use of codeberg requires the use of an open-source licence for all project. One can later explain why this is important.
Thank you for this easier-to-read list of points. We could even convert this into ToDo-Boxes (
[ ]) and ask people to pick one (some) of them.&
rather link to it, please
This page was mainly a blocker for licence reminders to spread awareness, and is thus mainly linked there. So the most important thing is to make people understand why a FLOSS licence is the thing we all want in their repo, not "just because it's in the Terms of Use". Whoever is going to rework this, please keep in mind that people might read the article without even fully understanding what this spirit means. I know many people who literally thought that they are contributing to Open Source because they put their code into a publicly accessible space (like a Git(Hub) repo). Those will be redirected to this article, and they should be caring about FLOSS afterwards ๐
@fnetX Ah, I did not fully get that people will be mainly redirected there with the licence reminder. Thanks!
I had in mind to start like this:
Perhaps indicate that REUSE (https://reuse.software/) is the prefered (expected) approach.
Copy from the original issue, I think this is the part not yet implemented but proposed in the now-closed issue.
For a public domain equivalent license, we recommend using 0BSD instead of other licenses. I think it would be beneficial to explain why: it has better reception and recognition from companies.
Relevant comment on choosealicence.com: https://github.com/github/choosealicense.com/issues/805#issuecomment-799220564
Found this issue via Community repo: Codeberg/Community#624 I apologize if this should be a separate issue or in a different tracker; this is my best guess.
Currently the new repo page still links to https://choosealicense.com/ where MIT license is prominently and favorably described as mentioned previously.
I would suggest that when this is fixed, the drop down list should correspond to the names given on the provided documentation.
This libre license advocated by the linked page is "GNU GPLv3". If I type "GNU" into the drop down I get
gnu-javamail-exceptionandgnu-plot. Type "GPL" and there are about 2 dozen options. "GPLv3" shows nothing but there are 4x variations underGPL-3.0-. In my browser the drop down only show 3 lines at a time so it is not easy to find thatv3is described as-3.0-.. you need to hunt a lot if you don't already know that. Then, I don't know which one actually is the same one I want.It's fine to have the long extensive list for those who wish to use it, but the first items should be exactly the same wording as whatever documentation is provided. In this case, the top item should be
GNU GPLv3, followed, I guess, byMIT.I'm in favour of promoting https://writefreesoftware.org/ from Codeberg, replacing Choose a license where applicable. WriteFreeSoftware aligns better with our mission, is more approachable in my opinion, and covers more than "simply choosing a license". Because writing Free Software does not end with picking a choice from a checkbox alone.
I am guessing you would link directly to Choosing a license? If yes I think it is a huge improvement over the existing link. It very succinctly touches on a range of issues to consider.
With regards to my previous comment about the licenses being findable in the list, I think the change of link should be made irregardless.
But I would like to point out that of the libre licenses recommended, none of them are findable. (Both the MIT and BSD licenses are findable though.)
The problem is that abbreviations are being used instead of the full names. Also, the GPL abbreviations have different word orders than the full names on this website. So they are not located in the expected alphabetical order.
On my desktop browser, this drop down shows up with a fancy type-to-find widget that should make obtaining the correct item from the long list pretty fast. Yes none of them are findable this way; you really have to scroll through the list which only shows 3 lines at a time.
The solution could be to list the full name along with abbreviations. For example, replace "MPL-2.0" with "Mozilla Public License 2.0 (MPL-2.0)". Assuming other browsers work the same way mine does, this would still allow people who know the abbreviation they are looking for to locate easily (typing "mpl").
Idk if there is some other reason why the listings are abbreviation-only. Internationalization?
Could you try to propose your changes to the license chooser to https://codeberg.org/forgejo/forgejo?
The list is autogenerated from SPDX license data, but I'm pretty sure that someone could make adjustments to this process to allow the format "Full Name (Short Name)".
I've had this issue pinned as I was trying to articulate a request in https://codeberg.org/forgejo/forgejo as requested. But I couldn't get it very concise.
Now I see the linked documentation has been changed to https://docs.codeberg.org/getting-started/licensing. For me, I like the new one. I finally know which license to select from the list (AGPL 3.0 or later). I honestly couldn't figure it out before.
I feel that the document might be a little complicated for someone who isn't already framiliar with the concepts though. Maybe it's just impossible to explain in a way that's both reasonably accurate/nuanced and also extremely brief.
I am curious:
1: are the effects measurable?
Are there any metrics available describing how many people actually select a license at the "create repo" page and if it changes over time? Especially if it can be correlated with viewing the explainer document.
Hope it doesn't come across as excessively taylorist or snooping.
2: flowchart flow
Is the intention to make the "flowchart" section visually clearer? I am not framiliar with eleventy. Without adding a bunch of complexity to the whole repo would it be possible to add some more hints to help follow the narrative? Such as borders on the left side, highlight on mouse over? Like this (tiny on purpose to show structure not content):
3: easy input license into form
Would it be possible to have links next to each license name that brings you to the new repo page with that form filled? Could look like this:
With that URL being
https://codeberg.org/repo/create?license=AGPL-3.0-or-laterand clicking it does this:Not sure if it would/could go back to the previous tab the user arrived from or if it just opens a fresh one.
It might sound excessively hand-holding but remembering a long code to find it in a list among a bunch of other nearly-identical long codes is kind of hard if you don't already have a familiarity with what they are designating.
If it can't be done by magic, then having an option to copy the exact and complete name as it appears in the drop down list would be a good alternative. Like how code snippets often have the little "copy" button in the top-right corner.
4: other ways to make license choosing easier
The easier it is the more likely it will happen.
Allow user/organization to configure default license for new repos. Then you are not faced with re-reading the guidance document every time. Make a thoughtful decision once and revisit it only when needed.
Provide a page showing an overview of licenses of all repos for user/organization. Like https://codeberg.org/username?tab=repositories there could be a search filter/sort for license, and for needs-a-license. This would let people check easily if they forgot somewhere. For repos which are public, it would encourage accountability as other poeple could easily see an overview.
Have some toggle for the list on new repo page to be abbreviated on an opt-in basis. Most people do not need all these choices. Being able to click "Short list" or something and have everything but the most up to date and popular 5-10 options go away would make it easier if you are trying to jog your memory.
Somewhat conversely, I still think the full names would be worthwhile including in addition to the abbreviations. Previously I was trying to search for "gnu" instead of GPL which gets you like "GNU-compiler-exception". Other commonly-used name someone might want like mozilla or creative commons are likewise not findable.
There should be a link on the new repo page to wherever the licenses are stored. I assume in their own repo somewhere. So that the full text can be read by anyone so inclined prior to accepting it.
I do not find a way to add the license after the repo is created. If it exists it's hard to find. If it doesn't exist it would be nice. In the settings have an "add license" section. Even if it is literally just a link to wherever the license are kept and instructions on how to do it manually. But better if it's magic of course. I think it's reasonable that you might want to work on something a little before deciding on a license.
Sorry there's so many things. It's a bit of a bike shed type thing probably but thought I'd throw them out there in case any of them sound like a good fit.
Idea: Fork Choose a License and carry over the essential points of the current article ("our perspective") onto that tool?
Do you mean formatting of license texts, or formatting of the licensing guide, or formatting of documents in projects? For the latter, REUSE would define some sort of formatting which is even machine readable.
(Honestly, this post reads like a advertisement for this commercial service which is probably not interesting for this community.)
Yes it does sound like that. @moderation