The table in the checklist contains a column that refers to the acceptable legal framework for each of the components.
A comment from @hook and a discussion at the in-person workshop last week highlighted that the term used in the draft is not appropriate.
I think that for code components we can easily require to be made available under an OSI Approved License.
For model parameters, since the legal regimes are less clear, the recommendation from the workgroup in Gothenburg settled on the term Available under OSD-conformant terms which implies that the terms will have to be reviewed under the lens of the Open Source Definition… An exercise to start soon (stay tuned.)
The issue is with the documentation for the components in the class of Data transparency: There is no formal definition of “open documentation” and the OSI hasn’t reviewed licenses popular for documentation, like CC-BY. Some of these licenses would comply with the Open Source Definition though, so as @zacksuggested before, we should be able to use a term like OSD-compliant or OSD-compatible
What wording would you prefer to accompany the requirements for documentation about the data?
OSD-compliant would mean that documentation would need to be under a license that fulfils all ten OSD criteria, and many of those are quite software-specific. This could be tricky, there is a reason why OSI hasn’t approved (m)any non-software licenses thus far.
as for OSD-compatible, it seems a bit ambiguous what that even means. So many proprietary licenses are compatible with so many (non-copyleft) OSD-compliant licenses, that I fear this means almost nothing. (Well, not exactly nothing, as it does mean the documentation license cannot remove the FOSS’ness of the code license, at least.)
Open Knowledge Foundation (OKFN) has their own “Open Definition”, which is perhaps the best drafted definition of open data and open content I’ve seen so far:
(There is also the Definition of Free Cultural Works, based on the 4 freedoms, which used to have quite some traction back in the day, but I haven’t followed its development in ages, to see how it fares nowadays. It seems the definition has not changed much in almost a decade.)
As such, I propose to adopt The Open Definition from OKFN for non-code stuff.
Code license
A further complication is whether (for code) we’d also consider licenses that are tagged as:
non-reusable
redundant
superseded
voluntarily retired
…
These are technically OSI-approved, just that OSI suggest not to use them.
The new tagging/classification of licenses is a great thing, but it does have consequences, and allows for more finer-tuned policies.
The main difference I see between the terms OSD-compliant and OSD-compatible is that compliant is a legally charged term, it feels more strict and in my mind, leads to a strict evaluation and approval process. Compatible suggests a lightweight review that anyone can do, it doesn’t lead necessarily to requiring a new list of approved licenses. I may be wrong
It would be tricky but possible, right? OSI could create a special category of licenses for documentation only: we have the infrastructure and also the time to get the board to approve this by October. @pchestek@Kappa What do you think? If we say documentation of Open Source AI needs to be available with OSD-compliant terms, do we need to create a special category of OSI Approved Licenses for documentation?
I’m reading the words OSD-compatible differently. To me that means compatible with the points of the Open Source Definition not compatible with existing licenses. In practice, this would mean that a system with documentation shared with CC-BY would pass while one using CC-BY-NC wouldn’t.
I agree with you, that’d be a good definition. But the OKFN is currently reviewing the Open Definition, and judging the first round of comments, it makes me wonder if the principles of open will survive the review.
Maybe it’s a complication, I’m not sure. In any case, I think this is not an issue worth analyzing now because it applies also to “classic” software.
I would start with what we want to achieve. We need that the documentation is complete and accurate, this is a technical requirement. We need that the documentation be readable, therefore needs to be in an open format that anyone has the permission to build something to read and modify (sorry to belatedly bring this up). We need that the documentation is free from restrictions that would limits its circulation, including by requiring seeking additional permission or requiring royalties or requiring audited distribution or the likes.
The scope of the license is therefore quite limited, and I agree that CC-BY and CC-zero would qualify. CC-BY-SA would also qualify. NC and ND would not qualify. BY would also require that there are no DRMs or other technical restrictions, but as long as they are not imposed technically, I don’t see this as a requirement.
For the time being I do not see the need to be ultra-specific of what open means. While the requirements above seem all relevant, there might be other. Do we need to vet those licenses? I would regard this as a good service that OSI could implement to remove any doubts, but at the same time I would not put it as a hard requirement.
[sorry for the bad English, I am pressed to complete other things and can’t re-edit much]
There is always the option to refer to the specific version of the definition. And we can bump the reference to a newer version, if the newer version is better (or at least not worse); while staying with the current version of OKFN definition, if their definition does not move in line with our needs.
That is also how we do it in REUSE.software (and I’ve seen it elsewhere too as a good practice) – we refer to a specific SPDX spec version. Since the recently released SPDX 3.0 does not include (yet) file-based tags anymore, REUSE spec is still fine.
Small aside: I suggest that open source succeeded because in the first instance no-one needs to perform a review of OSI-approved licenses; rather there is a single public review and then a steward memorialises the result. Any approach that expects multiple opinions will be one where no-one actually decides…
If OSI were to do this work, I would prefer the term OSD-compliant.
The term compatible is ambiguous. Especially for non-English speaking people like us, the term could be interpreted in an expansive way. The criteria should be clearly stated.
I voted for OSD-compatible precisely because it is open for interpretation and more inclusive. Open Source by its nature cannot be enforced; My take is that OSS succeeded not because anybody is forcing closed-source corporations to join the community, but because it is beneficial from a more or less narrow profit-making perspective. I think that enforcing legal compliance (especially in the start) would have opposite to desired effect.
E.g. the only reason (i suggest) some companies have open sourced their LLMs a is because they wanted to compete with other ones ahead of them…
As such, I propose to adopt The Open Definition from OKFN for non-code stuff.
