• Draft: Proposal Alternative: Traning data is not source code

    From Aigars Mahinovs@21:1/5 to All on Tue May 6 21:00:01 2025
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA256

    ** Proposal Text **

    Choice 3: Training data for training of AI models is not to be
    considered "source code" in the context of DFSG. Instead the real
    source code in such a case is "Training Data Information" and the
    training data itself is an intermediate build artifact.

    AI models are compatible with DFSG only if they provide complete
    "Training Data Information". AI models whose reproduction from
    training data or from training data information is prohibitively
    expensive or is impractical are compatible with DFSG only if they
    provide ways to modify the AI model and create derivative works
    directly from the trained model.

    The meaning of "Data Information" is based on definitions and
    explanations from https://opensource.org/ai/open-source-ai-definition

    ** Rationale **

    The problem of collection and distribution of training data sets can
    be fully avoided by going another step back - seeing the "training
    data information" as the *actual* source code and the "training data"
    itself only being an intermediate build artifact. While this might not guarantee a fully reproducible rebuild of a model (even if that could
    be a possibility in some cases by identifying the exact version of the
    source data with use of hashes), it does a step better - it makes it
    possible (if enough resources are invested) to create a new version of
    the model with new and updated data. And it does not put the onus on
    Debian to redistribute this intermediate data.

    The definition maintains all guidelines of DFSG intact, but add two clarifications:

    1) Training data is not source code. There is a difference in
    copyright case law between source code and training data. It is really
    clear that a compiled binary is a derived work of the source code.
    However, there is no direct copyright relationship between training
    data and an AI model or its outputs. That is why it should be
    considered separately. The specifics may need to be adjusted based on
    future court orders. For example, it might be necessary to include
    protections against AI regurgitation.

    2) An AI model that is both prohibitively expensive to reproduce and
    is not easily modifiable does not (de-facto) satisfy the DFSG derived
    works requirement.
    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCAAdFiEEFmwrqIlWRDzdY39G+mQ7ph0ievsFAmgaWqoACgkQ+mQ7ph0i evtd0Q/9FrxQqHQI94GBNQF3uA+BbcghJYq4ZSLxGdrhS6g2IQpZ3Vq+dMJ9WKrr 5Wbmct2u2vt2Mk36WFnuTQDkEv6Cx9QN/lMUfMhcnBVnt8hL1XjRCbQGCMqiUcRz /QFAGbhjuxwvLWPDAKs3AEWbv0nPTmacEzMVA7s8629ZnRq9sV9fzcnP0jqBBQq0 lvaeDJBiKgpmM3b/ENeyKopmuRroCpqpG2OTghAsMSa7JHqfibgqamHmFkeDaOJt 5HveKmcm9AV2PwVP6UZHpyDciCCPFkZSpor1V+02qhEZBtHKNxGNgAYb/Edxnsxh 1W7MRQrwi8alPXeFKYLKNbD1ZP7WUDjvEXVJF1ucmir0599us+soPjN9VFNkr58F 5ugoubQN+rcz989tPbSnUst6wSPkDgRlkjtaF+uPn6LCIFuvCt3GH+OxJlmYG/K+ 1C9Ea60WMkn38b6Yn9gW7WYq09hnP6kpPeXfmD68Ac0YxWKoj18FPD3WDwTc5/S5 Fp+LpJ3vd1PpcYfacA0a+l7H0Vc5K4woRjzCU4KTVeYpBZSe4hRuOn3igFx6Z53E cUwjoZqnCLU7SoiDP9xXSBTF3UBM/iTcrW33gBE3ujKyv+p2z74eUvrn302ZFA9G JlDoRdmTHqLlNncEA04FdJ6+VBNY6GZKGXK5r0vDMnQ26MMHWdU=
    =imT+
    -----END PGP SIGNATURE-----


    --
    Best regards,
    Aigars Mahinovs mailto:[email protected]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefano Zacchiroli@21:1/5 to Aigars Mahinovs on Wed May 7 11:30:01 2025
    Thanks for this proposal, Aigars.

    How would you compare it with Sam's proposal? As I can see it the
    general idea behind both proposals is quite similar, even though the
    wording is different. The main content different I can see is that you
    focus on the notion of "data information", whereas Sam's proposal is
    more general and focus on the practicality of being able to make
    modifications.

    Assuming you both agree that the proposals go in the same general
    direction, is there a possibility of merging them into a single one?

    TIA,
    Cheers

    On Tue, May 06, 2025 at 08:55:45PM +0200, Aigars Mahinovs wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA256

    ** Proposal Text **

    Choice 3: Training data for training of AI models is not to be
    considered "source code" in the context of DFSG. Instead the real
    source code in such a case is "Training Data Information" and the
    training data itself is an intermediate build artifact.

    AI models are compatible with DFSG only if they provide complete
    "Training Data Information". AI models whose reproduction from
    training data or from training data information is prohibitively
    expensive or is impractical are compatible with DFSG only if they
    provide ways to modify the AI model and create derivative works
    directly from the trained model.

    The meaning of "Data Information" is based on definitions and
    explanations from https://opensource.org/ai/open-source-ai-definition

    ** Rationale **

    The problem of collection and distribution of training data sets can
    be fully avoided by going another step back - seeing the "training
    data information" as the *actual* source code and the "training data"
    itself only being an intermediate build artifact. While this might not guarantee a fully reproducible rebuild of a model (even if that could
    be a possibility in some cases by identifying the exact version of the
    source data with use of hashes), it does a step better - it makes it
    possible (if enough resources are invested) to create a new version of
    the model with new and updated data. And it does not put the onus on
    Debian to redistribute this intermediate data.

    The definition maintains all guidelines of DFSG intact, but add two clarifications:

    1) Training data is not source code. There is a difference in
    copyright case law between source code and training data. It is really
    clear that a compiled binary is a derived work of the source code.
    However, there is no direct copyright relationship between training
    data and an AI model or its outputs. That is why it should be
    considered separately. The specifics may need to be adjusted based on
    future court orders. For example, it might be necessary to include protections against AI regurgitation.

    2) An AI model that is both prohibitively expensive to reproduce and
    is not easily modifiable does not (de-facto) satisfy the DFSG derived
    works requirement.
    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCAAdFiEEFmwrqIlWRDzdY39G+mQ7ph0ievsFAmgaWqoACgkQ+mQ7ph0i evtd0Q/9FrxQqHQI94GBNQF3uA+BbcghJYq4ZSLxGdrhS6g2IQpZ3Vq+dMJ9WKrr 5Wbmct2u2vt2Mk36WFnuTQDkEv6Cx9QN/lMUfMhcnBVnt8hL1XjRCbQGCMqiUcRz /QFAGbhjuxwvLWPDAKs3AEWbv0nPTmacEzMVA7s8629ZnRq9sV9fzcnP0jqBBQq0 lvaeDJBiKgpmM3b/ENeyKopmuRroCpqpG2OTghAsMSa7JHqfibgqamHmFkeDaOJt 5HveKmcm9AV2PwVP6UZHpyDciCCPFkZSpor1V+02qhEZBtHKNxGNgAYb/Edxnsxh 1W7MRQrwi8alPXeFKYLKNbD1ZP7WUDjvEXVJF1ucmir0599us+soPjN9VFNkr58F 5ugoubQN+rcz989tPbSnUst6wSPkDgRlkjtaF+uPn6LCIFuvCt3GH+OxJlmYG/K+ 1C9Ea60WMkn38b6Yn9gW7WYq09hnP6kpPeXfmD68Ac0YxWKoj18FPD3WDwTc5/S5 Fp+LpJ3vd1PpcYfacA0a+l7H0Vc5K4woRjzCU4KTVeYpBZSe4hRuOn3igFx6Z53E cUwjoZqnCLU7SoiDP9xXSBTF3UBM/iTcrW33gBE3ujKyv+p2z74eUvrn302ZFA9G JlDoRdmTHqLlNncEA04FdJ6+VBNY6GZKGXK5r0vDMnQ26MMHWdU=
    =imT+
    -----END PGP SIGNATURE-----


    --
    Best regards,
    Aigars Mahinovs mailto:[email protected]


    --
    Stefano Zacchiroli . [email protected] . https://upsilon.cc/zack _. ^ ._
    Full professor of Computer Science o o o \/|V|\/ Télécom Paris, Polytechnic Institute of Paris o o o </> <\> Co-founder & CSO Software Heritage o o o o /\|^|/\ Mastodon: https://mastodon.xyz/@zacchiro '" V "'

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEE8ZooXsFA+JEz681OfH5Cj5NBJ5kFAmgbJ5sACgkQfH5Cj5NB J5l1QQ//YEElRzicozxiQqsN744mJu6oY2r8RwHq3JfAQfDP4VGrL5ta0pmwCxNX FduNt78q4hmODEGmiOI+sniZuVZMpt6qP0lAhaY283RqfiNf+pRL5HAjvTdN3gEw jsPxsY9fH5nK2xHJdFxDF+WQTLIowR1/ZjZUff49kBEOBHhHAWHmgQ3Dx9bKu+k9 d5RBk/kLMHyv91HoTxcfl4uM5+O/EoglF0JkeBZNa0VbNzcVs4tErSqlKlX7lA0I +ZI9QRZiMKc9PEqeuURgbTB+pAtKzpnnw40yNA6hWeIW6GhAgn+y5Dz1uyKS5bJK TAwl6x0RFPMTs+ZIM+pVP/cvjtryw4bytGP/f66S5TRkYud018+y4o7PuaSHgTny LFxiOxdnL2ii0i0KVU3EHYB+nB4h9crLU8smU7ahenVTNvDWtgc02TYyqpWAupLL de2mslzSPuwgnIDVetiVIk/+ErFII1VfdJoezcVDEGKhKlXXW6bjXaj0Zty/nuQM 4aoQ5cQX4+VO2J8DobVacy
  • From Sam Hartman@21:1/5 to All on Wed May 7 16:00:01 2025
    "Aigars" == Aigars Mahinovs <[email protected]> writes:

    Aigars> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

    Aigars> ** Proposal Text **

    Aigars> Choice 3: Training data for training of AI models is not to
    Aigars> be considered "source code" in the context of DFSG. Instead
    Aigars> the real source code in such a case is "Training Data
    Aigars> Information" and the training data itself is an intermediate
    Aigars> build artifact.

    Aigars> AI models are compatible with DFSG only if they provide
    Aigars> complete "Training Data Information". AI models whose
    Aigars> reproduction from training data or from training data
    Aigars> information is prohibitively expensive or is impractical are
    Aigars> compatible with DFSG only if they provide ways to modify the
    Aigars> AI model and create derivative works directly from the
    Aigars> trained model.

    Aigars> The meaning of "Data Information" is based on definitions
    Aigars> and explanations from
    Aigars> https://opensource.org/ai/open-source-ai-definition

    Seconded/sponsored.
    I think we're tight enough into the end of discussion period deadline
    that you should make this a formal proposal immediately and I am happy
    for my sponsorship to apply as soon as that happens.

    -----BEGIN PGP SIGNATURE-----

    iHUEARYKAB0WIQSj2jRwbAdKzGY/4uAsbEw8qDeGdAUCaBtl0wAKCRAsbEw8qDeG dAhFAQCCjladMN6gB9/QIA0ctZWbbQjh2h8ogAzd2Z0UmNuFiQEAlbAt2tBRkhRm j4BrZlM9jznbisVxkt507n1bCSwZBwY=
    =nT44
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Aigars Mahinovs@21:1/5 to Sam Hartman on Wed May 7 16:40:02 2025
    @Debian Project Secretary
    Please consider the proposal as submitted and signed to be the
    official proposal.
    The "Draft" part of the subject was in error. And the subject is not
    actually GPG signed anyway :)

    On Wed, 7 May 2025 at 15:53, Sam Hartman <[email protected]> wrote:

    "Aigars" == Aigars Mahinovs <[email protected]> writes:

    Aigars> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

    Aigars> ** Proposal Text **

    Aigars> Choice 3: Training data for training of AI models is not to
    Aigars> be considered "source code" in the context of DFSG. Instead
    Aigars> the real source code in such a case is "Training Data
    Aigars> Information" and the training data itself is an intermediate
    Aigars> build artifact.

    Aigars> AI models are compatible with DFSG only if they provide
    Aigars> complete "Training Data Information". AI models whose
    Aigars> reproduction from training data or from training data
    Aigars> information is prohibitively expensive or is impractical are
    Aigars> compatible with DFSG only if they provide ways to modify the
    Aigars> AI model and create derivative works directly from the
    Aigars> trained model.

    Aigars> The meaning of "Data Information" is based on definitions
    Aigars> and explanations from
    Aigars> https://opensource.org/ai/open-source-ai-definition

    Seconded/sponsored.
    I think we're tight enough into the end of discussion period deadline
    that you should make this a formal proposal immediately and I am happy
    for my sponsorship to apply as soon as that happens.



    --
    Best regards,
    Aigars Mahinovs mailto:[email protected]
    #--------------------------------------------------------------#
    | .''`. Debian GNU/Linux (http://www.debian.org) |
    | : :' : Latvian Open Source Assoc. (http://www.laka.lv) |
    | `. `' Software Engineer, BMW |
    | `- |
    #--------------------------------------------------------------#

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sam Hartman@21:1/5 to All on Wed May 7 16:30:01 2025
    "Stefano" == Stefano Zacchiroli <[email protected]> writes:

    Stefano> Thanks for this proposal, Aigars. How would you compare it
    Stefano> with Sam's proposal? As I can see it the general idea
    Stefano> behind both proposals is quite similar, even though the
    Stefano> wording is different. The main content different I can see
    Stefano> is that you focus on the notion of "data information",
    Stefano> whereas Sam's proposal is more general and focus on the
    Stefano> practicality of being able to make modifications.

    I think Aigars proposal handles the case of models where the training
    data cannot be distributed better than mine. (spam messages and ham
    messages for a spam classifier, creative commons works that do not allow modification for an LLM).
    I think my proposal allows people to be more sloppy so long as practical modification is possible. One of my concerns about the OSI AI
    definition is that the requirements around training information sound
    like a minimum quality bar for free models.
    In my experience we have not required free software to be high quality
    software to be good.
    I wouldn't generally say that software is non-free because the
    documentation of its build scripts is buggy and I cannot get them to
    run.
    I appreciate that the SFC has held people to fairly high standards for documenting their build systems as part of GPL enforcement actions, but
    I would argue that if the people had tried to follow the GPL in the
    first place, this level of rigor would have been inconsistent with
    requirements for freedom.
    Obviously it would have been desirable, but I don't like it when other
    things get mixed in with freedom.

    I think my proposal should be fixed to handle the case where upstream distributes training information because they cannot distribute training
    data even if they have it.
    One possibility would be to remove the last sentence from my proposal
    and assume ftpmaster will judge appropriately when upstreams are clearly
    acting in bad faith.

    Right now though, I don't see enough support for either my proposal or Aigars's proposal to move forward.
    I am quite disappointed by that, because I think the current ballot
    option undermines part of the core of what software freedom is to me.

    To me, software freedom is about an achievable set of standards we
    commit to in order to empower our users.
    Software freedom may be a sacrifice in terms of not being able to use
    some convenient market options.
    But it's never before been a sacrifice about potential. Russ's comment
    that he doesn't think a Bayesian classifier can be free software hit me hard--my immediate reaction was "If that's true, then software freedom is wrong."

    Users might want a Bayesian classifier--I do enough that I've trained
    one. Software in main like a mail reader or a mail system might well
    want to include a classifier.
    Saying that even if someone is as dedicated to freedom as they can be,
    they can never live up to our standards and include that reasonable functionality in Debian main makes me think we have lost sight of our
    users.

    I appreciate that if you take a position less strong that Russ you could
    ship a crappy Bayesian classifier trained only on DFSG-licensed spam and
    ham messages.
    I think it's clear that such a classifier would function significantly
    less effectively than other classifiers.

    In the past, we have said that specific software is not free because the copyright holder is unwilling (but able) to make the necessary grants.
    Or perhaps the copyright holder did a poor job of tracking their
    licensing and is unable to document what the license is.
    But none of that has restricted the type of software that can be free.

    In this discussion, I have been convinced that training data for some
    of the models we might want will never be licensed under a DFSG-free
    license. This is in part because the copyright holder of the training
    data is often not the person training a model. In many cases (spam,
    virus detection, etc), the interests of the copyright holder in the
    training data are not aligned with the interest of those training the
    model.
    Yet in the same discussion, I have been convinced that it is much more
    likely such training is fair use under copyright law.
    I do not think there is consensus in our community on the ethics of
    training on news articles or books even if it is legally fair use.
    For me at least I have no ethical problem using spam and ham messages to
    train a classifier.

    I am sad that it looks like there is not even support to put an option
    on the ballot that would empower our users to have a spam classifier in
    main.

    (For what it's worth, I'd be totally fine moving model data to a new
    archive section (or expanding the definition of contrib) that did not
    have the negative connotations of non-free.)

    -----BEGIN PGP SIGNATURE-----

    iHUEARYKAB0WIQSj2jRwbAdKzGY/4uAsbEw8qDeGdAUCaBtsOAAKCRAsbEw8qDeG dDQxAQD2XiZ7Dq00ZTgepXfWSoM4ApA9MU9olTrD4RyKlyr5ogEAr8zdFlPSeezT 5j02icH70a5xl6atT/27jtjE/Q6qoQ8=
    =eFku
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Clint Adams@21:1/5 to Sam Hartman on Wed May 7 17:30:01 2025
    On Wed, May 07, 2025 at 08:20:40AM -0600, Sam Hartman wrote:
    I am sad that it looks like there is not even support to put an option
    on the ballot that would empower our users to have a spam classifier in
    main.

    I think there are pros and cons to having a spam classifier trained
    on unincluded data in main, whether or not it's non-free data. I
    also think that voting on any of this is premature, and if a vote is
    called anytime soon, I will be voting FD above all other options.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefano Zacchiroli@21:1/5 to Sam Hartman on Thu May 8 16:50:01 2025
    On Wed, May 07, 2025 at 08:20:40AM -0600, Sam Hartman wrote:
    Right now though, I don't see enough support for either my proposal or Aigars's proposal to move forward. I am quite disappointed by that,
    because I think the current ballot option undermines part of the core
    of what software freedom is to me.

    I think there might be support for at least one of those options, and
    that people are just not paying attention very much to this discussion
    right now, either because they are tired or because they are confused
    about the timeline (I certainly am myself!).

    Either way, having a single option would certainly be better than having
    two, in terms of reaching the needed quorum for an alternative option to
    be on the ballot. (Assuming you two are fine with "merging" the
    proposals, of course.)

    Cheers
    --
    Stefano Zacchiroli . [email protected] . https://upsilon.cc/zack _. ^ ._
    Full professor of Computer Science o o o \/|V|\/ Télécom Paris, Polytechnic Institute of Paris o o o </> <\> Co-founder & CSO Software Heritage o o o o /\|^|/\ Mastodon: https://mastodon.xyz/@zacchiro '" V "'

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEE8ZooXsFA+JEz681OfH5Cj5NBJ5kFAmgcwmEACgkQfH5Cj5NB J5mpAw//TVWTH1+3DigMNC9+OY52ArVYoV8wD66wr0K70fFLkn/+MGolUqYsP5s1 GEpiSE1Hkq4QTKaFQNnWyVXmpRNhc9mgeZPVzFGITvpjiR9pzCR0N4bNF85Sh6GV Rq/Mb491SDvucC+azoQiGCNHKFgPwjuKAtA8B7SPXSnpOa+DN6wf9dTMKJ/xi9L7 areNdkBWkNyb27bcke10gBsIEPTVsTZSt9UuNWja24+G4Du4SoTOOeUKaGShZM85 Pz497wSfl0k3WE4V6bQ5L629MBy+zLqEiDH9CmnTCNdsoF4Mr8gvRaMxmPsJl8AZ 0vi5aPYQGhOmHDtjVpLIrjCIRjoBIw9j05S7E9lA3o6IxPc6+5U+dXI2Bc23f7Ly qVZ8c8YlCWrf6g4Af/KsdATnknjm0Jqw+BkzIQDhtZ5MpPcy1+MxxW9M+Ypjc9EK ZpwniLJHjb0/+qXlpQp3tigw3Pi3/CHLYnsVBn8GuqDv+ysXoGqF7pxRi7HATVjO xhafeNLrue+cW56w7Q6Mvr
  • From Sam Hartman@21:1/5 to All on Thu May 8 18:00:01 2025
    "Stefano" == Stefano Zacchiroli <[email protected]> writes:


    Stefano> Either way, having a single option would certainly be
    Stefano> better than having two, in terms of reaching the needed
    Stefano> quorum for an alternative option to be on the
    Stefano> ballot. (Assuming you two are fine with "merging" the
    Stefano> proposals, of course.)

    I don't see this at all.
    I don't see anyone stepping forward and saying they would sponsor a
    merged proposal but not one of the existing proposals.
    I've sponsored Aigars's proposal. I don't think he likes my option
    enough to sponsor it.
    I would encourage you to sponsor his proposal if you have not done so.

    I think our voting system deals well with ballot options, so I've never
    bought into the desire to minimize ballot options.
    I'm absolutely happy to work with Aigars to minimize differences between
    our proposals and to highlight those differences, not out of a desire to
    get a single merged proposal, but out of a desire to be clear what we
    are voting for.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kurt Roeckx@21:1/5 to Aigars Mahinovs on Tue May 13 23:30:01 2025
    On Wed, May 07, 2025 at 04:39:27PM +0200, Aigars Mahinovs wrote:
    @Debian Project Secretary
    Please consider the proposal as submitted and signed to be the
    official proposal.
    The "Draft" part of the subject was in error. And the subject is not
    actually GPG signed anyway :)

    But I also got a bad signature on that mail.


    Kurt

    On Wed, 7 May 2025 at 15:53, Sam Hartman <[email protected]> wrote:

    "Aigars" == Aigars Mahinovs <[email protected]> writes:

    Aigars> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

    Aigars> ** Proposal Text **

    Aigars> Choice 3: Training data for training of AI models is not to
    Aigars> be considered "source code" in the context of DFSG. Instead
    Aigars> the real source code in such a case is "Training Data
    Aigars> Information" and the training data itself is an intermediate
    Aigars> build artifact.

    Aigars> AI models are compatible with DFSG only if they provide
    Aigars> complete "Training Data Information". AI models whose
    Aigars> reproduction from training data or from training data
    Aigars> information is prohibitively expensive or is impractical are
    Aigars> compatible with DFSG only if they provide ways to modify the
    Aigars> AI model and create derivative works directly from the
    Aigars> trained model.

    Aigars> The meaning of "Data Information" is based on definitions
    Aigars> and explanations from
    Aigars> https://opensource.org/ai/open-source-ai-definition

    Seconded/sponsored.
    I think we're tight enough into the end of discussion period deadline
    that you should make this a formal proposal immediately and I am happy
    for my sponsorship to apply as soon as that happens.



    --
    Best regards,
    Aigars Mahinovs mailto:[email protected]
    #--------------------------------------------------------------#
    | .''`. Debian GNU/Linux (http://www.debian.org) |
    | : :' : Latvian Open Source Assoc. (http://www.laka.lv) |
    | `. `' Software Engineer, BMW |
    | `- |
    #--------------------------------------------------------------#


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonathan Dowland@21:1/5 to Kurt Roeckx on Thu May 15 11:00:01 2025
    On Tue May 13, 2025 at 10:29 PM BST, Kurt Roeckx wrote:
    But I also got a bad signature on that mail.

    With the "main" proposal temporarily withdrawn, and with this alternate
    having only one sponsor and no valid PGP signature, I take it the
    alternative is not going forward at this time either?

    --
    Please do not CC me for listmail.

    👱🏻 Jonathan Dowland
    [email protected]
    🔗 https://jmtd.net

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)