Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #13630 > unrolled thread

Concerns regarding the "Open Source AI Definition" 1.0-RC2

Back to article view | Back to linux.debian.project

Contents

  Concerns regarding the "Open Source AI Definition" 1.0-RC2 Mo Zhou <lumin@debian.org> - 2024-10-26 20:10 +0200
    Re: Concerns regarding the "Open Source AI Definition" 1.0-RC2 Stefano Zacchiroli <zack@debian.org> - 2024-10-26 22:30 +0200
    Re: Concerns regarding the "Open Source AI Definition" 1.0-RC2 David Bremner <david@tethera.net> - 2024-10-27 14:00 +0100
      Re: Concerns regarding the "Open Source AI Definition" 1.0-RC2 Stefano Zacchiroli <zack@debian.org> - 2024-10-27 16:50 +0100
        Re: Concerns regarding the "Open Source AI Definition" 1.0-RC2 David Bremner <david@tethera.net> - 2024-10-27 17:50 +0100
    Re: Concerns regarding the "Open Source AI Definition" 1.0-RC2 Charles Plessy <plessy@debian.org> - 2024-10-28 13:20 +0100
    Re: Concerns regarding the "Open Source AI Definition" 1.0-RC2 Stefano Zacchiroli <zack@debian.org> - 2024-10-29 12:20 +0100
      Re: Concerns regarding the "Open Source AI Definition" 1.0-RC2 Jeremy Stanley <fungi@yuggoth.org> - 2024-10-29 17:20 +0100
      Re: Concerns regarding the "Open Source AI Definition" 1.0-RC2 Stefano Zacchiroli <zack@debian.org> - 2024-10-29 18:30 +0100
      Re: Concerns regarding the "Open Source AI Definition" 1.0-RC2 Gunnar Wolf <gwolf@debian.org> - 2024-10-30 08:50 +0100
    Re: Concerns regarding the "Open Source AI Definition" 1.0-RC2 Gunnar Wolf <gwolf@debian.org> - 2024-10-30 08:50 +0100

#13630 — Concerns regarding the "Open Source AI Definition" 1.0-RC2

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.

[toc] | [next] | [standalone]

#13631

[Multipart message — attachments visible in raw view] — view raw

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 "'

[toc] | [prev] | [next] | [standalone]

#13632

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. 

[toc] | [prev] | [next] | [standalone]

#13633

[Multipart message — attachments visible in raw view] — view raw

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 "'

[toc] | [prev] | [next] | [standalone]

#13634

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".

[toc] | [prev] | [next] | [standalone]

#13636

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

[toc] | [prev] | [next] | [standalone]

#13637

[Multipart message — attachments visible in raw view] — view raw

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 "'

[toc] | [prev] | [next] | [standalone]

#13638

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#13639

[Multipart message — attachments visible in raw view] — view raw

[ 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 "'

[toc] | [prev] | [next] | [standalone]

#13643

[Multipart message — attachments visible in raw view] — view raw

Stefano Zacchiroli dijo [Tue, Oct 29, 2024 at 07:03:18AM -0400]:
> (...)
> 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.

Thank you, Stefano, for being involved in this process. I clearly recognize you
stand for the right causes and courses of action... and the weight of the
(want-to-be-closed) industry is just too much.

You are somewhat right with the PS you direct at Jonathan. However, having a
"not good, but oh-not-all-that-bad" model has not been a very successful
strategy in the past. I'm thinking about all the software that surfaced ~20-25
years ago, during the years of the license proliferation boom, licensed under
licenses that seemed to be free but were not really (i.e. the Micosoft Shared
Source Initiative).

(I cannot refrain from sharing again my Confusing Public License, from 2007:
https://gwolf.org/2007/04/version-3-14-of-the-copl-released.html )

[toc] | [prev] | [next] | [standalone]

#13641

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.project

csiph-web