From fontana at sharpeleven.org  Tue Jul  1 01:49:50 2025
From: fontana at sharpeleven.org (Richard Fontana)
Date: Mon, 30 Jun 2025 21:49:50 -0400
Subject: Questions about copyleft-next
In-Reply-To: <WI3AbcYpjrIu7wxhRH2uNynScBuTnURos3V3Oc9gmaCI77ELA5gd9iXL4fF8oIxJnd2dOG-aWbDvKazfLxEMepmafQ4vbkoeJWHscs-7NZQ=@proton.me>
References: <WI3AbcYpjrIu7wxhRH2uNynScBuTnURos3V3Oc9gmaCI77ELA5gd9iXL4fF8oIxJnd2dOG-aWbDvKazfLxEMepmafQ4vbkoeJWHscs-7NZQ=@proton.me>
Message-ID: <CAGT84B3k8TYf__+rK_cKTbmCWc=o8exH=HPG3R5CNXnEXhbt0w@mail.gmail.com>

On Mon, Jun 30, 2025 at 6:18 PM secureblueadmin
<secureblueadmin at proton.me> wrote:
>
> I came across this project from a promotional post on Reddit and found it interesting as a FOSS developer. As someone who's not a lawyer, I have a question regarding the license. There's this section, which is an interesting way of preventing (A)GPL/commercial dual licensing:
>
>     7. Nullification of Copyleft/Proprietary Dual Licensing
>
>     If I offer to license, for a fee, a Covered Work under terms other than
>     a license that is OSI-Approved or FSF-Free as of the release date of this
>     License or a numbered version of copyleft-next released by the
>     Copyleft-Next Project, then the license I grant You under section 1 is no
>     longer subject to the conditions in sections 3 through 5.
>
> However, this license also says:
>
>     If the Derived Work includes material licensed under the GPL, You may
>     instead license the Derived Work under the GPL.
>
> As far as I can tell, it would seem that if there's some code under copyleft-next that you want to include in your GPL/commercial dual licensed software, you can just create a Derived work that combines `copyleft-next` code with `GPL` code, and then use that derived work (now under the GPL) in your GPL/commercial dual licensed software. Is this not a loophole?
>
> Anyhow, thanks for taking the time to read this and bear with my lack of legal knowledge :)

No need to apologize for what you say is a lack of legal knowledge. I
would think your question would be equally likely to be raised by a
lawyer.

Bear in mind that it's been about ... well, a long time since I
actually looked at this license :) but:

The GPL already is pretty effective at prohibiting
copyleft/proprietary dual-licensed derivative works (note: bkuhn
prefers to call this "proprietary relicensing"), since that is a
straightforward GPL violation and this is true under copyleft-next
0.3.1 too. That GPL escape hatch clause doesn't allow you to grant a
proprietary license covering your 'Derived Work'. So I think that
addresses your question, and I think this is basically the point
Denver is making in his response too.

In copyleft-next 0.3.1 the proprietary relicensing poison pill (isn't
that what we sometimes used to call it?) speaks of 'Covered Works'
which includes 'Derived Works'. But it's really always been aimed (at
least primarily) at what copyleft-next 0.3.1 calls 'My Work', that is,
the initial copylefted work released by a copyright holder. This
attempts to address a problem that was assumed to be unavoidable under
the GPL (possibly in part because of the legacy of viewing the GPL as
a bare or noncontractual copyright license).

Richard


From bkuhn at ebb.org  Tue Jul  1 06:16:37 2025
From: bkuhn at ebb.org (Bradley M. Kuhn)
Date: Mon, 30 Jun 2025 23:16:37 -0700
Subject: Questions about copyleft-next
In-Reply-To: <CAGT84B3k8TYf__+rK_cKTbmCWc=o8exH=HPG3R5CNXnEXhbt0w@mail.gmail.com>
References: <WI3AbcYpjrIu7wxhRH2uNynScBuTnURos3V3Oc9gmaCI77ELA5gd9iXL4fF8oIxJnd2dOG-aWbDvKazfLxEMepmafQ4vbkoeJWHscs-7NZQ=@proton.me>
 <CAGT84B3k8TYf__+rK_cKTbmCWc=o8exH=HPG3R5CNXnEXhbt0w@mail.gmail.com>
Message-ID: <aGN9RSWK8zipmgSY@ebb.org>

> On Mon, Jun 30, 2025 at 6:18 PM secureblueadmin asked about:

> > [this] is an interesting way of preventing (A)GPL/commercial dual
> > licensing:
> >     7. Nullification of Copyleft/Proprietary Dual Licensing
> >
> >     If I offer to license, for a fee, a Covered Work under terms other
> >     than a license that is OSI-Approved or FSF-Free as of the release
> >     date of this License or a numbered version of copyleft-next released
> >     by the Copyleft-Next Project, then the license I grant You under
> >     section 1 is no longer subject to the conditions in sections 3
> >     through 5.

Richard Fontana replied:
> In copyleft-next 0.3.1 the proprietary relicensing poison pill (isn't that
> what we sometimes used to call it?)

Shortly after you (Richard) invented §7, I dubbed it the “copyleft equality
clause”: https://sfconservancy.org/blog/2020/jan/06/copyleft-equality/

I remember because it marked the third time in my career [0] my only
contribution to something important was naming it.  Now that I'm active in
copyleft-next again, though, I hope to actually contribute more than names
for things again. 😆

I really dislike the term “poison pill” not only for its violence but also
because it's typically a tactic used by contracting parties who don't trust
each other.  IMO, the copyleft equality clause is a way that a licensor can
state “I won't engage in proprietary relicensing” and really mean it.  It
builds trust while poison pills typically erode trust.

secureblueadmin asked:
> > However, this license also says:
> >     If the Derived Work includes material licensed under the GPL, You may
> >     instead license the Derived Work under the GPL.
> >
> > As far as I can tell, it would seem that if there's some code under
> > copyleft-next that you want to include in your GPL/commercial dual
> > licensed software, you can just create a Derived work that combines
> > `copyleft-next` code with `GPL` code, and then use that derived work (now
> > under the GPL) in your GPL/commercial dual licensed software. Is this not
> > a loophole?
> >

secureblueadmin noted:
> > Anyhow, thanks for taking the time to read this and bear with my lack of
> > legal knowledge :)

Richard replied:
> No need to apologize for what you say is a lack of legal knowledge. I would
> think your question would be equally likely to be raised by a lawyer.

I agree.  IANAL either but I've been involved in copyleft policy for 30
years, and I still had to stare at the copyleft-next text and your question
for about 7 minutes to make sure I definitely agreed with Denver's and
Richard's analysis.

I think I do, for a third, slightly different reason: the copyleft equality
clause actually removes the §§3-5 requirements for everyone in the world all
at once and its binding once the Covered Work is distributed just once.

Remember the entity seeking to proprietary relicense *has* to have exclusive
rights to the code anyway, so they could always license the Covered Work a
new way (including under GPLv2, if they wanted) and didn't need copyleft-next
§3 to do it anyway.  Heck, §7 even lets them do it, too, without §§3-5.

The big flaw still remaining in the equality clause is that it may not fully
prevent entities in cahoots doing something nasty.

Meanwhile, on my “list” of conversations to reopen is a complete overhaul of
the approach in §3¶2 anyway.  But more on that much later; not first thing on
my list.

   -- bkuhn

[0] I named the Classpath and the Replicant projects but have contributed
    virtually nothing else to them other than the names and moral support to
    the developers.



From secureblueadmin at proton.me  Tue Jul  1 16:22:49 2025
From: secureblueadmin at proton.me (secureblueadmin)
Date: Tue, 01 Jul 2025 16:22:49 +0000
Subject: Questions about copyleft-next
In-Reply-To: <aGN9RSWK8zipmgSY@ebb.org>
References: <WI3AbcYpjrIu7wxhRH2uNynScBuTnURos3V3Oc9gmaCI77ELA5gd9iXL4fF8oIxJnd2dOG-aWbDvKazfLxEMepmafQ4vbkoeJWHscs-7NZQ=@proton.me>
 <CAGT84B3k8TYf__+rK_cKTbmCWc=o8exH=HPG3R5CNXnEXhbt0w@mail.gmail.com>
 <aGN9RSWK8zipmgSY@ebb.org>
Message-ID: <vIW1WuowIyrtxY3rCJzPWWFFnNEmVjqWRLext6-Belmx3_sF9GsyxgTycANL4G7ipGZUCh18qxK-ILg-IV1o62W-5EqaeUs2zXCUDx2HIMM=@proton.me>

I have a slightly tangential question along the lines of 

> “I won't engage in proprietary relicensing” and really mean it.

Is the intent of the current section 6 to preclude issues such as the addition of a CLA? https://isitreallyfoss.com/concerns/copyleft-cla/

Also, is there a plan to include an "affero clause" (network distribution) in this license? or in a different license? If so, how could this be done while still preserving the outward compatibility with (non-affero) GPL?


On Monday, June 30th, 2025 at 11:18 PM, Bradley M. Kuhn <bkuhn at ebb.org> wrote:

> 
> 
> > On Mon, Jun 30, 2025 at 6:18 PM secureblueadmin asked about:
> 
> > > [this] is an interesting way of preventing (A)GPL/commercial dual
> > > licensing:
> > > 7. Nullification of Copyleft/Proprietary Dual Licensing
> > > 
> > > If I offer to license, for a fee, a Covered Work under terms other
> > > than a license that is OSI-Approved or FSF-Free as of the release
> > > date of this License or a numbered version of copyleft-next released
> > > by the Copyleft-Next Project, then the license I grant You under
> > > section 1 is no longer subject to the conditions in sections 3
> > > through 5.
> 
> 
> Richard Fontana replied:
> 
> > In copyleft-next 0.3.1 the proprietary relicensing poison pill (isn't that
> > what we sometimes used to call it?)
> 
> 
> Shortly after you (Richard) invented §7, I dubbed it the “copyleft equality
> clause”: https://sfconservancy.org/blog/2020/jan/06/copyleft-equality/
> 
> I remember because it marked the third time in my career [0] my only
> contribution to something important was naming it. Now that I'm active in
> copyleft-next again, though, I hope to actually contribute more than names
> for things again. 😆
> 
> I really dislike the term “poison pill” not only for its violence but also
> because it's typically a tactic used by contracting parties who don't trust
> each other. IMO, the copyleft equality clause is a way that a licensor can
> state “I won't engage in proprietary relicensing” and really mean it. It
> builds trust while poison pills typically erode trust.
> 
> secureblueadmin asked:
> 
> > > However, this license also says:
> > > If the Derived Work includes material licensed under the GPL, You may
> > > instead license the Derived Work under the GPL.
> > > 
> > > As far as I can tell, it would seem that if there's some code under
> > > copyleft-next that you want to include in your GPL/commercial dual
> > > licensed software, you can just create a Derived work that combines
> > > `copyleft-next` code with `GPL` code, and then use that derived work (now
> > > under the GPL) in your GPL/commercial dual licensed software. Is this not
> > > a loophole?
> 
> 
> secureblueadmin noted:
> 
> > > Anyhow, thanks for taking the time to read this and bear with my lack of
> > > legal knowledge :)
> 
> 
> Richard replied:
> 
> > No need to apologize for what you say is a lack of legal knowledge. I would
> > think your question would be equally likely to be raised by a lawyer.
> 
> 
> I agree. IANAL either but I've been involved in copyleft policy for 30
> years, and I still had to stare at the copyleft-next text and your question
> for about 7 minutes to make sure I definitely agreed with Denver's and
> Richard's analysis.
> 
> I think I do, for a third, slightly different reason: the copyleft equality
> clause actually removes the §§3-5 requirements for everyone in the world all
> at once and its binding once the Covered Work is distributed just once.
> 
> Remember the entity seeking to proprietary relicense has to have exclusive
> rights to the code anyway, so they could always license the Covered Work a
> new way (including under GPLv2, if they wanted) and didn't need copyleft-next
> §3 to do it anyway. Heck, §7 even lets them do it, too, without §§3-5.
> 
> The big flaw still remaining in the equality clause is that it may not fully
> prevent entities in cahoots doing something nasty.
> 
> Meanwhile, on my “list” of conversations to reopen is a complete overhaul of
> the approach in §3¶2 anyway. But more on that much later; not first thing on
> my list.
> 
> -- bkuhn
> 
> [0] I named the Classpath and the Replicant projects but have contributed
> virtually nothing else to them other than the names and moral support to
> the developers.


From fontana at sharpeleven.org  Tue Jul  1 16:44:31 2025
From: fontana at sharpeleven.org (Richard Fontana)
Date: Tue, 1 Jul 2025 12:44:31 -0400
Subject: Questions about copyleft-next
In-Reply-To: <vIW1WuowIyrtxY3rCJzPWWFFnNEmVjqWRLext6-Belmx3_sF9GsyxgTycANL4G7ipGZUCh18qxK-ILg-IV1o62W-5EqaeUs2zXCUDx2HIMM=@proton.me>
References: <WI3AbcYpjrIu7wxhRH2uNynScBuTnURos3V3Oc9gmaCI77ELA5gd9iXL4fF8oIxJnd2dOG-aWbDvKazfLxEMepmafQ4vbkoeJWHscs-7NZQ=@proton.me>
 <CAGT84B3k8TYf__+rK_cKTbmCWc=o8exH=HPG3R5CNXnEXhbt0w@mail.gmail.com>
 <aGN9RSWK8zipmgSY@ebb.org>
 <vIW1WuowIyrtxY3rCJzPWWFFnNEmVjqWRLext6-Belmx3_sF9GsyxgTycANL4G7ipGZUCh18qxK-ILg-IV1o62W-5EqaeUs2zXCUDx2HIMM=@proton.me>
Message-ID: <CAGT84B3NCbw0tQjQCYZsaYUOghH2+LfW3UKCxAXZKhSD6y8r4A@mail.gmail.com>

On Tue, Jul 1, 2025 at 12:23 PM secureblueadmin
<secureblueadmin at proton.me> wrote:
>
> I have a slightly tangential question along the lines of
>
> > “I won't engage in proprietary relicensing” and really mean it.
>
> Is the intent of the current section 6 to preclude issues such as the addition of a CLA? https://isitreallyfoss.com/concerns/copyleft-cla/

That's this section:

"If You Distribute a work to Me specifically for inclusion in or
modification of a Covered Work (a "Patch"), and no explicit licensing
terms apply to the Patch, You license the Patch under this License, to
the extent of Your copyright in the Patch. This condition does not
negate the other conditions of this License, if applicable to the Patch."

This does not preclude the addition of a CLA, but I suppose (aside:
it's weird to discuss something you know you wrote but don't remember
:) it provides some support for the view that a CLA is not needed.
This is clearly modeled on Apache License 2.0 section 5.

> Also, is there a plan to include an "affero clause" (network distribution) in this license? or in a different license? If so, how could this be done while still preserving the outward compatibility with (non-affero) GPL?

Excellent question. copyleft-next 0.3.1 does not (as far as I can tell
:) have an "Affero clause". However, the latest "draft" version of
copyleft-next, i.e.
https://git.copyleft.org/copyleft-next/copyleft-next/src/commit/5fdb9dca6bd9c7ab204976e46ce4663b8d4482c7/Drafts/copyleft-next
does have one, which the original licensor can opt out of:

https://git.copyleft.org/copyleft-next/copyleft-next/src/commit/5fdb9dca6bd9c7ab204976e46ce4663b8d4482c7/Drafts/copyleft-next#L90-L98
(which uses these definitions:
https://git.copyleft.org/copyleft-next/copyleft-next/src/commit/5fdb9dca6bd9c7ab204976e46ce4663b8d4482c7/Drafts/copyleft-next#L226-L237
)

It does not conflict with what you call the outward compatibility of
GPL, because of this (counterpart in the latest "draft" to what I
called the GPL escape hatch in copyleft-next 0.3.1):
https://git.copyleft.org/copyleft-next/copyleft-next/src/commit/5fdb9dca6bd9c7ab204976e46ce4663b8d4482c7/Drafts/copyleft-next#L72-L80

As another aside, this structure of having "Releases" and "Drafts" was
probably a bad idea.

I won't speak for bkuhn (a well known enthusiast of the Affero GPL
both in theory and practice) but I think as a minimum feature
copyleft-next should have an "Affero clause" of some sort. That was
not an assumption I would have made in at least the earlier earlier
history of copyleft-next, obviously.

Richard


> On Monday, June 30th, 2025 at 11:18 PM, Bradley M. Kuhn <bkuhn at ebb.org> wrote:
>
> >
> >
> > > On Mon, Jun 30, 2025 at 6:18 PM secureblueadmin asked about:
> >
> > > > [this] is an interesting way of preventing (A)GPL/commercial dual
> > > > licensing:
> > > > 7. Nullification of Copyleft/Proprietary Dual Licensing
> > > >
> > > > If I offer to license, for a fee, a Covered Work under terms other
> > > > than a license that is OSI-Approved or FSF-Free as of the release
> > > > date of this License or a numbered version of copyleft-next released
> > > > by the Copyleft-Next Project, then the license I grant You under
> > > > section 1 is no longer subject to the conditions in sections 3
> > > > through 5.
> >
> >
> > Richard Fontana replied:
> >
> > > In copyleft-next 0.3.1 the proprietary relicensing poison pill (isn't that
> > > what we sometimes used to call it?)
> >
> >
> > Shortly after you (Richard) invented §7, I dubbed it the “copyleft equality
> > clause”: https://sfconservancy.org/blog/2020/jan/06/copyleft-equality/
> >
> > I remember because it marked the third time in my career [0] my only
> > contribution to something important was naming it. Now that I'm active in
> > copyleft-next again, though, I hope to actually contribute more than names
> > for things again. 😆
> >
> > I really dislike the term “poison pill” not only for its violence but also
> > because it's typically a tactic used by contracting parties who don't trust
> > each other. IMO, the copyleft equality clause is a way that a licensor can
> > state “I won't engage in proprietary relicensing” and really mean it. It
> > builds trust while poison pills typically erode trust.
> >
> > secureblueadmin asked:
> >
> > > > However, this license also says:
> > > > If the Derived Work includes material licensed under the GPL, You may
> > > > instead license the Derived Work under the GPL.
> > > >
> > > > As far as I can tell, it would seem that if there's some code under
> > > > copyleft-next that you want to include in your GPL/commercial dual
> > > > licensed software, you can just create a Derived work that combines
> > > > `copyleft-next` code with `GPL` code, and then use that derived work (now
> > > > under the GPL) in your GPL/commercial dual licensed software. Is this not
> > > > a loophole?
> >
> >
> > secureblueadmin noted:
> >
> > > > Anyhow, thanks for taking the time to read this and bear with my lack of
> > > > legal knowledge :)
> >
> >
> > Richard replied:
> >
> > > No need to apologize for what you say is a lack of legal knowledge. I would
> > > think your question would be equally likely to be raised by a lawyer.
> >
> >
> > I agree. IANAL either but I've been involved in copyleft policy for 30
> > years, and I still had to stare at the copyleft-next text and your question
> > for about 7 minutes to make sure I definitely agreed with Denver's and
> > Richard's analysis.
> >
> > I think I do, for a third, slightly different reason: the copyleft equality
> > clause actually removes the §§3-5 requirements for everyone in the world all
> > at once and its binding once the Covered Work is distributed just once.
> >
> > Remember the entity seeking to proprietary relicense has to have exclusive
> > rights to the code anyway, so they could always license the Covered Work a
> > new way (including under GPLv2, if they wanted) and didn't need copyleft-next
> > §3 to do it anyway. Heck, §7 even lets them do it, too, without §§3-5.
> >
> > The big flaw still remaining in the equality clause is that it may not fully
> > prevent entities in cahoots doing something nasty.
> >
> > Meanwhile, on my “list” of conversations to reopen is a complete overhaul of
> > the approach in §3¶2 anyway. But more on that much later; not first thing on
> > my list.
> >
> > -- bkuhn
> >
> > [0] I named the Classpath and the Replicant projects but have contributed
> > virtually nothing else to them other than the names and moral support to
> > the developers.
> _______________________________________________
> next mailing list
> next at lists.copyleft.org
> https://lists.copyleft.org/mailman/listinfo/next


From secureblueadmin at proton.me  Tue Jul  1 16:56:43 2025
From: secureblueadmin at proton.me (secureblueadmin)
Date: Tue, 01 Jul 2025 16:56:43 +0000
Subject: Questions about copyleft-next
In-Reply-To: <CAGT84B3NCbw0tQjQCYZsaYUOghH2+LfW3UKCxAXZKhSD6y8r4A@mail.gmail.com>
References: <WI3AbcYpjrIu7wxhRH2uNynScBuTnURos3V3Oc9gmaCI77ELA5gd9iXL4fF8oIxJnd2dOG-aWbDvKazfLxEMepmafQ4vbkoeJWHscs-7NZQ=@proton.me>
 <CAGT84B3k8TYf__+rK_cKTbmCWc=o8exH=HPG3R5CNXnEXhbt0w@mail.gmail.com>
 <aGN9RSWK8zipmgSY@ebb.org>
 <vIW1WuowIyrtxY3rCJzPWWFFnNEmVjqWRLext6-Belmx3_sF9GsyxgTycANL4G7ipGZUCh18qxK-ILg-IV1o62W-5EqaeUs2zXCUDx2HIMM=@proton.me>
 <CAGT84B3NCbw0tQjQCYZsaYUOghH2+LfW3UKCxAXZKhSD6y8r4A@mail.gmail.com>
Message-ID: <RBOXfRqQB4QmQOuWk0WgSROdwaP7khi7ydMaCoyjzUhux6uqWLsIo1Ol8cKVoRuWQTfGMyp8BnoIlrIVDb6ARlKBJ0qca-GJPlW6z0bBQEQ=@proton.me>


> it provides some support for the view that a CLA is not needed.

I should have been more precise, I specifically meant the all-too-common type of CLA used alongside the AGPLv3 nowadays, where contributors have to sign over carte blanche rights to the project owners. Doesn't section 6 preclude that kind of CLA, or at least contradict it?

> latest "draft" version

Explicitly listing compatible inbound licenses seems like it could cause issues. What about niche licenses like https://opensource.org/license/bsdpluspatent ?

> https://git.copyleft.org/copyleft-next/copyleft-next/src/commit/5fdb9dca6bd9c7ab204976e46ce4663b8d4482c7/Drafts/copyleft-next#L72-L80

Doesn't this make it trivially easy to get around the "affero clause"?

> and a condition in
>   the Compatible License conflicts with any of the terms of this
>   License, You have permission to comply with that Compatible 
> License
>   condition.

Both GPLv2 and v3 contain clauses stating:

(v2)
> You may not impose any further restrictions on the recipients' exercise of the rights granted herein. 

(v3)
> You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License.

Ergo per the copyleft-next terms, I have permission to instead comply with this term of the GPL, and ignore the "affero" clause of the copyleft-next license. Am I missing something here or is this a loophole? I believe the EUPL has the same problem if I'm not mistaken.

On Tuesday, July 1st, 2025 at 9:44 AM, Richard Fontana <fontana at sharpeleven.org> wrote:

> 
> 
> On Tue, Jul 1, 2025 at 12:23 PM secureblueadmin
> secureblueadmin at proton.me wrote:
> 
> > I have a slightly tangential question along the lines of
> > 
> > > “I won't engage in proprietary relicensing” and really mean it.
> > 
> > Is the intent of the current section 6 to preclude issues such as the addition of a CLA? https://isitreallyfoss.com/concerns/copyleft-cla/
> 
> 
> That's this section:
> 
> "If You Distribute a work to Me specifically for inclusion in or
> modification of a Covered Work (a "Patch"), and no explicit licensing
> terms apply to the Patch, You license the Patch under this License, to
> the extent of Your copyright in the Patch. This condition does not
> negate the other conditions of this License, if applicable to the Patch."
> 
> This does not preclude the addition of a CLA, but I suppose (aside:
> it's weird to discuss something you know you wrote but don't remember
> :) it provides some support for the view that a CLA is not needed.
> This is clearly modeled on Apache License 2.0 section 5.
> 
> > Also, is there a plan to include an "affero clause" (network distribution) in this license? or in a different license? If so, how could this be done while still preserving the outward compatibility with (non-affero) GPL?
> 
> 
> Excellent question. copyleft-next 0.3.1 does not (as far as I can tell
> :) have an "Affero clause". However, the latest "draft" version of
> copyleft-next, i.e.
> https://git.copyleft.org/copyleft-next/copyleft-next/src/commit/5fdb9dca6bd9c7ab204976e46ce4663b8d4482c7/Drafts/copyleft-next
> does have one, which the original licensor can opt out of:
> 
> https://git.copyleft.org/copyleft-next/copyleft-next/src/commit/5fdb9dca6bd9c7ab204976e46ce4663b8d4482c7/Drafts/copyleft-next#L90-L98
> (which uses these definitions:
> https://git.copyleft.org/copyleft-next/copyleft-next/src/commit/5fdb9dca6bd9c7ab204976e46ce4663b8d4482c7/Drafts/copyleft-next#L226-L237
> )
> 
> It does not conflict with what you call the outward compatibility of
> GPL, because of this (counterpart in the latest "draft" to what I
> called the GPL escape hatch in copyleft-next 0.3.1):
> https://git.copyleft.org/copyleft-next/copyleft-next/src/commit/5fdb9dca6bd9c7ab204976e46ce4663b8d4482c7/Drafts/copyleft-next#L72-L80
> 
> As another aside, this structure of having "Releases" and "Drafts" was
> probably a bad idea.
> 
> I won't speak for bkuhn (a well known enthusiast of the Affero GPL
> both in theory and practice) but I think as a minimum feature
> copyleft-next should have an "Affero clause" of some sort. That was
> not an assumption I would have made in at least the earlier earlier
> history of copyleft-next, obviously.
> 
> Richard
> 
> > On Monday, June 30th, 2025 at 11:18 PM, Bradley M. Kuhn bkuhn at ebb.org wrote:
> > 
> > > > On Mon, Jun 30, 2025 at 6:18 PM secureblueadmin asked about:
> > > 
> > > > > [this] is an interesting way of preventing (A)GPL/commercial dual
> > > > > licensing:
> > > > > 7. Nullification of Copyleft/Proprietary Dual Licensing
> > > > > 
> > > > > If I offer to license, for a fee, a Covered Work under terms other
> > > > > than a license that is OSI-Approved or FSF-Free as of the release
> > > > > date of this License or a numbered version of copyleft-next released
> > > > > by the Copyleft-Next Project, then the license I grant You under
> > > > > section 1 is no longer subject to the conditions in sections 3
> > > > > through 5.
> > > 
> > > Richard Fontana replied:
> > > 
> > > > In copyleft-next 0.3.1 the proprietary relicensing poison pill (isn't that
> > > > what we sometimes used to call it?)
> > > 
> > > Shortly after you (Richard) invented §7, I dubbed it the “copyleft equality
> > > clause”: https://sfconservancy.org/blog/2020/jan/06/copyleft-equality/
> > > 
> > > I remember because it marked the third time in my career [0] my only
> > > contribution to something important was naming it. Now that I'm active in
> > > copyleft-next again, though, I hope to actually contribute more than names
> > > for things again. 😆
> > > 
> > > I really dislike the term “poison pill” not only for its violence but also
> > > because it's typically a tactic used by contracting parties who don't trust
> > > each other. IMO, the copyleft equality clause is a way that a licensor can
> > > state “I won't engage in proprietary relicensing” and really mean it. It
> > > builds trust while poison pills typically erode trust.
> > > 
> > > secureblueadmin asked:
> > > 
> > > > > However, this license also says:
> > > > > If the Derived Work includes material licensed under the GPL, You may
> > > > > instead license the Derived Work under the GPL.
> > > > > 
> > > > > As far as I can tell, it would seem that if there's some code under
> > > > > copyleft-next that you want to include in your GPL/commercial dual
> > > > > licensed software, you can just create a Derived work that combines
> > > > > `copyleft-next` code with `GPL` code, and then use that derived work (now
> > > > > under the GPL) in your GPL/commercial dual licensed software. Is this not
> > > > > a loophole?
> > > 
> > > secureblueadmin noted:
> > > 
> > > > > Anyhow, thanks for taking the time to read this and bear with my lack of
> > > > > legal knowledge :)
> > > 
> > > Richard replied:
> > > 
> > > > No need to apologize for what you say is a lack of legal knowledge. I would
> > > > think your question would be equally likely to be raised by a lawyer.
> > > 
> > > I agree. IANAL either but I've been involved in copyleft policy for 30
> > > years, and I still had to stare at the copyleft-next text and your question
> > > for about 7 minutes to make sure I definitely agreed with Denver's and
> > > Richard's analysis.
> > > 
> > > I think I do, for a third, slightly different reason: the copyleft equality
> > > clause actually removes the §§3-5 requirements for everyone in the world all
> > > at once and its binding once the Covered Work is distributed just once.
> > > 
> > > Remember the entity seeking to proprietary relicense has to have exclusive
> > > rights to the code anyway, so they could always license the Covered Work a
> > > new way (including under GPLv2, if they wanted) and didn't need copyleft-next
> > > §3 to do it anyway. Heck, §7 even lets them do it, too, without §§3-5.
> > > 
> > > The big flaw still remaining in the equality clause is that it may not fully
> > > prevent entities in cahoots doing something nasty.
> > > 
> > > Meanwhile, on my “list” of conversations to reopen is a complete overhaul of
> > > the approach in §3¶2 anyway. But more on that much later; not first thing on
> > > my list.
> > > 
> > > -- bkuhn
> > > 
> > > [0] I named the Classpath and the Replicant projects but have contributed
> > > virtually nothing else to them other than the names and moral support to
> > > the developers.
> > > _______________________________________________
> > > next mailing list
> > > next at lists.copyleft.org
> > > https://lists.copyleft.org/mailman/listinfo/next


