Hi folks,

While diverse issues persist, the world and the software ecosystem is
still proceeding
with the advancement of AI. As a particular type of software, AI is
quite different
from the paradigm of traditional software, since there are more
components involved
as an integral parts of the AI system. People gradually realize the Open
Source
Definition[3], derived from DFSG[4], could no longer cover AI software
very well.

To answer the question "what kind of AI is free software / open source",
there are
multiple relevant efforts in recent years. Six years ago we discussed
the same question[6],
and as a result, I drafted an unofficial document named ML-Policy[5]; In
the recent
one or two years, OSI started the drafting process of "Open Source AI Definition" (OSAID),
and its 1.0-RC2 version[1] is available for public review, and about to
be formally
released; FSF is working on a similar effort concurrently[2].

I think the upcoming of release of OSAID will make a big impact on the
open source
ecosystem. However, while OSAID starts from DFSG and the software
freedom definition,
it is very concerning to me. Here I'll only discuss the most pressing
issue -- data.

The current OSAID-1.0-RC2 only requires "data information", but not the "original
training data" to be available. That effectively allows "Open Source AI"
to hide
their original training datasets. A group of people expressed their
concerns and
disagreement about the draft on OSI's forum[7][8][9][10], emphasizing
the negative
impacts of allowing "Open Source AI" to hide their original training
datasets.

Allowing "Open Source AI" to hide their original training dataset is
nothing different
than setting up a dataset barrier protecting the monopoly. The "open
source community"
around such "Open Source AI" is only able to conduct further development
based on
such AI, but not able to inspect the process of how the original piece
of "Open
Source AI" is produced, and not able to improve the "Open Souce AI" itself. This leads to many implications including but not limited to security
and bias issues.
For instance, without being able to access the original training data of
an "Open
Source AI", once those "Open Source AI" starts to say harmful or toxic
things,
or starts to deliver advertisements, nobody other than the first party
is able
to diagnose and fix the bias issue or rip the advertisement off and
produce an
improved AI. In the sense of traditional open source software this looks ridiculous
because you can easily modify its source code, ripping off the
advertisement pop up
window, and re-compile it.

My mind remains mostly the same from 6 years ago. And after 5~6 years,
the most
important concept in ML-Policy remains to be ToxicCandy, which is
exactly AI released under
open source license with their training data hidden.

I felt OSI destines to draft something I disagree with some time ago.
And upon the
release of OSAID-1.0, it will make a huge, irreversible impact. I could
not convince
OSI to change their mind, but I do not want to see free software
communities being
impacted by the OSAID and start to compromise software freedom.

No data, no trust. No data, no security. No data, no freedom[11].

Maybe it is time for us to build a consensus on how we tell whether a
piece of
AI is DFSG-compliant or not, instead of waiting for ftp-masters to
interpret those
binary blobs case-by-case.

Do we need a GR to reach a consensus?

[1] https://opensource.org/ai/drafts/the-open-source-ai-definition-1-0-rc2
[2] https://www.fsf.org/news/fsf-is-working-on-freedom-in-machine-learning-applications
[3] https://opensource.org/osd
[4] https://www.debian.org/social_contract
[5] https://salsa.debian.org/deeplearning-team/ml-policy/-/blob/master/ML-Policy.rst
[6] https://lwn.net/Articles/760142/
[7] https://discuss.opensource.org/t/training-data-access/152
[8] https://discuss.opensource.org/t/list-of-unaddressed-issues-of-osaid-rc2/650 [9] https://discuss.opensource.org/t/what-does-preferred-form-really-mean-in-open-source/625
[10] https://discuss.opensource.org/t/the-open-source-ish-ai-definition-osaid/580 [11] The freedom to study, change, and improve the AI.

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

On Sat, Oct 26, 2024 at 10:41:12AM -0700, Mo Zhou wrote:

I drafted an unofficial document named ML-Policy[5]

[5]: https://salsa.debian.org/deeplearning-team/ml-policy/-/blob/master/ML-Policy.rst

