# How to describe the acceptable terms to receive documentation? **URL:** \ **Category:** Open Source AI\ **Tags:** draft\ **Created:** [April 23, 2024, 2:56pm UTC](https://discuss.opensource.org/t/how-to-describe-the-acceptable-terms-to-receive-documentation/313 "2024-04-23T14:56:15Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![stefano](https://yyz1.discourse-cdn.com/flex011/user_avatar/discuss.opensource.org/stefano/32/4_2.png) [@stefano](https://discuss.opensource.org/u/stefano)\ **Post date:** [April 23, 2024, 2:56pm UTC](https://discuss.opensource.org/t/how-to-describe-the-acceptable-terms-to-receive-documentation/313/1 "2024-04-23T14:56:15Z")
The table in the [checklist](https://hackmd.io/i7aIMKLHQc6Vx6Rh7m1w8g?both#Table-of-default-required-components) contains a column that refers to the acceptable legal framework for each of the components. A [comment](https://hackmd.io/i7aIMKLHQc6Vx6Rh7m1w8g?comment=e0c9ecd8-7d56-4682-928c-dfc4fd18a5df&) 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 @zack [suggested](https://discuss.opensource.org/t/report-of-working-group-document-review/292/3) 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? _Poll ([view on site](https://discuss.opensource.org/t/how-to-describe-the-acceptable-terms-to-receive-documentation/313/1))_ ---
**Author:** ![hook](https://yyz1.discourse-cdn.com/flex011/user_avatar/discuss.opensource.org/hook/32/872_2.png) [@hook](https://discuss.opensource.org/u/hook)\ **Post date:** [April 24, 2024, 8:06am UTC](https://discuss.opensource.org/t/how-to-describe-the-acceptable-terms-to-receive-documentation/313/2 "2024-04-24T08:06:20Z")
# Documentation license > [@stefano](#): > > 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 @zack [suggested](https://discuss.opensource.org/t/report-of-working-group-document-review/292/3) before, we should be able to use a term like `OSD-compliant` or `OSD-compatible` I have concerns about both options: - _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: > **[The Open Definition - Open Definition - Defining Open in Open Data, Open...](https://opendefinition.org)** > > The Open Definition - Open Definition - Defining Open in Open Data, Open Content and Open Knowledge (There is also the [Definition of Free Cultural Works](https://freedomdefined.org/), 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 🔧 ➡ ⚙ ⚙ > [@stefano](#): > > I think that for code components we can easily require to be made available under an `OSI Approved 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. ---
**Author:** ![stefano](https://yyz1.discourse-cdn.com/flex011/user_avatar/discuss.opensource.org/stefano/32/4_2.png) [@stefano](https://discuss.opensource.org/u/stefano)\ **Post date:** [April 24, 2024, 10:09am UTC](https://discuss.opensource.org/t/how-to-describe-the-acceptable-terms-to-receive-documentation/313/3 "2024-04-24T10:09:12Z")
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 🙂 > [@hook](#): > > - _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. 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? > [@hook](#): > > - 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.) 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. > [@hook](#): > > 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: 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](https://blog.okfn.org/2023/06/26/debriefing-the-open-definition-workshop-at-rightscon/), it makes me wonder if the principles of open will survive the review. > [@hook](#): > > A further complication is whether (for code) we’d also consider licenses that are tagged as: 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. ---
**Author:** ![Kappa](https://yyz1.discourse-cdn.com/flex011/user_avatar/discuss.opensource.org/kappa/32/367_2.png) [@Kappa](https://discuss.opensource.org/u/Kappa)\ **Post date:** [April 24, 2024, 10:31am UTC](https://discuss.opensource.org/t/how-to-describe-the-acceptable-terms-to-receive-documentation/313/4 "2024-04-24T10:31:41Z")
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] ---
**Author:** ![hook](https://yyz1.discourse-cdn.com/flex011/user_avatar/discuss.opensource.org/hook/32/872_2.png) [@hook](https://discuss.opensource.org/u/hook)\ **Post date:** [April 25, 2024, 5:45am UTC](https://discuss.opensource.org/t/how-to-describe-the-acceptable-terms-to-receive-documentation/313/5 "2024-04-25T05:45:12Z")
> [@stefano](#): > > > [@hook](#): > > > > 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: > > 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](https://blog.okfn.org/2023/06/26/debriefing-the-open-definition-workshop-at-rightscon/), it makes me wonder if the principles of open will survive the review. 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. ---
**Author:** ![webmink](https://yyz1.discourse-cdn.com/flex011/user_avatar/discuss.opensource.org/webmink/32/55_2.png) [@webmink](https://discuss.opensource.org/u/webmink)\ **Post date:** [April 25, 2024, 10:26pm UTC](https://discuss.opensource.org/t/how-to-describe-the-acceptable-terms-to-receive-documentation/313/6 "2024-04-25T22:26:50Z")
> [@stefano](#): > > `Compatible` suggests a lightweight review that anyone can do, 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… ---
**Author:** ![shujisado](https://yyz1.discourse-cdn.com/flex011/user_avatar/discuss.opensource.org/shujisado/32/230_2.png) [@shujisado](https://discuss.opensource.org/u/shujisado)\ **Post date:** [May 2, 2024, 10:20am UTC](https://discuss.opensource.org/t/how-to-describe-the-acceptable-terms-to-receive-documentation/313/7 "2024-05-02T10:20:57Z")
> [@stefano](#): > > 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. 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. ---
**Author:** ![kabir.kbr](https://avatars.discourse-cdn.com/v4/letter/k/47e85d/32.png) [@kabir.kbr](https://discuss.opensource.org/u/kabir.kbr)\ **Post date:** [July 12, 2024, 5:48pm UTC](https://discuss.opensource.org/t/how-to-describe-the-acceptable-terms-to-receive-documentation/313/8 "2024-07-12T17:48:49Z")
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…