From fontana at sharpeleven.org  Tue Jul  1 17:33:29 2025
From: fontana at sharpeleven.org (Richard Fontana)
Date: Tue, 1 Jul 2025 13:33:29 -0400
Subject: Questions about copyleft-next
In-Reply-To: <RBOXfRqQB4QmQOuWk0WgSROdwaP7khi7ydMaCoyjzUhux6uqWLsIo1Ol8cKVoRuWQTfGMyp8BnoIlrIVDb6ARlKBJ0qca-GJPlW6z0bBQEQ=@proton.me>
References: <WI3AbcYpjrIu7wxhRH2uNynScBuTnURos3V3Oc9gmaCI77ELA5gd9iXL4fF8oIxJnd2dOG-aWbDvKazfLxEMepmafQ4vbkoeJWHscs-7NZQ=@proton.me>
 <CAGT84B3k8TYf__+rK_cKTbmCWc=o8exH=HPG3R5CNXnEXhbt0w@mail.gmail.com>
 <aGN9RSWK8zipmgSY@ebb.org>
 <vIW1WuowIyrtxY3rCJzPWWFFnNEmVjqWRLext6-Belmx3_sF9GsyxgTycANL4G7ipGZUCh18qxK-ILg-IV1o62W-5EqaeUs2zXCUDx2HIMM=@proton.me>
 <CAGT84B3NCbw0tQjQCYZsaYUOghH2+LfW3UKCxAXZKhSD6y8r4A@mail.gmail.com>
 <RBOXfRqQB4QmQOuWk0WgSROdwaP7khi7ydMaCoyjzUhux6uqWLsIo1Ol8cKVoRuWQTfGMyp8BnoIlrIVDb6ARlKBJ0qca-GJPlW6z0bBQEQ=@proton.me>
Message-ID: <CAGT84B0oUaXcGsWJCPQCB43wSj_-CT0-8r+WmK8=nJ0L=8fxLw@mail.gmail.com>

On Tue, Jul 1, 2025 at 12:56 PM secureblueadmin
<secureblueadmin at proton.me> wrote:
>
>
> > it provides some support for the view that a CLA is not needed.
>
> I should have been more precise, I specifically meant the all-too-common type of CLA used alongside the AGPLv3 nowadays, where contributors have to sign over carte blanche rights to the project owners. Doesn't section 6 preclude that kind of CLA, or at least contradict it?

Section 6 is what you might call an "inbound=outbound" clause, but
just as in the inspirational provision of the Apache License 2.0, it
doesn't do anything to stop a project from using the sort of CLA
you're talking about if it's determined to do so.

Maybe there's a way to accomplish what you're talking about, though.
Like generalizing the copyleft equality clause (as bkuhn calls it) or
something like that.

> > latest "draft" version
>
> Explicitly listing compatible inbound licenses seems like it could cause issues. What about niche licenses like https://opensource.org/license/bsdpluspatent ?
>
> > https://git.copyleft.org/copyleft-next/copyleft-next/src/commit/5fdb9dca6bd9c7ab204976e46ce4663b8d4482c7/Drafts/copyleft-next#L72-L80
>
> Doesn't this make it trivially easy to get around the "affero clause"?

> > and a condition in
> >   the Compatible License conflicts with any of the terms of this
> >   License, You have permission to comply with that Compatible
> > License
> >   condition.
>
> Both GPLv2 and v3 contain clauses stating:
>
> (v2)
> > You may not impose any further restrictions on the recipients' exercise of the rights granted herein.
>
> (v3)
> > You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License.
>
> Ergo per the copyleft-next terms, I have permission to instead comply with this term of the GPL, and ignore the "affero" clause of the copyleft-next license. Am I missing something here or is this a loophole? I believe the EUPL has the same problem if I'm not mistaken.

So what 'Draft' copyleft-next says is:

The following activities do not violate [the no-further-restrictions
requirement]:
"a. Distribution of a Covered Work incorporating material governed by a
Compatible License, but the requirement in section FIXME to provide
Corresponding Source is in no case limited by this permission. If
the Compatible License is a GPL-Family License, and a condition in
the Compatible License conflicts with any of the terms of this
License, You have permission to comply with that Compatible License
condition."

So at least with respect to the Corresponding Source requirement [that
should have been changed to "CCS" which is the defined term used in
this draft version], this is trying to address the concern you're
raising. If you always have the original license requirement to
provide CCS, does it matter whether nominally the license of part of
the source code is BSD+Patent? That's the question, anyway. And
doesn't the same issue otherwise exist in the *GPL* licenses? I can
have a big chunk of some AGPLv3 work be under BSD+Patent, presumably.

Richard


From secureblueadmin at proton.me  Tue Jul  1 18:00:12 2025
From: secureblueadmin at proton.me (secureblueadmin)
Date: Tue, 01 Jul 2025 18:00:12 +0000
Subject: Questions about copyleft-next
In-Reply-To: <CAGT84B0oUaXcGsWJCPQCB43wSj_-CT0-8r+WmK8=nJ0L=8fxLw@mail.gmail.com>
References: <WI3AbcYpjrIu7wxhRH2uNynScBuTnURos3V3Oc9gmaCI77ELA5gd9iXL4fF8oIxJnd2dOG-aWbDvKazfLxEMepmafQ4vbkoeJWHscs-7NZQ=@proton.me>
 <CAGT84B3k8TYf__+rK_cKTbmCWc=o8exH=HPG3R5CNXnEXhbt0w@mail.gmail.com>
 <aGN9RSWK8zipmgSY@ebb.org>
 <vIW1WuowIyrtxY3rCJzPWWFFnNEmVjqWRLext6-Belmx3_sF9GsyxgTycANL4G7ipGZUCh18qxK-ILg-IV1o62W-5EqaeUs2zXCUDx2HIMM=@proton.me>
 <CAGT84B3NCbw0tQjQCYZsaYUOghH2+LfW3UKCxAXZKhSD6y8r4A@mail.gmail.com>
 <RBOXfRqQB4QmQOuWk0WgSROdwaP7khi7ydMaCoyjzUhux6uqWLsIo1Ol8cKVoRuWQTfGMyp8BnoIlrIVDb6ARlKBJ0qca-GJPlW6z0bBQEQ=@proton.me>
 <CAGT84B0oUaXcGsWJCPQCB43wSj_-CT0-8r+WmK8=nJ0L=8fxLw@mail.gmail.com>
Message-ID: <2G4iTT0VCBXfBLxeTVpRSOJAFbqBNkSE8DZpXCTU4asw7nZvnlZp4_XDTJksitMAb4SjDO9oWqBvwrDc8iPLxB9kpEstjgNeFbc381pcxo0=@proton.me>

> doesn't do anything to stop a project from using the sort of CLA you're talking about if it's determined to do so.

I see. It requires licensing patches under copyleft-next, but doesn't preclude licensing patches under other licenses as well.

> If you always have the original license requirement to provide CCS, does it matter whether nominally the license of part of
the source code is BSD+Patent?

I think something got mixed up here. I was making two separate and unrelated points. 

Point 1: Why have an explicit inbound list as opposed to allowing any license approved by the OSI and FSF?

Point 2 is a hypothetical:

Say for whatever reason I want to get around the network licensing clause of copyleft-next. copyleft-next allows me to disregard any condition of copyleft-next that conflicts with the terms of a Compatible License:

>  If the Compatible License is a GPL-Family License, and a condition in the Compatible License conflicts with any of the terms of this License, You have permission to comply with that Compatible License condition.

The GPL contains "no further restrictions" clauses that conflict with the "network distribution" clause of copyleft-next. Therefore to circumvent the network distribution clause, I can write some GPL code, mix it with copyleft-next code, and release that as a new project-ng without the network distribution clause, as permitted by the copyleft-next draft license and as required by the GPL. Now I've created a version of the original code that can be used downstream without adherence to the network clause.

What am I missing here?

On Tuesday, July 1st, 2025 at 10:33 AM, Richard Fontana <fontana at sharpeleven.org> wrote:

> 
> 
> On Tue, Jul 1, 2025 at 12:56 PM secureblueadmin
> secureblueadmin at proton.me wrote:
> 
> > > it provides some support for the view that a CLA is not needed.
> > 
> > I should have been more precise, I specifically meant the all-too-common type of CLA used alongside the AGPLv3 nowadays, where contributors have to sign over carte blanche rights to the project owners. Doesn't section 6 preclude that kind of CLA, or at least contradict it?
> 
> 
> Section 6 is what you might call an "inbound=outbound" clause, but
> just as in the inspirational provision of the Apache License 2.0, it
> doesn't do anything to stop a project from using the sort of CLA
> you're talking about if it's determined to do so.
> 
> Maybe there's a way to accomplish what you're talking about, though.
> Like generalizing the copyleft equality clause (as bkuhn calls it) or
> something like that.
> 
> > > latest "draft" version
> > 
> > Explicitly listing compatible inbound licenses seems like it could cause issues. What about niche licenses like https://opensource.org/license/bsdpluspatent ?
> > 
> > > https://git.copyleft.org/copyleft-next/copyleft-next/src/commit/5fdb9dca6bd9c7ab204976e46ce4663b8d4482c7/Drafts/copyleft-next#L72-L80
> > 
> > Doesn't this make it trivially easy to get around the "affero clause"?
> 
> > > and a condition in
> > > the Compatible License conflicts with any of the terms of this
> > > License, You have permission to comply with that Compatible
> > > License
> > > condition.
> > 
> > Both GPLv2 and v3 contain clauses stating:
> > 
> > (v2)
> > 
> > > You may not impose any further restrictions on the recipients' exercise of the rights granted herein.
> > 
> > (v3)
> > 
> > > You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License.
> > 
> > Ergo per the copyleft-next terms, I have permission to instead comply with this term of the GPL, and ignore the "affero" clause of the copyleft-next license. Am I missing something here or is this a loophole? I believe the EUPL has the same problem if I'm not mistaken.
> 
> 
> So what 'Draft' copyleft-next says is:
> 
> The following activities do not violate [the no-further-restrictions
> requirement]:
> "a. Distribution of a Covered Work incorporating material governed by a
> Compatible License, but the requirement in section FIXME to provide
> Corresponding Source is in no case limited by this permission. If
> the Compatible License is a GPL-Family License, and a condition in
> the Compatible License conflicts with any of the terms of this
> License, You have permission to comply with that Compatible License
> condition."
> 
> So at least with respect to the Corresponding Source requirement [that
> should have been changed to "CCS" which is the defined term used in
> this draft version], this is trying to address the concern you're
> raising. If you always have the original license requirement to
> provide CCS, does it matter whether nominally the license of part of
> the source code is BSD+Patent? That's the question, anyway. And
> doesn't the same issue otherwise exist in the GPL licenses? I can
> have a big chunk of some AGPLv3 work be under BSD+Patent, presumably.
> 
> Richard


From fontana at sharpeleven.org  Wed Jul  2 02:44:27 2025
From: fontana at sharpeleven.org (Richard Fontana)
Date: Tue, 1 Jul 2025 22:44:27 -0400
Subject: Questions about copyleft-next
In-Reply-To: <2G4iTT0VCBXfBLxeTVpRSOJAFbqBNkSE8DZpXCTU4asw7nZvnlZp4_XDTJksitMAb4SjDO9oWqBvwrDc8iPLxB9kpEstjgNeFbc381pcxo0=@proton.me>
References: <WI3AbcYpjrIu7wxhRH2uNynScBuTnURos3V3Oc9gmaCI77ELA5gd9iXL4fF8oIxJnd2dOG-aWbDvKazfLxEMepmafQ4vbkoeJWHscs-7NZQ=@proton.me>
 <CAGT84B3k8TYf__+rK_cKTbmCWc=o8exH=HPG3R5CNXnEXhbt0w@mail.gmail.com>
 <aGN9RSWK8zipmgSY@ebb.org>
 <vIW1WuowIyrtxY3rCJzPWWFFnNEmVjqWRLext6-Belmx3_sF9GsyxgTycANL4G7ipGZUCh18qxK-ILg-IV1o62W-5EqaeUs2zXCUDx2HIMM=@proton.me>
 <CAGT84B3NCbw0tQjQCYZsaYUOghH2+LfW3UKCxAXZKhSD6y8r4A@mail.gmail.com>
 <RBOXfRqQB4QmQOuWk0WgSROdwaP7khi7ydMaCoyjzUhux6uqWLsIo1Ol8cKVoRuWQTfGMyp8BnoIlrIVDb6ARlKBJ0qca-GJPlW6z0bBQEQ=@proton.me>
 <CAGT84B0oUaXcGsWJCPQCB43wSj_-CT0-8r+WmK8=nJ0L=8fxLw@mail.gmail.com>
 <2G4iTT0VCBXfBLxeTVpRSOJAFbqBNkSE8DZpXCTU4asw7nZvnlZp4_XDTJksitMAb4SjDO9oWqBvwrDc8iPLxB9kpEstjgNeFbc381pcxo0=@proton.me>
Message-ID: <CAGT84B0ByNZCAT2HkewjMRvXTc+Z81O6fw-btxeH3Ni6S+Z0vA@mail.gmail.com>

On Tue, Jul 1, 2025 at 2:00 PM secureblueadmin
<secureblueadmin at proton.me> wrote:

> I think something got mixed up here. I was making two separate and unrelated points.
>
> Point 1: Why have an explicit inbound list as opposed to allowing any license approved by the OSI and FSF?

I don't remember, but I remember that various approaches were
experimented with for dealing with license compatibility (both the
general or inbound compatibility issue or whatever people started
calling it way back in the 2010s, and the special problem of GPL
compatibility).

In the latest "Draft" there's an appendix with an enumeration of
"Compatible Licenses", including a subset consisting of "GPL-Family
Licenses". Whereas it appears that the approach taken in 0.3.1 was
something reminiscent of what (in a completely different context) I
once called the "Rule of Two" (that is, an inbound-compatible license
has to be both FSF-free and OSI-approved). That Rule of Two was
actually meant to describe the Software Freedom Conservancy's policy
on licensing of member projects, if I'm remembering correctly. So
undoubtedly that was the inspiration.

I think this, like pretty much everything else IMO, has to be
completely rethought. :)

> Point 2 is a hypothetical:
>
> Say for whatever reason I want to get around the network licensing clause of copyleft-next. copyleft-next allows me to disregard any condition of copyleft-next that conflicts with the terms of a Compatible License:
>
> >  If the Compatible License is a GPL-Family License, and a condition in the Compatible License conflicts with any of the terms of this License, You have permission to comply with that Compatible License condition.

> The GPL contains "no further restrictions" clauses that conflict with the "network distribution" clause of copyleft-next. Therefore to circumvent the network distribution clause, I can write some GPL code, mix it with copyleft-next code, and release that as a new project-ng without the network distribution clause, as permitted by the copyleft-next draft license and as required by the GPL. Now I've created a version of the original code that can be used downstream without adherence to the network clause.
>
> What am I missing here?

It's possible you're right. There was a general assumption for the
entire (active) history of drafting of copyleft-next (if I remember
correctly) that GPL compatibility was *so* important as a pragmatic
goal that all other policies of the license could be subverted in
favor of that goal, although I don't think I or anyone else put it
that way explicitly. I think that assumption is probably questionable
now, but I don't know.

There might be ways of specifically addressing your concern about the
network services issue. The obvious one might be to distinguish
between AGPLv3 and GPLvn. At that point, though, given how little
non-proprietary-relicensed AGPLv3 code there is in the world, it
probably makes sense just to give up on GPL compatibility (which,
after all, you could achieve in other ways, like dual-licensing).

Richard


From josh at joshtriplett.org  Wed Jul  2 06:42:39 2025
From: josh at joshtriplett.org (Josh Triplett)
Date: Tue, 1 Jul 2025 23:42:39 -0700
Subject: Questions about copyleft-next
In-Reply-To: <CAGT84B0ByNZCAT2HkewjMRvXTc+Z81O6fw-btxeH3Ni6S+Z0vA@mail.gmail.com>
References: <WI3AbcYpjrIu7wxhRH2uNynScBuTnURos3V3Oc9gmaCI77ELA5gd9iXL4fF8oIxJnd2dOG-aWbDvKazfLxEMepmafQ4vbkoeJWHscs-7NZQ=@proton.me>
 <CAGT84B3k8TYf__+rK_cKTbmCWc=o8exH=HPG3R5CNXnEXhbt0w@mail.gmail.com>
 <aGN9RSWK8zipmgSY@ebb.org>
 <vIW1WuowIyrtxY3rCJzPWWFFnNEmVjqWRLext6-Belmx3_sF9GsyxgTycANL4G7ipGZUCh18qxK-ILg-IV1o62W-5EqaeUs2zXCUDx2HIMM=@proton.me>
 <CAGT84B3NCbw0tQjQCYZsaYUOghH2+LfW3UKCxAXZKhSD6y8r4A@mail.gmail.com>
 <RBOXfRqQB4QmQOuWk0WgSROdwaP7khi7ydMaCoyjzUhux6uqWLsIo1Ol8cKVoRuWQTfGMyp8BnoIlrIVDb6ARlKBJ0qca-GJPlW6z0bBQEQ=@proton.me>
 <CAGT84B0oUaXcGsWJCPQCB43wSj_-CT0-8r+WmK8=nJ0L=8fxLw@mail.gmail.com>
 <2G4iTT0VCBXfBLxeTVpRSOJAFbqBNkSE8DZpXCTU4asw7nZvnlZp4_XDTJksitMAb4SjDO9oWqBvwrDc8iPLxB9kpEstjgNeFbc381pcxo0=@proton.me>
 <CAGT84B0ByNZCAT2HkewjMRvXTc+Z81O6fw-btxeH3Ni6S+Z0vA@mail.gmail.com>
Message-ID: <aGTU3zc73uD6_Kyy@localhost>

On Tue, Jul 01, 2025 at 10:44:27PM -0400, Richard Fontana wrote:
> On Tue, Jul 1, 2025 at 2:00 PM secureblueadmin
> <secureblueadmin at proton.me> wrote:
> 
> > I think something got mixed up here. I was making two separate and unrelated points.
> >
> > Point 1: Why have an explicit inbound list as opposed to allowing any license approved by the OSI and FSF?
> 
> I don't remember, but I remember that various approaches were
> experimented with for dealing with license compatibility (both the
> general or inbound compatibility issue or whatever people started
> calling it way back in the 2010s, and the special problem of GPL
> compatibility).
> 
> In the latest "Draft" there's an appendix with an enumeration of
> "Compatible Licenses", including a subset consisting of "GPL-Family
> Licenses". Whereas it appears that the approach taken in 0.3.1 was
> something reminiscent of what (in a completely different context) I
> once called the "Rule of Two" (that is, an inbound-compatible license
> has to be both FSF-free and OSI-approved). That Rule of Two was
> actually meant to describe the Software Freedom Conservancy's policy
> on licensing of member projects, if I'm remembering correctly. So
> undoubtedly that was the inspiration.
> 
> I think this, like pretty much everything else IMO, has to be
> completely rethought. :)

Having a list of compatible inbound licenses seems reasonable for a
license that's regularly kept up to date. And it seems safer than
deferring that list to external organizations.

> It's possible you're right. There was a general assumption for the
> entire (active) history of drafting of copyleft-next (if I remember
> correctly) that GPL compatibility was *so* important as a pragmatic
> goal that all other policies of the license could be subverted in
> favor of that goal, although I don't think I or anyone else put it
> that way explicitly. I think that assumption is probably questionable
> now, but I don't know.
[...]
> probably makes sense just to give up on GPL compatibility (which,
> after all, you could achieve in other ways, like dual-licensing).

I personally think it's critically important to keep inbound (and
*outbound*) GPL compatibility, in order to limit the degree to which a
new copyleft license bifurcates the ecosystem. It doesn't matter how
good the new license is; if using it means my users can't incorporate
GPLed software, I'd stick with the GPL (and not bother dual licensing).
And that's especially true if the new license's primary benefit is just
simplification; dual-licensing eliminates the benefit of simplicity.


From josh at joshtriplett.org  Tue Jul  1 18:19:28 2025
From: josh at joshtriplett.org (Josh Triplett)
Date: Tue, 1 Jul 2025 11:19:28 -0700
Subject: Registration process for git.copyleft.org?
Message-ID: <aGQmsDzWPoiiqwKx@localhost>

What is the registration process for git.copyleft.org? It has a page for
signing in with a username and password, but no obvious link from that
page for registration.

(I am hoping there is a means of registering and signing in without
having an OpenID URL.)


From winstondegreef at gmail.com  Thu Jul  3 07:35:11 2025
From: winstondegreef at gmail.com (Winston de Greef)
Date: Thu, 3 Jul 2025 03:35:11 -0400
Subject: vs CC BY-SA 4.0
Message-ID: <CAD2RJqYHd0-y_zX91DGUUNsBaAPmXskOym=4JOMK7zt-naDawg@mail.gmail.com>

Hi,

I was wondering why I might consider this license instead of something like
CC Attribution-ShareAlike 4.0 International.

Sincerely,
Winston de Greef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.copyleft.org/pipermail/next/attachments/20250703/1831ff7e/attachment.html>

From wolftune at riseup.net  Thu Jul  3 18:51:33 2025
From: wolftune at riseup.net (Aaron Wolf)
Date: Thu, 3 Jul 2025 11:51:33 -0700
Subject: vs CC BY-SA 4.0
In-Reply-To: <CAD2RJqYHd0-y_zX91DGUUNsBaAPmXskOym=4JOMK7zt-naDawg@mail.gmail.com>
References: <CAD2RJqYHd0-y_zX91DGUUNsBaAPmXskOym=4JOMK7zt-naDawg@mail.gmail.com>
Message-ID: <043cd39d-d4e4-497a-ab18-913a3ccf2512@riseup.net>

CC licenses aren't written for executable code projects (software). They 
have no requirements about *source* code or other source material, only 
the published form of works.

On 7/3/25 12:35, Winston de Greef wrote:
> Hi,
>
> I was wondering why I might consider this license instead of something 
> like CC Attribution-ShareAlike 4.0 International.
>
> Sincerely,
> Winston de Greef
>
> _______________________________________________
> next mailing list
> next at lists.copyleft.org
> https://lists.copyleft.org/mailman/listinfo/next
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.copyleft.org/pipermail/next/attachments/20250703/46686581/attachment.html>

From bkuhn at ebb.org  Thu Jul  3 20:16:40 2025
From: bkuhn at ebb.org (Bradley M. Kuhn)
Date: Thu, 3 Jul 2025 13:16:40 -0700
Subject: vs CC BY-SA 4.0
In-Reply-To: <CAD2RJqYHd0-y_zX91DGUUNsBaAPmXskOym=4JOMK7zt-naDawg@mail.gmail.com>
References: <CAD2RJqYHd0-y_zX91DGUUNsBaAPmXskOym=4JOMK7zt-naDawg@mail.gmail.com>
Message-ID: <aGblKM6f+WKj3jgW@ebb.org>

Winston de Greef wrote:
> I was wondering why I might consider this license instead of something like
> CC Attribution-ShareAlike 4.0 International.