[...]

Maybe it is time for us to build a consensus on how we tell whether a
piece of AI is DFSG-compliant or not, instead of waiting for
ftp-masters to interpret those binary blobs case-by-case.

Do we need a GR to reach a consensus?

A vote is not a good tool to build consensus (quite the contrary), but
it could be an effective decision-making tool.

Before getting in to that procedural question, though, do you (or
anyone) know what ftpmasters think of the ML-Policy? Because if, say,
they agree with it, it would be enough for them to adopt/endorse that
policy to turn it into the an official Debian policy on this matter.

(In case of doubt: mine is a real question, I have no idea what
fptmasters think about this matter. It just seems important to me to
find that out, before considering a GR that overlaps with ftpmasters'
delegated responsibilities.)

Cheers
--
Stefano Zacchiroli . zack@upsilon.cc . 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+JEz681OfH5Cj5NBJ5kFAmcdUF0ACgkQfH5Cj5NB J5kkRA//Zle5QNG0J9FhLhnS4rhUFSEEzGSWnBxAlk4VlaZRIZsmjaAnA9GQeZWN NMYZwSGgFiwgPgxCTqWb/41ByOunawkaDjIxYp1Nz327DlPCIavm2hqdicbYmj9e MTtpTwX9pP8WrBBqvDhEl29oT/lIZAr0YyJTi2wHIxTcQgRutfeNBQXmyoDlbLZw 2LL+PwIRKayQaaML95wmcOq/Fs5CPCqUzaCCM25ZAyvhI7z6MjO8xTccXu0ZYk2y 3LPpcgf3VAZYviNeetCifmqepriXZFrQwhBar3ayG9QVhf/5nleR/nFhAtHLsuwL f2yqhEVrgmTzw9xSZ2SYFDtC4nrVnW1DqDlw/5lfYdKJkicgCsiHxcqkFattwsgJ lUG4ZqOZR0QzA6LrrvPwfvKXKvlk6e8gPvWvpCkjOHyjna7XLSJQFBjcztJqsIpt s47hgbKdAsmLSRl8AG8qzKrfybhfJ2z72uwmwHGWQOChTzlA84t2pxjLxJLXz5M4 5aR/7L3SLc1pEBzPeKEyAw

Mo Zhou <lumin@debian.org> writes:

My mind remains mostly the same from 6 years ago. And after 5~6 years,
the most important concept in ML-Policy remains to be ToxicCandy,
which is exactly AI released under open source license with their
training data hidden.

Although I'm not involved with machine learning (aka "AI") in Debian, I
do feel pretty strongly that secret training data is wrong for software
in Debian main. So consider this a note of support.

While I agree with Stefano's later followup that GR's are not good tools
for building concensus, I'm not sure such policy decision is really in
the spirit of the FTP master delegation. I recognize that my skepticism
is influenced by the fact that I would consider following the proposed
"OSAID" model to be a substantial weakening of the DFSG.

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

On Sun, Oct 27, 2024 at 09:00:07AM -0300, David Bremner wrote:

While I agree with Stefano's later followup that GR's are not good tools
for building concensus, I'm not sure such policy decision is really in
the spirit of the FTP master delegation. I recognize that my skepticism
is influenced by the fact that I would consider following the proposed "OSAID" model to be a substantial weakening of the DFSG.

But who's saying that Debian will follow OSAID? Historically, it is OSI
that has followed Debian, not the other way around. And the only mention
of "open source" in our founding documents is to point out that the OSD
was based on the DFSG; everything else is about "free software". AFAICT
OSI decisions do not influence Debian policies in any way.

Re: GR, I'd be totally fine with one. (And I'd personally vote in favor
of a text that states that Debian-acceptable ML models should come with DFSG-compliant training datasets.) I just not want to use the GR tool as
a hammer against a delegated team if no override is needed.

I don't understand your argument that this decision is not in the realm
of the ftpmaster activities. How could it *not* be, given they are the
team deciding NEW queue acceptance, and that most notably they do so
based on licensing aspects?

