Re: FOSS APAS & FOSS-friendly ToS restrictions (was Re: Minutes of AI Assist Committee TUE 2022-06-22, 18:00-19:00 UTC)

[Joseph Turner]

The gist of my poorly phrased last message was that it might not be necessary to add a TOS (or an additional restriction to copyleft) to the Trainer if the Model couldn't be used to produce proprietary software. Now I realize that I missed the important point that, in order to stop people from using Model to make proprietary software from GPL'd input, the current GPL *might* not be sufficient (regardless of the Model's licensing/TOS).

Thank you for bringing the RTL exception, and the nuances it brings up with respect to this topic.

Joseph

P.S. Thank you for making the subject line more descriptive.

On June 29, 2022 3:11:09 PM PDT, "Bradley M. Kuhn" <bkuhn at sfconservancy.org> wrote:
>2022-06-22 committee meeting minutes noted:
>> > Some also noted we'd probably need to use terms of service to keep the thing
>> > FOSS if we wanted to enforce a moral requirement (as opposed to, say, having
>> > the copyleft license alone “take care of it”).  Using terms of service to
>> > mandate software freedom has not been used in past, and may be another type
>> > of activity that would dilute coalition between more and less strident
>> > activists.
>
>Just as a reminder: the Committee is debating lots of speculative ideas about
>what could be, or what we might want to do as activists.  So, when you read
>the minutes, keep in mind they aren't officially proposals — they're
>discussion and ideas; we're publishing the minutes for transparency and to
>spur discussion.
>
>I say that because …
>
>Joseph Turner wrote:
>> IIUC, the terms of service would be used to mandate that this new FOSS
>> Trainer be exclusively used on FOSS inputs to produce a FOSS Model. Is that
>> correct?
>
>… I don't know think anyone on the committee came to any conclusion on
>specifics of how a ToS would be used here, just a general sense that ToS has
>not been used before as a tool for software freedom, and the idea was floated
>that perhaps such can more easily “be done” with ToS when copyleft
>can't/shouldn't do those things.
>
>If we open that door (which, as you can note in the minutes, some on the
>committee immediately felt this runs immediately afoul of “fields of use” as
>stated in the OSD/DSFG), probably a lot of options are present, but the
>question would be whether they are ethical or not, and whether they violate
>some other principle of software rights.
>
>cf: the part in the minutes where we talked about whether “field of use” was
>a fundamental principle or not, at least when the field of use is “writing
>more proprietary software”.
>
>To add something to that we didn't discuss in committee: one might argue that
>copyleft itself is a “field of use” restriction since you cannot modify
>copyleft software *into* proprietary software, so your “field of use” is, in
>some sense, restricted.  I think it's historically and culturally significant
>that DFSG/OSD were both written well after copyleft was established to be
>clearly a reasonable way to promote and protect software freedom.  I posit
>that had DFSG/OSD been written *before* copyleft was invented, *many* would
>have argued that copyleft itself *is* a “field of use” restriction.  That's
>what leads me to wonder whether or not “no field of use” restriction is more
>“cargo cult” than it is a rigorously considered a priori principle of rights.
>Perhaps there *is* some software where that really ought to prohibit a given
>“field of use” … loosely defined.  For example, the GCC RTL Exception to GPL
>exists as a tactical move, not because it's morally wrong for a compiler to
>have a license that only allows it to compile code under a GPL-compatible
>license.  What if GCC were to remove the RTL Exception entirely tomorrow
>(which the GCC developers can do at any time for future code — after all, all
>GPLv3 Additional Permissions can be removed by anyone to return to pure
>GPLv3).  Would it be reasonable to say that GCC team had added a “field of
>use” restriction to GCC?  If not, why not? 🤔
>
>Anyway, that's just a thought experiment to explore on where the “field of
>use principle” comes from and to think about whether it really ought to be an
>absolute/a priori principle in the age of more advanced AI.
>
>Regardless, as I wrote in
>https://sfconservancy.org/blog/2022/mar/17/copyleft-ethical-source-putin-ukraine/
>, I do believe that holding together the strained coalition around the
>FSD/DFSG/OSD has value and we must take great care.  A ToS-based software
>freedom protecting solution could easily backfire in this regard, just as
>writing in other ethical requirements into (would-be) FOSS licenses does.
>
>> *If* the primary cost to produce a FOSS Model is compute time and not
>> developer time in creation and maintenance of the Trainer, then perhaps no
>> TOS would be necessary to prevent the creation of a proprietary Model with
>> the FOSS Trainer. IOW, if donations are given with the explicit goal of
>> creating a FOSS Model (and Trainer), and we create a good FOSS Model, then
>> perhaps the cost to create an alternative proprietary Model from the FOSS
>> Trainer would be prohibitively high.
>
>This logic doesn't seem to hold to me, because the cost is prohibitively high
>for hobbyist and charities, but not for-profit companies and their trade
>associations — all of whom are the key entities that either don't mind (or
>actually *want*) more proprietary software in the world.  I think your
>argument only works in a world where resources are distributed perfectly
>equally to all … and that world has never existed in human history AFAIK.
>--
>Bradley M. Kuhn - he/him
>Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
>========================================================================
>Become a Conservancy Sustainer today: https://sfconservancy.org/sustainer
>-- 
>ai-assist mailing list
>ai-assist at lists.copyleft.org
>https://lists.copyleft.org/mailman/listinfo/ai-assist
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.copyleft.org/pipermail/ai-assist/attachments/20220704/96af2abd/attachment.htm>