Copyleft blog post: change the example to be generic #274

earl-warren commented 2023年07月01日 09:25:40 +02:00

Using F3 driver as an example is not the best idea because:

• it is currently published under MIT
• code strongly related to interoperability is arguably a legitimate
  use case for permissive licenses
• it may trigger negative response even from people generaly favorable
  to copyleft

It is replaced by a theoritical example that is both easier to
understand and more likely to happen.

Using F3 driver as an example is not the best idea because: * it is currently published under MIT * code strongly related to interoperability is arguably a legitimate use case for permissive licenses * it may trigger negative response even from people generaly favorable to copyleft It is replaced by a theoritical example that is both easier to understand and more likely to happen.

forgejo-website commented 2023年07月01日 10:49:33 +02:00

Preview ready: https://forgejo.codeberg.page/@pull_274/

Preview ready: https://forgejo.codeberg.page/@pull_274/

n0toose commented 2023年07月01日 11:30:32 +02:00

I excitedly shared this WIP blog post (while making sure to say that it's a WIP) and it was brought up to me that a person in my circles is not too excited because of the DCO and not because of the blog post. (the blog posts cites the DCO, so I believe that the DCO complements the blog post which is why I'm addressing this here)

• Because of this pull request, or the Free Software license(s) involved. should be more explicit so that prospective contributors won't think that we'll take their MIT patches and relicense these specific patches under the GNU GPL v3.
• Off-topic point regarding: (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed [...]. Allowing people to change their identity information in Sign-off's to the best extent that's technically possible (e.g. the person may change their name, Forgejo rebases trees / overwrites / obscures linear histories regularly and GPLv3-licensed commits will probably not be upstreamed) upon request would be ideal.

I excitedly shared this WIP blog post (while making sure to say that it's a WIP) and it was brought up to me that a person in my circles is not too excited *because of the DCO and not because of the blog post.* (the blog posts cites the DCO, so I believe that the DCO complements the blog post which is why I'm addressing this here) - Because of this pull request, `or the Free Software license(s) involved.` should be more explicit so that prospective contributors won't think that we'll take their MIT patches and relicense these specific patches under the GNU GPL v3. - **Off-topic** point regarding: `(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed [...]`. Allowing people to change their identity information in Sign-off's to the best extent that's technically possible (e.g. the person may change their name, Forgejo rebases trees / overwrites / obscures linear histories regularly and GPLv3-licensed commits will probably not be upstreamed) upon request would be ideal.

caesar commented 2023年07月01日 11:58:10 +02:00

Gitea already has a DCO so that's not a change from our side. Though maybe worth clarifying in the blog post that it's not a new thing.

so that prospective contributors won't think that we'll take their MIT patches and relicense these specific patches under the GNU GPL v3

MIT specifically allows that, so any code licensed under MIT could always be relicensed under GPL or any other license, by anyone. The main reason to release code under MIT is specifically to allow people that freedom. Or am I misunderstanding the concern?

Gitea already has a DCO so that's not a change from our side. Though maybe worth clarifying in the blog post that it's not a new thing. > so that prospective contributors won't think that we'll take their MIT patches and relicense these specific patches under the GNU GPL v3 MIT specifically allows that, so any code licensed under MIT could always be relicensed under GPL or any other license, by anyone. The main reason to release code under MIT is specifically to allow people that freedom. Or am I misunderstanding the concern?

n0toose commented 2023年07月01日 12:14:22 +02:00

Or am I misunderstanding the concern?

Sorry, I did not express myself correctly. DCOs are not CLAs, but they still remind of CLAs to many people, so what I was trying to say is that one could be possibly worried about their patch being distributed under more restrictive terms than the desired. This concern is possibly moot, I don't think that I can recite it and express it in a way that shows that this is an objective problem.

Gitea already has a DCO so that's not a change from our side. Though maybe worth clarifying in the blog post that it's not a new thing.

I presume that any changes from Forgejo's side would introduce incompatibilities and that any problems with the DCO should be taken up with Gitea, then. Got it.

> Or am I misunderstanding the concern? Sorry, I did not express myself correctly. DCOs are not CLAs, but they still remind of CLAs to many people, so what I was trying to say is that one could be possibly worried about their patch being distributed under more restrictive terms than the desired. This concern is possibly moot, I don't think that I can recite it and express it in a way that shows that this is an objective problem. > Gitea already has a DCO so that's not a change from our side. Though maybe worth clarifying in the blog post that it's not a new thing. I presume that any changes from Forgejo's side would introduce incompatibilities and that any problems with the DCO should be taken up with Gitea, then. Got it.

earl-warren commented 2023年07月01日 13:00:17 +02:00

I presume that any changes from Forgejo's side would introduce incompatibilities and that any problems with the DCO should be taken up with Gitea, then. Got it.

There is no reason to ever change the DCO. It is a very simple statement that essentially says the people contributing have a right to do so.

I'm not aware of any project having issues with DCO incompatibilities and I don't think that's a thing actually. Unless you have a specific example in mind?

DCOs are not CLAs, but they still remind of CLAs to many people, so what I was trying to say is that one could be possibly worried about their patch being distributed under more restrictive terms than the desired.

That cannot happen with a DCO, ony with a CLA. A CLA would allow licensing copylefted code under a proprietary license. A DCO does not grant such a permission to anyone.

https://opensource.com/article/18/3/cla-vs-dco-whats-difference

CLAs may also give the project the right to relicense the work later. [...] it's also a risk that, at some point in the future, a project would take a direction that the contributors find unacceptable.

I argue that the only motivation for a company to impose a CLA is to to re-license under a proprietary license. It is a lot of work with no other benefit. Non profit organizations may have different motives (the FSF has CLA since its inception).

> I presume that any changes from Forgejo's side would introduce incompatibilities and that any problems with the DCO should be taken up with Gitea, then. Got it. There is no reason to ever change the DCO. It is a very simple statement that essentially says the people contributing have a right to do so. I'm not aware of any project having issues with DCO incompatibilities and I don't think that's a thing actually. Unless you have a specific example in mind? > DCOs are not CLAs, but they still remind of CLAs to many people, so what I was trying to say is that one could be possibly worried about their patch being distributed under more restrictive terms than the desired. That cannot happen with a DCO, ony with a CLA. A CLA would allow licensing copylefted code under a proprietary license. A DCO does not grant such a permission to anyone. https://opensource.com/article/18/3/cla-vs-dco-whats-difference > CLAs may also give the project the right to relicense the work later. [...] it's also a risk that, at some point in the future, a project would take **a direction that the contributors find unacceptable**. I argue that the **only** motivation for a company to impose a CLA is to to re-license under a proprietary license. It is a **lot** of work with no other benefit. Non profit organizations may have different motives (the FSF has CLA since its inception).

earl-warren commented 2023年07月01日 13:03:06 +02:00

I excitedly shared this WIP blog post (while making sure to say that it's a WIP)

It was published a month ago https://forgejo.org/2023-06-copyleft/, after discussions that started mid-april.

> I excitedly shared this WIP blog post (while making sure to say that it's a WIP) It was published a month ago https://forgejo.org/2023-06-copyleft/, after [discussions](https://codeberg.org/forgejo/website/pulls/204) that started mid-april.

n0toose commented 2023年07月01日 13:31:46 +02:00

I'm not aware of any project having issues with DCO incompatibilities and I don't think that's a thing actually. Unless you have a specific example in mind?

I think that I just keep saying vague things that don't correspond with what I have in my head, probably woke up on the wrong side of the bed today. I'd suggest that we drop this as I don't intend to cause any further disruption that takes time away from everyone involved without getting further.

I was trying to pass on arguments that are not mine, but I think that I should probably not recite arguments from other people when they are more than capable at doing this themselves; I was trying to contribute to making this project as good as it can get for everyone by passing on external feedback that would be, in retrospect, better expressed by the people themselves.

---

What I meant to say here is that you probably can't take a commit that signs off a DCO (as in, the Developer Certificate of Origin by the Linux Foundation) (e.g. "I certify that the contents of the commit are mine"), and then take that sign-off and apply it to a supposedly different agreement that I mistakenly also referred to a "DCO" and therefore came up with the term "DCO incompatibility" which is absolutely not a thing.

I suggested figuring out whether we could come up with some other equivalent that makes contributors feel safer, but this proposal does not make sense, as it would most likely have to be a derivative of the DCO, which is forbidden. Please dismiss that.

> I'm not aware of any project having issues with DCO incompatibilities and I don't think that's a thing actually. Unless you have a specific example in mind? I think that I just keep saying vague things that don't correspond with what I have in my head, probably woke up on the wrong side of the bed today. *I'd suggest that we drop this as I don't intend to cause any further disruption that takes time away from everyone involved without getting further.* I was trying to pass on arguments that are not mine, but I think that I should probably not recite arguments from other people when they are more than capable at doing this themselves; I was trying to contribute to making this project as good as it can get for everyone by passing on external feedback that would be, in retrospect, better expressed by the people themselves. --- What I meant to say here is that you probably can't take a commit that signs off a DCO (as in, the Developer Certificate of Origin by the Linux Foundation) (e.g. "I certify that the contents of the commit are mine"), and then take that sign-off and apply it to a supposedly different agreement that I mistakenly also referred to a "DCO" and therefore came up with the term "DCO incompatibility" which is absolutely not a thing. I suggested figuring out whether we could come up with some other equivalent that makes contributors feel safer, but this proposal does not make sense, as it would most likely have to be a derivative of the DCO, which is forbidden. Please dismiss that.

Reason:

Ghost commented 2023年07月01日 21:00:28 +02:00

image

That's a bug, I did specify a reason: "The comments were addressed" or something similar.

 That's a bug, I did specify a reason: "The comments were addressed" or something similar.

caesar commented 2023年07月02日 01:34:58 +02:00

DCOs are not CLAs, but they still remind of CLAs to many people

That is true, and is one problem with DCOs. People are more familiar with the concept of CLAs, so the assume (wrongly) that a DCO is the same thing when in fact it is merely a declaration that "I am not violating someone else's copyright".

> DCOs are not CLAs, but they still remind of CLAs to many people That is true, and is one problem with DCOs. People are more familiar with the concept of CLAs, so the assume (wrongly) that a DCO is the same thing when in fact it is merely a declaration that "I am not violating someone else's copyright".