Cheers
--
Stefano Zacchiroli . zack@upsilon.cc . 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+JEz681OfH5Cj5NBJ5kFAmceXPIACgkQfH5Cj5NB J5lcGA/6Avw7j8tixIhr0AabbJlLz3bvEMmw1UAfhtYJmMFZfbS3QuVg0mES1/Am UFkdPDinuRfa+KiypUoeDeiTpsstXe+FDUZihWydxzbAnw+7sZEakBNr+c5tBLG/ UCUumIHXj1J8u1pCm3kx2EQ6/a8rHz7TLR2LklEy/tnwljF3CMKRFSItJtfAHjXC csUC4IiiSCqaHUj4dYsi649Xdm1AOrZJhr/LSvin5syCseBjZnwYL7JDJvxdGqEC t1kOfSOv1bl2r+MdUeEqMAIzQnc/kcKexTtco69LAdGq2KDylWFoe3g2JND8eXhx yudaRzrFxWrxRmdzWcZcK8SZGXdlDme9TYBZg2ze8xJn/jfQev3PM6XA8LQUDKgM F03bCBgVSUWVO2+hckacAsGXM6p9v6c27MJD5VeI3fUMqGf0gsjZEraSkP+gmEkh 26tCg57/alefcu5/rlEgp4Za9PD+32fbv6FE2Vf3cIOuJJZVjaX1pdAEDgwt1Icx f8F6N2C4TAVfTKpdFBzAd3

Stefano Zacchiroli <zack@debian.org> writes:

I don't understand your argument that this decision is not in the realm
of the ftpmaster activities. How could it *not* be, given they are the
team deciding NEW queue acceptance, and that most notably they do so
based on licensing aspects?

I didn't really mean to trigger a governance debate, just express that I thought the decision at hand went beyond what I think of as ftp-master's mission.

Policy 2.2.1 says "Every package in main must comply with the DFSG.",
and then points to the ftp-master REJECT-FAQ as "the project’s current working interpretation of the DFSG." By "spirit of the delegation", I
meant "interpreting the DFSG". For me training-data-less models are
clearly incompatible with the DFSG, so I am uncomfortable with
potentially accepting them as "interpreting the DFSG".

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

Thanks Mo for the heads-up,

and I agree with what you wrote.

Also I find it very worrisome that the FSF and the OSI come with two definitions about AI software freedom that are radically different.

Until now, FSF-free and OSI-open definitions have kept a such a large
overlap in practice, that we can write on our hompeage that "Debian is
made of free and open source software", without anybody finding this
definition confusing. And as we also write "and will always be 100%
free", I wonder if this was a masterpiece of farseeing.

I worry that if there are two competing definitions, OSI's version will
become the refuge of those who deliberately want to leverage as many
obstacles as possible to the freedom of their users, while profiting
from calling themselves Open Source.

If the divide persists, I want Debian to chose the side of freedom. And
maybe the consequence will be that we stop calling ourselves open source because the OSI would be killing its brand. If the OSI cares about it,
maybe we can send them a message telling that?

Also, we can also call to the people and organisations who are currently
listed as endorsers to think again about the divide they are about to
support if the current OSI draft is accepted?

https://opensource.org/ai/endorsements

Cheers,

Charles

--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://fediscience.org/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy

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

On Mon, Oct 28, 2024 at 09:53:31PM +0200, Jonathan Carter wrote:

The companies [...] want to restrict what you can actually use it
for, and call it open source? And then OSI makes a definition that
seems carefully crafted to let these kind of licenses slip through?

The licensing terms for the Meta Llama models are indeed horrific, but I
don't understand your point here. In order to be OSAID compliant, Meta
will precisely have to change those licensing terms and make them DFSG-compliant. That would be a *good* thing for the world and would fix
the main thing you are upset about.