The key reason that I recommend avoiding CC-BY-SA-4.0 is that it is *not* a
true copyleft.  Specifically, CC-BY-SA-4.0 (and other CC “share alike”s makes
basically no effort to assure that downstream recipients can *effectively*
take advantage of their right to modify.

Traditionally, software-focused copylefts always included some specific
description of what materials and rights must be provided downstream to allow
users/consumers to make *effective* use of their rights.  For example, GPLv2
talks about “complete, corresponding source code” which includes “scripts
used to control compilation and installation of the executable”.  A different
copyleft license, GPLv3, also has a lengthy definition for its defined term
“Corresponding Source”.

IMO, this material is the heart of what it means to be copyleft: if you can't
use the license to demand the artifacts you need *easily* engage in your
right to modify and/or install the software, then you don't really have a
copyleft license.

CC-BY-SA (any version) has never any real equivalent of a “source code
provision”.  The argument CC always made about this was that it's too hard to
define what “source code” is for works other than software (e.g., movies).

*But* there are some quite obvious activities that CC-BY-SA seems to allow
which are clearly not make it non-copyleft.  For example, CC-BY-SA [0] allows
licensees to take a CC-BY-SA'd high-quality SVG, turn it into a tiny PNG,
incorporate it into another work, but not provide the original SVG to
downstream.  In fact, they can do all their development in SVG and only
distribute the PNGs.

This is an obvious case where, if you're doing graphics editing as vector
images, the “corresponding source code” is clearly the SVG files you edited
in, say, Inkscape, not some PNG you exported at the end.

While copyleft-next is primarily going to be a software license, we
are actively thinking about this issues.

[0] To my knowledge, I'm not as expert in CC-BY-SA so if I'm mistaken, I
    welcome correction from others.


    -- bkuhn (he/them)


From fontana at sharpeleven.org  Fri Jul  4 00:34:39 2025
From: fontana at sharpeleven.org (Richard Fontana)
Date: Thu, 3 Jul 2025 20:34:39 -0400
Subject: vs CC BY-SA 4.0
In-Reply-To: <aGblKM6f+WKj3jgW@ebb.org>
References: <CAD2RJqYHd0-y_zX91DGUUNsBaAPmXskOym=4JOMK7zt-naDawg@mail.gmail.com>
 <aGblKM6f+WKj3jgW@ebb.org>
Message-ID: <CAGT84B1EKJ6b6QpKair7mmoquwnMifoQMDqCexmbrtSishfMzQ@mail.gmail.com>

On Thu, Jul 3, 2025 at 4:17 PM Bradley M. Kuhn <bkuhn at ebb.org> wrote:
>
> Winston de Greef wrote:
> > I was wondering why I might consider this license instead of something like
> > CC Attribution-ShareAlike 4.0 International.
>
> The key reason that I recommend avoiding CC-BY-SA-4.0 is that it is *not* a
> true copyleft.  Specifically, CC-BY-SA-4.0 (and other CC “share alike”s makes
> basically no effort to assure that downstream recipients can *effectively*
> take advantage of their right to modify.
>
> Traditionally, software-focused copylefts always included some specific
> description of what materials and rights must be provided downstream to allow
> users/consumers to make *effective* use of their rights.  For example, GPLv2
> talks about “complete, corresponding source code” which includes “scripts
> used to control compilation and installation of the executable”.  A different
> copyleft license, GPLv3, also has a lengthy definition for its defined term
> “Corresponding Source”.
>
> IMO, this material is the heart of what it means to be copyleft: if you can't
> use the license to demand the artifacts you need *easily* engage in your
> right to modify and/or install the software, then you don't really have a
> copyleft license.
>
> CC-BY-SA (any version) has never any real equivalent of a “source code
> provision”.

I would also argue that CC-BY-SA (any version I'm aware of) is not
truly (in general) a _libre_ license, despite common assumptions
otherwise. One particular problem that exists in all Creative Commons
licenses I'm familiar with is the language about patents - in CC-BY-SA
4.0:
"Patent and trademark rights are not licensed under this Public License."
While in general what a FLOSS license should say, if anything, about
patents is a difficult topic, I would contend that a license that says
"patents aren't licensed" can't be considered _libre_ (trademarks
don't raise the same concern).

Admittedly, for many kinds of works commonly licensed under CC-BY-SA
4.0 and other Creative Commons licenses, this is not likely to matter
because such works will, probably, not be susceptible to being covered
by a valid patent claim. Occasionally, however, purportedly FLOSS
projects use CC-BY-SA and other CC licenses for code and other
functional material, possibly assuming that they are _libre_. Similar
language is also in CC0, which *is* pretty commonly used for code.

Still, we can certainly learn from studying how Creative Commons
attempted to solve copyleft and other libre or quasi-libre license
implementation problems.

Richard


From josh at joshtriplett.org  Tue Jul  1 18:40:06 2025
From: josh at joshtriplett.org (Josh Triplett)
Date: Tue, 1 Jul 2025 11:40:06 -0700
Subject: Copyleft-next should not do unilateral disarmament via the sunset
 clause
Message-ID: <aGQrhpirwz5_c8ea@localhost>

I can very much appreciate arguments that copyright should not last as
long as it does.

However, as long as proprietary software continues to have the full
duration of copyright at its disposal, it seems like a license
purporting to be the future of copyleft should not be unilaterally
disarming by turning into a permissive license after 15 years.

The world already has enough permissive licenses, and far too much
pressure towards permissive licensing and away from copyleft. I don't
think an intended-as-flagship copyleft license should be adding to the
steady decline of copyleft towards permissive licensing; that seems like
a step backwards, and a good reason to continue using the GPL instead.

In general, the concept of doing better than the GPL seems like a good
idea. However, introducing regressions relative to the GPL runs counter
to that goal. There's already going to be a substantial amount of
bifurcation between this license and the GPL; it'd be easier to argue
against that bifurcation if this license were an improvement over the
GPL in every respect, including in the strength of its copyleft.

- Josh Triplett


From me at aethrvmn.gr  Sat Jul  5 15:38:22 2025
From: me at aethrvmn.gr (Vasileios Valatsos)
Date: Sat, 5 Jul 2025 17:38:22 +0200
Subject: Copyleft-next should not do unilateral disarmament via the sunset
 clause
In-Reply-To: <aGQrhpirwz5_c8ea@localhost>
References: <aGQrhpirwz5_c8ea@localhost>
Message-ID: <01d241ab-fc04-4404-8a10-28b819d06720@aethrvmn.gr>

Personally I agree, and feel like any "sunsetting" of a copyleft clause 
is a defeat for any libre software license.

 > I don't think an intended-as-flagship copyleft license should be 
adding to the steady decline of copyleft towards permissive licensing

I fully agree. The purpose of copyleft was to ensure the freedoms of the 
end user, not of the developer; there is zero reason for any person who 
cares about end user freedoms to pick copyleft-next over the GPL, as old 
a the GPL may be and in need of a refresh.

If anything I would go the extra mile and say that copyleft-next should 
reinforce the idea of copyleft in new spaces such as AI training 
(although that's for a different thread).

 > However, introducing regressions relative to the GPL runs counter to 
that goal.

Apart from regressions, with which I fully agree, I feel like the issue 
on top is that 'sunsetting', in terms of patents and copyrights at 
least, is meant to limit the ability of people (or corporations) to hold 
on to, and to prevent users from accessing, their own proprietary work.

In this sense sunsetting copyleft is nonsensical, because copyleft 
enforces user access.

- Vasileios Valatsos


From james at frost.cx  Sun Jul  6 19:59:28 2025
From: james at frost.cx (James Frost)
Date: Sun, 6 Jul 2025 20:59:28 +0100
Subject: What is permissive-next for?
Message-ID: <524e09a3-7464-4249-90ad-30061fd0d6a2@frost.cx>

I was wondering what the intent of the permissive-next[1] licence was?

By my reading it is essentially equivalent to the Apache 2.0 licence, 
does it add anything that I have missed? It seems to me that permissive 
licences are plenty well covered by the Apache 2.0/MIT/BSD licences.

Does this licence add anything over Apache 2.0 that I have missed, or is 
there some other reason for its creation?

Thanks,
James.

[1]: 
https://git.copyleft.org/copyleft-next/copyleft-next/src/commit/85138bac3ff7e0d94a6c76ae1ea3ba7011efad07/Drafts/permissive-next



From bkuhn at ebb.org  Sun Jul  6 23:57:36 2025
From: bkuhn at ebb.org (Bradley M. Kuhn)
Date: Sun, 6 Jul 2025 16:57:36 -0700
Subject: Copyleft-next should not do unilateral disarmament via the
 sunset clause
In-Reply-To: <01d241ab-fc04-4404-8a10-28b819d06720@aethrvmn.gr>
References: <aGQrhpirwz5_c8ea@localhost>
 <01d241ab-fc04-4404-8a10-28b819d06720@aethrvmn.gr>
Message-ID: <aGsNcDtoIzmX+Nyd@ebb.org>

I think at one point I supported the sunset clause … in an effort to be
realistic about how long software is actually useful without changes or
improvements (which of course would be newly copyrightable).

We should also consider the question of when copyleft contractual obligations
should sunset (and if they should).

These are complex questions, but I think starting from first principles,
cutting the existing sunset clause and design from scratch may make more
sense.

I'm curious what Fontana thinks since he added it in:

commit c2569e09be25540028979bf883d2f3a0c9d45d6f
Author: Richard Fontana <fontana at sharpeleven.org>
Date:   Feb 19 2013

    Add 'Copyleft Sunset' provision.

    See mailing list thread "Limited-term copyleft" beginning at
    https://lists.fedorahosted.org/pipermail/copyleft-next/2013-February/000499.html

Sadly that URL fails so I wonder if folks could find a better link to that
thread on the old list?
--
     -- bkuhn, noting: IANAL & TINLA


From bkuhn at ebb.org  Mon Jul  7 00:05:24 2025
From: bkuhn at ebb.org (Bradley M. Kuhn)
Date: Sun, 6 Jul 2025 17:05:24 -0700
Subject: Registration process for git.copyleft.org?
In-Reply-To: <aGQmsDzWPoiiqwKx@localhost>
References: <aGQmsDzWPoiiqwKx@localhost>
Message-ID: <aGsPRJcjKFUf77Bv@ebb.org>

Thanks for asking, Josh, this is an important question and sorry
there is no obvious answer on the site.  I'll try to fix that.

Sorry that I took a few days to answer this email; much of the new
infrastructure was set up in a hurry to meet the announcement date we wanted
(to coincide with GPLv3's 18th anniversary), so there are still some bugs
sitting around in the setup.

Josh Triplett wrote:
> What is the registration process for git.copyleft.org? It has a page for
> signing in with a username and password, but no obvious link from that page
> for registration.

So, unfortunately, forgejo's only options are (a) unmoderated registration
open to the world or (b) admin-only creation of accounts.

We're worried about the unwieldiness of moderation, so we're going with (b).

It's going to be easiest for me if you want an account on git.copyleft.org to
please private mention @next at copyleft.org on the fediverse in reply to this
post: https://fedi.copyleft.org/@next/114809018445342879


If that doesn't work, email to me privately should work “eventually” as a
backup option.


I'm looking for a better solution than these two options, but it's the best I
can offer at the moment.

--
     -- bkuhn, noting: IANAL & TINLA


From fontana at sharpeleven.org  Mon Jul  7 00:41:08 2025
From: fontana at sharpeleven.org (Richard Fontana)
Date: Sun, 6 Jul 2025 20:41:08 -0400
Subject: Copyleft-next should not do unilateral disarmament via the sunset
 clause
In-Reply-To: <aGsNcDtoIzmX+Nyd@ebb.org>
References: <aGQrhpirwz5_c8ea@localhost>
 <01d241ab-fc04-4404-8a10-28b819d06720@aethrvmn.gr>
 <aGsNcDtoIzmX+Nyd@ebb.org>
Message-ID: <CAGT84B0YPN3qTo8kk2T6pc4SaQrosySD7W_hhvb6wZ+N9qRWfQ@mail.gmail.com>

On Sun, Jul 6, 2025 at 8:10 PM Bradley M. Kuhn <bkuhn at ebb.org> wrote:
>
> I think at one point I supported the sunset clause … in an effort to be
> realistic about how long software is actually useful without changes or
> improvements (which of course would be newly copyrightable).
>
> We should also consider the question of when copyleft contractual obligations
> should sunset (and if they should).
>
> These are complex questions, but I think starting from first principles,
> cutting the existing sunset clause and design from scratch may make more
> sense.

I agree.

> I'm curious what Fontana thinks since he added it in:
>
> commit c2569e09be25540028979bf883d2f3a0c9d45d6f
> Author: Richard Fontana <fontana at sharpeleven.org>
> Date:   Feb 19 2013
>
>     Add 'Copyleft Sunset' provision.
>
>     See mailing list thread "Limited-term copyleft" beginning at
>     https://lists.fedorahosted.org/pipermail/copyleft-next/2013-February/000499.html
>
> Sadly that URL fails so I wonder if folks could find a better link to that
> thread on the old list?

Not sure but I suspect this may be related to the datacenter migration
that Fedora has been undergoing recently.

Richard


From fontana at sharpeleven.org  Mon Jul  7 00:54:17 2025
From: fontana at sharpeleven.org (Richard Fontana)
Date: Sun, 6 Jul 2025 20:54:17 -0400
Subject: What is permissive-next for?
In-Reply-To: <524e09a3-7464-4249-90ad-30061fd0d6a2@frost.cx>
References: <524e09a3-7464-4249-90ad-30061fd0d6a2@frost.cx>
Message-ID: <CAGT84B3ck3HKSC8MBmiFnvpMvO+KrAeYYQdMFX7M2fZ1Utjqqg@mail.gmail.com>

On Sun, Jul 6, 2025 at 4:05 PM James Frost <james at frost.cx> wrote:
>
> I was wondering what the intent of the permissive-next[1] licence was?
>
> By my reading it is essentially equivalent to the Apache 2.0 licence,
> does it add anything that I have missed? It seems to me that permissive
> licences are plenty well covered by the Apache 2.0/MIT/BSD licences.
>
> Does this licence add anything over Apache 2.0 that I have missed, or is
> there some other reason for its creation?

The way I remember it, at certain points in the active drafting
history of copyleft-next, the project had these bouts of ambition, or
hubris or whatever, one of which was entertaining the idea that
copyleft-next could also be the basis of a *noncopyleft* license
variant, thus giving rise potentially to a suite of textually similar
model licenses comparable to the Creative Commons licenses.

I pretty much agree with you that at this point "permissive licences
are plenty well covered by the Apache 2.0/MIT/BSD licences" (not to
mention zillions of others) and I think permissive-next should be
abandoned so that copyleft-next can focus entirely on copyleft.

Richard

> [1]:
> https://git.copyleft.org/copyleft-next/copyleft-next/src/commit/85138bac3ff7e0d94a6c76ae1ea3ba7011efad07/Drafts/permissive-next


From fontana at sharpeleven.org  Mon Jul  7 15:02:21 2025
From: fontana at sharpeleven.org (Richard Fontana)
Date: Mon, 7 Jul 2025 11:02:21 -0400
Subject: Copyleft-next should not do unilateral disarmament via the sunset
 clause
In-Reply-To: <CAGT84B0YPN3qTo8kk2T6pc4SaQrosySD7W_hhvb6wZ+N9qRWfQ@mail.gmail.com>
References: <aGQrhpirwz5_c8ea@localhost>
 <01d241ab-fc04-4404-8a10-28b819d06720@aethrvmn.gr>
 <aGsNcDtoIzmX+Nyd@ebb.org>
 <CAGT84B0YPN3qTo8kk2T6pc4SaQrosySD7W_hhvb6wZ+N9qRWfQ@mail.gmail.com>
Message-ID: <CAGT84B1HjpCa=suKhTmKdC7HFK5JDVRUXzgzSSrzyC_K3KuBFQ@mail.gmail.com>

On Sun, Jul 6, 2025 at 8:41 PM Richard Fontana <fontana at sharpeleven.org> wrote:
>
> On Sun, Jul 6, 2025 at 8:10 PM Bradley M. Kuhn <bkuhn at ebb.org> wrote:
> >
> > I think at one point I supported the sunset clause … in an effort to be
> > realistic about how long software is actually useful without changes or
> > improvements (which of course would be newly copyrightable).
> >
> > We should also consider the question of when copyleft contractual obligations
> > should sunset (and if they should).
> >
> > These are complex questions, but I think starting from first principles,
> > cutting the existing sunset clause and design from scratch may make more
> > sense.
>
> I agree.
>
> > I'm curious what Fontana thinks since he added it in:
> >
> > commit c2569e09be25540028979bf883d2f3a0c9d45d6f
> > Author: Richard Fontana <fontana at sharpeleven.org>
> > Date:   Feb 19 2013
> >
> >     Add 'Copyleft Sunset' provision.
> >
> >     See mailing list thread "Limited-term copyleft" beginning at
> >     https://lists.fedorahosted.org/pipermail/copyleft-next/2013-February/000499.html
> >
> > Sadly that URL fails so I wonder if folks could find a better link to that
> > thread on the old list?
>
> Not sure but I suspect this may be related to the datacenter migration
> that Fedora has been undergoing recently.

The thread can be read via Hyperkitty at:
https://lists.fedoraproject.org/archives/list/copyleft-next at lists.fedorahosted.org/thread/QE3LAPLGBIKCACEOKLMKAW7FCLS2USKZ/


From me at aethrvmn.gr  Mon Jul  7 21:17:10 2025
From: me at aethrvmn.gr (Vasileios Valatsos)
Date: Mon, 7 Jul 2025 23:17:10 +0200
Subject: Copyleft-next should not do unilateral disarmament via the sunset
 clause
In-Reply-To: <CAGT84B1HjpCa=suKhTmKdC7HFK5JDVRUXzgzSSrzyC_K3KuBFQ@mail.gmail.com>
References: <CAGT84B1HjpCa=suKhTmKdC7HFK5JDVRUXzgzSSrzyC_K3KuBFQ@mail.gmail.com>
Message-ID: <80ea22f7-17e3-4c24-88ca-fff908786257@aethrvmn.gr>


 >The thread can be read via Hyperkitty at:
 >https://lists.fedoraproject.org/archives/list/copyleft-next at lists.fedorahosted.org/thread/QE3LAPLGBIKCACEOKLMKAW7FCLS2USKZ/

That thread is very interesting, it does have some good points, however 
I still think that, as others in that thread said, if someone wanted to 
add a sunset clause this could be achieved with a separate license or an 
additional custom clause, so people can choose whether or not they want 
to include a sunset clause (I for example wouldn't), but there might be 
usecases or developers who might want to. (Maybe a copyleft-temp?)

Also, and I hope it doesn't come as rude, it's funny how the first 
thread in that link is about the non-commercial use of software past a 
certain age, but the initial post was about code from 1979 used in a 
commercial setting. (46 years!)

- Vasileios Valatsos


From james at frost.cx  Tue Jul  8 21:35:41 2025
From: james at frost.cx (James Frost)
Date: Tue, 8 Jul 2025 22:35:41 +0100
Subject: What do the defined acronyms stand for?
Message-ID: <76c02b2c-066c-42c1-961c-e2bc69894e95@frost.cx>

Reading through the licence there are a couple terms that are defined as 
acronyms without being expanded. I would be interested in knowing what 
they mean. As these terms are not used repeatedly, I feel it would be 
best to write the full acronym out to improve the licence's readability.

The acronyms are:

NSS: My guess is Network Service Source. This is only used once, so 
really has no justification in being shortened.

CCS: Covered Code Source? Not really sure about this one. This is 
referenced three times in the licence, all in section 5, so perhaps that 
could be reworded to expand the term.



From bkuhn at ebb.org  Thu Jul 10 00:43:20 2025
From: bkuhn at ebb.org (Bradley M. Kuhn)
Date: Wed, 9 Jul 2025 17:43:20 -0700
Subject: Registration process for git.copyleft.org?
In-Reply-To: <aGsPRJcjKFUf77Bv@ebb.org>
References: <aGQmsDzWPoiiqwKx@localhost>
 <aGsPRJcjKFUf77Bv@ebb.org>
Message-ID: <aG8MqM0rh3qxfMP3@ebb.org>

I just wanted to follow up on this post to note that we got a really useful
comment here:

https://fedi.copyleft.org/@algernon at come-from.mad-scientist.club/114813685920621285


I wanted to let everyone know we've got “Login via Codeberg” on a
low-priority list of things to implement for git.copyleft.org as it sounds
like a good compromise (and Codeberg is the “flagship” forgejo instance).

As you all know from our announcement, SFC is donating the sysadmin work to
us for copyleft-next, so we are trying to prioritize the time to the most
urgent.

In the meantime, this method continues the best way to request a
git.copyleft.org account:

I wrote:
> It's going to be easiest for me if you want an account on git.copyleft.org to
> please private mention @next at copyleft.org on the fediverse in reply to this
> post: https://fedi.copyleft.org/@next/114809018445342879


Thanks for your understanding!
--
     -- bkuhn, noting: IANAL & TINLA


From fontana at sharpeleven.org  Thu Jul 10 18:24:57 2025
From: fontana at sharpeleven.org (Richard Fontana)
Date: Thu, 10 Jul 2025 14:24:57 -0400
Subject: What do the defined acronyms stand for?
In-Reply-To: <76c02b2c-066c-42c1-961c-e2bc69894e95@frost.cx>
References: <76c02b2c-066c-42c1-961c-e2bc69894e95@frost.cx>
Message-ID: <CAGT84B3BK__BPL-RysDj6xix4BgF-2jQLW4tztGo6a70ppxiPQ@mail.gmail.com>

On Tue, Jul 8, 2025 at 5:43 PM James Frost <james at frost.cx> wrote:
>
> Reading through the licence there are a couple terms that are defined as
> acronyms without being expanded. I would be interested in knowing what
> they mean. As these terms are not used repeatedly, I feel it would be
> best to write the full acronym out to improve the licence's readability.

> The acronyms are:
>
> NSS: My guess is Network Service Source. This is only used once, so
> really has no justification in being shortened.

> CCS: Covered Code Source? Not really sure about this one. This is
> referenced three times in the licence, all in section 5, so perhaps that
> could be reworded to expand the term.

These are in the latest 'Draft'.
NSS is defined at
https://git.copyleft.org/copyleft-next/copyleft-next/src/branch/main/Drafts/copyleft-next#L231-L237
CCS is defined at
https://git.copyleft.org/copyleft-next/copyleft-next/src/branch/main/Drafts/copyleft-next#L213-L224

These terms are not used in the latest 'Release' (0.3.1). However, I
see an error in the draft in that at one point it uses 'Corresponding
Source' rather than 'CCS'.

I wonder if you didn't notice the definitions because they're at the
end. In modern-day formal commercial contracts it's common to see a
set of defined terms and most often these are at the beginning of the
agreement. A number of FLOSS licenses follow this convention. I had a
former co-worker who preferred to put definitions at the end and I
believe this is what influenced the approach taken in the more recent
versions of copyleft-next. The argument is basically stylistic, that
having definitions at the beginning creates 'clutter', especially
where there's a tendency to have a lot of definitions.

If a term is only used once, you might still want it to be a defined
term (whether an acronym/initialism or not). However, I would say a
term used only once should perhaps be defined close to where it's used
rather than in a definitions section.

Richard


From james at frost.cx  Thu Jul 10 19:05:58 2025
From: james at frost.cx (James Frost)
Date: Thu, 10 Jul 2025 20:05:58 +0100
Subject: What do the defined acronyms stand for?
In-Reply-To: <CAGT84B3BK__BPL-RysDj6xix4BgF-2jQLW4tztGo6a70ppxiPQ@mail.gmail.com>
References: <76c02b2c-066c-42c1-961c-e2bc69894e95@frost.cx>
 <CAGT84B3BK__BPL-RysDj6xix4BgF-2jQLW4tztGo6a70ppxiPQ@mail.gmail.com>
Message-ID: <60f4b8c8-af4e-4f77-8bdf-c247a16957b1@frost.cx>

 > I wonder if you didn't notice the definitions

Sorry, I didn't make myself very clear. I've read the definitions and 
agree they define what they mean, but I was wondering what the expansion 
of the initialism were. The context is that I'm writing up some proposed 
amendments, one of which is to remove unnecessary initialisms, as they 
are often a barrier to comprehensibility, and I wanted to know what to 
put in their stead.

So my point is that I think the licence would be clearer if it continued 
using "Network Service Source" and "Corresponding Source" rather than 
the initialisms, as those terms give a reasonable approximation of their 
meaning to the casual reader without having to refer to the definitions.

 > it's common to see a set of defined terms and most often these are at 
the beginning of the agreement.

This is another thing I've noted in my review. As the definitions 
underpin the rest of the licence text, I feel that it is clearer to put 
them at the front so readers know what you are referring to when they 
read it. This probably depends on the length of your document, as a very 
long document might be better served with a glossary in a separate 
chapter at the end so that it can be easily be located when needed. The 
licence text is short enough that navigation is not a significant issue, 
so I'd have a small preference for the front, though I don't feel too 
strongly about it.

 > I would say a term used only once should perhaps be defined close to 
where it's used rather than in a definitions section.

I'd agree with that, though it does risk adding inconsistency if you 
still have to define terms used throughout the text, and can affect the 
flow of the text if the terms already give an approximate understanding 
without the definitions.

Thanks,
James.



From fontana at sharpeleven.org  Fri Jul 11 00:23:06 2025
From: fontana at sharpeleven.org (Richard Fontana)
Date: Thu, 10 Jul 2025 20:23:06 -0400
Subject: What do the defined acronyms stand for?
In-Reply-To: <60f4b8c8-af4e-4f77-8bdf-c247a16957b1@frost.cx>
References: <76c02b2c-066c-42c1-961c-e2bc69894e95@frost.cx>
 <CAGT84B3BK__BPL-RysDj6xix4BgF-2jQLW4tztGo6a70ppxiPQ@mail.gmail.com>
 <60f4b8c8-af4e-4f77-8bdf-c247a16957b1@frost.cx>
Message-ID: <CAGT84B3Vvnv6NbJQBK23Ev=neUwUUUQKzDqQrGqNijwXgpG7dw@mail.gmail.com>

On Thu, Jul 10, 2025 at 3:06 PM James Frost <james at frost.cx> wrote:
>
>  > I wonder if you didn't notice the definitions
>
> Sorry, I didn't make myself very clear. I've read the definitions and
> agree they define what they mean, but I was wondering what the expansion
> of the initialism were. The context is that I'm writing up some proposed
> amendments, one of which is to remove unnecessary initialisms, as they
> are often a barrier to comprehensibility, and I wanted to know what to
> put in their stead.
>
> So my point is that I think the licence would be clearer if it continued
> using "Network Service Source" and "Corresponding Source" rather than
> the initialisms, as those terms give a reasonable approximation of their
> meaning to the casual reader without having to refer to the definitions.

Oh I see. You're probably right. I don't remember but it's possible
this started out with using "CCS" and maybe I thought that that would
be understood because ... well, Bradley and I think others at the
Software Freedom Conservancy, and maybe also people at the FSF, have
used that term for "Complete Corresponding Source". Then I probably
thought of using "NSS" similarly.

>  > it's common to see a set of defined terms and most often these are at
> the beginning of the agreement.
>
> This is another thing I've noted in my review. As the definitions
> underpin the rest of the licence text, I feel that it is clearer to put
> them at the front so readers know what you are referring to when they
> read it. This probably depends on the length of your document, as a very
> long document might be better served with a glossary in a separate
> chapter at the end so that it can be easily be located when needed. The
> licence text is short enough that navigation is not a significant issue,
> so I'd have a small preference for the front, though I don't feel too
> strongly about it.

Probably most contract-drafting lawyers would agree with you. It's
possible I came to like putting definitions at the end partly to defy
convention and tradition, even though the one person I know who
prefers this doesn't strike me as a particularly unconventional
lawyer.

Richard


From fontana at sharpeleven.org  Fri Jul 11 00:29:57 2025
From: fontana at sharpeleven.org (Richard Fontana)
Date: Thu, 10 Jul 2025 20:29:57 -0400
Subject: What do the defined acronyms stand for?
In-Reply-To: <60f4b8c8-af4e-4f77-8bdf-c247a16957b1@frost.cx>
References: <76c02b2c-066c-42c1-961c-e2bc69894e95@frost.cx>
 <CAGT84B3BK__BPL-RysDj6xix4BgF-2jQLW4tztGo6a70ppxiPQ@mail.gmail.com>
 <60f4b8c8-af4e-4f77-8bdf-c247a16957b1@frost.cx>
Message-ID: <CAGT84B3CkBTbzzqHzArVr8o-O6XzdZ1-RyGNSFXb_9zae3eDLQ@mail.gmail.com>

On Thu, Jul 10, 2025 at 3:06 PM James Frost <james at frost.cx> wrote:
> The context is that I'm writing up some proposed
> amendments, one of which is to remove unnecessary initialisms, as they
> are often a barrier to comprehensibility, and I wanted to know what to
> put in their stead.

I appreciate and welcome the interest very much but might suggest
holding off because I have a feeling we may want to just start over
from scratch, given how long it's been since this license was even
occasionally being reviewed and modified. Which reminds me, I should
start a thread on what the goals of copyleft-next are or should be at
this point. They aren't necessarily going to match whatever the
objectives were over a decade ago, as I think we're already starting
to see with some of the comments e.g. on the "Copyleft Sunset" and so
forth.

Richard


From bkuhn at ebb.org  Fri Jul 11 01:05:21 2025
From: bkuhn at ebb.org (Bradley M. Kuhn)
Date: Thu, 10 Jul 2025 18:05:21 -0700
Subject: drafting strategy & =?utf-8?B?4oCcc3BlY2lv?=
 =?utf-8?Q?us_argument_vector=E2=80=9D_vs=2E_programme?= =?utf-8?Q?r?=
 readability (was Re: What do the defined acronyms stand for?)
In-Reply-To: <60f4b8c8-af4e-4f77-8bdf-c247a16957b1@frost.cx>
References: <76c02b2c-066c-42c1-961c-e2bc69894e95@frost.cx>
 <CAGT84B3CkBTbzzqHzArVr8o-O6XzdZ1-RyGNSFXb_9zae3eDLQ@mail.gmail.com>
 <CAGT84B3BK__BPL-RysDj6xix4BgF-2jQLW4tztGo6a70ppxiPQ@mail.gmail.com>
 <60f4b8c8-af4e-4f77-8bdf-c247a16957b1@frost.cx>
Message-ID: <aHBjUdECSacbPkGg@ebb.org>

[ NOTE: Some will receive a duplicate of this email.  I accidentally posted
  with X-No-Archive on and wanted this to land in the archives. ]

I kinda took a tangent here, and I'm only partially addressing what James was
asking.  Nevertheless, I started writing here and I think this is useful as
we reframe our discussion on how we'll draft the next copyleft-next (ha!), so
I'm sending it along.  The TL;DR is that I think discussion of readability
needs more context rather than getting into the nitty gritty of word choices
and the like.  IOW, I think James' questions are focused on tactics of
drafting copyleft clauses, and we have to first explore the *strategy* for
drafting copyleft before working on tactics.

Most notably, I am arguing we must take a drafting strategy that assumes
we've got a Cartisian “evil genius” arguing constantly that the plain text
doesn't mean what is says.  Because “evil geniuses” that do are already in
many positions of power throughout the tech industry and are already doing
just that for all existing copyleft licenses.  They haven't started with
copyleft-next only because it's not popular enough yet for them to bother.

What's funny, and I promise this is true, I had *just* finished drafting
this email when Richard posted two emails, one of which said:

Richard Fontana wrote:
>> Which reminds me, I should
>> start a thread on what the goals of copyleft-next are or should be at
>> this point. They aren't necessarily going to match whatever the
>> objectives were over a decade ago, as I think we're already starting
>> to see with some of the comments

In essence, my email below was kinda not exactly answering James' point,
but was answering this question above that Richard hadn't written yet.

(Sorry, I'm just kinda loving that Richard and I are sitting late
at our desks, squeezing in volunteer time for copyleft-next, and worried
about the same thing even though I'm sure we're going to disagree
on the approach.  HBR shows you how the proverbial sausage is made.)

James Frost wrote:
> So my point is that I think the licence would be clearer if it continued
> using "Network Service Source" and "Corresponding Source" rather than the
> initialisms, as those terms give a reasonable approximation of their
> meaning to the casual reader without having to refer to the definitions.

While “defined terms” are a concept that only lawyers and programmers can
love, the sad fact is we have to favor iron-solid clarity for posterity over
readability (more times than not, anyway).

I'm going to write more about this on this list over the coming months, but
here's a flavor of what I'm getting at:

One of my goals in revitalizing copyleft-next is to bring my lessons learned
from 27 years of GPLv2/LGPLv2.1 enforcement experience (and 18 years of
A?GPLv3 enforcement [0] experience) to decrease copyleft-next's “specious
argument vector” for enterprising, malicious lawyers who want to “get their
client off” with ludicrous arguments that delay release of CCS.

Just one example from my real world GPLv2 enforcement work to give you a
flavor:

I have *literally* had multiple malicious lawyers tell me that since
GPLv2§3(b) doesn't specify *how long* the distributor has to deliver source
code once the written offer is exercised that their client can take an
indefinite period of time to deliver the CCS without penalty.  This is real
world stuff: one Fortune 500 company that you've all heard of is *right now*
holding back source for dozens of products containing GPLv2/LGPLv2.1 code
relying on this argument plus a “if you don't like it, sue us” attitude.

It's obvious that GPLv2§3(b) is written for readability — assuming that the
redistributor *wants* to follow the obvious reading, and since GPLv2§3(a) is
*right there* above it, well, how could anyone possible think/argue that
GPLv2§3(b) doesn't mean “deliver CCS right quick”!  Yet, shameless lawyers
tell me that “six months to get source is totally reasonable” all the time.🙄

Now, James could be right that in this case — perhaps using 2-3 plain-text
words (instead of TLAs and the like) for defined terms will increase
readability and not increase the “specious argument vector”.

But, we must consider carefully with each readability increase whether it
increases “specious argument vector” such that a future individual consumer —
who is not versed in legalese — doesn't get source code because they're
tricked by fancy, malicious legalistic arguments.

 * * *

Meanwhile, it seems that replacing TLAs with jargon terms *from other
licenses* may in fact be a path to increase “specious argument vector”.

For example, “Corresponding Source” is basically a GPLv3-centric jargon term.
It's actually going to be confusing in its own way, because the definition of
“CCS” in copyleft-next will certainly vary from the definition in GPLv3.
Again, I can *totally* imagine some enterprising malicious lawyer saying that
his client thought the definition was the GPLv3 one, not the copyleft-next
one.  Sure, that's a ludicrous argument and any non-corrupt judge would laugh
them out of the courtroom — but it may take serious resources (and many
years) to get to the point where the judge decides.  What about the poor
tinkerer who gets that email and has no resources to sue and sits for years
waiting for CCS?

IOW, for years we felt the key drafting goal was make the text of the license
accessible so that programmers would adopt the license, and let in only an
absolute minimum amount of legalese.  “Programmers must understand” was
essential.  Yet, Apache-2.0 (in addition to having an inappropriate name) is
filled with legalese so complicated that I've seen lawyers argue for hours
about how many patent licenses dance on the head of its pin.

Then, there's the argument about how GPLv3 was was too complex, too
lawyeristic and that programmers didn't like it.  First, many programmers did
like it, but to the extent that fewer programmers liked GPLv3, it was because
they didn't like its *policy* choices.

Anyway, this is a serious problem, touches every piece of copyleft drafting
these days, and as I said, I'll write more about this problem and how
copyleft-next can help solve it as time goes on.  But I hope we can
incorporate the “minimize specious argument vector” into a key strategy in
drafting.


[0] It probably won't surprise you all to learn that I have never actually
    seen a violation of LGPLv3  in the wild.
--
     -- bkuhn, noting: IANAL & TINLA


From bkuhn at ebb.org  Fri Jul 11 01:09:07 2025
From: bkuhn at ebb.org (Bradley M. Kuhn)
Date: Thu, 10 Jul 2025 18:09:07 -0700
Subject: Code of Conduct: we need one =?utf-8?Q?=28?= =?utf-8?B?4oCm?= in
 parallel / in addition to HBR)
Message-ID: <aHBkMyN+D4PiowjL@ebb.org>

HBR is, ultimately, not a Code of Conduct — it's a useful addendum to a Code
of Conduct.

We need a Code of Conduct (CoC) for the project.  As we start to open up
contributions via so many methods (fediverse, forgejo instance, mailing list)
— inevitably we'll get some folks showing up who are completely new to FOSS
contribution and we'll need the formalization of a CoC to deal with it.  We
don't want it to happen but we're fooling ourselves if we think it never
will.  (Have you seen the Internet lately? 😩)

It's my firmly held belief that a CoC does make tricky and tense community
moments easier because you have a formal process to deal with the situation.

That said, one frustration I have is that CoC's are like technical standards
— they're great because there are so many to chose from.

I'm curious if folks have a particular CoC template that they particularly
like and think would be good for copyleft-next?

I did some poking around and discussion with colleagues well-versed in this
area, and frankly there is no clear standard, and I don't think (other than
the HBR addendum) that we should write our own from scratch.

I'll spend time this weekend reading over CoC recommended templates to see if
one looks a particular good fit, but curious if anyone else has already done
that work.
--
     -- bkuhn, noting: IANAL & TINLA


From me at aethrvmn.gr  Fri Jul 11 07:49:35 2025
From: me at aethrvmn.gr (Vasileios Valatsos)
Date: Fri, 11 Jul 2025 09:49:35 +0200
Subject: Should there be a clause for AI?
Message-ID: <0d5e37b8-9e53-4845-a2ee-c42c231e24d7@aethrvmn.gr>

I apologize in advance for opening what is, in my regard, a giant can of 
worms.

Normally, when you use any software under a copyleft license, you must 
disclose any modifications, and release them under said license. However 
recently, with the training of language models and other generative 
methods, there is a laundering effect, where the end user is "handed" 
copyleft licensed code generated by the generative model, which 
effectively bypasses the copyleft clause. To my understanding (I am not 
a USA citizen) this is because, in the USA, the products of non-humans 
are not copyrightable (or copyleftable). At the same time, the capacity 
of machine learning models to output copyleft code *verbatim* is very 
uncomfortable; a picture taken by a monkey isn't copyrightable, or 
attributable to me, but when I purposefully train monkeys to take 
pictures of people, there must be some liability.

Adding a clause to the effect of "copyleft must be preserved even after 
being generated by non-human methods" is obviously unreasonable, one 
can't expect that the end user of a generative model will look up the 
license for each line generated, especially since the recent focus is on 
generating entire app suites or frameworks in an "agentic" fashion (aka 
you create a framework were models attempt to coordinate with themselves 
as to better solve the given task), better known as "vibe coding".

At the same time, the argument from the developers of machine learning 
methods capable of outputting verbatim copyleft licensed code is that 
the model itself isn't a derivative of the code, but rather that the 
code has been embedded into the "semantic understanding" of the model 
(as in, it *has* affected the model parameters, but the model itself 
would exist without it), and therefore the model itself doesn't fall 
under copyleft. In other words, the fact that the copyleft code was 
included in the database rather than the codebase means that there is 
nothing for the copyleft to apply to.

To this extent, I myself personally use a second license, specifically 
for using projects as training data:

---
Training Public License (TPL) v1.0

Copyright © 2025

This code and content is licensed under the GPLv3 or later, with the 
following special condition:

If you use any part of this code, notes, or data for training, 
fine-tuning, or evaluating a machine learning system (including but not 
limited to neural networks, large language models, or any algorithm 
where this content influences the resulting system), you must release 
all resulting models, weights, and related code under the GPLv3 or later.

All other uses are governed by the regular terms of the GPLv3 or later.
---

I wonder if (a) this would make sense in copyleft-next, (b) if it even 
belongs in the conversation, (c) if there is a better way to tackle this.

It does feel like it is a nuclear option, despite adhering perfectly to 
the spirit of copyleft. I guess you can say that copyleft itself is a 
nuclear option.



From bcotton at funnelfiasco.com  Fri Jul 11 14:19:29 2025
From: bcotton at funnelfiasco.com (Ben Cotton)
Date: Fri, 11 Jul 2025 10:19:29 -0400
Subject: =?UTF-8?Q?Re=3A_Code_of_Conduct=3A_we_need_one_=28=E2=80=A6_in_parallel_=2F_?=
 =?UTF-8?Q?in_addition_to_HBR=29?=
In-Reply-To: <aHBkMyN+D4PiowjL@ebb.org>
References: <aHBkMyN+D4PiowjL@ebb.org>
Message-ID: <CAJox1157Q722B60e58=pUiLgnQfZMOzu9F-0sAeeCO9DzMYbcA@mail.gmail.com>

On Thu, Jul 10, 2025 at 9:09 PM Bradley M. Kuhn <bkuhn at ebb.org> wrote:
>
> I'm curious if folks have a particular CoC template that they particularly
> like and think would be good for copyleft-next?
>
> I did some poking around and discussion with colleagues well-versed in this
> area, and frankly there is no clear standard, and I don't think (other than
> the HBR addendum) that we should write our own from scratch.

I'm generally in favor of the Contributor Covenant
(https://www.contributor-covenant.org/), although it's been long
enough since I had to think about it that I don't remember any
particular details of what I liked or disliked about it. Fedora's
"new" (it's been several years now) code of conduct is largely based
on it, with some modifications, and it has served well.

-- 
Ben Cotton (he/him)
TZ=America/Indiana/Indianapolis


From bcotton at funnelfiasco.com  Fri Jul 11 14:31:51 2025
From: bcotton at funnelfiasco.com (Ben Cotton)
Date: Fri, 11 Jul 2025 10:31:51 -0400
Subject: Should there be a clause for AI?
In-Reply-To: <0d5e37b8-9e53-4845-a2ee-c42c231e24d7@aethrvmn.gr>
References: <0d5e37b8-9e53-4845-a2ee-c42c231e24d7@aethrvmn.gr>
Message-ID: <CAJox116GJQtWTUCZVq94=oo-ajVwAKyZgUHy=heukMQnrnJZLA@mail.gmail.com>

On Fri, Jul 11, 2025 at 4:01 AM Vasileios Valatsos <me at aethrvmn.gr> wrote:
>
> I apologize in advance for opening what is, in my regard, a giant can of
> worms.

It's a conversation that we can't avoid. Credit to you for standing up. :-)

> I wonder if (a) this would make sense in copyleft-next, (b) if it even
> belongs in the conversation, (c) if there is a better way to tackle this.

Would this be field of use discrimination? I think it would, and would
therefore violate FSF Freedom 0 and OSD criteria 6. That would render
copyleft-next neither Open Source nor Free in the capital-letter sense
of the terms.

More theoretically, I'm a big fan of "don't make rules you can't/won't
enforce." If you release something under the TPL and I decide to use
it to train an AI model, how will you know? bkuhn will correct me if
I'm wrong, but that would seem to be one challenge in GPL enforcement
in the traditional software arena. At least with traditional software,
there's typically some external evidence that a project was used in
violation of its license. I'm not sure there's a good way to detect it
in an LLM unless I make my training data public (which I would not if
I were intending to violate the license).

I'm not suggesting we stick our heads in the sand, but large language
models are a complex problem from a variety of legal (I say as
not-a-lawyer), ethical, practical, etc standpoints. I don't see a
clear way forward to addressing them in a license like copyleft-next
at this point.

--
Ben Cotton (he/him)
TZ=America/Indiana/Indianapolis


From xcoadic at protonmail.com  Fri Jul 11 14:41:06 2025
From: xcoadic at protonmail.com (Xavier Coadic)
Date: Fri, 11 Jul 2025 14:41:06 +0000
Subject: =?utf-8?Q?Re:_Code_of_Conduct:_we_need_one_(=E2=80=A6_in_parallel_/_in_addition_to_HBR)?=
In-Reply-To: <CAJox1157Q722B60e58=pUiLgnQfZMOzu9F-0sAeeCO9DzMYbcA@mail.gmail.com>
References: <aHBkMyN+D4PiowjL@ebb.org>
 <CAJox1157Q722B60e58=pUiLgnQfZMOzu9F-0sAeeCO9DzMYbcA@mail.gmail.com>
Message-ID: <sGPThNigbP1vnSgQYaZZzE7eHL4QfUetH_Cbu8agKjwZMnispAT7jNp7plPRkMnK-UHN-79tpgZNSQHR5wZrMpIvLc_wCI4ONBzzbJl39zM=@protonmail.com>

FunkWhale did a particular adaptation of this CoC / Contributor Covenant that I find very inspiring
https://www.funkwhale.audio/code-of-conduct/




Xavier Coadic





**[https://xavcc.frama.io ][https_xavcc.frama.io]**






\-------- Message d'origine --------
Le 11 juil. 2025 à 16:19, Ben Cotton < bcotton at funnelfiasco.com> a écrit :
On Thu, Jul 10, 2025 at 9:09 PM Bradley M. Kuhn wrote: > > I'm curious if folks have a particular CoC template that they particularly > like and think would be good for copyleft-next? > > I did some poking around and discussion with colleagues well-versed in this > area, and frankly there is no clear standard, and I don't think (other than > the HBR addendum) that we should write our own from scratch. I'm generally in favor of the Contributor Covenant ([https://www.contributor-covenant.org/),][https_www.contributor-covenant.org] although it's been long enough since I had to think about it that I don't remember any particular details of what I liked or disliked about it. Fedora's "new" (it's been several years now) code of conduct is largely based on it, with some modifications, and it has served well. -- Ben Cotton (he/him) TZ=America/Indiana/Indianapolis \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ next mailing list next at lists.copyleft.org https://lists.copyleft.org/mailman/listinfo/next



[https_xavcc.frama.io]: https://xavcc.frama.io/
[https_www.contributor-covenant.org]: https://www.contributor-covenant.org/%29,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.copyleft.org/pipermail/next/attachments/20250711/07ed2a95/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - EmailAddress(s=xcoadic at protonmail.com) - 0x4E310051.asc
Type: application/pgp-keys
Size: 652 bytes
Desc: not available
URL: <http://lists.copyleft.org/pipermail/next/attachments/20250711/07ed2a95/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.copyleft.org/pipermail/next/attachments/20250711/07ed2a95/attachment.sig>

From wolftune at riseup.net  Fri Jul 11 15:43:51 2025
From: wolftune at riseup.net (Aaron Wolf)
Date: Fri, 11 Jul 2025 08:43:51 -0700
Subject: =?UTF-8?Q?Re=3A_Code_of_Conduct=3A_we_need_one_=28=E2=80=A6_in_para?=
 =?UTF-8?Q?llel_/_in_addition_to_HBR=29?=
In-Reply-To: <sGPThNigbP1vnSgQYaZZzE7eHL4QfUetH_Cbu8agKjwZMnispAT7jNp7plPRkMnK-UHN-79tpgZNSQHR5wZrMpIvLc_wCI4ONBzzbJl39zM=@protonmail.com>
References: <aHBkMyN+D4PiowjL@ebb.org>
 <CAJox1157Q722B60e58=pUiLgnQfZMOzu9F-0sAeeCO9DzMYbcA@mail.gmail.com>
 <sGPThNigbP1vnSgQYaZZzE7eHL4QfUetH_Cbu8agKjwZMnispAT7jNp7plPRkMnK-UHN-79tpgZNSQHR5wZrMpIvLc_wCI4ONBzzbJl39zM=@protonmail.com>
Message-ID: <52c54749-b54f-4dc8-a07a-e47b545f5081@riseup.net>

I have many opinions about the topic of CoC but don't feel up for 
getting into depth here.

I like much of what I see from that Funkwhale adaptation. My general 
concern for CoC in practice is that there's usually not enough 
combination of methods for cutting off immediate harm ASAP while also 
having restorative process focused on learning and growth. Most of the 
time, subtle harms are allowed to continue for too long and then after 
they get worse, punitive and threatening actions are taken that cause 
people to get defensive and everything leads to limits and bans. So, 
there is neither a truly high-standard of healthy interactions being 
maintained nor an effective learning and restoration process.

I've given talks about this in the past, and I like this article:
https://authenticengine.com/2016/adopting-a-code-of-conduct-is-an-adaptive-challenge-not-a-technical-one/

And FWIW, I'm a co-author of both
https://wiki.snowdrift.coop/community/conduct
and https://wiki.social.coop/wiki/Code_of_conduct

neither of which I feel is ideal but which bring up some other 
approaches that some CoC are missing

I'm working on a much longer-term project that will eventually offer a 
different class of CoC and practices altogether but it's not yet usable 
enough to discuss practically here.

I would just urge the core ideas that:

- tensions should be addressed sooner rather than later
- tensions should be processed *privately* while following some fair 
predetermined method
- the goal should be to get everyone back to good standing and continual 
learning and improvement *without* letting conduct issues be noise that 
disrupts or distresses the community or turns anyone off

Some of this is technical, like it's unfortunately not possible with 
email for me to make a mistake that upsets someone, see it, edit and fix 
it. There's no editing with email. But I'll say personally: if I ever 
say something that upsets anyone in any way, I would like to know about 
it ASAP, discuss privately (with that person or someone else who is 
facilitating), and figure out the best way to fix/resolve things. I do 
NOT want minor issues to be ignored nor to make lots of public noise. 
Clear up any tensions while they are still subtle.

I wish I could suggest a simple pop-in solution but it's not that easy 
because of the interacting problems with mediocre social-norms and 
mediocre communication moderation tools.

All for now,
Aaron

On 7/11/25 7:41, Xavier Coadic wrote:
> FunkWhale did a particular adaptation of this CoC / Contributor 
> Covenant that I find very inspiring
> https://www.funkwhale.audio/code-of-conduct/
>
>
> Xavier Coadic
>
> *https://xavcc.frama.io *
>
>
> -------- Message d'origine --------
> Le 11 juil. 2025 à 16:19, Ben Cotton < bcotton at funnelfiasco.com> a écrit :
> On Thu, Jul 10, 2025 at 9:09 PM Bradley M. Kuhn wrote: > > I'm curious 
> if folks have a particular CoC template that they particularly > like 
> and think would be good for copyleft-next? > > I did some poking 
> around and discussion with colleagues well-versed in this > area, and 
> frankly there is no clear standard, and I don't think (other than > 
> the HBR addendum) that we should write our own from scratch. I'm 
> generally in favor of the Contributor Covenant 
> (https://www.contributor-covenant.org/), although it's been long 
> enough since I had to think about it that I don't remember any 
> particular details of what I liked or disliked about it. Fedora's 
> "new" (it's been several years now) code of conduct is largely based 
> on it, with some modifications, and it has served well. -- Ben Cotton 
> (he/him) TZ=America/Indiana/Indianapolis 
> _______________________________________________ next mailing list 
> next at lists.copyleft.org https://lists.copyleft.org/mailman/listinfo/next
>
> _______________________________________________
> next mailing list
> next at lists.copyleft.org
> https://lists.copyleft.org/mailman/listinfo/next
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.copyleft.org/pipermail/next/attachments/20250711/ee016d58/attachment.html>

From zefr0x at tuta.io  Fri Jul 11 15:48:20 2025
From: zefr0x at tuta.io (zefr0x at tuta.io)
Date: Fri, 11 Jul 2025 17:48:20 +0200 (CEST)
Subject: My view of copyleft and thoughts about copyleft-next
Message-ID: <OUu2Eey--F-9@tuta.io>

I'm a software developer who embraced the FLOSS and copyleft philosophies since my beginnings, every software project that I started is licensed under either GPLv3 or AGPLv3 except for two libraries licensed under LGPLv3. I'm not a lawyer, but I have some experience in writing very simple policies and guidelines for my projects. However, something might be missing or unintentionally against my intent (will be always open to productive discussions).

I'm writing this to provide my vision of what should be the optimal goal of a copyleft license. Also, I have some thoughts and ideas of things that are in copyleft-next that I think should be discussed for modification, along with things that are not and should be discussed for addition.

This should help to develop an intent for this license, as I believe that copyleft-next should not be just a license, but a vision, mission, and goal. As of this, to clarify any thing that I will say, I will start by writing -as possible- about my personal intent.

---

My optimal world of copyleft for software, hardware, and knowledge of creative works in general is that all knowledge belongs to the whole humanity (and any other type of creatures), so no one has the right to restrict any type of knowledge for themself or for a group of people. This doesn't mean that you can't put your name such as the author, designer, inventor, or discoverer. You have the absolute right to be credited in the history. It just means that you don't own the knowledge for yourself. Everyone has the right to do anything with it including (but not limited to) copy, distribute, study, change and improve, but they don't have the right to own the knowledge or restrict it for themself.

There is no exception for any type of knowledge from this rule. However, we must define the barrier between knowledge and applications of knowledge. So, for example software is considered a type of knowledge, while hardware is an application of knowledge. For software, you are required to open the source-code, history of development, design, documentation, user manual, and etc. But for hardware you are required to open the design, design history, list of materials, manufacturing process, user manual, and etc. The word "knowledge" is very general and this is intended.

This might be off-topic, but this rule is applicable for digital media, books, research papers, digital art, and anything as long as it begin a knowledge. Some people might oppose this with the argument that it stimulate creativity, but I believe that creativity has two pillars: resources (off-topic) and knowledge (on-topic). For projects aimed to provide an application of knowledge there is not a problem, since they can be backed with resources from anyone interested in the application. But for projects aimed to provide knowledge by itself the passion of its developers will be the main driver, and I believe this was always the case with or without copyright. The problem is about finding a sustainable framework to provide resources for creative projects aimed for knowledge, and passionate creative development will always solve this problem. Additionally, the copyleft will ensure that who build applications of knowledge is the best one with the best resources, not the one who restricts the knowledge.

So the knowledge will be open, and the competitiveness will be mainly derived by resources and building a framework to obtain it. They might be mainly driven with passionate human resources, or anything else. I don't know what the optimal framework for any project, maybe it is by having both copyleft and copyright projects igniting each other? or is it both knowledge driven and application driven projects igniting each other? You can have resources with multiple methods, but the knowledge is one.

I see copyleft licenses as a method or abstraction to run this optimal world on top of the copyright and intellectual property systems adopted in the current world. So what I want to see is that by using the copyleft-next license for your project or contributing to copyleft-next licensed projects you are committing to those ideas of an optimal copyleft world no matter what is written in the license, since it is just an abstraction to fit into the current legal system. So I would like to see copyleft-next as the new license with the exact previous intention of having this optimal world of open knowledge in the current legal system.

---

Now lets go throw the latest draft of copyleft-next:

"""
9. Copyleft Sunset
The conditions in sections 4 through 8 no longer apply once fifteen
years have elapsed from the date of My first distribution of My Work
under this License.
"""

This is currently being discussed in another thread, and I believe that it oppose my vision of copyleft, since it make a restriction earlier than the copyright legal system and not just fitting into it.

"""
11. Later License Versions
The Copyleft-Next Project may release new versions of copyleft-next,
designated by a distinguishing version number ("Later Versions").
Unless I explicitly remove the option of distributing Covered Works
under Later Versions, You may distribute Covered Code under any Later
Version.
"""

There must be restrictions on "Later Versions". Can they go away from the copyleft concept? or are they required to just make copyleft stronger? Can they left any restrictions from previous version?
The license can change, but there must be an explicitly defined vision of the Copyleft-Next Project that will never change to maintain trust.

"""
15. Definitions
"Source Code" means the preferred form of a work for making
modifications to it.

[...]

CCS means: (i) the Source Code form of the Covered Work; (ii) all
scripts, instructions, know-how, and similar information that are
reasonably necessary for a skilled developer to generate such Object
Code from the Source Code provided under (i); and (iii) a list clearly
identifying all Separate Works (other than those provided in
compliance with (ii)) that were specifically used in building and (if
applicable) installing the Covered Work (for example, a specified
proprietary compiler including its version number). OCS must be
machine-readable and, to the extent that its licensing is not governed
by section 2 of this License, must be available under terms satisfying
the Free Software Foundation's Free Software Definition
(https://www.gnu.org/philosophy/free-sw.en.html, version 1.135).

NSS means: (i) the Source Code form of the Covered Work; (ii) all
scripts, instructions, know-how, and similar information that are
reasonably necessary to use the Covered Work to substantially
replicate the Network Service, and (iii) a list clearly identifying
all Separate Works that are specifically used in or required for
providing the Network Service (for example, a specified web server
including its version number).
"""

Since I have the freedom to modify Source Code, and not just to generate Object Code or replicate a Network Service, I expect to have reasonable knowledge to modify it. This is by having development scripts, architecture/design documentation, development history, and a list of development tools. Without this type of knowledge included, even a skilled developer will need a huge work of reverse engineering of the design and the way that the project was developed to work on it properly. Additionally, I would expect documentation and specification of the language used to write the Source Code, even if the compiler was proprietary. This will covers the freedom to study the Source Code and maybe to create a compiler by yourself.

Also, with the freedom to run the software, there must be a list of runtime dependencies and know-how. It's not necessary to have documentation of how to do every specific thing using the software, but I will need to know where and how can I run it and if I need a special hardware to do so etc.

As for the lists of Separate Works, other than the name and the version, I would expect a URL where I can have access or a communication channel to request access.

---

Now I will write about things that I think should be included in the copyleft-next:

1. Learning and Reuse of Knowledge

There will be no problem if everything was just copyleft, but this is not the case. So to what extent can I learn from copyleft project and then use my knowledge to build a copyright one or another with a permissive license?

In my view, Source Code is not just code, but it's knowledge including algorithms, hacks, methods, design, and etc. So when you use this knowledge in your project to an extent out of Fair Use (not necessarily just coping portions of code), your work is a derivative. With the same concept, when learning from an API or a GUI to create a clone of my work with reverse engineering, your code is not derivative, but the overall interface and the design of the overall software is derivative and you must release it (the design or the interface) with copyleft license, proper credits, and notice. This should prevent things like creating an MIT licensed clean room Rust rewrite of a copyleft project and having any derivative design decision licensed under the MIT.

>From the same view, when dealing with LLMs (AI), it is just about learning and reuse. Yes, it is faster, but this is not an argument to treat it differently from humans' learning. It might be weird and humans often fear or oppose new things that they don't understand, but I will not blindly just ban AI training, since this will be loudly against the core concept of copyleft. So what I see as the best solution is to just consider the portions of AI models that learned from copyleft knowledge as derivative works (probably can't be enforced when mixing data with different licenses in one model, so we might restrict that?), and -to an extent- content generated with these models are also derivative works whether it was code, design, hacks, algorithms, methods, or etc when they are creative work. However, if this can't be enforced in the current legal system, I will go with just opening the knowledge without any restriction. Knowledge by default must be open when we can't legally enforce copyleft, otherwise we will just be hurting people who are building open LLMs (bad people will do it anyway). 

Just to clarify that, I'm not against training AI with anything just like humans do learn (knowledge should be open), but it is not a copyleft only world and most companies will try as they can to get as much data and then just restrict it. In my opinion the bad thing is not that they are training AI on my data, but it is about not releasing the models for the public. Additionally, private personal information should be anonymized, since even for humans it is not ethical to access these.

2. About Jurisdictions

I noticed that things might not be included in this license since it might be a common sense or not enforceable in USA or EU court. I believe that we should focus on making the copyleft-next as global as possible and as applicable as possible even in jurisdictions with few experiences in copyright cases or with different copyright concepts.

For example, to my knowledge I don't think that there is a clear definition of "derivative work" in the current draft.

However, I don't know how much work has been done here, since I'm not an expert of any legal system.

---

Summery and What is Expected:

- All knowledge belongs to the whole humanity, so no one has the right to restrict any type of knowledge.

-The Copyleft-Next Project should have a vision, mission, and goal to act as a definition of an optimal world of copyleft and how to achieve it. This will also help to trust the Later License Versions clause.

- The Copyleft Sunset clause is against the optimal world of copyleft.

- Definitions of CCS and NSS should be extended to include knowledge that are necessities or facilitation of the other freedoms, not just to provide the code and the knowledge to build it, but also the ability to run, modify, and study it.

- CCS is not just bare code, but a knowledge, and any knowledge of creative work done using it should also be under the same copyleft license.

- When learning and reusing to an extent, the produced content should be considered as derivative, not just by copying code, but also by creating a separate software with separate code but with a derivative design, algorithms, hacks, or etc. The code by itself will be Separate Work, but the design and any other knowledge of creative work will be derivative and under copyleft.

- The previous point includes AI training, so the model and anything it produces to be derivative and under copyleft.

- Make copyleft-next as applicable as possible in jurisdictions with different copyright systems.


P.S. Sorry for writing a lot in a single email. I think separate topics can be discussed in sub-threads :)

zefr0x


From wolftune at riseup.net  Fri Jul 11 16:02:35 2025
From: wolftune at riseup.net (Aaron Wolf)
Date: Fri, 11 Jul 2025 09:02:35 -0700
Subject: Should there be a clause for AI?
In-Reply-To: <CAJox116GJQtWTUCZVq94=oo-ajVwAKyZgUHy=heukMQnrnJZLA@mail.gmail.com>
References: <0d5e37b8-9e53-4845-a2ee-c42c231e24d7@aethrvmn.gr>
 <CAJox116GJQtWTUCZVq94=oo-ajVwAKyZgUHy=heukMQnrnJZLA@mail.gmail.com>
Message-ID: <4ca6cff5-b602-4210-b7b4-52c9f4b3a279@riseup.net>

I like the idea of addressing AI issues within copyleft-next. AI is the 
most important dilemma we all face here.

That "Training Public License" seems to have a potential flaw by my 
first read. It says " you must release all resulting models, weights, 
and related code under the GPLv3 or later" but what does "release" mean? 
There's no Affero-type clause, so keeping the AI running on private 
servers even if giving others access might not count. And without 
anything specific about "release", it doesn't say to whom. It doesn't 
say that it must be published and accessible to anyone in the general 
public. On the opposite end, "release" mandates could suggest that every 
single iteration of the AI must be published, which is infeasible.

In order to deal with the issue of copyleft code used in AI training, I 
imagine a need for more clarity, as in how GPLv3 family describes 
"convey" but furthermore also clarifying when what is conveyed to whom.

I will share a related perspective on the big-picture in that other new 
thread on copyleft overall

Cheers,

Aaron

On 7/11/25 7:31, Ben Cotton wrote:
> On Fri, Jul 11, 2025 at 4:01 AM Vasileios Valatsos<me at aethrvmn.gr> wrote:
>> I apologize in advance for opening what is, in my regard, a giant can of
>> worms.
> It's a conversation that we can't avoid. Credit to you for standing up. :-)
>
>> I wonder if (a) this would make sense in copyleft-next, (b) if it even
>> belongs in the conversation, (c) if there is a better way to tackle this.
> Would this be field of use discrimination? I think it would, and would
> therefore violate FSF Freedom 0 and OSD criteria 6. That would render
> copyleft-next neither Open Source nor Free in the capital-letter sense
> of the terms.
>
> More theoretically, I'm a big fan of "don't make rules you can't/won't
> enforce." If you release something under the TPL and I decide to use
> it to train an AI model, how will you know? bkuhn will correct me if
> I'm wrong, but that would seem to be one challenge in GPL enforcement
> in the traditional software arena. At least with traditional software,
> there's typically some external evidence that a project was used in
> violation of its license. I'm not sure there's a good way to detect it
> in an LLM unless I make my training data public (which I would not if
> I were intending to violate the license).
>
> I'm not suggesting we stick our heads in the sand, but large language
> models are a complex problem from a variety of legal (I say as
> not-a-lawyer), ethical, practical, etc standpoints. I don't see a
> clear way forward to addressing them in a license like copyleft-next
> at this point.
>
> --
> Ben Cotton (he/him)
> TZ=America/Indiana/Indianapolis
> _______________________________________________
> next mailing list
> next at lists.copyleft.org
> https://lists.copyleft.org/mailman/listinfo/next
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.copyleft.org/pipermail/next/attachments/20250711/843b78e8/attachment.html>

From wolftune at riseup.net  Fri Jul 11 16:07:38 2025
From: wolftune at riseup.net (Aaron Wolf)
Date: Fri, 11 Jul 2025 09:07:38 -0700
Subject: My view of copyleft and thoughts about copyleft-next
In-Reply-To: <OUu2Eey--F-9@tuta.io>
References: <OUu2Eey--F-9@tuta.io>
Message-ID: <e3f11488-5584-4c9c-ad86-c60636aad1c8@riseup.net>

Wrote this thinking about the AI issue in the other thread, but tagging 
on here as it is broader:

In my view, the overall issue of software-freedom and copyleft can be 
summarized as: No entity reserves practical or legal exclusive power.

Real software freedom means that while I might be less capable of 
updating a program compared to an experienced coder who already knows 
the software, they have provided me everything feasible that they have 
access to in doing such updating. There's no code or tools or legal 
rights that they have that I don't. And I think this is the framing we 
need to bring to copyleft-next in general and to AI specifically. What 
does it look like to say that an AI development company has no technical 
or legal exclusive ability to do something, either using the AI or 
developing it, that you and I may not have? Copyleft means whatever 
licensing terms say that this sort of non-exclusivity must be maintained 
as the status.

Aaron

On 7/11/25 8:48, zefr0x at tuta.io wrote:
> I'm a software developer who embraced the FLOSS and copyleft philosophies since my beginnings, every software project that I started is licensed under either GPLv3 or AGPLv3 except for two libraries licensed under LGPLv3. I'm not a lawyer, but I have some experience in writing very simple policies and guidelines for my projects. However, something might be missing or unintentionally against my intent (will be always open to productive discussions).
>
> I'm writing this to provide my vision of what should be the optimal goal of a copyleft license. Also, I have some thoughts and ideas of things that are in copyleft-next that I think should be discussed for modification, along with things that are not and should be discussed for addition.
>
> This should help to develop an intent for this license, as I believe that copyleft-next should not be just a license, but a vision, mission, and goal. As of this, to clarify any thing that I will say, I will start by writing -as possible- about my personal intent.
>
> ---
>
> My optimal world of copyleft for software, hardware, and knowledge of creative works in general is that all knowledge belongs to the whole humanity (and any other type of creatures), so no one has the right to restrict any type of knowledge for themself or for a group of people. This doesn't mean that you can't put your name such as the author, designer, inventor, or discoverer. You have the absolute right to be credited in the history. It just means that you don't own the knowledge for yourself. Everyone has the right to do anything with it including (but not limited to) copy, distribute, study, change and improve, but they don't have the right to own the knowledge or restrict it for themself.
>
> There is no exception for any type of knowledge from this rule. However, we must define the barrier between knowledge and applications of knowledge. So, for example software is considered a type of knowledge, while hardware is an application of knowledge. For software, you are required to open the source-code, history of development, design, documentation, user manual, and etc. But for hardware you are required to open the design, design history, list of materials, manufacturing process, user manual, and etc. The word "knowledge" is very general and this is intended.
>
> This might be off-topic, but this rule is applicable for digital media, books, research papers, digital art, and anything as long as it begin a knowledge. Some people might oppose this with the argument that it stimulate creativity, but I believe that creativity has two pillars: resources (off-topic) and knowledge (on-topic). For projects aimed to provide an application of knowledge there is not a problem, since they can be backed with resources from anyone interested in the application. But for projects aimed to provide knowledge by itself the passion of its developers will be the main driver, and I believe this was always the case with or without copyright. The problem is about finding a sustainable framework to provide resources for creative projects aimed for knowledge, and passionate creative development will always solve this problem. Additionally, the copyleft will ensure that who build applications of knowledge is the best one with the best resources, not the one who restricts the knowledge.
>
> So the knowledge will be open, and the competitiveness will be mainly derived by resources and building a framework to obtain it. They might be mainly driven with passionate human resources, or anything else. I don't know what the optimal framework for any project, maybe it is by having both copyleft and copyright projects igniting each other? or is it both knowledge driven and application driven projects igniting each other? You can have resources with multiple methods, but the knowledge is one.
>
> I see copyleft licenses as a method or abstraction to run this optimal world on top of the copyright and intellectual property systems adopted in the current world. So what I want to see is that by using the copyleft-next license for your project or contributing to copyleft-next licensed projects you are committing to those ideas of an optimal copyleft world no matter what is written in the license, since it is just an abstraction to fit into the current legal system. So I would like to see copyleft-next as the new license with the exact previous intention of having this optimal world of open knowledge in the current legal system.
>
> ---
>
> Now lets go throw the latest draft of copyleft-next:
>
> """
> 9. Copyleft Sunset
> The conditions in sections 4 through 8 no longer apply once fifteen
> years have elapsed from the date of My first distribution of My Work
> under this License.
> """
>
> This is currently being discussed in another thread, and I believe that it oppose my vision of copyleft, since it make a restriction earlier than the copyright legal system and not just fitting into it.
>
> """
> 11. Later License Versions
> The Copyleft-Next Project may release new versions of copyleft-next,
> designated by a distinguishing version number ("Later Versions").
> Unless I explicitly remove the option of distributing Covered Works
> under Later Versions, You may distribute Covered Code under any Later
> Version.
> """
>
> There must be restrictions on "Later Versions". Can they go away from the copyleft concept? or are they required to just make copyleft stronger? Can they left any restrictions from previous version?
> The license can change, but there must be an explicitly defined vision of the Copyleft-Next Project that will never change to maintain trust.
>
> """
> 15. Definitions
> "Source Code" means the preferred form of a work for making
> modifications to it.
>
> [...]
>
> CCS means: (i) the Source Code form of the Covered Work; (ii) all
> scripts, instructions, know-how, and similar information that are
> reasonably necessary for a skilled developer to generate such Object
> Code from the Source Code provided under (i); and (iii) a list clearly
> identifying all Separate Works (other than those provided in
> compliance with (ii)) that were specifically used in building and (if
> applicable) installing the Covered Work (for example, a specified
> proprietary compiler including its version number). OCS must be
> machine-readable and, to the extent that its licensing is not governed
> by section 2 of this License, must be available under terms satisfying
> the Free Software Foundation's Free Software Definition
> (https://www.gnu.org/philosophy/free-sw.en.html, version 1.135).
>
> NSS means: (i) the Source Code form of the Covered Work; (ii) all
> scripts, instructions, know-how, and similar information that are
> reasonably necessary to use the Covered Work to substantially
> replicate the Network Service, and (iii) a list clearly identifying
> all Separate Works that are specifically used in or required for
> providing the Network Service (for example, a specified web server
> including its version number).
> """
>
> Since I have the freedom to modify Source Code, and not just to generate Object Code or replicate a Network Service, I expect to have reasonable knowledge to modify it. This is by having development scripts, architecture/design documentation, development history, and a list of development tools. Without this type of knowledge included, even a skilled developer will need a huge work of reverse engineering of the design and the way that the project was developed to work on it properly. Additionally, I would expect documentation and specification of the language used to write the Source Code, even if the compiler was proprietary. This will covers the freedom to study the Source Code and maybe to create a compiler by yourself.
>
> Also, with the freedom to run the software, there must be a list of runtime dependencies and know-how. It's not necessary to have documentation of how to do every specific thing using the software, but I will need to know where and how can I run it and if I need a special hardware to do so etc.
>
> As for the lists of Separate Works, other than the name and the version, I would expect a URL where I can have access or a communication channel to request access.
>
> ---
>
> Now I will write about things that I think should be included in the copyleft-next:
>
> 1. Learning and Reuse of Knowledge
>
> There will be no problem if everything was just copyleft, but this is not the case. So to what extent can I learn from copyleft project and then use my knowledge to build a copyright one or another with a permissive license?
>
> In my view, Source Code is not just code, but it's knowledge including algorithms, hacks, methods, design, and etc. So when you use this knowledge in your project to an extent out of Fair Use (not necessarily just coping portions of code), your work is a derivative. With the same concept, when learning from an API or a GUI to create a clone of my work with reverse engineering, your code is not derivative, but the overall interface and the design of the overall software is derivative and you must release it (the design or the interface) with copyleft license, proper credits, and notice. This should prevent things like creating an MIT licensed clean room Rust rewrite of a copyleft project and having any derivative design decision licensed under the MIT.
>
>  From the same view, when dealing with LLMs (AI), it is just about learning and reuse. Yes, it is faster, but this is not an argument to treat it differently from humans' learning. It might be weird and humans often fear or oppose new things that they don't understand, but I will not blindly just ban AI training, since this will be loudly against the core concept of copyleft. So what I see as the best solution is to just consider the portions of AI models that learned from copyleft knowledge as derivative works (probably can't be enforced when mixing data with different licenses in one model, so we might restrict that?), and -to an extent- content generated with these models are also derivative works whether it was code, design, hacks, algorithms, methods, or etc when they are creative work. However, if this can't be enforced in the current legal system, I will go with just opening the knowledge without any restriction. Knowledge by default must be open when we can't legally enforce copyleft, otherwise we will just be hurting people who are building open LLMs (bad people will do it anyway).
>
> Just to clarify that, I'm not against training AI with anything just like humans do learn (knowledge should be open), but it is not a copyleft only world and most companies will try as they can to get as much data and then just restrict it. In my opinion the bad thing is not that they are training AI on my data, but it is about not releasing the models for the public. Additionally, private personal information should be anonymized, since even for humans it is not ethical to access these.
>
> 2. About Jurisdictions
>
> I noticed that things might not be included in this license since it might be a common sense or not enforceable in USA or EU court. I believe that we should focus on making the copyleft-next as global as possible and as applicable as possible even in jurisdictions with few experiences in copyright cases or with different copyright concepts.
>
> For example, to my knowledge I don't think that there is a clear definition of "derivative work" in the current draft.
>
> However, I don't know how much work has been done here, since I'm not an expert of any legal system.
>
> ---
>
> Summery and What is Expected:
>
> - All knowledge belongs to the whole humanity, so no one has the right to restrict any type of knowledge.
>
> -The Copyleft-Next Project should have a vision, mission, and goal to act as a definition of an optimal world of copyleft and how to achieve it. This will also help to trust the Later License Versions clause.
>
> - The Copyleft Sunset clause is against the optimal world of copyleft.
>
> - Definitions of CCS and NSS should be extended to include knowledge that are necessities or facilitation of the other freedoms, not just to provide the code and the knowledge to build it, but also the ability to run, modify, and study it.
>
> - CCS is not just bare code, but a knowledge, and any knowledge of creative work done using it should also be under the same copyleft license.
>
> - When learning and reusing to an extent, the produced content should be considered as derivative, not just by copying code, but also by creating a separate software with separate code but with a derivative design, algorithms, hacks, or etc. The code by itself will be Separate Work, but the design and any other knowledge of creative work will be derivative and under copyleft.
>
> - The previous point includes AI training, so the model and anything it produces to be derivative and under copyleft.
>
> - Make copyleft-next as applicable as possible in jurisdictions with different copyright systems.
>
>
> P.S. Sorry for writing a lot in a single email. I think separate topics can be discussed in sub-threads :)
>
> zefr0x
> _______________________________________________
> next mailing list
> next at lists.copyleft.org
> https://lists.copyleft.org/mailman/listinfo/next
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.copyleft.org/pipermail/next/attachments/20250711/a452e421/attachment.html>

From me at aethrvmn.gr  Fri Jul 11 16:31:23 2025
From: me at aethrvmn.gr (Vasileios Valatsos)
Date: Fri, 11 Jul 2025 18:31:23 +0200
Subject: Should there be a clause for AI?
In-Reply-To: <4ca6cff5-b602-4210-b7b4-52c9f4b3a279@riseup.net>
References: <0d5e37b8-9e53-4845-a2ee-c42c231e24d7@aethrvmn.gr>
 <CAJox116GJQtWTUCZVq94=oo-ajVwAKyZgUHy=heukMQnrnJZLA@mail.gmail.com>
 <4ca6cff5-b602-4210-b7b4-52c9f4b3a279@riseup.net>
Message-ID: <c5918f53-2cc8-4591-a275-c3f74c4c3fd6@aethrvmn.gr>

On 11/7/25 18:02, Aaron Wolf wrote:
 > That "Training Public License" seems to have a potential flaw by my
 > first read. It says " you must release all resulting models, weights,
 > and related code under the GPLv3 or later" but what does "release" mean?
 > There's no Affero-type clause, so keeping the AI running on private
 > servers even if giving others access might not count.

Very true, honestly this is just my attempt at the "preventative" 
interpretation of the GPLv3-or-later, where it works as a deterent. In 
that viewpoint, I just wanted a patchwork while the ongoing dialog 
progressed, so it is neither stated properly, nor is a "good" license. 
It is meant however to deter, and to that extent I think it sort of 
works okay as a patch.

On 7/11/25 7:31, Ben Cotton wrote:
 > Would this be field of use discrimination? I think it would, and would
 > therefore violate FSF Freedom 0 and OSD criteria 6. That would render
 > copyleft-next neither Open Source nor Free in the capital-letter sense
 > of the terms.

Honestly I believe it is a matter of view. For me it is inclusive rather 
than exclusive; "Copyleft holds for these use cases, and also for this 
one." A clause like that could act as a clarification; in my opinion 
this sort of works like the AGPL. One could argue that the AGPL is also 
discriminatory, same for the LGPL, or for the GPL with linking 
exception, etc.

 > At least with traditional software,
 > there's typically some external evidence that a project was used in
 > violation of its license. I'm not sure there's a good way to detect it
 > in an LLM unless I make my training data public (which I would not if
 > I were intending to violate the license).

Again, as I said before, I believe that copyleft works in two ways; as a 
deterent and as an enabler. This clarification clause would work as a 
deterent. Much like you need to prove the GPL violation, you would also 
need to prove this, however I don't think this poses such an 
insurmountable issue. For one, I can get a verbatim snippet of GPL 
licensed code. There are also active legal cases in the USA about LLMs 
being trained on copyrighted data, for example OpenAI vs New York Times, 
so there is tangible proof that there are ways to figure out if such 
models have used code licensed in such a way that would require them to 
be open (open as in open, not as in OSAID open).

- Vasileios Valatsos





From zefr0x at tuta.io  Fri Jul 11 16:54:33 2025
From: zefr0x at tuta.io (zefr0x at tuta.io)
Date: Fri, 11 Jul 2025 18:54:33 +0200 (CEST)
Subject: My view of copyleft and thoughts about copyleft-next
In-Reply-To: <e3f11488-5584-4c9c-ad86-c60636aad1c8@riseup.net>
References: <OUu2Eey--F-9@tuta.io>
 <e3f11488-5584-4c9c-ad86-c60636aad1c8@riseup.net>
Message-ID: <OUuPEgj--J-9@tuta.io>

Jul 11, 2025, 19:07 by wolftune at riseup.net:

>
>  In my view, the overall issue of software-freedom and copyleft can      be summarized as: No entity reserves practical or legal exclusive      power.
>
>


>
> Real software freedom means that while I might be less capable of      updating a program compared to an experienced coder who already      knows the software, they have provided me everything feasible that      they have access to in doing such updating.
>


>
> There's no code or      tools or legal rights that they have that I don't.
>
>

"Not reserving practical or legal exclusive power" looks like a very broad definition to me, it might include everything like hardware and human resources, not just knowledge.

What about this: No entity reserves practical or legal exclusive power on knowledge?
With software as a type of knowledge including its code and design etc.


From wolftune at riseup.net  Fri Jul 11 21:35:44 2025
From: wolftune at riseup.net (Aaron Wolf)
Date: Fri, 11 Jul 2025 14:35:44 -0700
Subject: My view of copyleft and thoughts about copyleft-next
In-Reply-To: <OUuPEgj--J-9@tuta.io>
References: <OUu2Eey--F-9@tuta.io>
 <e3f11488-5584-4c9c-ad86-c60636aad1c8@riseup.net> <OUuPEgj--J-9@tuta.io>
Message-ID: <31489a5e-c31f-49b2-a482-295f0f18b8b5@riseup.net>

Well, the big picture question is two parts: open vs exclusive; and 
abundant vs scarce.
Each of the four combinations presents different issues.
See my whole talk about this:
https://media.libreplanet.org/u/libreplanet/m/why-our-economy-fails-public-goods-like-free-software-bf79/

So when it comes to *software* freedom, we're talking about open 
abundance. So the question is whether anything *abundant* has been made 
*exclusive* (i.e. "club goods"). We aren't critiquing having exclusivity 
for scarce goods, though even that isn't *always* appropriate.

Yes, knowledge is abundant. And for this list, the question is how a 
*copyright* license relates to freedom, and everything that is covered 
by *copyright* law fits the abundant category.

So, I meant my basic framing with that premise as a given.

Cheers,

Aaron

On 7/11/25 9:54, zefr0x at tuta.io wrote:
> Jul 11, 2025, 19:07 bywolftune at riseup.net:
>
>>   In my view, the overall issue of software-freedom and copyleft can      be summarized as: No entity reserves practical or legal exclusive      power.
>>
>>
>
>> Real software freedom means that while I might be less capable of      updating a program compared to an experienced coder who already      knows the software, they have provided me everything feasible that      they have access to in doing such updating.
>>
>
>> There's no code or      tools or legal rights that they have that I don't.
>>
>>
> "Not reserving practical or legal exclusive power" looks like a very broad definition to me, it might include everything like hardware and human resources, not just knowledge.
>
> What about this: No entity reserves practical or legal exclusive power on knowledge?
> With software as a type of knowledge including its code and design etc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.copyleft.org/pipermail/next/attachments/20250711/fe0bdfa8/attachment.html>

From fontana at sharpeleven.org  Sat Jul 12 15:49:50 2025
From: fontana at sharpeleven.org (Richard Fontana)
Date: Sat, 12 Jul 2025 11:49:50 -0400
Subject: Should there be a clause for AI?
In-Reply-To: <0d5e37b8-9e53-4845-a2ee-c42c231e24d7@aethrvmn.gr>
References: <0d5e37b8-9e53-4845-a2ee-c42c231e24d7@aethrvmn.gr>
Message-ID: <CAGT84B3dpMXnw1bp3W4bWpdBSgAHTzT-xKoNOwzAc1toEjN1GQ@mail.gmail.com>

On Fri, Jul 11, 2025 at 4:01 AM Vasileios Valatsos <me at aethrvmn.gr> wrote:
>
> Normally, when you use any software under a copyleft license, you must
> disclose any modifications, and release them under said license. However
> recently, with the training of language models and other generative
> methods, there is a laundering effect, where the end user is "handed"
> copyleft licensed code generated by the generative model, which
> effectively bypasses the copyleft clause. To my understanding (I am not
> a USA citizen) this is because, in the USA, the products of non-humans
> are not copyrightable (or copyleftable).

No, that is not correct, though I've heard confusion even from US
lawyers on this point.

The emerging notion (in the US and some other jurisdictions) that
generative model output is not copyrightable is based on the
assumption that the output would otherwise meet the minimum
requirements for copyrightability if the output *had* been created by
a human: in the US, basically, minimum originality and minimum
creativity (to the extent those are different things). In other words,
for example, if I use an LLM to generate a novel, and it's indeed as
far as anyone can tell an entirely original novel, no substantial
resemblance to any existing works, I can't claim I am the copyright
holder of the novel, because it was generated by a machine. At the
same time, the creator or vendor of the LLM or LLM product that
generated the novel also can't claim copyright ownership of the novel,
for the same reason.

(As an aside, this rationale is somewhat curious, given that we've
assumed for decades that things like aleatoric music compositions are
copyrightable.)

However, none of that means that the output couldn't possibly infringe
the copyright of some third party. You're right that a problem of such
models is that they could in effect 'launder' copyrighted material
(possibly copylefted) in the training data of the model. But that's
not because of some special legal situation, and it's really no
different from other modes of copyright infringement. If I write a
novel, and it's used to train a model (let's assume I don't have a
copyright infringement claim based on the act of training, an issue
that has been raised in a number of current lawsuits in the US), and
the model can be shown to produce output that's substantially similar
to my novel, I might have a copyright infringement claim against
someone in connection with the use of that model.

I will also say that I have not seen a credible argument since after
the initial rollout of GitHub Copilot that an LLM product was emitting
copylefted code (that is, code that was substantially similar to some
existing third party code under a copyleft license). It's obviously
*possible* and indeed the possibility is unavoidable, but I have to
wonder whether it's uncommon (and/or practically detectable) since I
think we'd otherwise be hearing more accusations about specific
misappropriations from copyleft code authors.

I assume you're not suggesting that the mere obvious fact that popular
LLMs are trained, in part, on copyleft code means that any output of
such LLMs has to be assumed to be a copy, in some sense, or a
derivative work, of such copyleft training data even if there is no
apparent similarity between training data and output. That's a
separate issue, anyway.

> To this extent, I myself personally use a second license, specifically
> for using projects as training data:
>
> ---
> Training Public License (TPL) v1.0
>
> Copyright © 2025
>
> This code and content is licensed under the GPLv3 or later, with the
> following special condition:
>
> If you use any part of this code, notes, or data for training,
> fine-tuning, or evaluating a machine learning system (including but not
> limited to neural networks, large language models, or any algorithm
> where this content influences the resulting system), you must release
> all resulting models, weights, and related code under the GPLv3 or later.
>
> All other uses are governed by the regular terms of the GPLv3 or later.
> ---
>
> I wonder if (a) this would make sense in copyleft-next, (b) if it even
> belongs in the conversation, (c) if there is a better way to tackle this.

There's a threshold question here which we haven't even addressed with
this reboot of copyleft-next, which is raised by your suggestion. Your
license is not a free software license -- by current standards, in my
opinion. I think that's fairly obvious but I wonder if you disagree
since you're structuring this as a "condition" on GPLv3 that requires
resulting work to be licensed under GPLv3.

The threshold question is, should copyleft-next be a free software
license? I think the answer has to be "yes" since I have no interest
in drafting a non-FLOSS license and I think it was always assumed that
copyleft-next would be a free software license.

Of course, the definition of free software, or software freedom, is
not set in stone. I think the most basic principles are permanent but
the interpretation of those principles will have to evolve with
changing conditions. For example, in another thread the Affero concept
was mentioned. In 1991 the notion of an Affero clause might have
commonly been regarded in the early GPL community (not to mention the
large anti-copyleft camp in the early free software community) as
being in conflict with the principles of free software, though maybe
that community wouldn't have had a good way of expressing that idea.
In 2025, there are *still* some people in the free software community
who regard an Affero clause as being categorically in conflict with
software freedom, but I'd contend this hasn't been a mainstream view
since the early 2000s.

So all that is to say that maybe the definition of free software, or
our application of that definition, needs to evolve specifically
because of the challenges being created by the rise of LLMs trained on
vast quantities of free software and being used (a) potentially,
though hopefully very rarely, to produce output that violates the
licenses of that training data, (b) commonly to produce output that
may not resemble such training data closely at all and yet in some
justifiable (to some people) sense feels like a misappropriation of
that work. I don't know whether extending the frontier of what
software freedom is is within the scope of this project, though. I've
kind of thought we have a more modest goal, which is to assume a
fairly conservative view of what software freedom is (basically,
software freedom is what the FLOSS community generally thought it was
around 2012) and draft a copyleft license that fits within that view.

Richard


From me at aethrvmn.gr  Sat Jul 12 17:32:33 2025
From: me at aethrvmn.gr (Vasileios Valatsos)
Date: Sat, 12 Jul 2025 19:32:33 +0200
Subject: Should there be a clause for AI?
In-Reply-To: <CAGT84B3dpMXnw1bp3W4bWpdBSgAHTzT-xKoNOwzAc1toEjN1GQ@mail.gmail.com>
References: <0d5e37b8-9e53-4845-a2ee-c42c231e24d7@aethrvmn.gr>
 <CAGT84B3dpMXnw1bp3W4bWpdBSgAHTzT-xKoNOwzAc1toEjN1GQ@mail.gmail.com>
Message-ID: <07488e39-bf43-4d8e-ba7f-6d068dae555a@aethrvmn.gr>

On 12/7/25 17:49, Richard Fontana wrote:
 > But that's not because of some special legal situation, and it's really
 > no different from other modes of copyright infringement. If I write a
 > novel, and it's used to train a model (let's assume I don't have a
 > copyright infringement claim based on the act of training, an issue
 > that has been raised in a number of current lawsuits in the US), and
 > the model can be shown to produce output that's substantially similar
 > to my novel, I might have a copyright infringement claim against
 > someone in connection with the use of that model.

Yes, I fully agree. My point is that with the current state of things, 
it is very problematic to figure out *who* that someone is.

It obviously can't be the end user, because they has no control over the 
stochastic output of the model, and they can't possibly reference the 
output and compare to figure out if it may violate any copyright/copyleft.

 > I assume you're not suggesting that the mere obvious fact that popular
 > LLMs are trained, in part, on copyleft code means that any output of
 > such LLMs has to be assumed to be a copy, in some sense, or a
 > derivative work, of such copyleft training data even if there is no
 > apparent similarity between training data and output. That's a
 > separate issue, anyway.

Obviously not. A large language model is a graph with weighted nodes; 
the training data only alters the values of the weights, so it can't be 
a derivative.

There are two different arguments made with respect to "copyright 
abuse"; I won't go into depth here because as you said, it is a separate 
issue. For completeness though, the first is what the NYT claim against 
OpenAI and Microsoft; that because the model can output verbatim copies 
of copyrighted content, it is a copyright violation which hurts the 
author financially. The second one is the one that artists use in the 
case of generative AI for media (images/video/audio) generation, and has 
to do with the fact that .

Neither of those really matter when it comes to copyleft; copyleft 
grants freedoms rather than restrict, however in both those cases it is 
not the model that is treated as a copy or a derivative, but it's 
capacity to output copyrighted (or copylefted) material (exactly because 
it has been trained on them, rather than accidentally generating a 
similar output). I am also not a lawyer, so I can't really confidently 
interpret neither the EU AI 
Act(https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai), 
nor the US Copyright office reports (https://www.copyright.gov/ai/), nor 
any other legal framework that might come up in other parts of the world.

 > I will also say that I have not seen a credible argument since after
 > the initial rollout of GitHub Copilot that an LLM product was emitting
 > copylefted code (that is, code that was substantially similar to some
 > existing third party code under a copyleft license). It's obviously
 > *possible* and indeed the possibility is unavoidable, but I have to
 > wonder whether it's uncommon (and/or practically detectable) since I
 > think we'd otherwise be hearing more accusations about specific
 > misappropriations from copyleft code authors.

I don't know if this derails the discussion, but my personal opinion and 
observation is that this is because there are two "groups": One "group" 
has moved out of GitHub and either self-host, or use Codeberg and other 
FOSS solutions (in both Codeberg and SourceHut, as well as freedesktop's 
GitLab, Anubis is deployed to block crawlers.). The other one is either 
apathetic or at least waiting to see what the law has to say.

Regarding your criticism of my patchwork of a license, I fully agree; as 
stated in another response in the thread, I made it, and use it as a bad 
deterrent against scraping, and is there only until a proper solution is 
found. I would never consider myself capable to come up with a license 
from scratch, hence why this thread was started in the first place.

Obviously regarding your statement that any new copyleft license should 
be libre, I also agree. I was the person mentioning the Affero clause, 
as an example of something that *could* be interpreted as non-free 
whilst actually being free; this was done because the claim was that a 
clause regarding the use of the software as training data would be seen 
as violating Freedom 0, while I hold the position that it is of a 
similar nature to the AGPL, LGPL, and the GPL with linking exception 
(all three discriminate about a specific use of the software, but still 
are libre, because they don't prevent the use of the software, just 
extend or retract the copyleft clause).

 > So all that is to say that maybe the definition of free software, or
 > our application of that definition, needs to evolve specifically
 > because of the challenges being created by the rise of LLMs trained on
 > vast quantities of free software and being used (a) potentially,
 > though hopefully very rarely, to produce output that violates the
 > licenses of that training data, (b) commonly to produce output that
 > may not resemble such training data closely at all and yet in some
 > justifiable (to some people) sense feels like a misappropriation of
 > that work.

If we are to accept that the definition of free software is 
community-derived, and not mandated by an entity such as the FSF or the 
OSI, then there is no need to "evolve" the definition, since this 
process is organically happening. It is, however, an issue trying to 
freeze and formalize the "current" or "2012" definition such that it can 
be used as a basis for writing new licenses, since while everyone agrees 
on the spirit of FLOSS, people vehemently disagree on the word of FLOSS.

 > I don't know whether extending the frontier of what
 > software freedom is is within the scope of this project, though. I've
 > kind of thought we have a more modest goal, which is to assume a
 > fairly conservative view of what software freedom is (basically,
 > software freedom is what the FLOSS community generally thought it was
 > around 2012) and draft a copyleft license that fits within that view.

This is exactly why the subject of the thread is in the form of a 
question, as well as at the end I questioned even the sensibility of 
such a clause in the first place. To be honest I believe that the mere 
act of writing a new license is more than a "modest" goal, since the 
hope is that it gets adopted and preferred over other copyleft licenses, 
either for legibility/clarity, better legal interpretability, etc. This 
means that, at least to some extent, the underlying goal of 
copyleft-next would be to replace GPL at least in some use-cases. Most 
probably this task by it's own is ambitious enough for now and aiming 
for a "perfect, all encompassing license that tries to tackle every 
single issue at the same time" on the first go might be too much.

At the same time, I remember in another thread a discussion about the 
ambition of copyleft-next having a structure similar to CC; perhaps in 
place of that there is a family of licenses closer to the (A/L)-GPL family?

- Vasileios Valatsos


From kuno at frob.nl  Sun Jul 13 06:56:57 2025
From: kuno at frob.nl (Kuno Woudt)
Date: Sun, 13 Jul 2025 01:56:57 -0500
Subject: Should there be a clause for AI?
In-Reply-To: <07488e39-bf43-4d8e-ba7f-6d068dae555a@aethrvmn.gr>
References: <0d5e37b8-9e53-4845-a2ee-c42c231e24d7@aethrvmn.gr>
 <CAGT84B3dpMXnw1bp3W4bWpdBSgAHTzT-xKoNOwzAc1toEjN1GQ@mail.gmail.com>
 <07488e39-bf43-4d8e-ba7f-6d068dae555a@aethrvmn.gr>
Message-ID: <e50a301c-385b-46c8-ba14-6308f18a9955@app.fastmail.com>

On Sat, Jul 12, 2025, at 12:32 PM, Vasileios Valatsos wrote:
> On 12/7/25 17:49, Richard Fontana wrote:
>  > But that's not because of some special legal situation, and it's really
>  > no different from other modes of copyright infringement. If I write a
>  > novel, and it's used to train a model (let's assume I don't have a
>  > copyright infringement claim based on the act of training, an issue
>  > that has been raised in a number of current lawsuits in the US), and
>  > the model can be shown to produce output that's substantially similar
>  > to my novel, I might have a copyright infringement claim against
>  > someone in connection with the use of that model.
>
> Yes, I fully agree. My point is that with the current state of things, 
> it is very problematic to figure out *who* that someone is.
>
> It obviously can't be the end user, because they has no control over the 
> stochastic output of the model, and they can't possibly reference the 
> output and compare to figure out if it may violate any copyright/copyleft.

Why would it not be the end user?   They have control over whether they
publish the output or not.  I don't think copyright law cares about the
practicality of a user determining whether their tools generated copyrighted
output.

If I manage to accidentally or on purpose convince a chatbot to output
substantial chunks of a literary work -- I'd expect that publishing that output
would be copyright infringement regardless of whether I know that what
I'm publishing is a pre-existing copyrighted work.


From wolftune at riseup.net  Sun Jul 13 15:25:55 2025
From: wolftune at riseup.net (Aaron Wolf)
Date: Sun, 13 Jul 2025 08:25:55 -0700
Subject: Should there be a clause for AI?
In-Reply-To: <e50a301c-385b-46c8-ba14-6308f18a9955@app.fastmail.com>
References: <0d5e37b8-9e53-4845-a2ee-c42c231e24d7@aethrvmn.gr>
 <CAGT84B3dpMXnw1bp3W4bWpdBSgAHTzT-xKoNOwzAc1toEjN1GQ@mail.gmail.com>
 <07488e39-bf43-4d8e-ba7f-6d068dae555a@aethrvmn.gr>
 <e50a301c-385b-46c8-ba14-6308f18a9955@app.fastmail.com>
Message-ID: <e9c6d2b1-52d9-4aba-b165-f49cdf69908d@riseup.net>

First, I want to clear up a mistake in this thread:

Vasileios wrote:

 >Normally, when you use any software under a copyleft license, you must 
disclose any modifications, and release them under said license. 
Disclosing modifications and releasing them under the same license 
applies only when *conveying* the software to others, not just when 
*using*. Perhaps this was understood, perhaps not, but this is a 
widespread misunderstanding, so please be careful about that. Anyone can 
use copyleft software and even modify it *without* any copyleft 
requirements being triggered. Modifications can be made and kept 
private. They do not need to be disclosed to anyone if the software is 
used only privately. And they only need to be disclosed to those who 
receive the software when sharing. Anyway, on the AI question: The 
dilemma is about maintaining practical software freedom. There's no 
point in developing copyleft-next if it does nothing to actually support 
software freedom in practice. Let's imagine that we succeed at blocking 
legal AI training on copyleft-next code. Maybe there's some incentive 
for programmers to then use copyleft-next more widely. If a sufficient 
amount of code gets a copyleft-next license, that could give the whole 
copyleft-next ecosystem an advantage over (legal) AIs. But if AIs can be 
trained adequately enough without the copyleft-next code, then people 
will eventually be able to trivially reverse-engineer any copyleft-next 
programs with AI. Imagine a future where each time someone encounters a 
copyleft-next program and doesn't want to accept the copyleft terms, 
they simply go to an AI and describe the functionality of the 
copyleft-next program and get some *different* code that is effective 
enough to replace the copyleft-next program. That scenario would make 
copyleft-next pretty useless. Is there any realistic possibility of 
keeping enough code out of AI training such that it couldn't do what I'm 
envisioning? I have a hard time believing it. And in this scenario, 
what's the point of copyleft-next? If anyone who wants to remove 
software-freedom can get AI assistance in doing so, then we're left with 
software-freedom only from those who already care to maintain it… and 
then there's no need for copyleft. Are we banking on the idea that 
AI-generated code will remain more buggy or otherwise unreliable than 
human written copyleft code? Or is the idea that we do indeed encourage 
AI training with copyleft-next code as a hack to encourage more public 
freedom with the AI itself? We are concerned that a free society needs 
to not have a few companies or governments have exclusive AI control, 
and so we think copyright-licensing is a means to legally compel AI 
weights and so on to be released to the public? This scenario is not 
about excluding copyleft-next from training but getting AI's to be more 
free. But in practice, powerful companies that want exclusive control 
would likely exclude copyleft-next code if they felt it would compel 
them to be more free with their AIs than they want otherwise, right? 
Note that without any AI clauses, I *think* copyleft would still apply 
to the use of AI to do simple code modifications. So, imagine someone 
uses an AI to add a minor feature to a copyleft-next program, and they 
publish their update. This should be no different than if a human 
programmer had made the updates, right? And no extra clause is needed 
for this case. What is the whole goal of copyleft-next within the 
context of this brave-new-AI-world we're facing? Where does it fit in? 
Aaron

On 7/12/25 11:56, Kuno Woudt wrote:
> On Sat, Jul 12, 2025, at 12:32 PM, Vasileios Valatsos wrote:
>> On 12/7/25 17:49, Richard Fontana wrote:
>>   > But that's not because of some special legal situation, and it's really
>>   > no different from other modes of copyright infringement. If I write a
>>   > novel, and it's used to train a model (let's assume I don't have a
>>   > copyright infringement claim based on the act of training, an issue
>>   > that has been raised in a number of current lawsuits in the US), and
>>   > the model can be shown to produce output that's substantially similar
>>   > to my novel, I might have a copyright infringement claim against
>>   > someone in connection with the use of that model.
>>
>> Yes, I fully agree. My point is that with the current state of things,
>> it is very problematic to figure out *who* that someone is.
>>
>> It obviously can't be the end user, because they has no control over the
>> stochastic output of the model, and they can't possibly reference the
>> output and compare to figure out if it may violate any copyright/copyleft.
> Why would it not be the end user?   They have control over whether they
> publish the output or not.  I don't think copyright law cares about the
> practicality of a user determining whether their tools generated copyrighted
> output.
>
> If I manage to accidentally or on purpose convince a chatbot to output
> substantial chunks of a literary work -- I'd expect that publishing that output
> would be copyright infringement regardless of whether I know that what
> I'm publishing is a pre-existing copyrighted work.
> _______________________________________________
> next mailing list
> next at lists.copyleft.org
> https://lists.copyleft.org/mailman/listinfo/next
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.copyleft.org/pipermail/next/attachments/20250713/b96ba941/attachment.html>

From fontana at sharpeleven.org  Sun Jul 13 21:13:53 2025
From: fontana at sharpeleven.org (Richard Fontana)
Date: Sun, 13 Jul 2025 17:13:53 -0400
Subject: Should there be a clause for AI?
In-Reply-To: <e9c6d2b1-52d9-4aba-b165-f49cdf69908d@riseup.net>
References: <0d5e37b8-9e53-4845-a2ee-c42c231e24d7@aethrvmn.gr>
 <CAGT84B3dpMXnw1bp3W4bWpdBSgAHTzT-xKoNOwzAc1toEjN1GQ@mail.gmail.com>
 <07488e39-bf43-4d8e-ba7f-6d068dae555a@aethrvmn.gr>
 <e50a301c-385b-46c8-ba14-6308f18a9955@app.fastmail.com>
 <e9c6d2b1-52d9-4aba-b165-f49cdf69908d@riseup.net>
Message-ID: <CAGT84B240m18rMSVzxhr3XA4TsSJVHLcDa_KgyM4Z1Ha9ia4ow@mail.gmail.com>

> Disclosing modifications and releasing them under the same license applies only when *conveying* the software to others, not just when *using*. Perhaps this was understood, perhaps not, but this is a widespread misunderstanding, so please be careful about that. Anyone can use copyleft software and even modify it *without* any copyleft requirements being triggered. Modifications can be made and kept private. They do not need to be disclosed to anyone if the software is used only privately. And they only need to be disclosed to those who receive the software when sharing.

That assumes copyleft conforms to what I was calling "software freedom
as the FLOSS community understood it in 2012" or however I put it.
There have been a number of licenses, perhaps we'd consider them
pseudo or quasi-FLOSS, that attempt to break with this principle that
copyleft requirements are triggered only by "conveying", and indeed
this is also an argument that anti-AGPL people will use to say that
AGPL is not a free software license. (And it's also part of the reason
why in 1991 AGPL probably would have been seen as "non-free" if the
vocabulary had existed adequately then.)

The reason I mention this:

> The dilemma is about maintaining practical software freedom. There's no point in developing copyleft-next if it does nothing to actually support software freedom in practice.
>
> Let's imagine that we succeed at blocking legal AI training on copyleft-next code.

I don't see how you can block legal AI training on copyleft-next code
while adhering to 2012 software freedom, or (I'd contend) 2025
software freedom. Separately, the direction courts seem to be going in
the US would probably make licenses prohibiting AI training pointless.

(Apologies if I'm misunderstanding what you mean by "succeed at
blocking legal AI training".)

 > Are we banking on the idea that AI-generated code will remain more
buggy or otherwise unreliable than human written copyleft code?

I think we can assume this (in general) for the shorter term, though I
don't know how short that is.

> We are concerned that a free society needs to not have a few companies or governments have exclusive AI control, and so we think copyright-licensing is a means to legally compel AI weights and so on to be released to the public? This scenario is not about excluding copyleft-next from training but getting AI's to be more free. But in practice, powerful companies that want exclusive control would likely exclude copyleft-next code if they felt it would compel them to be more free with their AIs than they want otherwise, right?

It sounds like you're envisioning that a "copyleft-next for AI" could
devise some sort of "clever hack" or jujitsu move or whatever to make
models themselves to be free, or more free. This is probably worth
discussing, but it's probably not going to take the form of a license
that says "if you want to train your model with this copyleft-next
code, you have to do these things to make your resulting model
copyleft".

As for the powerful companies training the kinds of models we're
talking about, barring some unexpected direction in the law favoring
copyright holders of training data (which I'd note that I personally
am not especially sympathetic to), I think they just aren't going to
care much as they don't care right now that they are training using
copies of proprietary (and GPL, etc.) works. Or more precisely, they
do care, but they believe they are in the right.

> Note that without any AI clauses, I *think* copyleft would still apply to the use of AI to do simple code modifications. So, imagine someone uses an AI to add a minor feature to a copyleft-next program, and they publish their update. This should be no different than if a human programmer had made the updates, right? And no extra clause is needed for this case.

It is potentially different for the reason I think I stated in this
thread, that in some jurisdictions the emerging principle is that
seemingly original works of generative AI models are not copyrightable
because they are not human authored. So you can imagine a situation
where the same minor feature is added to a copyleft-next program, but
if a human does it without using an AI tool, it's copyrightable and
therefore copyleft applies to the modifications, while if it was
entirely AI generated copyleft might not apply to those modifications.
I'm not sure this has that much practical significance though (at
least not until the tools we're talking about get much better). We
have minor features added to copyleft programs today that are under
permissive licenses or are essentially outside of the scope of
copyright entirely.

Richard


From wolftune at riseup.net  Sun Jul 13 21:30:07 2025
From: wolftune at riseup.net (Aaron Wolf)
Date: Sun, 13 Jul 2025 14:30:07 -0700
Subject: Should there be a clause for AI?
In-Reply-To: <CAGT84B240m18rMSVzxhr3XA4TsSJVHLcDa_KgyM4Z1Ha9ia4ow@mail.gmail.com>
References: <0d5e37b8-9e53-4845-a2ee-c42c231e24d7@aethrvmn.gr>
 <CAGT84B3dpMXnw1bp3W4bWpdBSgAHTzT-xKoNOwzAc1toEjN1GQ@mail.gmail.com>
 <07488e39-bf43-4d8e-ba7f-6d068dae555a@aethrvmn.gr>
 <e50a301c-385b-46c8-ba14-6308f18a9955@app.fastmail.com>
 <e9c6d2b1-52d9-4aba-b165-f49cdf69908d@riseup.net>
 <CAGT84B240m18rMSVzxhr3XA4TsSJVHLcDa_KgyM4Z1Ha9ia4ow@mail.gmail.com>
Message-ID: <bd1c7042-7d14-4445-bbc5-bfcc690f71ee@riseup.net>

I agree with the bulk of these points. https://ai-2027.com/ is a good 
reference for the premise that AI could reach levels categorically 
different from today within what is a short-term in human time scale.

Anyway, the last point on contributions to copyleft-next projects: 
*some* legal entity would be publishing updated versions of a project… I 
mean, it's possible for an AI to anonymously put out some updated 
version of a program and nobody finds out where it came from, but this 
is comparable to a human doing so anonymously. As long as some human or 
corporation, some recognized legal entity is the *publisher* of some 
software, then that legal entity would be bound to follow the 
copyleft-next license in terms of *their* access to the copyrighted 
code. It shouldn't matter that the *updates* are not copyrightable 
precisely…

So, this brings up a key point for the actual license. We might be 
unable to specify that updates made by AI shall use copyleft-next as a 
license if those updates are not themselves copyrightable. However, I 
don't see why copyleft-next couldn't still specify that these 
uncopyrightable updates be released in source form as part of following 
the terms of copyleft-next in terms of including the *original* code in 
the updated program.

In other words, we should be able to say that it violates the 
copyleft-next license for a legal entity to publish an adaptation 
without making the source code available, even in cases where it is 
impossible to apply a copyright license to the code updates. The legal 
entity should still face the requirement to pass on all the source code 
that remains under copyleft-next and make available with it all the 
source code that is public domain but part of the update.

Aaron

On 7/13/25 2:13, Richard Fontana wrote:
>> Disclosing modifications and releasing them under the same license applies only when *conveying* the software to others, not just when *using*. Perhaps this was understood, perhaps not, but this is a widespread misunderstanding, so please be careful about that. Anyone can use copyleft software and even modify it *without* any copyleft requirements being triggered. Modifications can be made and kept private. They do not need to be disclosed to anyone if the software is used only privately. And they only need to be disclosed to those who receive the software when sharing.
> That assumes copyleft conforms to what I was calling "software freedom
> as the FLOSS community understood it in 2012" or however I put it.
> There have been a number of licenses, perhaps we'd consider them
> pseudo or quasi-FLOSS, that attempt to break with this principle that
> copyleft requirements are triggered only by "conveying", and indeed
> this is also an argument that anti-AGPL people will use to say that
> AGPL is not a free software license. (And it's also part of the reason
> why in 1991 AGPL probably would have been seen as "non-free" if the
> vocabulary had existed adequately then.)
>
> The reason I mention this:
>
>> The dilemma is about maintaining practical software freedom. There's no point in developing copyleft-next if it does nothing to actually support software freedom in practice.
>>
>> Let's imagine that we succeed at blocking legal AI training on copyleft-next code.
> I don't see how you can block legal AI training on copyleft-next code
> while adhering to 2012 software freedom, or (I'd contend) 2025
> software freedom. Separately, the direction courts seem to be going in
> the US would probably make licenses prohibiting AI training pointless.
>
> (Apologies if I'm misunderstanding what you mean by "succeed at
> blocking legal AI training".)
>
>   > Are we banking on the idea that AI-generated code will remain more
> buggy or otherwise unreliable than human written copyleft code?
>
> I think we can assume this (in general) for the shorter term, though I
> don't know how short that is.
>
>> We are concerned that a free society needs to not have a few companies or governments have exclusive AI control, and so we think copyright-licensing is a means to legally compel AI weights and so on to be released to the public? This scenario is not about excluding copyleft-next from training but getting AI's to be more free. But in practice, powerful companies that want exclusive control would likely exclude copyleft-next code if they felt it would compel them to be more free with their AIs than they want otherwise, right?
> It sounds like you're envisioning that a "copyleft-next for AI" could
> devise some sort of "clever hack" or jujitsu move or whatever to make
> models themselves to be free, or more free. This is probably worth
> discussing, but it's probably not going to take the form of a license
> that says "if you want to train your model with this copyleft-next
> code, you have to do these things to make your resulting model
> copyleft".
>
> As for the powerful companies training the kinds of models we're
> talking about, barring some unexpected direction in the law favoring
> copyright holders of training data (which I'd note that I personally
> am not especially sympathetic to), I think they just aren't going to
> care much as they don't care right now that they are training using
> copies of proprietary (and GPL, etc.) works. Or more precisely, they
> do care, but they believe they are in the right.
>
>> Note that without any AI clauses, I *think* copyleft would still apply to the use of AI to do simple code modifications. So, imagine someone uses an AI to add a minor feature to a copyleft-next program, and they publish their update. This should be no different than if a human programmer had made the updates, right? And no extra clause is needed for this case.
> It is potentially different for the reason I think I stated in this
> thread, that in some jurisdictions the emerging principle is that
> seemingly original works of generative AI models are not copyrightable
> because they are not human authored. So you can imagine a situation
> where the same minor feature is added to a copyleft-next program, but
> if a human does it without using an AI tool, it's copyrightable and
> therefore copyleft applies to the modifications, while if it was
> entirely AI generated copyleft might not apply to those modifications.
> I'm not sure this has that much practical significance though (at
> least not until the tools we're talking about get much better). We
> have minor features added to copyleft programs today that are under
> permissive licenses or are essentially outside of the scope of
> copyright entirely.
>
> Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.copyleft.org/pipermail/next/attachments/20250713/a73e4553/attachment.html>

From fontana at sharpeleven.org  Sun Jul 13 23:21:29 2025
From: fontana at sharpeleven.org (Richard Fontana)
Date: Sun, 13 Jul 2025 19:21:29 -0400
Subject: Should there be a clause for AI?
In-Reply-To: <bd1c7042-7d14-4445-bbc5-bfcc690f71ee@riseup.net>
References: <0d5e37b8-9e53-4845-a2ee-c42c231e24d7@aethrvmn.gr>
 <CAGT84B3dpMXnw1bp3W4bWpdBSgAHTzT-xKoNOwzAc1toEjN1GQ@mail.gmail.com>
 <07488e39-bf43-4d8e-ba7f-6d068dae555a@aethrvmn.gr>
 <e50a301c-385b-46c8-ba14-6308f18a9955@app.fastmail.com>
 <e9c6d2b1-52d9-4aba-b165-f49cdf69908d@riseup.net>
 <CAGT84B240m18rMSVzxhr3XA4TsSJVHLcDa_KgyM4Z1Ha9ia4ow@mail.gmail.com>
 <bd1c7042-7d14-4445-bbc5-bfcc690f71ee@riseup.net>
Message-ID: <CAGT84B09jcaaQzcv0YymiwvH3mNdW_Ox+EDSYg9qVL9bjoGuqg@mail.gmail.com>

On Sun, Jul 13, 2025 at 5:30 PM Aaron Wolf <wolftune at riseup.net> wrote:
>
> I agree with the bulk of these points. https://ai-2027.com/ is a good reference for the premise that AI could reach levels categorically different from today within what is a short-term in human time scale.

I've seen that before. That seems to give us very little time to have
a copyleft-next that has any chance of accomplishing anything before
the robots take over. :-)

> Anyway, the last point on contributions to copyleft-next projects: *some* legal entity would be publishing updated versions of a project… I mean, it's possible for an AI to anonymously put out some updated version of a program and nobody finds out where it came from, but this is comparable to a human doing so anonymously. As long as some human or corporation, some recognized legal entity is the *publisher* of some software, then that legal entity would be bound to follow the copyleft-next license in terms of *their* access to the copyrighted code. It shouldn't matter that the *updates* are not copyrightable precisely…

Oh, absolutely. I'm just saying AI-generated modifications in some
cases will be equivalent to public domain modifications in the
pre-AI-hype world.

> So, this brings up a key point for the actual license. We might be unable to specify that updates made by AI shall use copyleft-next as a license if those updates are not themselves copyrightable. However, I don't see why copyleft-next couldn't still specify that these uncopyrightable updates be released in source form as part of following the terms of copyleft-next in terms of including the *original* code in the updated program.

Sure, this is how it would work today under the GPL.

Richard


From me at aethrvmn.gr  Tue Jul 15 19:32:51 2025
From: me at aethrvmn.gr (Vasileios Valatsos)
Date: Tue, 15 Jul 2025 21:32:51 +0200
Subject: Should there be a clause for AI?
In-Reply-To: <CAGT84B09jcaaQzcv0YymiwvH3mNdW_Ox+EDSYg9qVL9bjoGuqg@mail.gmail.com>
References: <0d5e37b8-9e53-4845-a2ee-c42c231e24d7@aethrvmn.gr>
 <CAGT84B3dpMXnw1bp3W4bWpdBSgAHTzT-xKoNOwzAc1toEjN1GQ@mail.gmail.com>
 <07488e39-bf43-4d8e-ba7f-6d068dae555a@aethrvmn.gr>
 <e50a301c-385b-46c8-ba14-6308f18a9955@app.fastmail.com>
 <e9c6d2b1-52d9-4aba-b165-f49cdf69908d@riseup.net>
 <CAGT84B240m18rMSVzxhr3XA4TsSJVHLcDa_KgyM4Z1Ha9ia4ow@mail.gmail.com>
 <bd1c7042-7d14-4445-bbc5-bfcc690f71ee@riseup.net>
 <CAGT84B09jcaaQzcv0YymiwvH3mNdW_Ox+EDSYg9qVL9bjoGuqg@mail.gmail.com>
Message-ID: <ebd50283-54be-4ef1-98b8-1745a2dc6e83@aethrvmn.gr>

There is a great big deal that I want to expand on; first and foremost 
that someone possibly (almost certainly) smarter than me has put my 
argumentation in a manner that is much clearer than what I could hope to 
achieve in an email or two:

https://www.youtube.com/watch?v=CdKxgT1o864

The essential point of this discussion is that myself and others feel 
like the proper definitions of FOSS are not enough to encapsulate what 
AI does as a software. At the same time I understand any hesitation on 
the extremely overbearing and uninvited work that would come with the 
task, so in all earnest I think that this discussion should be 
abandoned, not because a solution is unattainable, but because it is 
beyond of the scope of what copyleft-next should have, especially since 
it is at an extremely volatile time, where there are much more urgent, 
and obvious, and tackleable problems (like the RHEL source code abuse, 
and the "sending source in floppy discs twenty years after the fact, to 
name a few.).

Now that's out, I really *really* want to respond to some things said in 
this thread.

On Sun, Jul 13, 2025 at 5:30 PM Aaron Wolf <wolftune at riseup.net> wrote:
 > I agree with the bulk of these points. https://ai-2027.com/ is a good 
reference for the premise that AI could reach levels categorically 
different from today within what is a short-term in human time scale.

Please don't fall for marketing hype. OpenAI has been saying "AGI next 
week" since 2022. Scaling is *not* the solution. I understand that they 
are *experts* and that "their opinion has weight", but (a) appeal to 
authority is a logical fallacy, and (b) I am also an ai researcher 
(Apart from working as an ai researcher I also maintain GPLv3-or-later 
ai libraries), so I appeal to myself to tell you to not fall for the 
hype. It's all marketing so that people talk about the field more, so 
that VC funding is given without question. Everybody in the field is 
aware of the insurmountable limitations to scaling.

On 14/7/25 01:21, Richard Fontana wrote:
 > I've seen that before. That seems to give us very little time to have
 > a copyleft-next that has any chance of accomplishing anything before
 > the robots take over. :-)

NO. The USA is not the only legal framework in the world, and copyleft 
has won cases outside of it. Even if citizens of the USA don't benefit 
(which they will, because this license closes loopholes), other citizens 
of other countries with as of yet undefined software and copyright laws, 
such as the global South, will benefit *immensely*. Just consider the 
fact that the notion of fair use exists mostly within the USA.

In any case, I think that copyleft-next is a much needed update to 
copyleft implementations that I don't care about an AI license, 
especially since there are others who are attempting to fix that exact 
problem, so a double license solution becomes feasible.

Apart from those points:

On Sun, Jul 13, 2025 at 3:25 PM Aaron Wolf <wolftune at riseup.net> wrote:
 > Disclosing modifications and releasing them under the same license
 > applies only when *conveying* the software to others, not just when
 > *using*. Perhaps this was understood, perhaps not, but this is a
 > widespread misunderstanding, so please be careful about that.

You are correct, I should've been more careful. I used the phrase I did 
be because in AI/ML settings you have something more akin to AGPL, where 
the distribution is part of the copyleft clauses.

 > That scenario would make copyleft-next pretty useless.

That scenario makes any copyleft license useless because I can generate 
it via LLMs and have it closed source. Worse, current copyleft licenses 
appear to be useless because there is no consideration for LLM outputs. 
I can, right now, feed an LLM any source code line by line, with the 
instruction to repeat the code. The output is non-copyrightable, so does 
copyleft hold? I dont know.

 > If anyone who wants to remove software-freedom can get AI assistance
 > in doing so, then we're left with software-freedom only from those who
 > already care to maintain it… and then there's no need for copyleft.

Exactly my point.

On 7/12/25 11:56, Kuno Woudt wrote:
 > If I manage to accidentally or on purpose convince a chatbot to output
 > substantial chunks of a literary work -- I'd expect that publishing
 > that output would be copyright infringement regardless of whether I
 > know that what I'm publishing is a pre-existing copyrighted work.

My hesitation on that has more to do with the fact that most people 
don't know/check software licenses, especially vibe coders. I think of 
it as people who bought a fake "brand", like a fake iPhone, or bought a 
CD containing a pirated movie file.

On 14/7/25 01:21, Richard Fontana wrote:
 > It sounds like you're envisioning that a "copyleft-next for AI" could
 > devise some sort of "clever hack" or jujitsu move or whatever to make
 > models themselves to be free, or more free. This is probably worth
 > discussing, but it's probably not going to take the form of a license
 > that says "if you want to train your model with this copyleft-next
 > code, you have to do these things to make your resulting model
 > copyleft".

Honestly the more I think about it I understand the attainability and 
the folly of such an endeavour. However I think more reasonable a type 
of strong ShareAlike clause. Maybe if copyleft-next is inside the 
training data, the training data get infected? At the same time there is 
no distribution of data, but then again, ShareAlike doesn't need 
distribtuion of the data. And while it isn't about software strictly, it 
is about copyleft so maybe this could prove better?

In any case, as I originally stated, I consider this a matter for a 
later time. Currently I would much rather have a copyleft-next license 
without any such clause, which can be amended, rather than no 
copyleft-next license, but endless "fruitfull" discussions about the 
approach.

- Vasileios Valatsos


From denver at ossguy.com  Fri Jul 18 22:21:16 2025
From: denver at ossguy.com (Denver Gingerich)
Date: Fri, 18 Jul 2025 22:21:16 +0000
Subject: Code of Conduct: we need =?utf-8?Q?one?= =?utf-8?B?ICjigKY=?= in
 parallel / in addition to HBR)
In-Reply-To: <CAJox1157Q722B60e58=pUiLgnQfZMOzu9F-0sAeeCO9DzMYbcA@mail.gmail.com>
References: <aHBkMyN+D4PiowjL@ebb.org>
 <CAJox1157Q722B60e58=pUiLgnQfZMOzu9F-0sAeeCO9DzMYbcA@mail.gmail.com>
Message-ID: <20250718222116.GU7497@ossguy.com>

On Fri, Jul 11, 2025 at 10:19:29AM -0400, Ben Cotton wrote:
> On Thu, Jul 10, 2025 at 9:09 PM Bradley M. Kuhn <bkuhn at ebb.org> wrote:
> >
> > I'm curious if folks have a particular CoC template that they particularly
> > like and think would be good for copyleft-next?
> >
> > I did some poking around and discussion with colleagues well-versed in this
> > area, and frankly there is no clear standard, and I don't think (other than
> > the HBR addendum) that we should write our own from scratch.
> 
> I'm generally in favor of the Contributor Covenant
> (https://www.contributor-covenant.org/), although it's been long
> enough since I had to think about it that I don't remember any
> particular details of what I liked or disliked about it. Fedora's
> "new" (it's been several years now) code of conduct is largely based
> on it, with some modifications, and it has served well.

The Contributor Covenant is also what we at Soprani.ca (the umbrella that includes JMP) have adopted: https://soprani.ca/code-of-conduct/

We admittedly are not well-versed in this area, but our research suggested this was a fairly solid initial approach.

Denver
https://jmp.chat/


From bkuhn at ebb.org  Fri Jul 25 01:18:20 2025
From: bkuhn at ebb.org (Bradley M. Kuhn)
Date: Thu, 24 Jul 2025 18:18:20 -0700
Subject: Code of Conduct: we need =?utf-8?Q?one?= =?utf-8?B?ICjigKY=?= in
 parallel / in addition to HBR)
In-Reply-To: <52c54749-b54f-4dc8-a07a-e47b545f5081@riseup.net>
References: <aHBkMyN+D4PiowjL@ebb.org>
 <CAJox1157Q722B60e58=pUiLgnQfZMOzu9F-0sAeeCO9DzMYbcA@mail.gmail.com>
 <sGPThNigbP1vnSgQYaZZzE7eHL4QfUetH_Cbu8agKjwZMnispAT7jNp7plPRkMnK-UHN-79tpgZNSQHR5wZrMpIvLc_wCI4ONBzzbJl39zM=@protonmail.com>
 <52c54749-b54f-4dc8-a07a-e47b545f5081@riseup.net>
Message-ID: <aILbXBWB16u8gtQP@ebb.org>

Aaron Wolf wrote a number of days ago:
> Most of the time, subtle harms are allowed to continue for too long and
> then after they get worse, punitive and threatening actions are taken that
> cause people to get defensive and everything leads to limits and bans. So,
> there is neither a truly high-standard of healthy interactions being
> maintained nor an effective learning and restoration process.

I realize that given my life's work, everything reminds me of copyleft, but
this reminds me of copyleft. 🤣

It's the line between the written agreement and its actual enforcement — and
how difficult that enforcement is.

I think I do want a CoC for copyleft-next that designates a specific
enforcement agent — who is not too closely tied to the project to avoid
conflict of interest but who cares enough about the project to be responsive
when problems start early.

Aaron, do you think that might alleviate some of your concerns?

I've seen the problems you've described too in other projects and the above
is the only idea I've ever had to possible improve the situation.


I otherwise like the Contributor Covenant.  I just don't think it's a good
idea for various reasons for Richard or me to enforce the CoC, and I note
the Contributor Covenant says that "Community Leaders" are responsible
for enforcement. 🤔
--
     -- bkuhn, noting: IANAL & TINLA


From bcotton at funnelfiasco.com  Fri Jul 25 13:50:31 2025
From: bcotton at funnelfiasco.com (Ben Cotton)
Date: Fri, 25 Jul 2025 09:50:31 -0400
Subject: =?UTF-8?Q?Re=3A_Code_of_Conduct=3A_we_need_one_=28=E2=80=A6_in_parallel_=2F_?=
 =?UTF-8?Q?in_addition_to_HBR=29?=
In-Reply-To: <aILbXBWB16u8gtQP@ebb.org>
References: <aHBkMyN+D4PiowjL@ebb.org>
 <CAJox1157Q722B60e58=pUiLgnQfZMOzu9F-0sAeeCO9DzMYbcA@mail.gmail.com>
 <sGPThNigbP1vnSgQYaZZzE7eHL4QfUetH_Cbu8agKjwZMnispAT7jNp7plPRkMnK-UHN-79tpgZNSQHR5wZrMpIvLc_wCI4ONBzzbJl39zM=@protonmail.com>
 <52c54749-b54f-4dc8-a07a-e47b545f5081@riseup.net> <aILbXBWB16u8gtQP@ebb.org>
Message-ID: <CAJox115pyy7+bUyOK0PFtJtzTW4mJg7M6YQm=QP5HyQH986CSg@mail.gmail.com>

On Thu, Jul 24, 2025 at 9:20 PM Bradley M. Kuhn <bkuhn at ebb.org> wrote:
>
> I otherwise like the Contributor Covenant.  I just don't think it's a good
> idea for various reasons for Richard or me to enforce the CoC, and I note
> the Contributor Covenant says that "Community Leaders" are responsible
> for enforcement. 🤔

Can you say more about your concerns here? In my experience, CoC
enforcement works best when it comes from people who are leaders in
the community because they have (generally) earned the respect of the
community*. Having an "outsider" handle enforcement can lead to
resentment from the community, and can also mean that the person
(ideally people) making decisions lack context of the day-to-day
interactions in the project.

As much as I hate to ask anyone to do CoC enforcement work, because
it's unpleasant, I do think you and Richard are the two
best-positioned people to do it, perhaps with a third person to
provide coverage when one of you is off-grid for a while, etc.

* Yes, they can lose that respect, especially if they mishandle CoC enforcement.

-- 
Ben Cotton (he/him)
TZ=America/Indiana/Indianapolis


From fontana at sharpeleven.org  Sat Jul 26 04:37:51 2025
From: fontana at sharpeleven.org (Richard Fontana)
Date: Sat, 26 Jul 2025 00:37:51 -0400
Subject: =?UTF-8?Q?Re=3A_Code_of_Conduct=3A_we_need_one_=28=E2=80=A6_in_parallel_=2F_?=
 =?UTF-8?Q?in_addition_to_HBR=29?=
In-Reply-To: <CAJox115pyy7+bUyOK0PFtJtzTW4mJg7M6YQm=QP5HyQH986CSg@mail.gmail.com>
References: <aHBkMyN+D4PiowjL@ebb.org>
 <CAJox1157Q722B60e58=pUiLgnQfZMOzu9F-0sAeeCO9DzMYbcA@mail.gmail.com>
 <sGPThNigbP1vnSgQYaZZzE7eHL4QfUetH_Cbu8agKjwZMnispAT7jNp7plPRkMnK-UHN-79tpgZNSQHR5wZrMpIvLc_wCI4ONBzzbJl39zM=@protonmail.com>
 <52c54749-b54f-4dc8-a07a-e47b545f5081@riseup.net> <aILbXBWB16u8gtQP@ebb.org>
 <CAJox115pyy7+bUyOK0PFtJtzTW4mJg7M6YQm=QP5HyQH986CSg@mail.gmail.com>
Message-ID: <CAGT84B0N7Y5gTzqixHs-pWy+w8v8quj3yEa-s+-wbQ1G4-Lmag@mail.gmail.com>

On Fri, Jul 25, 2025 at 9:50 AM Ben Cotton <bcotton at funnelfiasco.com> wrote:

> On Thu, Jul 24, 2025 at 9:20 PM Bradley M. Kuhn <bkuhn at ebb.org> wrote:
> >
> > I otherwise like the Contributor Covenant.  I just don't think it's a
> good
> > idea for various reasons for Richard or me to enforce the CoC, and I note
> > the Contributor Covenant says that "Community Leaders" are responsible
> > for enforcement. 🤔
>
> Can you say more about your concerns here? In my experience, CoC
> enforcement works best when it comes from people who are leaders in
> the community because they have (generally) earned the respect of the
> community*. Having an "outsider" handle enforcement can lead to
> resentment from the community, and can also mean that the person
> (ideally people) making decisions lack context of the day-to-day
> interactions in the project.
>
> As much as I hate to ask anyone to do CoC enforcement work, because
> it's unpleasant, I do think you and Richard are the two
> best-positioned people to do it, perhaps with a third person to
> provide coverage when one of you is off-grid for a while, etc.
>

I'm not sure I agree with bkuhn on the idea of "a CoC for copyleft-next
that designates a specific
enforcement agent — who is not too closely tied to the project to avoid
conflict of interest but who cares enough about the project to be responsive
when problems start early", for the reason given by Ben above. The main
concern I have with me and bkuhn enforcing the CoC is that we need some
mechanism to subject ourselves to the CoC too, which ought to mean
enforcement (in that case) by someone else, though I think that someone
else should be drawn from the copyleft-next community, such as it is.

However, I'd be curious to learn about projects that have used an outside
CoC enforcement agent successfully.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.copyleft.org/pipermail/next/attachments/20250726/bec6d2a9/attachment.html>

From wolftune at riseup.net  Sun Jul 27 16:42:05 2025
From: wolftune at riseup.net (Aaron Wolf)
Date: Sun, 27 Jul 2025 09:42:05 -0700
Subject: =?UTF-8?Q?Re=3A_Code_of_Conduct=3A_we_need_one_=28=E2=80=A6_in_para?=
 =?UTF-8?Q?llel_/_in_addition_to_HBR=29?=
In-Reply-To: <CAGT84B0N7Y5gTzqixHs-pWy+w8v8quj3yEa-s+-wbQ1G4-Lmag@mail.gmail.com>
References: <aHBkMyN+D4PiowjL@ebb.org>
 <CAJox1157Q722B60e58=pUiLgnQfZMOzu9F-0sAeeCO9DzMYbcA@mail.gmail.com>
 <sGPThNigbP1vnSgQYaZZzE7eHL4QfUetH_Cbu8agKjwZMnispAT7jNp7plPRkMnK-UHN-79tpgZNSQHR5wZrMpIvLc_wCI4ONBzzbJl39zM=@protonmail.com>
 <52c54749-b54f-4dc8-a07a-e47b545f5081@riseup.net> <aILbXBWB16u8gtQP@ebb.org>
 <CAJox115pyy7+bUyOK0PFtJtzTW4mJg7M6YQm=QP5HyQH986CSg@mail.gmail.com>
 <CAGT84B0N7Y5gTzqixHs-pWy+w8v8quj3yEa-s+-wbQ1G4-Lmag@mail.gmail.com>
Message-ID: <a8c8b8cb-2725-4a9b-ac32-db130bc81b94@riseup.net>

I don't think a designated neutral enforcement-agent is necessary or 
sufficient.

I think the issue is quite simply that everyone who feels off-put about 
anything knows what to do (which is NOT ignore your feelings) sooner 
rather than later. And that has to include knowing how to privately ask 
for help or perspective. Also, everyone needs to know that if anyone 
else is put-off by something, the poster who led to the reaction will be 
contacted *privately* and be supported in figuring out healthy 
resolution that comes with presumption of good-will and aim to keep 
everyone in good standing.

In other words, concerned people need to be encouraged to take action 
*sooner* but to do so privately. And accused/implicated people need to 
trust that they won't have to publicly save-face or defend themselves 
and trust that everyone is focused on resolution and restoration rather 
than punishment.

And finally, there can still be the more generic stuff that says that of 
course there *is* a mechanism to simply limit or block people who cause 
problems and don't participate in good-faith with restorative process.

I don't think it matters super much about the CoC otherwise, Contributor 
Covenant is acceptable enough — as long as it doesn't look like it was 
just plopped on in order to check to CoC-task-box. I tend to think that 
using it does *risk* that impression, so there's *some* value in a more 
project-specific CoC.

The enforcement stuff just needs to be really clear, who to contact, 
what will happen, etc. And I think having an alternate outside person is 
*fine* if such a person is up for doing it (and okay, it could be me I 
suppose)… but it's not as important as just having an explicit clear process

Aaron

On 7/25/25 9:37, Richard Fontana wrote:
> On Fri, Jul 25, 2025 at 9:50 AM Ben Cotton <bcotton at funnelfiasco.com> 
> wrote:
>
>     On Thu, Jul 24, 2025 at 9:20 PM Bradley M. Kuhn <bkuhn at ebb.org> wrote:
>     >
>     > I otherwise like the Contributor Covenant.  I just don't think
>     it's a good
>     > idea for various reasons for Richard or me to enforce the CoC,
>     and I note
>     > the Contributor Covenant says that "Community Leaders" are
>     responsible
>     > for enforcement. 🤔
>
>     Can you say more about your concerns here? In my experience, CoC
>     enforcement works best when it comes from people who are leaders in
>     the community because they have (generally) earned the respect of the
>     community*. Having an "outsider" handle enforcement can lead to
>     resentment from the community, and can also mean that the person
>     (ideally people) making decisions lack context of the day-to-day
>     interactions in the project.
>
>     As much as I hate to ask anyone to do CoC enforcement work, because
>     it's unpleasant, I do think you and Richard are the two
>     best-positioned people to do it, perhaps with a third person to
>     provide coverage when one of you is off-grid for a while, etc.
>
>
> I'm not sure I agree with bkuhn on the idea of "a CoC for 
> copyleft-next that designates a specific
> enforcement agent — who is not too closely tied to the project to avoid
> conflict of interest but who cares enough about the project to be 
> responsive
> when problems start early", for the reason given by Ben above. The 
> main concern I have with me and bkuhn enforcing the CoC is that we 
> need some mechanism to subject ourselves to the CoC too, which ought 
> to mean enforcement (in that case) by someone else, though I think 
> that someone else should be drawn from the copyleft-next community, 
> such as it is.
>
> However, I'd be curious to learn about projects that have used an 
> outside CoC enforcement agent successfully.
>
> Richard
>
> _______________________________________________
> next mailing list
> next at lists.copyleft.org
> https://lists.copyleft.org/mailman/listinfo/next
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.copyleft.org/pipermail/next/attachments/20250727/a207c84b/attachment.html>

From bkuhn at ebb.org  Sun Aug 24 03:03:42 2025
From: bkuhn at ebb.org (Bradley M. Kuhn)
Date: Sat, 23 Aug 2025 20:03:42 -0700
Subject: Code of Conduct: we need =?utf-8?Q?one?= =?utf-8?B?ICjigKY=?= in
 parallel / in addition to HBR)
In-Reply-To: <CAGT84B0N7Y5gTzqixHs-pWy+w8v8quj3yEa-s+-wbQ1G4-Lmag@mail.gmail.com>
References: <aHBkMyN+D4PiowjL@ebb.org>
 <CAJox1157Q722B60e58=pUiLgnQfZMOzu9F-0sAeeCO9DzMYbcA@mail.gmail.com>
 <sGPThNigbP1vnSgQYaZZzE7eHL4QfUetH_Cbu8agKjwZMnispAT7jNp7plPRkMnK-UHN-79tpgZNSQHR5wZrMpIvLc_wCI4ONBzzbJl39zM=@protonmail.com>
 <52c54749-b54f-4dc8-a07a-e47b545f5081@riseup.net>
 <aILbXBWB16u8gtQP@ebb.org>
 <CAJox115pyy7+bUyOK0PFtJtzTW4mJg7M6YQm=QP5HyQH986CSg@mail.gmail.com>
 <CAGT84B0N7Y5gTzqixHs-pWy+w8v8quj3yEa-s+-wbQ1G4-Lmag@mail.gmail.com>
Message-ID: <aKqBDj6rs+Ic8Maw@ebb.org>

>> On Thu, Jul 24, 2025 bkuhn wrote:
>> > I otherwise like the Contributor Covenant.  I just don't think it's a
>> > good idea for various reasons for Richard or me to enforce the CoC, and
>> > I note the Contributor Covenant says that "Community Leaders" are
>> > responsible for enforcement. 🤔

Ben Cotton wrote:
>> Can you say more about your concerns here?

TL;DR is: Quis custodiet ipsos custodes?
in English: “Who watches the watchers themselves?”

which is what Richard were kinda getting at here:
> The main concern I have with me and bkuhn enforcing the CoC is that we need
> some mechanism to subject ourselves to the CoC too,


Ben Cotton wrote further:
>> In my experience, CoC enforcement works best when it comes from people who
>> are leaders in the community because they have (generally) earned the
>> respect of the community*. Having an "outsider" handle enforcement can
>> lead to resentment from the community, and can also mean that the person
>> (ideally people) making decisions lack context of the day-to-day
>> interactions in the project.

I think it depends somewhat on who the outsider is.  Some outsiders wouldn't
be good, others would be.

Ultimately, if there is a complaint against a community leader, then they
need to recuse themselves.  Also, too often, a CoC complaint *stems* from a
disagreement about policy that turned into an ugly and inappropriate
exchange.

It might well help, especially given that copyleft-next is *all* about policy
(and nothing else) that maybe we want to appoint a panel of people who are
familiar with this project but aren't actively participating at this time.

Ben noted further:
>> As much as I hate to ask anyone to do CoC enforcement work, because it's
>> unpleasant, I do think you and Richard are the two best-positioned people
>> to do it, perhaps with a third person to provide coverage when one of you
>> is off-grid for a while, etc.

Richard noted further:
> … [how can we find someone] who is not too closely tied to the project to
> avoid conflict of interest but who cares enough about the project to be
> responsive

I think given that Richard and I are very “well connected” in FOSS, I think
we can get a panel of three people together who *aren't* actively involved in
the project, whom we trust and know well, and who would be willing to do it
because they care about this project even though they don't participate from
day to day.

If it was a lot work (i.e., lots of CoC complaints) we're doing something
wrong so it shouldn't be a big job: so they'd be a Reserve Force ready to
DTRT if something comes up.

--
     -- bkuhn, noting: IANAL & TINLA
        Fediverse (via Mastodon): https://fedi.copyleft.org/@bkuhn


From a_removed_address at proton.me  Sun Aug 24 07:40:23 2025
From: a_removed_address at proton.me (Jubei)
Date: Sun, 24 Aug 2025 07:40:23 +0000
Subject: Taking Artists Into Consideration
Message-ID: <5UF-hXvfK9yNS-XKYl2TA-KrQK9NdR_QLaGgucinAVxoTctpn_Zen5xaWtxtR80XkgMihtrUQX0LN1uFmsL9cmkfIX0u0DEAoIa3QRwyr38=@proton.me>

As things are currently, the creators of free art can not guarantee that all derivatives of their works will remain free. Most copyleft licenses designed for art fall flat when applied to multimedia works, particularly entertainment software like video games. Take the SCP Foundation, for example. It is a popular collaborative writing project licensed under CC BY-SA. A lot of games have been made based on it. Can you guess how many of those games are open source? Not a lot, and that is because CC BY-SA has no source sharing clause. If your CC BY-SA licensed story is adapted into a game, you can only hope that the developer shares the source code.

Now if copyleft licenses designed for art can not protect all derivatives, what about ones designed for software? Surely then all adaptions will have to be free, right? Not quite. The strongest copyleft license for software currently is the AGPL stewarded by the FSF. According to the FSF, "non-functional data" does not need to be under a free license to be distributed with free software. They specifically cite game art when explaining this. Presumably the same is true in reverse. A game with art licensed under the AGPL does not need have free code. If this is the opinion the license stewards hold, it is doubtful that a broader interpretation of the copyleft scope would hold up in court.

However, even if the AGPL also applied to art linked to the software and vice versa, would that even be desirable? Imagine trying to share AGPL licensed art on social media only for it to be immediately deleted because the site owners do not want to make their site AGPL too. If you take the AGPL as it is currently written and apply this maximalist interpretation, it would be nearly impossible to share art licensed under it. Regardless of how you view it, no copyleft license that currently exists can fully protect free art in a practical way.

This is where copyleft-next comes in. I think this project has the potential to finally give free art creators a copyleft license that they can be entirely confident in. This does not mean I think that copyleft-next should stop being a software license. Rather, I think a license that is equally applicable to art and code is the key here. Before getting into specifics on how this would be technically feasible, let me lay down the goals.

1. A game whose plot, characters, etc. are derived from copyleft-next licensed literature needs to share its source code under the same license.
2. A game that includes copyleft-next licensed art needs to share its source code under the same license.
3. A game whose code is licensed under copyleft-next can only include artwork that is under a compatible license.
4. Art licensed under copyleft-next can be included with other types of software without triggering the copyleft clause.
5. Other types of software licensed under copyleft-next can include proprietary art without triggering the copyleft clause.

Assume that by game I mean any software designed more for artistic expression or entertainment than for a practical purpose. Visual novels and other types of creative software apply here. Media sharing websites would not be included in this scope, as they are more so distributors of art rather than extensions of it.

Please let me know what you all think of this proposal for copyleft-next functionality. Remember that the above points are just goals and not clauses. Figuring out what needs to be done to achieve those goals has yet to be seen. Over a decade ago, Bart Kelsey came up with an interesting solution, though it is not entirely applicable to this project. https://freegamer.blogspot.com/2011/12/why-we-need-better-copyleft-for-artists.html


From wolftune at riseup.net  Sun Aug 24 14:38:51 2025
From: wolftune at riseup.net (Aaron Wolf)
Date: Sun, 24 Aug 2025 07:38:51 -0700
Subject: Taking Artists Into Consideration
In-Reply-To: <5UF-hXvfK9yNS-XKYl2TA-KrQK9NdR_QLaGgucinAVxoTctpn_Zen5xaWtxtR80XkgMihtrUQX0LN1uFmsL9cmkfIX0u0DEAoIa3QRwyr38=@proton.me>
References: <5UF-hXvfK9yNS-XKYl2TA-KrQK9NdR_QLaGgucinAVxoTctpn_Zen5xaWtxtR80XkgMihtrUQX0LN1uFmsL9cmkfIX0u0DEAoIa3QRwyr38=@proton.me>
Message-ID: <19532468-1925-40c3-bffd-e8aa98639909@riseup.net>

I see several misunderstandings in this otherwise-correct assessment of 
the non-free status of many derivatives in practice.

"Ifyour CC BY-SA licensed story is adapted into a game, you can only 
hope that the developer shares the source code." Right! The game has no 
source-requirement for the use of the CC BY-SA licensed story. But it 
*is* required to have the whole derivative by CC BY-SA as long as the 
story-use does indeed implicate the original copyright. Are the games 
released under CC BY-SA? If not, then we're discussing copyright 
violation, and that makes license differences irrelevant. "According to 
the FSF, "non-functional data" does not need to be under a free license 
to be distributed with free software." That's not a *copyright* opinion 
from a legal perspective. That's a political/ethical opinion. The FSF is 
simply saying that it is OKAY with them and their mission/values if you 
publish a video game with AGPL for the source code and 
All-Rights-Reserved for the story and artwork. This position of theirs 
has zero implication for interpretation of AGPL. If someone publishes a 
game where the story and artwork *are* themselves licensed with AGPL as 
well as the source code, then all of it *is* under AGPL. AGPL *can* 
already protect art freedom, and FSF's opinion that art-need-not-be-free 
has no bearing on this. The fact that AGPL isn't widely used for art is 
incidental. There's not much precedent for the interpretation of what 
counts as "source" for AGPL art, but there's no doubt that the license 
still calls for it. Again, FSF has never stated an opinion that clauses 
within AGPL are non-applicable to art. Instead, the FSF position is 
simply "we think it's okay for art to not be free". For your proposals, 
I see mostly good points. It would be ideal for copyleft-next to remain 
one-way compatible with CC-BY-SA (like GPL/AGPL are). 
https://wiki.creativecommons.org/wiki/ShareAlike_compatibility:_GPLv3 
It's also ideal if copyleft-next can be broad enough in terms of what 
"source" means such that it does its best to make sure that art source, 
like code source, is the *preferred form for making changes* rather than 
some lesser source form. Overall, my point is that I don't think these 
are actual problems with the status quo. The current situation is simply 
that CC BY-SA does not require source availability and that licenses 
that do are not used for art often enough. But we also see license 
violation often, and no license can solve that problem.


Aaron

On 8/24/25 12:40, Jubei wrote:
> As things are currently, the creators of free art can not guarantee that all derivatives of their works will remain free. Most copyleft licenses designed for art fall flat when applied to multimedia works, particularly entertainment software like video games. Take the SCP Foundation, for example. It is a popular collaborative writing project licensed under CC BY-SA. A lot of games have been made based on it. Can you guess how many of those games are open source? Not a lot, and that is because CC BY-SA has no source sharing clause. If your CC BY-SA licensed story is adapted into a game, you can only hope that the developer shares the source code.
>
> Now if copyleft licenses designed for art can not protect all derivatives, what about ones designed for software? Surely then all adaptions will have to be free, right? Not quite. The strongest copyleft license for software currently is the AGPL stewarded by the FSF. According to the FSF, "non-functional data" does not need to be under a free license to be distributed with free software. They specifically cite game art when explaining this. Presumably the same is true in reverse. A game with art licensed under the AGPL does not need have free code. If this is the opinion the license stewards hold, it is doubtful that a broader interpretation of the copyleft scope would hold up in court.
>
> However, even if the AGPL also applied to art linked to the software and vice versa, would that even be desirable? Imagine trying to share AGPL licensed art on social media only for it to be immediately deleted because the site owners do not want to make their site AGPL too. If you take the AGPL as it is currently written and apply this maximalist interpretation, it would be nearly impossible to share art licensed under it. Regardless of how you view it, no copyleft license that currently exists can fully protect free art in a practical way.
>
> This is where copyleft-next comes in. I think this project has the potential to finally give free art creators a copyleft license that they can be entirely confident in. This does not mean I think that copyleft-next should stop being a software license. Rather, I think a license that is equally applicable to art and code is the key here. Before getting into specifics on how this would be technically feasible, let me lay down the goals.
>
> 1. A game whose plot, characters, etc. are derived from copyleft-next licensed literature needs to share its source code under the same license.
> 2. A game that includes copyleft-next licensed art needs to share its source code under the same license.
> 3. A game whose code is licensed under copyleft-next can only include artwork that is under a compatible license.
> 4. Art licensed under copyleft-next can be included with other types of software without triggering the copyleft clause.
> 5. Other types of software licensed under copyleft-next can include proprietary art without triggering the copyleft clause.
>
> Assume that by game I mean any software designed more for artistic expression or entertainment than for a practical purpose. Visual novels and other types of creative software apply here. Media sharing websites would not be included in this scope, as they are more so distributors of art rather than extensions of it.
>
> Please let me know what you all think of this proposal for copyleft-next functionality. Remember that the above points are just goals and not clauses. Figuring out what needs to be done to achieve those goals has yet to be seen. Over a decade ago, Bart Kelsey came up with an interesting solution, though it is not entirely applicable to this project.https://freegamer.blogspot.com/2011/12/why-we-need-better-copyleft-for-artists.html
> _______________________________________________
> next mailing list
> next at lists.copyleft.org
> https://lists.copyleft.org/mailman/listinfo/next
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.copyleft.org/pipermail/next/attachments/20250824/8c519e57/attachment.html>

From jason at bluehome.net  Sun Aug 24 14:55:44 2025
From: jason at bluehome.net (Jason Self)
Date: Sun, 24 Aug 2025 07:55:44 -0700
Subject: Taking Artists Into Consideration
In-Reply-To: <5UF-hXvfK9yNS-XKYl2TA-KrQK9NdR_QLaGgucinAVxoTctpn_Zen5xaWtxtR80XkgMihtrUQX0LN1uFmsL9cmkfIX0u0DEAoIa3QRwyr38=@proton.me>
References: <5UF-hXvfK9yNS-XKYl2TA-KrQK9NdR_QLaGgucinAVxoTctpn_Zen5xaWtxtR80XkgMihtrUQX0LN1uFmsL9cmkfIX0u0DEAoIa3QRwyr38=@proton.me>
Message-ID: <f1fec00e0e0352919360db9da5f21a01da1a1ce5.camel@bluehome.net>

There seems to be a number of things conflated.

> Take the SCP Foundation, for example. It is a popular collaborative
> writing project licensed under CC BY-SA. A lot of games have been
> made based on it. Can you guess how many of those games are open
> source? Not a lot, and that is because CC BY-SA has no source sharing
> clause.

This framing makes it sound like CC BY-SA is uniquely deficient, when
in reality the limitation is tied to copyright itself. While it's true
CC BY-SA doesn't have a source-sharing clause, the absence of SCP games
with source code isn't solely explained by that. A license can only
"bite" as far as copyright itself goes. For CC BY-SA to apply to the
game, the game software itself would need to be treated as a derivative
of the written material - and that’s a legally nuanced question.
Pinning the outcome on CC BY-SA's source code sharing required for CC
BY-SA not applying to the game oversimplifies the situation, and isn't
specific to CC BY-SA either.

> Now if copyleft licenses designed for art can not protect all
> derivatives, what about ones designed for software? Surely then all
> adaptions will have to be free, right? Not quite. The strongest
> copyleft license for software currently is the AGPL stewarded by the
> FSF. According to the FSF, "non-functional data" does not need to be
> under a free license to be distributed with free software. They
> specifically cite game art when explaining this. Presumably the same
> is true in reverse. A game with art licensed under the AGPL does not
> need have free code. If this is the opinion the license stewards
> hold, it is doubtful that a broader interpretation of the copyleft
> scope would hold up in court.

I think there's some conflation happening here. That statement comes
from the GNU Free System Distribution Guidelines (FSDG), which are
about what’s acceptable for inclusion in a fully free GNU/Linux
distribution. It's a policy matter, not a statement about how copyleft
licensing operates legally.

The FSDG's position that non-functional data (like game art) may not
need to be under a free license for the system as a whole to count as
"free" doesn’t mean that applying a strong copyleft license to that art
itself wouldn't trigger any obligations under copyleft. Copyright and
license enforcement is a separate question from FSF distribution
policy. Mixing the two leads to a misleading conclusion - the FSDG is
about what counts as "free enough" for a distro, not about what a
copyleft license can or can't require in court.

> However, even if the AGPL also applied to art linked to the software
> and vice versa, would that even be desirable?

But earlier, you lamented that CC BY-SA doesn't do this - that it
doesn’t pull in software derived from art under a copyleft obligation
and also didn't have a source code sharing clause. Then, when
considering a license that might actually do that (because the GPL
family of licenses would - at a minimum - inolve sharing the source
code of the art), you seem to suddenly pivot to why that scenario would
be undesirable. This feels inconsistent.

> Imagine trying to share AGPL licensed art on social media only for it
> to be immediately deleted because the site owners do not want to make
> their site AGPL too.

That strikes me as an overstatement. Simply posting a picture image
doesn't inherently mean that the entire site is now a derived work of
that image. I encourage you to read the GPL FAQ on that topic:
https://www.gnu.org/licenses/gpl-faq.html#MereAggregation

> 1. A game whose plot, characters, etc. are derived from copyleft-next
> licensed literature needs to share its source code under the same
> license.
> 2. A game that includes copyleft-next licensed art needs to share its
> source code under the same license.
> 3. A game whose code is licensed under copyleft-next can only include
> artwork that is under a compatible license.
> 4. Art licensed under copyleft-next can be included with other types
> of software without triggering the copyleft clause.
> 5. Other types of software licensed under copyleft-next can include
> proprietary art without triggering the copyleft clause.

Looking at those goals, #2 and #4 feel like they're in tension. In #2
you propose that if copyleft-next art is included in a game, the game's
source must be shared under the same license. But in #4 you say that
art licensed under copyleft-next can be included with other software
without triggering copyleft. That inconsistency makes it hard to see
what the actual principle is.

Even putting that aside, many of the goals you've listed could already
be achieved under existing licenses - at least to the extent copyright
law itself allows. For example, if a court considers the game software
to be a derivative of the story/art, then CC BY-SA or the (A)GPL
already impose copyleft obligations. If you want copyleft-next to reach
beyond those scenarios - to apply cases where copyright wouldn't
otherwise reach - then that would be an expansion of scope beyond
copyright's usual boundaries. If that's what you mean, it would be
useful to say so directly, because that's a much larger and more
controversial topic than just "current licenses aren't strong enough."


From me at aethrvmn.gr  Sun Aug 24 20:27:01 2025
From: me at aethrvmn.gr (Vasileios Valatsos)
Date: Sun, 24 Aug 2025 22:27:01 +0200
Subject: Taking Artists Into Consideration
In-Reply-To: <f1fec00e0e0352919360db9da5f21a01da1a1ce5.camel@bluehome.net>
References: <5UF-hXvfK9yNS-XKYl2TA-KrQK9NdR_QLaGgucinAVxoTctpn_Zen5xaWtxtR80XkgMihtrUQX0LN1uFmsL9cmkfIX0u0DEAoIa3QRwyr38=@proton.me>
 <f1fec00e0e0352919360db9da5f21a01da1a1ce5.camel@bluehome.net>
Message-ID: <a9b04f22-4921-48b6-b08d-47393d895a09@app.fastmail.com>

If I may interject, I think that the spirit of what OP is trying to say, and also based on the linked blog post at the end of OP's email, is that current "art" or "content" oriented copyleft licenses, so ShareAlike and FAL mainly, are weak copyleft in the sense that as long as you provide the modifications done to the original you are compliant with the license. So in their example, SCP Foundation lore is CC BY-SA, and if a game dev uses or modifies and then offers work based on SCP Foundation lore, they simply need to provide the modified lore under CC BY-SA. 

This contradicts how strong copyleft works, where if I have a project with GPLv3/AGPL code or libs, I must release all of the project under GPLv3/AGPL, even if the majority of the code is MIT for example.

Therefore, if I understood correctly, OP is asking for a "viral", strong copyleft license for art. In my opinion it should be a different license, maybe copyleft-art(?), if even possible/reasonable, because I think a single license trying to encompass every sort of digital object might be too broad.

> This framing makes it sound like CC BY-SA is uniquely deficient, when
> in reality the limitation is tied to copyright itself. While it's true
> CC BY-SA doesn't have a source-sharing clause, the absence of SCP games
> with source code isn't solely explained by that. A license can only
> "bite" as far as copyright itself goes. For CC BY-SA to apply to the
> game, the game software itself would need to be treated as a derivative
> of the written material - and that’s a legally nuanced question.
> Pinning the outcome on CC BY-SA's source code sharing required for CC
> BY-SA not applying to the game oversimplifies the situation, and isn't
> specific to CC BY-SA either.

LGPL and GPL with linking exception were created specifically to give a pass to linking. One could argue that using content in a downstream medium is a type of linking, like for example using an AGPL lib for a service, but I am not a lawyer so it is not for me to comment.

Intuitively it does feel like CC BY-SA and FAL are in the weaker side of copyleft though, and I have searched for stronger copyleft licenses for my own content.

- Vasileios Valatsos
_______________________________________________
> next mailing list
> next at lists.copyleft.org
> https://lists.copyleft.org/mailman/listinfo/next


From jason at bluehome.net  Mon Aug 25 23:32:48 2025
From: jason at bluehome.net (Jason Self)
Date: Mon, 25 Aug 2025 16:32:48 -0700
Subject: Taking Artists Into Consideration
In-Reply-To: <a9b04f22-4921-48b6-b08d-47393d895a09@app.fastmail.com>
References: <5UF-hXvfK9yNS-XKYl2TA-KrQK9NdR_QLaGgucinAVxoTctpn_Zen5xaWtxtR80XkgMihtrUQX0LN1uFmsL9cmkfIX0u0DEAoIa3QRwyr38=@proton.me>
 <f1fec00e0e0352919360db9da5f21a01da1a1ce5.camel@bluehome.net>
 <a9b04f22-4921-48b6-b08d-47393d895a09@app.fastmail.com>
Message-ID: <331bb83639f5b08835dcf8891dd84fc2f6e171ad.camel@bluehome.net>

We actually already have what's being described there - strong copyleft
licenses that can be applied to art. The GPL can be used on any
copyrightable work, not just code. So the issue isn't that such
licenses don't exist. The real question is whether a particular use -
like a game built from CC BY-SA licensed stories or art - legally
counts as a derivative work under copyright to trigger those strong
copyleft obligations in the first place.

If it does, then a strong copyleft license already works as suggested:
the whole derivative would have to be released under the same license.
If it doesn't, then no copyright-based license can stretch that far
without trying to go beyond what copyright itself would otherwise
require. That's why I raised that question at the very end of the email
as to if that is the intention. And if it is...

Imagine if the image viewing program Viewnior (from MATE) were
considered a derivative of the images it displays. It's not, obviously,
but it shows how overbroad things could become if one makes a license
that any program displaying the image must itself by licensed under the
same license as the image itself, and a game engine could be doing
nothing more than what Viewnior does in terms of displaying a
copyrighted image during game play, and otherwise be completely
unrelated, copyright-wise.

So the real point of tension isn't about whether strong copyleft
licenses for art exist (they do), but whether what OP is really
proposing is a license that pushes obligations further than copyright-
based licenses would typically require such that it's not possible to
open the image in Viewnior to view it anymore without it turning into
some sort of license violation. And if it's okay for Viewnior to do
nothing more than display the image on screen then, to be consistent,
it has to be okay for a game engine to do exactly the same.


From me at aethrvmn.gr  Thu Sep 18 17:13:06 2025
From: me at aethrvmn.gr (Vasileios Valatsos)
Date: Thu, 18 Sep 2025 19:13:06 +0200
Subject: =?UTF-8?Q?Re=3A_Code_of_Conduct=3A_we_need_one_=28=E2=80=A6_in_para?=
 =?UTF-8?Q?llel_/_in_addition_to_HBR=29?=
In-Reply-To: <aHBkMyN+D4PiowjL@ebb.org>
References: <aHBkMyN+D4PiowjL@ebb.org>
Message-ID: <179da842-4ef2-489a-95b9-eac9c0823523@aethrvmn.gr>

  >I'm curious if folks have a particular CoC template that they 
particularly
  >like and think would be good for copyleft-next?

  >I did some poking around and discussion with colleagues well-versed 
in this
  >area, and frankly there is no clear standard, and I don't think 
(other than
  >the HBR addendum) that we should write our own from scratch.

Why not the Ruby CoC? It's short enough, and in my opinion provides the 
proper guidelines:
----

This document provides community guidelines for a safe, respectful, 
productive, and collaborative place for any person who is willing to 
contribute to the Ruby community. It applies to all “collaborative 
space”, which is defined as community communications channels (such as 
mailing lists, submitted patches, commit comments, etc.).

      Participants will be tolerant of opposing views.

      Participants must ensure that their language and actions are free 
of personal attacks and disparaging personal remarks.

      When interpreting the words and actions of others, participants 
should always assume good intentions.

      Behaviour which can be reasonably considered harassment will not 
be tolerated.

----
As you said, there are many options to choose from, so why not the 
shortest/simplest?

-Vasileios Valatsos


From bkuhn at ebb.org  Wed Sep 24 20:24:54 2025
From: bkuhn at ebb.org (Bradley M. Kuhn)
Date: Wed, 24 Sep 2025 13:24:54 -0700
Subject: HBR Cure for Richard/bkuhn phone conversation today.
Message-ID: <87zfaj1tux.fsf@ebb.org>

Richard and I had a 1 hour phone call today.  Most of it was not about
copyleft-next, but some of it was, and here's the “HBR cure” for that:

  * We discussed that we both have had less time — given demands of our day
    jobs — to put into copyleft-next than we had wanted to when launched in
    July.  Both of us are going to work to clear some things from our
    schedules in the coming months, and are hoping to do a “bigger push” of
    work on copyleft-next during November and December.  We plan to talk
    again mid-October to look into that.

  * We discussed that, based on they types of things and and ideas that
    folks have been raising, that it might be best to redraft many sections
    from scratch rather than attempt to mold the text there into addressing
    some of the very interesting issues folks have been raising.  The text
    there is not sacrosanct, and indeed, treating license texts as a
    sacrosanct often leads to weird drafting histories and carry along
    baggage of verbiage that may simply not be needed.

  * We briefly discussed license compatibility, and pondered ways of making
    copyleft-next compatible with other copylefts while not causing it to
    simply “degrade” to that copyleft.
-- 
     -- bkuhn, noting: IANAL & TINLA
        Fediverse (via Mastodon): https://fedi.copyleft.org/@bkuhn