<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>There's at least one acronym, heretofore unfamiliar to me, being
tossed around in this thread. OSAID did not pop-up for me, in the
<a href="https://search.brave.com/search?q=OSAID">first page of
search results</a>, so I had to dig a bit.</p>
<p>For the other passive followers out there, please correct me if I
am wrong, but it seems likely that OSAID is a reference to the
drafts on this page: <a
href="https://opensource.org/deepdive/drafts"
class="moz-txt-link-freetext">https://opensource.org/deepdive/drafts</a></p>
<div class="moz-signature">
<div> <a href="https://stackexchange.com/users/3795089/jwdonahue">
<br>
</a>
</div>
</div>
<div class="moz-cite-prefix">On 9/9/2024 4:31 PM, Josh Berkus wrote:<br>
</div>
<blockquote type="cite"
cite="mid:9b32b1a0-981f-46ab-8d10-e91b7711c236@berkus.org">On
9/1/24 05:53, Stefano Maffulli wrote:
<br>
<blockquote type="cite">- What new challenges do you expect to see
in reviewing these licenses?
<br>
</blockquote>
<br>
I see three major challenges:
<br>
<br>
1. We'll need to review TOS for types of content which are not
subject to copyright law (e.g. collections of model weights). To
date, all of the license eval on this list has been within the
framework of copyright law. I suspect that I lot of us would need
some education on how to evaluate non-copyright terms; I know that
I will.
<br>
<br>
2. We will also need to evaluate whether certain types of content
(model weights, training process docs, etc.) require any
clarification of the OSD for compliance.
<br>
<br>
3. The OSAID certifies complete software systems, not just
licensing documents. So we will need to verify that the terms
submitted are actually applied to the software available. To
date, L-R has operated by waiting for folks to submit documents to
us; the OSAID will require us -- or someone else -- to perform a
compliance review.
<br>
<br>
> - Do you recommend any changes to the process in light of
potential new challenges?
<br>
<br>
Given the above, I'm pretty sure that we need some kind of
organized digital tracking of verifications.
<br>
<br>
We also might consider splitting the work. I believe that L-R is
going to be much better equipped to evaluate whether the various
documents (licenses and terms) comply with the OSD, and leave it
to another team (staff, maybe?) to evaluate whether the AI
software actually uses all approved documents.
<br>
<br>
Finally, I think we'll want to list approved documents which are
not software licenses separately on the website from the software
licenses.
<br>
<br>
</blockquote>
</body>
</html>