And Meta is not liking that idea. Meta is, right now, lobbying EU
regulators to convince them that what should count as "open source AI"
for the purposes of the EU AI Act is their (Meta's) version, rather than
OSAID.

I have personally fought (and lost) during the OSAID definition process
to make access to training data mandatory in the definition. So while
I'm certainly not against criticizing OSAID, we should do that for the
right reasons.

Cheers

PS To make Llama models OSAID-compliant Meta, in addition to (1)
changing the model license, will also have to: (2) provide "a listing
of all publicly available training data and where to obtain it", and
(3) release under DFSG-compatible terms their entire training
pipeline (currently unreleased). I don't think they will ever get
there. But if they do, these would also be good things for the world.
Not *as good* as having access to the entire training dataset, but
good nonetheless.

--
Stefano Zacchiroli . zack@upsilon.cc . 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+JEz681OfH5Cj5NBJ5kFAmcgwPUACgkQfH5Cj5NB J5kxRQ//RPrzPS6Q1x98FuI+Dyh0ZEWDWDUjagGYb54dxavdRFeotG6urf1tg5l1 t/EY/uPLLUTWKUuq8dj9E/olI5OUAUYihr8BnlChXgw80XExeQECCjdZzdwlEQOD kJtX+Icc5cxasWMWYfB/RjXeVJ7AR94YJspqXr4ZmZQ4uL4yENkKrZnuNAIcSJfc LDD61pCLmCZSevUAAfcOIzPYW5UBVb0uvXtOCLJmU/5RDFv6FDmNtfpNSTOS/rfK Mkv59ICJDPrReErqGziZbQOG28pHEyGkPa++38XkdQo1ubc6pQCHZUuJrUziJCUo vzaxOcdKro6Y2tuRIUinZt0GMFflBB8a4gu5yjOI2rC5JoFz4RHDLDM4OqwrwcgV wBPlLnabSPJR7F32I2JWmNU7Efn3HRzGVASM5I4r7ZtdGw7pNtQdJZgAta77xUWK +fQ8ZWo0kegxoEcELNHNJKpKQ9w2mRPcPdRRqcSv1mO0fwRJoc1WwID63cKI0uXK K0wlNz7brSpcUgs6FP5DQI

On 2024-10-29 17:45:20 +0200 (+0200), Jonathan Carter wrote:
[...]

What is the OSI's motivation for creating such an incredibly lax definition for open source AI? Meta is already calling their absolutely-not-open-source model Open Source and promoting it as such, without as much as a *peep* from the OSI condemning the abuse of the term. (although, while doing a quick search to make sure that's true, I found this link from OSI to an article that keeps insisting that LLama3 is open source: https://opensource.org/press-mentions/meta-inches-toward-open-source-ai-with-new-llama-3-1)

[...]

The earliest comment I'm aware of from them on that specific point
is this article (2023-07-20):

https://opensource.org/blog/metas-llama-2-license-is-not-open-source

Meta is confusing “open source” with “resources available to
some users under some conditions,” two very different things.
We’ve asked them to correct their misstatement.

--
Jeremy Stanley

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

iQKTBAABCgB9FiEEl65Jb8At7J/DU7LnSPmWEUNJWCkFAmchCJ9fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 QUU0OTZGQzAyREVDOUZDMzUzQjJFNzQ4Rjk5NjExNDM0OTU4MjkACgkQSPmWEUNJ WClftg//dOo/6B10AtdZiPHLsaqNo2u0++2epcti68oXIskVRWmZck4fa5/iYyoP p4uFVp56L8e6pts5YP9KgHgBdLUyZ+Vi+yMTgWi+imrwHF4UyUg86ixBOLm07EIa rNCSvoyZ3PIzsrRGgpiv2UCipcmq72Grkhy0ArYZjs5RAJQF5e0F3Kh83CbAmeS3 k7SiXThIc5Xm9HQNtZJjOsU+3i6HDUWHG4U76ow+MKtU6zLogpU4/UYodmn8ZsAg tP6PSHPqEYSuCk9Z6icp0qtD6jJQcBjJGWrs8yv3tRmhTRGpGLQGTQ10FhohKE6t Wy1aN775a4SjIzxegBSythyiDEStdxkiX0C3a+v7mJIrtq5WKVh2J3wZwU8ockYH uuhPhfGQ+xh4yp08+Fo0DbcYyWNqzeNX8oQw41JdkaosrDHfgLUVcMaJ0+cxPdkN qFm997daGbz8fiC/XkCg5G4/wVCzJfSOpnWHPoIyst/ucOWcIFVs/N7i1W/nKYy/ BwlT3dmi1CqYsN04yhGmnd+nFCED+nyK4QXJOU6IyET23QJ7nMLemmnaJ7NcSceo s9FYPVE8ulcF29rhCj70X+HX040rv/d7T9vUh7JzV3TcNMggPoOaQUGtjMe7kwbA nBX4vfJBcIYGJV8HrcwogVD2NlT5Ly+knFz1hTG2g6PR8r864So=
=8kBB
-----END PGP SIGNATURE-----

--- SoupGate-Win32

[ reordering quoted text ]

Hello Jonathan,

On Tue, Oct 29, 2024 at 05:45:20PM +0200, Jonathan Carter wrote:

On 2024/10/29 13:03, Stefano Zacchiroli wrote:

To make Llama models OSAID-compliant Meta [...] will also have to:
[...] (3) release under DFSG-compatible terms their entire training pipeline (currently unreleased).

Again, the OSAID doesn't particularly care about DFSG-compatible, so
not sure where point 3 comes in here, but if there's something obvious
I missed, I'm all ears.

"DFSG-compliant" was a Debian-slip of mine. I meant "OSD-compliant" (the standard OSD, not OSAID). Sorry about that, but the two definitions are
de facto equivalent for the purpose of our discussion here.

Now, about the code of the training pipeline, OSAID [1] has this to say:

Code: The complete source code used to train and run the system. The
Code shall represent the full specification of how the data was
processed and filtered, and how the training was done. Code shall be
made available under OSI-approved licenses.

Where "OSI-approved licenses" refers to [2] (sure, an explicit link or
mention would be better, but that is what that expression has always
meant in the context of OSD).

[1]: https://opensource.org/ai/open-source-ai-definition
[2]: https://opensource.org/licenses

In order to be OSAID compliant, Meta will precisely have to change
those licensing terms and make them DFSG-compliant. That would be a
*good* thing for the world and would fix the main thing you are
upset about.

Unfortunately that's not the case. Meta won't have to make Llama3 DFSG compliant in order to be OSAID compliant, since OSAID as not as robust as
the OSD.

That's not-not the case :-). Here is what OSAID says about model
parameters (highlight mine):

Parameters: The model parameters, such as weights or other
configuration settings. Parameters shall be made available under *OSI-approved terms*.

[...]

The Open Source AI Definition does not require a specific legal
mechanism for assuring that the model parameters are *freely available
to all*. They may be free by their nature or a license or other legal instrument may be required to ensure their freedom.

AFAIR, in the early days of the OSAID process, the requirements for the
weights were the same of the training code, i.e., under an "OSI-approved license". Then it was pointed out by lawyers and legal scholars that
there is not always an applicable *license* for a matrix of floats. They
might not be protectable by "intellectual property" at all (we don't
know yet), or be in the public domain, or any other number of weird
legal cases. Hence it was not appropriate to use the "OSI-approved
license" expression and OSI picked the alternative expression
"OSI-approved terms". But the intent is that, no matter what legal
regime applies to the weights, they should grant to users the
traditional 4 freedoms, which are defined earlier on in the OSAID.

I agree that it could be better written in the definition, or at least clarified in the FAQ. But there is no doubt whatsoever that a violation
of any OSD point on the licensing terms (or whatever else applies) of
the model weights would disqualify an AI system to be OSAID-compliant.

Hope this clarifies,
Cheers
--
Stefano Zacchiroli . zack@upsilon.cc . 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+JEz681OfH5Cj5NBJ5kFAmchGSYACgkQfH5Cj5NB J5nNvg/+P75U+2oKIeUGXIZ4Wn8y6T8R3V5M/kaFnijfM5Ho4g9+aYfu5jZPM3E+ Ep4M+t5LBNQGMk280x1r+6szq3kR2PTsu8wlZQmJvw97cY8uqwBO19zlyT0+vBUP Fjq1GUMsPu/1m3WKtOD6qbIiUNNLJ4iTZ93h3pBekyCD++gUjWCTznajDpQYNGtM +mY2xdfK6aplDDN9NDBTX61o4oKvJDPSNg+LRxZjOF+BlpdlTkZEhU5QgsVGGn51 oM7sxovMO4Fn1mGs0aU0EeQGG/gm89iCI4fvBJ0bu6JA5u1eog7NkgW6FwNbV8Pe 7oT1VmaIHezD0pJgePRHA+ngxl3LlpVEPix6uHu94KVZhvCrEm07W1KqmcSl42nQ VW4n1dl5FUa1/6wOjIaW7gRx+laCVVFZFZr7Xtw7bRGQVejjDYl3uj65dBt+dhNI 0wSx6AKz6lcVggn+DRxzomE9It+XRU9gAfd/WGcZJ20DAon/zv/IWTPvOJcDUDQw h2RgW8XxwgZzxrGZiz42c6

Hello Mo Zhou,

Mo Zhou dijo [Sat, Oct 26, 2024 at 10:41:12AM -0700]:

Hi folks,

While diverse issues persist, the world and the software ecosystem is still proceeding with the advancement of AI. As a particular type of software, AI is
quite different from the paradigm of traditional software, since there are more components involved as an integral parts of the AI system. People gradually realize the Open Source Definition[3], derived from DFSG[4], could no longer cover AI software very well.
(...)

I thank you wholeheartedly for bringing up this important topic, and for doing so this quickly (given the OSAID was just approved this past weekend).

I am still starting to read the answers to your mail. I believe starting a GR is
a step in the right direction, as it is our only way to (formally) query the opinion of all of the project's members and coming up with a strong declaration (of course, risking it to be... for, against, or many flavors of NotA 😉). I agree, of course, with Zack: A vote is not a good tool to build consensus. It is, however, the right tool to find the opinion of everybody who cares to voice it. And it is useful for speaking out a clear voice in the name of the whole project.

As for the scope of this decision coinciding with the ftpmasters' delegation, I agree it is a tough spot; it would have to be carefully worded (and, if possible, done so with the participation of ftpmasters, when we know their position on this issue).

But I believe this issue goes beyond just interpreting the OSAID regarding works
to be included in (or kept from being so) in Debian: while ftpmasters are the team deciding NEW acceptance, they could base their decision on a project's GR -- and a GR on this topic would also send a clear signal, even to works not yet submitted to Debian, on where our collective position is. This can steer people to license their datasets in ways better aligned with our understanding of what should be called Free Software (the DFSG) or, in any case, a document better accepted than the OSAID. (of course, I'm assuming the project would vote against
accepting the OSAID as valid for us -- I can be, naturally, surprised). Debian can be a referent to other Free Software projects on a position to take before our ecosystem is forever changed.

I'll do my best to follow this thread, as it is IMO fundamental to a very large application area we have to cater for.

- Gunnar.

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

iHUEABYIAB0WIQRgswk9lhCOXLlxQu/i9jtDU/RZiQUCZyHVawAKCRDi9jtDU/RZ icODAQD9R27nZ5a+myW5b3or4eNqqBLL3H0dxho5X3OLQF4hUgD/cfJ5tDU05i4N OvDKdDBhk5tUXbZ5UQz11esadyST7Qg=
=E38x
-----END PGP SIGNATURE-----

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

I'm planning to draft a GR for this, but that is only going to happen
after I get through some busy weeks.

On 11/4/24 02:22, Gerardo Ballabio wrote:

The OSAID 1.0 has now been released (with no modifications from the RC2).
Are we still going to take any actions or will we let this go?

Gerardo

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