Should we endorse the Open Source AI Definition?
Robie Basak
robie.basak at ubuntu.com
Thu Feb 13 02:43:29 UTC 2025
Hi Merlijn,
Thank you for raising this topic! I agree that it's something that we
should be thinking about.
On Fri, Jan 31, 2025 at 01:28:03PM +0100, Merlijn Sebrechts wrote:
> *What are we endorsing specifically?*
>
> Our endorsement means two things.
>
> - Firstly, we are endorsing that the current definition is a good step
> in the right direction.
> - Secondly, we are endorsing that the OSI has the authority to create
> this definition and that we have faith in their process to create and
> improve this definition.
I appreciate you answering this question directly, since it's the first
question I had: what would it mean for Ubuntu to endorse this?
There's one important aspect that I think needs to be added to what
you've defined here: whatever Ubuntu adopts here must also be taken to
define what Ubuntu promises about what it itself ships.
For example: we have a definition of what Free Software is, and will not
ship anything in the Ubuntu main or universe archive components that
does not meet that definition. Snaps that we ship by default must also
comply. What we ship in restricted and multiverse is similarly clearly
defined.
If we adopt some definition for what is acceptable to us with respect to
AI models, I think it follows (or does it?) that we must commit not to
ship AI components that do not meet that definition in our main and
universe archive components. And we should probably extend that to any
snaps that Ubuntu ships by default, too.
We could choose to use your definition of endorsement _without_ tying it
to what we ship, but that doesn't seem like a good idea to me - it would
be an inconsistent set of values and cause user confusion.
If we do tie our endorsement to what we ship, then an endorsement would
have wider ramifications and so we must this yet more thoughtfully.
For the (deb) archive, we have the added complication that we ship
anything that Debian considers acceptable by default. It wouldn't be
practical for us to be more restrictive than Debian.
Looking at debian-project@, it looks like Debian might be leaning
towards a more strict subset than OSAID (if anything), so perhaps that
won't be an issue in practice - but it might be wise to see where Debian
go first before committing. In the meantime perhaps we could make it
clear what are intention is, while acknowledging that we will also
accept whatever Debian accepts.
We should also consult with Canonical (both management and legal) before
taking any decision.
Robie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20250213/d24b6ca7/attachment-0001.sig>
More information about the technical-board
mailing list