Codeberg/Documentation
43
151
Fork
You've already forked Documentation
129

#174: Proposal for more extensive article on licensing. #181

Merged
fnetX merged 13 commits from tok/codeberg-documentation:main into main 2022年03月07日 16:22:02 +01:00
Contributor
Copy link

Text is according to the discussion on the issue #174.

Text is according to the discussion on the issue #174.
n left a comment
Contributor
Copy link

Thank you for this comprehensive PR.
I haven't looked at everything closely, but here are my initial comments.

Thank you for this comprehensive PR. I haven't looked at everything closely, but here are my initial comments.
@ -14,3 +14,1 @@
> * The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
> * The freedom to redistribute copies so you can help others (freedom 2).
> * The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.
[Copyright law is extremely powerful](https://www.gnu.org/philosophy/enforcing-gpl.en.html). In fact it grants the author of a work exclusive rights to use or distribute their work. An author can grant permission of using his work under arbitrary conditions: Just for illustration, an author could invent for example a "coffee licence" and impose that whoever uses his work has to offer the author a coffee. Similarly, forever-open licences grant users the right to use the work provided that they will redistribute any derivative work using the same licence again (copyleft).
Contributor
Copy link
-In fact it grants the
+In fact, it grants the
```diff -In fact it grants the +In fact, it grants the ```
fnetX marked this conversation as resolved
@ -17,2 +14,3 @@
[Copyright law is extremely powerful](https://www.gnu.org/philosophy/enforcing-gpl.en.html). In fact it grants the author of a work exclusive rights to use or distribute their work. An author can grant permission of using his work under arbitrary conditions: Just for illustration, an author could invent for example a "coffee licence" and impose that whoever uses his work has to offer the author a coffee. Similarly, forever-open licences grant users the right to use the work provided that they will redistribute any derivative work using the same licence again (copyleft).
This page highlights some of the major topics to think about when licensing your code and aims to make it easy to choose one quickly. However, do make sure to dedicate more time to this if you have very specific goals in mind or expect a significant impact of your code.
# Major licence categories
Contributor
Copy link

Please start headings with ##, since # is used for the inital title.

Please start headings with `##`, since `#` is used for the inital title.
fnetX marked this conversation as resolved
@ -23,2 +20,3 @@
One of the major distinctions between licences is between:
> If a program is free but not copylefted, then some copies or modified versions may not be free at all. A software company can compile the program, with or without modifications, and distribute the executable file as a proprietary software product.
1. licences which guarantee the perpetual openness of the code. These licences are known as copyleft licences or forever-open licences. The GPL licences belongs to this category.
Contributor
Copy link

Someone reading this might think: How does it guarantee perpetual openness of the code?

We should explain that copyleft licenses require sharing your modifications under similar terms as the original licence.

I haven't ever heard of the term 'forever-open licences' being used. I think we should stick to calling them by the more widely used term: 'copyleft licences'.

First letter uppercase please.

Someone reading this might think: How does it guarantee perpetual openness of the code? We should explain that copyleft licenses require sharing your modifications under similar terms as the original licence. --- I haven't ever heard of the term 'forever-open licences' being used. I think we should stick to calling them by the more widely used term: 'copyleft licences'. --- First letter uppercase please.
Author
Contributor
Copy link

Someone reading this might think: How does it guarantee perpetual openness of the code?

Good point!

I haven't ever heard of the term 'forever-open licences' being used. I think we should stick to calling them by the more widely used term: 'copyleft licences'.

Indeed, that's not common terms. But I generally like the idea of calling something by what it is. The word "copyleft" on its own has no meaning to somebody who is not familiar with the concept. "forever-open" speaks for itself.

On the other hand "permissive" has a meaning on its own. It sounds somehow fair and good: You want to permit others to use your code. Ten years ago I was choosing permissive licences over a copyleft licences just because of the name. I did not know "copyleft". So I think there's a bias coming from the naming.

Philosophy aside, I see your point about sticking to common terms.

What would be your favourite option?

  • experiment with new terms, use them instead of copyleft/permissive. But of course also clearly mention the common terms.
  • use the new terms only for the sake of explaining copyleft/non-copyleft, then through the document use "copyleft/non-copyleft".
  • remove the "forever/temporarily-open" terms completely
> Someone reading this might think: How does it guarantee perpetual openness of the code? Good point! > I haven't ever heard of the term 'forever-open licences' being used. I think we should stick to calling them by the more widely used term: 'copyleft licences'. Indeed, that's not common terms. But I generally like the idea of calling something by what it is. The word "copyleft" on its own has no meaning to somebody who is not familiar with the concept. "forever-open" speaks for itself. On the other hand "permissive" has a meaning on its own. It sounds somehow fair and good: You *want* to permit others to use your code. Ten years ago I was choosing permissive licences over a copyleft licences just because of the name. I did not know "copyleft". So I think there's a bias coming from the naming. Philosophy aside, I see your point about sticking to common terms. What would be your favourite option? * experiment with new terms, use them instead of copyleft/permissive. But of course also clearly mention the common terms. * use the new terms only for the sake of explaining copyleft/non-copyleft, then through the document use "copyleft/non-copyleft". * remove the "forever/temporarily-open" terms completely
Contributor
Copy link

I would recommend sticking to copyleft and permissive, and removing the forever/temporarily-open labels. It would cause more confusion if someone were to search for a forever-open license and get no relevant results.

I would recommend sticking to copyleft and permissive, and removing the forever/temporarily-open labels. It would cause more confusion if someone were to search for a forever-open license and get no relevant results.
Contributor
Copy link

Also the SLFC has a very good explanation of copyleft that we could borrow from:

One important copyright concept that originated in the world of FOSS licensing is "copyleft". "Copyleft" is a play on the word "copyright". Whereas copyright law has traditionally been used to withhold permission to copy, modify or distribute software, some licenses instead use copyright law to require that such permissions be granted.

Copyleft licenses are conditional licenses. One of the conditions you must satisfy before distributing copylefted software is that any changes you make to that software be likewise released under the copylefted license. A copyleft license ensures that all modified versions of your project remain free in the same way. Such licenses are said to keep code "forever free".

https://softwarefreedom.org/resources/2008/foss-primer.html

Also the SLFC has a very good explanation of copyleft that we could borrow from: > One important copyright concept that originated in the world of FOSS licensing is "copyleft". "Copyleft" is a play on the word "copyright". Whereas copyright law has traditionally been used to withhold permission to copy, modify or distribute software, some licenses instead use copyright law to require that such permissions be granted. > > Copyleft licenses are conditional licenses. One of the conditions you must satisfy before distributing copylefted software is that any changes you make to that software be likewise released under the copylefted license. A copyleft license ensures that all modified versions of your project remain free in the same way. Such licenses are said to keep code "forever free". https://softwarefreedom.org/resources/2008/foss-primer.html
@ -23,2 +21,3 @@
> If a program is free but not copylefted, then some copies or modified versions may not be free at all. A software company can compile the program, with or without modifications, and distribute the executable file as a proprietary software product.
1. licences which guarantee the perpetual openness of the code. These licences are known as copyleft licences or forever-open licences. The GPL licences belongs to this category.
2. licences which permit to close the source. These licences are known as permissive licences or temporarily-open licences. The MIT licence or the Apache licence belong to this category.
Contributor
Copy link

Similar points as above.

Similar points as above.
@ -25,2 +23,3 @@
2. licences which permit to close the source. These licences are known as permissive licences or temporarily-open licences. The MIT licence or the Apache licence belong to this category.
An example of one of the strongest copyleft licenses is the [GNU Affero General Public License](https://www.gnu.org/licenses/why-affero-gpl.html). It adds a requirement that even when a modified program is run on a server and lets other users communicate with it, your server must also allow them to download the source code corresponding to the modified version.
There is no general rule for choosing one of the other in every situation, but as a rule-of-thumb we encourage using forever-open licences whenever possible.
Contributor
Copy link
-There is no general rule for choosing one of the other in every situation, but as a rule-of-thumb we encourage using forever-open licences whenever possible.
+There is no general rule for choosing one or the other, but we encourage using forever-open licences whenever possible.
```diff -There is no general rule for choosing one of the other in every situation, but as a rule-of-thumb we encourage using forever-open licences whenever possible. +There is no general rule for choosing one or the other, but we encourage using forever-open licences whenever possible. ```
fnetX marked this conversation as resolved
@ -42,2 +38,3 @@
For documentation, writing and other non-code assets a [Creative Commons (CC)](https://creativecommons.org/about/cclicenses/) license can be used, but note that only the following CC licenses are considered free (again sorted from protective to unconditional):
It can occur that different projects licenced with different open-source licences cannot be used together in a single, often larger, project because the licences require incompatible conditions.
Some licences, in fact, impose on developers (thanks to the power granted by copyright law) some restrictions/obligations on any [derivative work](https://en.wikipedia.org/wiki/Derivative_work). The term "derivative work" has a precise meaning in copyright law: For example when a developer modifies the source code written by somebody else, he has created a derivative work.
Contributor
Copy link
-For example when a developer modifies the source code written
+For example, when a developer modifies source code written

Please use gender-neutral language.

-he has created a derivative work.
+they have created a derivative work.
```diff -For example when a developer modifies the source code written +For example, when a developer modifies source code written ``` --- Please use gender-neutral language. ```diff -he has created a derivative work. +they have created a derivative work. ```
fnetX marked this conversation as resolved
@ -44,0 +40,4 @@
Some licences, in fact, impose on developers (thanks to the power granted by copyright law) some restrictions/obligations on any [derivative work](https://en.wikipedia.org/wiki/Derivative_work). The term "derivative work" has a precise meaning in copyright law: For example when a developer modifies the source code written by somebody else, he has created a derivative work.
As an example, if program A is licenced under GPL version 3 and program B is licenced under the Microsoft Public Licence [Ms-Pl](https://directory.fsf.org/wiki/License:MS-PL), the GPL requires to re-licence any derivative work based on both programs A and B again under GPL, while the Ms-Pl requires to re-licence the derivative work under Ms-Pl: the two conditions are incompatible with each other.
The incompatibility between licences is clearly a headache for every developer. A possible way out, and the one we recommend, is to use only mainstream licences (as recommended in this page) and hence avoid licence proliferation.
For more information on licence compatibility we recommend the commented [licence list curated by the GNU project](https://www.gnu.org/licenses/license-list.html).
Contributor
Copy link
-For more information on licence compatibility we recommend
+For more information on licence compatibility, we recommend
```diff -For more information on licence compatibility we recommend +For more information on licence compatibility, we recommend ```
fnetX marked this conversation as resolved
@ -44,0 +45,4 @@
## Conflict-of-interests
The open-source community is represented by a multitude of players with different, and sometimes opposite, interests. For example, the prominent websites [ChooseALicense.com](https://choosealicense.com) is curated by GitHub and can be assumed to reflect at least partially the interests of Microsoft: This website presents for example GPL last on the front page and it is silent about the missing patent clause in the MIT licence both in the front page and in the [dedicated page](https://choosealicense.com/licenses/mit/ ). Moreover, the wording "I want it simple and permissive" can induce people to favour the MIT licence: Laypeople will want to have legal matters simple, and "permissive" sounds like fair and good.
When visiting other websites we recommend inspecting its governance and the risk of conflicting interests.
Contributor
Copy link

Critiquing other guides is not appropriate for this documentation.
However you do make a good point that can be summarized to:

The open-source community is represented by a variety of groups with different interests. 
We recommend exercising discretion when reading articles on licensing (including this one).
Critiquing other guides is not appropriate for this documentation. However you do make a good point that can be summarized to: ```markdown The open-source community is represented by a variety of groups with different interests. We recommend exercising discretion when reading articles on licensing (including this one). ```
fnetX marked this conversation as resolved
@ -44,0 +55,4 @@
## Software projects
For software projects we recommend whenever possible to utilize a copyleft/forever-open licence. The only well-established licences of this type are those of the GNU General Public Licence (GPL) family. The GPL licences have evolved over time and come with different versions. Unfortunately some versions are not compatible with older ones. To avoid [licence proliferation](https://en.wikipedia.org/wiki/License_proliferation) and to ease compatibility with future versions we recommend to use the "GNU Affero General Public Licence v3.0 or later" with SPDK licence identifier ["AGPL-3.0-or-later"](https://spdx.org/licenses/). The AGPL provides the maximum openness of the code: Even when the software runs on a server, users who interact with that software (e.g. over a network connection) are entitled to receive a copy of the source code.
Contributor
Copy link
-For software projects we recommend whenever possible to utilize a copyleft/forever-open licence.
+For software projects, we recommend using a copyleft licence.

-Unfortunately some versions
+Unfortunately, some versions

-To avoid licence proliferation and to ease compatibility with future versions we recommend to use the
+To avoid licence proliferation and to allow compatibility with future versions, we recommend using

-with SPDK licence identifier
+with SPDX licence identifier
```diff -For software projects we recommend whenever possible to utilize a copyleft/forever-open licence. +For software projects, we recommend using a copyleft licence. ``` ```diff -Unfortunately some versions +Unfortunately, some versions ``` ```diff -To avoid licence proliferation and to ease compatibility with future versions we recommend to use the +To avoid licence proliferation and to allow compatibility with future versions, we recommend using ``` ```diff -with SPDK licence identifier +with SPDX licence identifier ```
fnetX marked this conversation as resolved
@ -44,0 +58,4 @@
For software projects we recommend whenever possible to utilize a copyleft/forever-open licence. The only well-established licences of this type are those of the GNU General Public Licence (GPL) family. The GPL licences have evolved over time and come with different versions. Unfortunately some versions are not compatible with older ones. To avoid [licence proliferation](https://en.wikipedia.org/wiki/License_proliferation) and to ease compatibility with future versions we recommend to use the "GNU Affero General Public Licence v3.0 or later" with SPDK licence identifier ["AGPL-3.0-or-later"](https://spdx.org/licenses/). The AGPL provides the maximum openness of the code: Even when the software runs on a server, users who interact with that software (e.g. over a network connection) are entitled to receive a copy of the source code.
The [Affero GPL v3.0](https://www.gnu.org/licenses/agpl-3.0.en.html) is compatible with the [GPL v3.0](https://www.gnu.org/licenses/gpl-3.0.en.html) and vice-versa thanks to article 13 in each licence.
If using the Affero General Public Licence (AGPL) v3.0 or later is not an option, we recommend to use another licence of the GNU family, such as the General Public Licence (GPL), or the Lesser General Public Licence (LGPL), always indicating the version "**v3.0 or later**".
Contributor
Copy link

We shouldn't completely discourage AGPL, but make each licence's advantages and disadvantages known. What licence someone chooses depends on what they're licensing with it, and if they're licensing server software software, it makes more sense to use AGPL.

We shouldn't completely discourage AGPL, but make each licence's advantages and disadvantages known. What licence someone chooses depends on what they're licensing with it, and if they're licensing server software software, it makes more sense to use AGPL.
Author
Contributor
Copy link

That was actually meant to be encouraging in the following sense: Choose the strongest protection compatible with the project. In my own experience, software can very often be 'server software'.
A simple example: A script to generate ASCII art does not look like server software and might be licenced under the GPL. But it can be turned into a proprietary online ASCII-art-service.

So if user-freedoms are important, then the AGPL should be chosen if there are no reasons against.

Reasons against could be:

  • The trigger condition "user interaction" is unwanted.
  • The employer does not like the AGPL.
  • The project must be usable to create closed-source services.
  • The project must be usable with some existing project where the AGPL would lead to a licence conflict.
  • The project is tiny enough, such that copyleft does not make much sense.

Do you have in mind to point out that the GPL does not yet get triggered when users are interacting with the software but only when they get a copy of the software?

Or do you think about some table showing advantages and disadvantages without implying an order among licences?

Sorry for so much text, but I think it is helpful to discuss that.

That was actually meant to be encouraging in the following sense: Choose the strongest protection compatible with the project. In my own experience, software can very often be 'server software'. A simple example: A script to generate ASCII art does not look like server software and might be licenced under the GPL. But it can be turned into a proprietary online ASCII-art-service. So if user-freedoms are important, then the AGPL should be chosen if there are no reasons against. Reasons against could be: * The trigger condition "user interaction" is unwanted. * The employer does not like the AGPL. * The project must be usable to create closed-source services. * The project must be usable with some existing project where the AGPL would lead to a licence conflict. * The project is tiny enough, such that copyleft does not make much sense. Do you have in mind to point out that the GPL does not yet get triggered when users are interacting with the software but only when they get a copy of the software? Or do you think about some table showing advantages and disadvantages without implying an order among licences? Sorry for so much text, but I think it is helpful to discuss that.
Contributor
Copy link

Yeah, we could give a list of common reasons to choose more copyleft or more permissive licences, while recommending to choose more copyleft licences.

A table would be very useful to compare different types of licences. Wikipedia has some we could modify:
https://en.wikipedia.org/wiki/Free-software_license#Comparison

Yeah, we could give a list of common reasons to choose more copyleft or more permissive licences, while recommending to choose more copyleft licences. A table would be very useful to compare different types of licences. Wikipedia has some we could modify: https://en.wikipedia.org/wiki/Free-software_license#Comparison
Owner
Copy link

I don't think we should "recommend", rather "point out popular choices". IMHO, there are many reasons not to use strong copyleft, especially if you "don't care" where your project ends and just want to get Licencing out of your way (or: if you code so that your project can be used as often as possible).

Different opinions need different licences, so I'd like to outline their main points as objectively as possible and hope users can make the decision they feel best with.

Adding your examples (e.g. consider that your code can be used without stating changes in online services if it's not AGPL etc) makes sense, so people caring about will come to the very similar conclusion, choosing AGPL for their project if possible.

I don't think we should "recommend", rather "point out popular choices". IMHO, there are many reasons not to use strong copyleft, especially if you "don't care" where your project ends and just want to get Licencing out of your way (or: if you code so that your project can be used as often as possible). Different opinions need different licences, so I'd like to outline their main points as objectively as possible and hope users can make the decision they feel best with. Adding your examples (e.g. consider that your code can be used without stating changes in online services if it's not AGPL etc) makes sense, so people caring about will come to the very similar conclusion, choosing AGPL for their project if possible.
@ -44,0 +59,4 @@
The [Affero GPL v3.0](https://www.gnu.org/licenses/agpl-3.0.en.html) is compatible with the [GPL v3.0](https://www.gnu.org/licenses/gpl-3.0.en.html) and vice-versa thanks to article 13 in each licence.
If using the Affero General Public Licence (AGPL) v3.0 or later is not an option, we recommend to use another licence of the GNU family, such as the General Public Licence (GPL), or the Lesser General Public Licence (LGPL), always indicating the version "**v3.0 or later**".
In some cases, such as when writing certain libraries, using the Lesser General Public Licence (LGPL) may lead to a broader usage. In such cases the [LGPL is preferred over the (A)GPL](https://www.gnu.org/licenses/gpl-faq.en.html#WhySomeGPLAndNotLGPL).
Contributor
Copy link
-In such cases the LGPL
+In such cases, the LGPL
```diff -In such cases the LGPL +In such cases, the LGPL ```
fnetX marked this conversation as resolved
@ -44,0 +60,4 @@
If using the Affero General Public Licence (AGPL) v3.0 or later is not an option, we recommend to use another licence of the GNU family, such as the General Public Licence (GPL), or the Lesser General Public Licence (LGPL), always indicating the version "**v3.0 or later**".
In some cases, such as when writing certain libraries, using the Lesser General Public Licence (LGPL) may lead to a broader usage. In such cases the [LGPL is preferred over the (A)GPL](https://www.gnu.org/licenses/gpl-faq.en.html#WhySomeGPLAndNotLGPL).
For software which is not very long (e.g. less than 300 lines of code) or unimportant, rather than using a copyleft licence you may use a [lax permissive licence instead](https://www.gnu.org/licenses/gpl-faq.en.html#WhatIfWorkIsShort).
Contributor
Copy link

They don't have to get our permission :)

-you may use
+you may consider using
They don't have to get our permission :) ```diff -you may use +you may consider using ```
fnetX marked this conversation as resolved
@ -44,0 +64,4 @@
If you are not allowed, or if you do not want, to use a forever-open licence (for example because the company you work for does not allow you to do so) we recommend to use a temporarily-open or permissive (in the sense that it permits users to close the code) licence which contains a patent provision. To avoid proliferation of licences, we recommend therefore to use the Apache licence version 2.0 (SPDK licence identifier Apache-2.0).
We recommend to follow the guidelines defined by the [GNU project](https://www.gnu.org/licenses/licenses.html). These guidelines are recommended by the [Free Software Foundation](https://fsf.org) too.
Contributor
Copy link
-We recommend to follow the guidelines
+We recommend following the guidelines
```diff -We recommend to follow the guidelines +We recommend following the guidelines ```
Owner
Copy link

not yet resolved

not yet resolved
fnetX marked this conversation as resolved
@ -44,0 +70,4 @@
We distinguish primarily between two families of hardware projects:
1. hardware projects with little or no software depedences (e.g. projects containing CAD drawings), and
Contributor
Copy link
-no software depedences
+no software dependencies
```diff -no software depedences +no software dependencies ```
Owner
Copy link

same here

same here
fnetX marked this conversation as resolved
@ -44,0 +73,4 @@
1. hardware projects with little or no software depedences (e.g. projects containing CAD drawings), and
2. hardware projects containing important software dependencies (e.g. the design of an integrated circuit) where compatibility issues with other licences may arise.
In the first case we recommend the use of the CERN Open Hardware Licence Version 2 - Strongly Reciprocal (SPDX licence identifier: CERN-OHL-S-2.0). This licence guarantees the forever-openness of the project, but is incompatible with other mainstream licences like those of the GNU-GPL family.
Contributor
Copy link
-In the first case we recommend 
+In the first case, we recommend
```diff -In the first case we recommend +In the first case, we recommend ```
fnetX marked this conversation as resolved
@ -44,0 +75,4 @@
In the first case we recommend the use of the CERN Open Hardware Licence Version 2 - Strongly Reciprocal (SPDX licence identifier: CERN-OHL-S-2.0). This licence guarantees the forever-openness of the project, but is incompatible with other mainstream licences like those of the GNU-GPL family.
In the second case there is currently no copyleft/forever-open licence with wide licence compatibility which is able to protect a hardware device. This is primarily due to the fact that hardware objects are not protected by Copyright law. While awaiting for the appearance of a suited licence, we recommend the use the "GNU Affero General Public Licence v3.0 or later" whenever the use of a CERN Open Hardware Licence is not permitted.
Contributor
Copy link
-In the second case there
+In the second case, there

While awaiting for the appearance of a suited licence, we recommend the use the..

Not sure what this means..

```diff -In the second case there +In the second case, there ``` --- > While awaiting for the appearance of a suited licence, we recommend the use the.. Not sure what this means..
@ -50,0 +90,4 @@
# How to include a licence
For instructions on how to correctly include a licence into your project, we recommend to follow the [tutorial for becoming "REUSE-compliant"](https://reuse.software/tutorial/).
Contributor
Copy link
-we recommend to follow the
+we recommend following the
```diff -we recommend to follow the +we recommend following the ```
fnetX marked this conversation as resolved
Author
Contributor
Copy link

Thank you for the review!

Quick question (I'm not yet that familiar with gitea): The diffs shown in your comments, are they just comments or actual changes somewhere which I can merge?

Thank you for the review! Quick question (I'm not yet that familiar with gitea): The diffs shown in your comments, are they just comments or actual changes somewhere which I can merge?
Owner
Copy link

Only manual comments AFAIK, with

```diff
+ blah
- blah
```

↓

+ blah
- blah
Only manual comments AFAIK, with ~~~ ```diff + blah - blah ``` ~~~ ↓ ```diff + blah - blah

This is quite an extensive update, @tok. Very nicely done, you obviously have a lot more knowledge on this topic then I have!

One note I do want to make is that all the additional info has made it more difficult to actually choose a license. Perhaps it could be worthwhile to move some more 'advanced' topics to a separate page?

I particularly like the comment from @n

The open-source community is represented by a variety of groups with different interests. We recommend exercising discretion when reading articles on licensing (including this one).

Perhaps this would be a point time to mention and link to an additional page that further documents Codeberg's position and other topics such as REUSE, etc.

Although I do appreciate that it is a complicated topic indeed, I hope our common goal is to make FOSS more prevalent in the world and for that need to lower the barrier to entry.

This is quite an extensive update, @tok. Very nicely done, you obviously have a lot more knowledge on this topic then I have! One note I do want to make is that all the additional info has made it more difficult to actually choose a license. Perhaps it could be worthwhile to move some more 'advanced' topics to a separate page? I particularly like the comment from @n > The open-source community is represented by a variety of groups with different interests. We recommend exercising discretion when reading articles on licensing (including this one). Perhaps this would be a point time to mention and link to an additional page that further documents Codeberg's position and other topics such as REUSE, etc. Although I do appreciate that it is a complicated topic indeed, I hope our common goal is to make FOSS more prevalent in the world and for that need to lower the barrier to entry.
Author
Contributor
Copy link

@michielappelman Thanks for the feedback. As you've seen there was already quite some comments and I want to integrate them into our proposal.

I think there is currently two different views on 'recommendations'. One says that we should rather be discrete since many projects have many different requirements.

The other (also mine) is: Being discrete and neutral is also a position. It is kind of a don't-care position which does not fit with Codebergs mission. Since there is so much lobbying from big technology organizations it is right to develop here a suggestion which fosters for example copyleft and avoids further fragmentation by proliferation of licenses.

Some ordered list as is in your article could make sense. I imagine something like this (especially for hardware and other creative work the choice is not complete, I just wrote something):

If you don't want to dive into details, consider the following lists to make a choice. Our recommendation is to use the first license in the list which does not 
conflict with any specific requirements of your project.
The licenses are sorted from 'strongest guarantee of user freedom' to 'weakest guarantee of user freedom'.
For software projects:
* AGPLv3+
* GPLv3+
* LGPLv3+
* Apache 2.0
* Public Domain
For hardware projects:
* OHL-S v2
* OHL-W v2
* OHL-P v2
For other creative work:
* CC-BY-SA
* ...
* ...

Yes, I think we should definitely link to REUSE. Especially for how to apply the license to the project.

But also, I think it is impossible to make a good choice if somebody does not understand the backgrounds (copyright, license, copyleft).

The tradeoff here is between:

  1. Don't ask the readers to think, give them a recommendation without much education.
  2. Educate the readers and empower them to make an informed decision.

Looking at Codebergs mission, I think we have to go for the second option.

A an acceptable solution could be to include at the top a link "TL;DR Just suggest me a license without explanations." which points to the above list.

@michielappelman Thanks for the feedback. As you've seen there was already quite some comments and I want to integrate them into our proposal. I think there is currently two different views on 'recommendations'. One says that we should rather be discrete since many projects have many different requirements. The other (also mine) is: Being discrete and neutral is also a position. It is kind of a don't-care position which does not fit with Codebergs mission. Since there is so much lobbying from big technology organizations it is right to develop here a suggestion which fosters for example copyleft and avoids further fragmentation by proliferation of licenses. Some ordered list as is in your article could make sense. I imagine something like this (especially for hardware and other creative work the choice is not complete, I just wrote something): ``` If you don't want to dive into details, consider the following lists to make a choice. Our recommendation is to use the first license in the list which does not conflict with any specific requirements of your project. The licenses are sorted from 'strongest guarantee of user freedom' to 'weakest guarantee of user freedom'. For software projects: * AGPLv3+ * GPLv3+ * LGPLv3+ * Apache 2.0 * Public Domain For hardware projects: * OHL-S v2 * OHL-W v2 * OHL-P v2 For other creative work: * CC-BY-SA * ... * ... ``` Yes, I think we should definitely link to REUSE. Especially for *how* to apply the license to the project. But also, I think it is impossible to make a good choice if somebody does not understand the backgrounds (copyright, license, copyleft). The tradeoff here is between: 1) Don't ask the readers to think, give them a recommendation without much education. 2) Educate the readers and empower them to make an informed decision. Looking at Codebergs mission, I think we *have* to go for the second option. A an acceptable solution could be to include at the top a link "TL;DR Just suggest me a license without explanations." which points to the above list.

I think there are two points to this. First, the type of licences recommended based on the position of Codeberg. Second, who the target of the article is and what the goal is. I am not knowledgeable enough on licensing or Codeberg's mission to discuss the first part.

However on the second part, I believe the article should (at least initially) try to find a middleground between "don't asking the readers to think" and "educating the readers to make a completely informed decision".

And that middleground could very well look like your suggestion to add a TLDR at the top, but perhaps making it look more like a ELI5 (Explain like I'm 5) and give a short and clear explanation of topics like copyright and copyleft, together with a couple of licence recommendations. With the rest of the article diving much deeper into topics such as patents, CLAs, proliferation, etc.

In summary, I think we are aligned, but wanted to make sure that from a casual programmer perspective the article stays on point and actually helps make a decision without immediately getting exposed to the full details of copyright law.

Happy to help improve that ELI5 part once you get this merged. Hopefully I can be of use in that regard...

I think there are two points to this. First, the type of licences recommended based on the position of Codeberg. Second, who the target of the article is and what the goal is. I am not knowledgeable enough on licensing or Codeberg's mission to discuss the first part. However on the second part, I believe the article should (at least initially) try to find a middleground between "don't asking the readers to think" and "educating the readers to make a completely informed decision". And that middleground could very well look like your suggestion to add a TLDR at the top, but perhaps making it look more like a ELI5 (*Explain like I'm 5*) and give a short and clear explanation of topics like copyright and copyleft, together with a couple of licence recommendations. With the rest of the article diving much deeper into topics such as patents, CLAs, proliferation, etc. In summary, I think we are aligned, but wanted to make sure that from a casual programmer perspective the article stays on point and actually helps make a decision without immediately getting exposed to the full details of copyright law. Happy to help improve that ELI5 part once you get this merged. Hopefully I can be of use in that regard...
* Add a simple decision diagram for sofware licences.
* Fix minor issues.
* Fix formatting.
* The issue with the 0BSD licence as a public-domain equivalent licence
 is still open. Public-domain is a copyright-waiver, not a licence. The
 0BSD does *not* waive any copyright. It is therefore not equivalent to
 public-domain, yet may have similar effects in practice. This needs
 further investigation.
Author
Contributor
Copy link

Dear all,

I just pushed a new version which includes most of the feedback from this discussion.
That is:

  • Minor things (typos, commas, formatting)
  • A simplified decision diagram for choosing a software licence. This should help to make a quick decision for most cases without diving into the details. It is placed after an introduction which explains why a licence is needed.

There is still a few things open:

For example the issue with the public-domain I'm not much familiar with. I see it rarely that projects are placed in the public domain. (Some I've seen are very universal things like reference implementations of cryptographic algorithms). Public-domain is not a licence but a copyright-waiver. I.e. it removes completely the copyright protection from some work. Copyright law does then not apply anymore. To me it is unclear what effects this has on liability.

The 0BSD is to my understanding not precisely public-domain. It does not waive the copyright but instead gives very wide permissions. In practice this might feel like public-domain.

If public-domain is really wanted, the FSF recommends the CC0 copyright-waiver. It also seems to include liability and warranty disclaimers. But as of today I don't know much about it. Since we also recommend the CC0 for non-software projects I now also put it for software projects.

I suggest to address this later. In my opinion, placing something in public-domain is rarely necessary. The Apache or MIT licences should cover most practical cases.

Dear all, I just pushed a new version which includes most of the feedback from this discussion. That is: * Minor things (typos, commas, formatting) * A simplified decision diagram for choosing a software licence. This should help to make a quick decision for most cases without diving into the details. It is placed after an introduction which explains why a licence is needed. There is still a few things open: For example the issue with the public-domain I'm not much familiar with. I see it rarely that projects are placed in the public domain. (Some I've seen are very universal things like reference implementations of cryptographic algorithms). Public-domain is not a licence but a *copyright-waiver*. I.e. it removes completely the copyright protection from some work. Copyright law does then not apply anymore. To me it is unclear what effects this has on liability. The 0BSD is to my understanding not precisely public-domain. It does not waive the copyright but instead gives very wide permissions. In practice this might feel like public-domain. If public-domain is really wanted, the FSF recommends the CC0 copyright-waiver. It also seems to include liability and warranty disclaimers. But as of today I don't know much about it. Since we also recommend the CC0 for non-software projects I now also put it for software projects. I suggest to address this later. In my opinion, placing something in public-domain is rarely necessary. The Apache or MIT licences should cover most practical cases.
Author
Contributor
Copy link

I think there are two points to this. First, the type of licences recommended based on the position of Codeberg. Second, who the target of the article is and what the goal is.

@michielappelman

First: Codeberg should focus on a small set of mainstream licences which cover a wide range of use cases. Especially for copy-left licence we should limit ourselves to one family in order to not promote licence incompatibilities. (There's an exeption for hardware, where no GPL-compatible strong-copyleft licence exists yet).
The new text should give you some impression about the recommended licences. The recommendations are of course dependent on the projects needs.

Second: As I understand the main readers should be users of Codeberg. If they don't have a licence in their repository, then Codeberg will display a banner with a link to this article.
The goal is to help readers to find a matching licence for their project. In order to make informed decisions, readers must have the possibility to get background information and understand the matter. Without understanding the fundamentals of Copyright law it is not possible to understand what a licence is and how it works.
Nobody is forced to read that, of course. People who don't care or already know everything can just skip the details.

In my opinion Codeberg's mission calls for that:

[...] to enable equal opportunities regarding the access to knowledge and education [...]

Regarding access to knowledge, Copyright and licences are crucial. Unfortunately, often they are used to deny access to information. If we want to foster a sustainable community we also need to spread such knowledge :)

> I think there are two points to this. First, the type of licences recommended based on the position of Codeberg. Second, who the target of the article is and what the goal is. @michielappelman First: Codeberg should focus on a small set of mainstream licences which cover a wide range of use cases. Especially for copy-left licence we should limit ourselves to one family in order to not promote licence incompatibilities. (There's an exeption for hardware, where no GPL-compatible strong-copyleft licence exists yet). The new text should give you some impression about the recommended licences. The recommendations are of course dependent on the projects needs. Second: As I understand the main readers should be users of Codeberg. If they don't have a licence in their repository, then Codeberg will display a banner with a link to this article. The goal is to help readers to find a matching licence for their project. In order to make informed decisions, readers must have the possibility to get background information and understand the matter. Without understanding the fundamentals of Copyright law it is not possible to understand what a licence is and how it works. Nobody is forced to read that, of course. People who don't care or already know everything can just skip the details. In my opinion [Codeberg's mission](https://codeberg.org/codeberg/org/src/branch/main/en/bylaws.md#2-purpose-and-tasks) calls for that: > [...] to enable equal opportunities regarding the access to knowledge and education [...] Regarding access to knowledge, Copyright and licences are crucial. Unfortunately, often they are used to *deny* access to information. If we want to foster a sustainable community we also need to spread such knowledge :)
Owner
Copy link

Thank you very much. If no one approves this earlier, I'll try to review more carefully in the next days :)

Thank you very much. If no one approves this earlier, I'll try to review more carefully in the next days :)
fnetX added the due date 2022年01月22日 2022年01月17日 02:43:07 +01:00
Owner
Copy link

Some current conversations about language mistakes aren't resolved yet (the last five as far as I can see). Please apply the suggestions.

I didn't yet have time to check whether the longer conversations above are still valid or can be marked as resolved.

Anyway, thank you very much. I'm sorry this takes some time to review.

Some current conversations about language mistakes aren't resolved yet (the last five as far as I can see). Please apply the suggestions. I didn't yet have time to check whether the longer conversations above are still valid or can be marked as resolved. Anyway, thank you very much. I'm sorry this takes some time to review.
Author
Contributor
Copy link

@fnetX Thanks for reviewing! Sorry, I missed the last few comments. But just fixed them.

@fnetX Thanks for reviewing! Sorry, I missed the last few comments. But just fixed them.
fnetX left a comment
Owner
Copy link

Again, thank you very much for doing all this work. Sorry, but I had more comments than I expected. You don't need to resolve all the proposals, but if you don't want to apply someone because of limited resources, please indicate and make sure it's in the issue.

Thank you very much!

Again, thank you very much for doing all this work. Sorry, but I had more comments than I expected. You don't need to resolve all the proposals, but if you don't want to apply someone because of limited resources, please indicate and make sure it's in the issue. Thank you very much!
@ -14,3 +14,1 @@
> * The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
> * The freedom to redistribute copies so you can help others (freedom 2).
> * The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.
[Copyright law is extremely powerful](https://www.gnu.org/philosophy/enforcing-gpl.en.html). In fact, it grants the author of a work exclusive rights to use or distribute their work. An author can grant permission of using his work under arbitrary conditions: Just for illustration, an author could invent for example a "coffee licence" and impose that whoever uses his work has to offer the author a coffee. Similarly, forever-open licences grant users the right to use the work provided that they will redistribute any derivative work using the same licence again (copyleft).
Owner
Copy link

These two paragraphs: I am not completely sure if this is interesting to everyone who tries to read this in 5 minutes and who just wants to know what Free Software is about and how to apply a Licence. Maybe this can be moved in a first "History on Copyright", or "What is Copyright?" so people can skip this if not interested?

These two paragraphs: I am not completely sure if this is interesting to everyone who tries to read this in 5 minutes and who just wants to know what Free Software is about and how to apply a Licence. Maybe this can be moved in a first "History on Copyright", or "What is Copyright?" so people can skip this if not interested?
@ -19,2 +16,3 @@
## Simplified decision diagram for choosing a software licence
## Copyleft
If you start a new software project, the decision diagram below helps to make a quick decision for a licence without understanding the matter in more depth. To make a more informed decision or if you need a licence for a non-software project, we recommend skipping this section and read the full article instead.
Owner
Copy link

not sure, but I suppose it's "reading" here? @n

not sure, but I suppose it's "reading" here? @n
Contributor
Copy link

This section still holds value even if someone reads the rest of the article, and someone who wanted to make a more informed decision would probably read the rest of the article without being prompted.

Suggested rewording:

The diagram below can help you quickly decide on which free software licence to choose. If you need a licence for a [non-software project](#hardware-projects), you can skip this section.
This section still holds value even if someone reads the rest of the article, and someone who wanted to make a more informed decision would probably read the rest of the article without being prompted. Suggested rewording: ```markdown The diagram below can help you quickly decide on which free software licence to choose. If you need a licence for a [non-software project](#hardware-projects), you can skip this section. ```
resectio marked this conversation as resolved
@ -23,2 +20,3 @@
### Licence decision diagram
> If a program is free but not copylefted, then some copies or modified versions may not be free at all. A software company can compile the program, with or without modifications, and distribute the executable file as a proprietary software product.
Do you want allow people to create proprietary (closed-source) project with your code, or do you expect your project to remain small (e.g. less than 300 lines)?
Owner
Copy link

"want to allow"

"want to allow"
Contributor
Copy link

This is a bit confusing since you are asking two different questions and the options are yes and no.

This is a bit confusing since you are asking two different questions and the options are yes and no.
Author
Contributor
Copy link

@n Since the "or" has a logical meaning (Boolean logic) I think there's no ambiguity.

But I'm happy about suggestions with better wording.

@n Since the "or" has a logical meaning (Boolean logic) I think there's no ambiguity. But I'm happy about suggestions with better wording.
@ -27,0 +26,4 @@
* Yes --> Do you want to allow people to use your code as a library and not disclose the source-code of their main program?
* No --> we recommend using the **GPL-3.0-or-later** licence
* Yes --> we recommend using the **LGPL-3.0-or-later** licence
* Yes --> Do you want to be able to sue in the future users of your code for patent infringement implemented in the code?
Owner
Copy link

maybe link to the patent section from here, so people who are wondering can easily head down?

of your code for [patent infringement](#patent-usage) implemented

might do the trick

maybe link to the patent section from here, so people who are wondering can easily head down? `of your code for [patent infringement](#patent-usage) implemented` might do the trick
resectio marked this conversation as resolved
@ -27,2 +31,3 @@
* Yes --> We recommend using the **MIT** licence
The other end of the spectrum is licensing your software under no restrictions at all. An example of this is the [0-Clause BSD license](https://spdx.org/licenses/0BSD.html). A completely unrestricted license means that the software is *free* (per the definition above) but any copies/modifications of it may not be. *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.
### Correctly applying a licence
Owner
Copy link

I'd propose to still add a generic explanation here. E.g.

In order to correctly license your work, you have to explicitly tell which files of your work are under which Licence, and how to find it.
We recommend you to follow these steps to avoid ambiguities:

I'd propose to still add a generic explanation here. E.g. > In order to correctly license your work, you have to explicitly tell which files of your work are under which Licence, and how to find it. > We recommend you to follow these steps to avoid ambiguities:
resectio marked this conversation as resolved
@ -29,2 +33,3 @@
### Correctly applying a licence
## Recommended Licenses
* Include the full licence text in the project.
Owner
Copy link

... maybe add:

usually in a file called LICENCE or COPYING

?

Or is this void when using reuse?

... maybe add: > usually in a file called LICENCE or COPYING ? Or is this void when using reuse?
Author
Contributor
Copy link

Reuse suggests to create a 'LICENCES' folder and put all licence files there. They are then named 'GPL-v3.0.txt', etc.

But yes, just putting a LICENCE or COPYING file might be a minimal solution.

Reuse suggests to create a 'LICENCES' folder and put all licence files there. They are then named 'GPL-v3.0.txt', etc. But yes, just putting a LICENCE or COPYING file might be a minimal solution.
resectio marked this conversation as resolved
@ -30,1 +35,3 @@
## Recommended Licenses
* Include the full licence text in the project.
* Add copyright and licence information to each source file.
* Follow the [tutorial for becoming "REUSE-compliant"](https://reuse.software/tutorial/).
Owner
Copy link

These steps are nice, but I wonder if we should split between "is a requirement" and "is best practice".

AFAIK, even courts accepted projects with only one LICENCE file, or a disclaimer in the README that this applies to all of the work.

On the other hand, if we tell users "this is the minimum", they might tend to be happy with it and don't follow on.

Still, this currently sounds as if everyone really needs to get used to use REUSE in the project, and although I think we should endorse, I doubt we should force this. TBH, I didn't yet find the time to properly look at REUSE, too. I'll probably do so soon, but I don't feel like I should ask others to do it.

These steps are nice, but I wonder if we should split between "is a requirement" and "is best practice". AFAIK, even courts accepted projects with only one LICENCE file, or a disclaimer in the README that this applies to all of the work. On the other hand, if we tell users "this is the minimum", they might tend to be happy with it and don't follow on. Still, this currently sounds as if everyone really needs to get used to use REUSE in the project, and although I think we should endorse, I doubt we should force this. TBH, I didn't yet find the time to properly look at REUSE, too. I'll probably do so soon, but I don't feel like I should ask others to do it.
Author
Contributor
Copy link

That's a good point. REUSE is not necessary to properly license a project. In fact a big majority of projects do not follow REUSE yet. So I would not enforce it either, but direct people to it if they need a fully detailed guide.

That's a good point. REUSE is not necessary to properly license a project. In fact a big majority of projects do not follow REUSE yet. So I would not enforce it either, but direct people to it if they need a fully detailed guide.
resectio marked this conversation as resolved
@ -42,2 +46,3 @@
For documentation, writing and other non-code assets a [Creative Commons (CC)](https://creativecommons.org/about/cclicenses/) license can be used, but note that only the following CC licenses are considered free (again sorted from protective to unconditional):
2. Licences which permit to close the source, i.e. temporarily-open licences. These licences are usually known as permissive licences. The MIT licence or the Apache licence belong to this category. The term "permissive" often causes confusion, because it sounds fair and good to unexperienced people.
People contributing to the development of a program relseased with a permissive licence must be aware that the program could become proprietary at any time. This is the case, for example, when a company hires the original team of developers.
Owner
Copy link

released

released
resectio marked this conversation as resolved
@ -44,0 +56,4 @@
Both copyleft and permissive licence can, or cannot, be free licences. For example, the [Modified BSD licence](https://www.gnu.org/licenses/license-list.en.html#ModifiedBSD) is a permissive non-copyleft free software licence.
In the context of licences, therefore, the term "free" has the meaning of "freedom" not of gratis, but this has often been confused. Still, free software is often also gratis software.
Gratis non-free software usually includes gratis proprietary programs (shareware), demonstration or trial versions, limited versions (crippleware), arvertising-supported software (e.g. antiviruses), and usually viruses and worms (the victim doesn't pay to get them).
Owner
Copy link

advertising? Or is this a word I don't know?

advertising? Or is this a word I don't know?
resectio marked this conversation as resolved
@ -44,0 +61,4 @@
### Patent usage
Some permissive/temporarily-open licences like the MIT licence do not contain a patent provision granting the users the right to use their patents. It is a common argument in favour of the MIT licence to claim that no public lawsuit has ever been conducted yet. Still the threat to be sued remains and it can be used to exert pressure. Some, if not most, licence disputes moreover are settled even [before reaching the court](https://www.gnu.org/philosophy/enforcing-gpl.en.html) and could therefore leave no trace. Even Google [avoided the use of the MIT licence when developing Android](https://source.android.com/setup/start/licenses), presumably because of the missing patent provision.
Owner
Copy link

Hmm, I'm missing an information about what "patent" means in practice for Free Software, e.g. on algorithms etc. You don't have to add this, but we should move this to the issue, then, for someone else to pick up.

Hmm, I'm missing an information about what "patent" means in practice for Free Software, e.g. on algorithms etc. You don't have to add this, but we should move this to the issue, then, for someone else to pick up.

patent would not be the correct word

patent would not be the correct word
resectio marked this conversation as resolved
@ -44,0 +90,4 @@
### Software projects
For software projects, we recommend whenever possible to utilize a copyleft licence. The only well-established licences of this type are those of the GNU General Public Licence (GPL) family. The GPL licences have evolved over time and come with different versions. Unfortunately, some versions are not compatible with older ones. To avoid [licence proliferation](https://en.wikipedia.org/wiki/License_proliferation) and to ease compatibility with future versions, we recommend using the "GNU Affero General Public Licence v3.0 or later" with SPDX licence identifier ["AGPL-3.0-or-later"](https://spdx.org/licenses/). The AGPL provides the maximum openness of the code: Even when the software runs on a server, users who interact with that software (e.g. over a network connection) are entitled to receive a copy of the source code.
Owner
Copy link

maybe link to the internal licence proliferation section instead, if someone just needs a tl;dr?

maybe link to the internal licence proliferation section instead, if someone just needs a tl;dr?
resectio marked this conversation as resolved
@ -44,0 +99,4 @@
If you are not allowed, or if you do not want, to use a forever-open licence (for example because the company you work for does not allow you to do so) we recommend using a temporarily-open or permissive (in the sense that it permits users to close the code) licence which contains a patent provision. To avoid proliferation of licences, we recommend therefore to use the Apache licence version 2.0 (SPDX licence identifier Apache-2.0).
We recommend following the guidelines defined by the [GNU project](https://www.gnu.org/licenses/licenses.html). These guidelines are recommended by the [Free Software Foundation](https://fsf.org) too.
Owner
Copy link

"..., too" I think

"These guidelines" could be shortened to "They", at least for me this read a little weird right now.

"..., too" I think "These guidelines" could be shortened to "They", at least for me this read a little weird right now.
resectio marked this conversation as resolved
@ -49,1 +126,3 @@
Like CC themselves, Codeberg **recommends against** using a [CC license on code](https://creativecommons.org/faq/#can-i-apply-a-creative-commons-license-to-software).
Like CC themselves, Codeberg **recommends against** using a [CC licence on code](https://creativecommons.org/faq/#can-i-apply-a-creative-commons-license-to-software).
## How to include a licence
Owner
Copy link

why don't link the "apply ..." section? Or why duplicate at all?

why don't link the "apply ..." section? Or why duplicate at all?
resectio marked this conversation as resolved
@ -50,0 +132,4 @@
### FAQ
We do not curate our own FAQ. Instead we redirect to other major collections:
Owner
Copy link

maybe tell that exchange in the community channels might be a good idea, you could link the contact page

maybe tell that exchange in the community channels might be a good idea, you could link the contact page
resectio marked this conversation as resolved
@ -50,0 +142,4 @@
* In the USA: 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, the latter is used.
Owner
Copy link

I'd write Codeberg uppercase, not sure the tld is necessary.

I'd write Codeberg uppercase, not sure the tld is necessary.
resectio marked this conversation as resolved
Author
Contributor
Copy link

@fnetX Please ignore the most recent review request, I accidentially clicked on the 're-request review' button.

@fnetX Please ignore the most recent review request, I accidentially clicked on the 're-request review' button.
tok changed title from (削除) #174: Proposal for more extensive article on licensing. (削除ここまで) to WIP: #174: Proposal for more extensive article on licensing. 2022年01月19日 08:59:33 +01:00
Contributor
Copy link

@tok are you still working on the PR? Unless I would like to take over, if you dont mind

@tok are you still working on the PR? Unless I would like to take over, if you dont mind
Author
Contributor
Copy link

Hi @schorsch,
Thanks for offering help! I just got many distractions. So what you find here is my most recent version.
According to the comments here there's mostly minor things yet to be done. And of course you are welcome to improve things.

For coordination: What would you intend to work on?

I'm actually still motivated to contribute, just did not have much time to spare. So let me know.
If it's just about fixing all the little things, I would actually also do it. Just neglected it for a while :/

Overall I think it would actually be good to soon come to a version which can be published. I mean, we can always extend it later.

Hi @schorsch, Thanks for offering help! I just got many distractions. So what you find here is my most recent version. According to the comments here there's mostly minor things yet to be done. And of course you are welcome to improve things. For coordination: What would you intend to work on? I'm actually still motivated to contribute, just did not have much time to spare. So let me know. If it's just about fixing all the little things, I would actually also do it. Just neglected it for a while :/ Overall I think it would actually be good to soon come to a version which can be published. I mean, we can always extend it later.
Contributor
Copy link

I just thought about fixing the above mentioned problems but I would also be fine if you are doing it

I just thought about fixing the above mentioned problems but I would also be fine if you are doing it
Author
Contributor
Copy link

I just thought about fixing the above mentioned problems but I would also be fine if you are doing it

I have some time right now. So will fix what I can and then let you know in an hour or two.

> I just thought about fixing the above mentioned problems but I would also be fine if you are doing it I have some time right now. So will fix what I can and then let you know in an hour or two.
Author
Contributor
Copy link

I just pushed a new version which takes into account most of the comments from above.

@schorsch If you have any other suggestions, feel free to continue. I will not work on it for today.

There are still a few open points:

maybe tell that exchange in the community channels might be a good idea, you could link the contact page

I think that's a good idea. But I leave it open for now because I'm not sure which community channels. The ones of Codeberg?

Do you want to allow people to create proprietary (closed-source) projects with your code, or do you expect your project to remain small (e.g. less than 300 lines)?

I cannot think of a better wording, so if anybody has a suggestion please tell.

I just pushed a new version which takes into account most of the comments from above. @schorsch If you have any other suggestions, feel free to continue. I will not work on it for today. There are still a few open points: > maybe tell that exchange in the community channels might be a good idea, you could link the contact page I think that's a good idea. But I leave it open for now because I'm not sure which community channels. The ones of Codeberg? > Do you want to allow people to create proprietary (closed-source) projects with your code, or do you expect your project to remain small (e.g. less than 300 lines)? I cannot think of a better wording, so if anybody has a suggestion please tell.
fnetX left a comment
Owner
Copy link

@tok thank you very much!

@schorsch I propose to merge thhis version as is, but I'd very much appreciate if you could take care of some remaining unresolved suggestions or whatever you still notice in a separate PR.

@tok thank you very much! @schorsch I propose to merge thhis version as is, but I'd very much appreciate if you could take care of some remaining unresolved suggestions or whatever you still notice in a separate PR.
Contributor
Copy link

@fnetX

@schorsch I propose to merge thhis version as is, but I'd very much appreciate if you could take care of some remaining unresolved suggestions or whatever you still notice in a separate PR.

Alright Id just solve the above conversations within this week and create a new PR

@fnetX > @schorsch I propose to merge thhis version as is, but I'd very much appreciate if you could take care of some remaining unresolved suggestions or whatever you still notice in a separate PR. Alright Id just solve the above conversations within this week and create a new PR
fnetX changed title from (削除) WIP: #174: Proposal for more extensive article on licensing. (削除ここまで) to #174: Proposal for more extensive article on licensing. 2022年03月07日 16:21:30 +01:00
Sign in to join this conversation.
No reviewers
Labels
Clear labels
Codeberg Pages

Issues affecting Codeberg Pages
Documentation Usability

Issues related to using and reading docs.codeberg.org
Forgejo
Good First Issue! 👋
Kind: Bug
Kind: Documentation
Kind: Enhancement
Kind: Feature
Kind: Question
Kind: Security
Licensing
Part: Generator

This is related to the generation of the documentation, not to the content itself
Priority: High

The priority is high
Priority: Low

The priority is low
Priority: Medium

The priority is medium
Reviewed: Confirmed

Something has been confirmed
Reviewed: Duplicate

Something exists already
Reviewed: Invalid

Something was marked as invalid
Reviewed: Wontfix

Something won't be fixed
Status: Blocked
Status: Help wanted

Contributions are welcome!
Status: In progress

Work is in progress
Status: Needs feedback

Feedback is needed
Status: Ready for Review

Work is completed
Status: Review

Review is in progress / Reviewers wanted
Status: Stale
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
6 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

2022年01月22日

Dependencies

No dependencies set.

Reference
Codeberg/Documentation!181
Reference in a new issue
Codeberg/Documentation
No description provided.
Delete branch "tok/codeberg-documentation:main"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?