[PROCESS] ToIP in violation of the Sovrin Glossary CC BY-SA section 3. Attribution requirements

[mwherman2000]

Need

ToIP is in violation of the Sovrin Glossary CC BY-SA section 3. Attribution requirements: https://creativecommons.org/licenses/by-sa/4.0/legalcode

Proposed Solution

1. Attach all the required elements of CC BY-SA section 3. Attribution to each Sovrin Glossary term and definition ingested into the ToIP Glossary, and
2. Ensure that all of the required elements of CC BY-SA section 3. Attribution are presented to each ToIP Glossary user wherever and whenever a Sovrin Glossary term and definition is either presented directly to a user or via a link to any Sovrin Glossary term and definition.

[dhh1128]

I don't think we are in violation yet, because we are not republishing anything so far. But I think we WOULD be in violation if we proceeded to publishing data without addressing the issue. So I think the appropriate course would be to figure out how to handle attribution in our tooling.

[mwherman2000]

@dhh1128 CC BY-SA applies at the point of acquisition/ingestion ...it doesn't matter that you do downstream as an internal ToIP process (e.g. Publishing). Anywhere/anytime you have external CC BY-SA content ingested/stored in any repository - ToIP repositories, in this case, you need to immediately satisfy the CC BY-SA Section 3. Attribution requirements.

[mwherman2000]

...think of it like a "chain of copyright rights and licensing rights custody" issue.

[dhh1128]

The Sovrin Glossary doesn't appear to have a CC BY-SA notice. I don't see one in the live version of the doc (which appears to be the frozen V3 link as well), or in the Governance Framework docs that comprise its parent artifacts.

I am not disputing that a CC BY-SA license was the intention; that was my understanding, too. But the lack of a formal statement actually concerns me (makes my worry about this issue stronger than it was when I first read it), because it means we could be in greater violation than we realized. @talltree , perhaps we need to make sure the CC license is more easy to find?

We actually are attributing Sovrin in the only artifact we've created, which is raw data in the CTWG repo. (Today there is no "TOIP Glossary" that contains the Sovrin data. The Sovrin data we do have is the result of an import experiment we did, and is very raw.) We attribute Sovrin's data by source name, which is not as good as a link but which does satisfy the attribution clause of the CC BY-SA license. But we don't satisfy other clauses of CC BY-SA, because we don't include a link to the license, to the disclaimers, and so forth -- so Michael is totally right we need to do better.

It's important to be precise about the scope of copyrightable material. A dictionary is copyrightable, and so are its individual definitions. But I don't believe the headwords (terms) themselves are copyrightable, and I'm certain that concepts are not. That is, you can copyright (and therefore license) a good definition for the concept "MRI machine" -- but you can't copyright the phrase "MRI machine" or the ideas that your definition of "MRI machine" points to. Intellectual property protections for those things use different mechanisms (e.g., trademarks, patents). See this discussion among professional librarians: https://librarycopyright.net/forum/view/390

The practical consequence to us is probably that in our internal data records, a term file is not copyrightable (since it decorates an uncopyrightable concept label with metadata). A concept file in its totality is not copyrightable, either. However, the definition field inside a concept record, plus any example usages that came from an external source, need to be cited correctly -- both in our corpus, and in any external manifestation of it (e.g., hovertext, a glossary). This is a good requirement for our tooling. I'm so glad Michael surfaced it.

[talltree]

@dhh1128 The copyright and licensing notice is in the same place in every document in the Sovrin Governance Framework V2 — in the footer at the end of the document (which for online papers is the standard place to put a copyright notice, no?). I know because I did the hard work (along with Sovrin Foundation superstar Matt Norton) to verify that we had the correct notice on every document.

I just confirmed the footer on the Sovrin Glossary V3 document and the SGF V3 Master Document both say:

© 2019 by Sovrin Foundation. This work is licensed under Creative Commons Attribution- ShareAlike 4.0 International License (http://creativecommons.org/licenses/by-sa/4.0/).

I do agree with you and Michael that with our CTWG tooling, we need a standard way to note the attribution for any content ingested under a CC by SA license — or other license that is compatible with our own CC by SA 4.0 license. And if submitted material is NOT compatible with our CC by SA 4.0 license, we cannot accept it, period.

[mwherman2000]

The facts are the facts guys. The Sovrin Glossary V3 is licensed under the CC BY-SA license. See below.

[mwherman2000]

And if submitted material is NOT compatible with our CC by SA 4.0 license, we cannot accept it, period.

The CC license that is used for the Sovrin Glossary, more specifically the CC BY-SA license, is more restrictive than the current choice of ToIP CC license (see https://github.com/trustoverip/concepts-and-terminology-wg/blob/master/LICENSE) which is CC BY (only).

Hence, the Sovrin Glossary CC BY-SA license is not compatible with the ToIP CC BY license and the Sovrin Glossary is not acceptable for acquisition and ingestion by ToIP (based on @talltree's logic).

[talltree]

@mwherman2000 See this screenshot from the Wikipedia page about Creative Commons licenses that explains that the new internationalized CC BY license and the older CC BY SA have the same features. Note that both require attribution.

I am not a lawyer, but my understanding is that content under a CC BY SA license can be redistributed under a CC BY license but without changing the underlying CC BA SA license.

[dhh1128]

Thank you for helping me find the statement. I looked for it at the beginning and in the footers on every page of the doc, but it did not occur to me to page down to the end. I'm glad that's cleared up. Breathing a sigh of relief.

[dhh1128]

@talltree : I went and read the wikipedia page, and I believe Michael is right. My reading is that CC BY-SA is more restrictive and therefore cannot have CC BY layered on top. The relevant sentence that convinced me was this one, in the table describing the share-alike provision:

Licensees may distribute derivative works only under a license identical to ("not more restrictive than") the license that governs the original work. (See also copyleft.) Without share-alike, derivative works might be sublicensed with compatible but more restrictive license clauses, e.g. CC BY to CC BY-NC.)

Of course, the license text itself, not the wikipedia page, would be normative -- and of course lawyers could/should weigh in to clarify that. But I think the tension does exist.

If my interpretation is right, then this has two consequences:

1. The github repo where this data appears needs to have a CC-BY-SA license on it -- or we need to delete the repo and rebuild one without the Sovrin data in it -- or we need to put a CC-BY-SA license just on the folder that contains the Sovrin definitions.

2. Assuming we get the repo issue ironed out, all glossaries that we build from the repo need to be sensitive to the license issue, such that, if a piece of CC BY-SA copyrighted material is included in a work built from the corpus, proper attribution is carried into the exported data and displayed in a reasonable fashion. This does NOT mean every glossary we build will have that characteristic; it only means glossaries that contain (by value, not by reference) definitions (not terms) written for the Sovrin Glossary.

[dhh1128]

Of course, there is another option as well. Copyright holders can choose to relicense their copyrighted material. We could approach the Sovrin Foundation about an alternative license.

[mwherman2000]

RE: Of course, there is another option as well. Copyright holders can choose to relicense their copyrighted material. We could approach the Sovrin Foundation about an alternative license.

Your suggestion is disadvantageous to upstream copyright holders such as the SF because it, in effect, is robbing of the full downstream attribution that is due to them in the first place.

[mwherman2000]

@dhh1128 Wikipedia is not an authority when it comes to understanding the differences between the different types of CC licenses.

Use this page instead: https://creativecommons.org/about/cclicenses/

[talltree]

Good points, Daniel. I am just one opinion but I suspect the Sovrin Foundation and the ToIP Foundation would be united in wanting to solve this licensing issue not only for themselves but for DIF and for everyone else who wants to participate in a shared community terminology corpus the way we are designing it. My suggestion is threefold: 1. Let's go to Linux Foundation counsel and get their advice on how best to structure the licensing we want to use for the CTWG corpus. 2. Let's take that advice to the Sovrin Foundation and see if they agree. 3. Let's then take it to all the other potentially interested contributors/customers (e.g., DIF, LFPH, Hyperledger, W3C CCG, etc.) and see if we can align. Thoughts?

…

On Mon, Mar 29, 2021 at 7:35 PM Daniel Hardman ***@***.***> wrote: Of course, there is another option as well. Copyright holders can choose to relicense their copyrighted material. We could approach the Sovrin Foundation about an alternative license. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#47 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZOITLIOT2USWPTXP7VEELTGE2HJANCNFSM4Z7VL6LA> .

[darrellodonnell]

Did we land anywhere on this issue?

[talltree]

Yes, it's closed. We are going to build in a standard way for glossary definitions to contain attributions. BTW, Mr. Herman has gone pretty quiet recently. I don't know what he's up to. =D

…

On Mon, Jun 21, 2021 at 7:46 AM darrellodonnell ***@***.***> wrote: Did we land anywhere on this issue? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#47 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZOITPJKUZ67JXOY62TWYLTT5GENANCNFSM4Z7VL6LA> .

[mwherman2000]

BTW, Mr. Herman has gone pretty quiet recently. I don't know what he's up to. =D

Combining lentils and maple peas. Harvest shouldn't last too long with our drought.

I did take a day to knock this out: https://www.youtube.com/watch?v=FFv4WZ0p3aY

"More news at 11...",
Michael

[mwherman2000]

If ToIP is still using the original CC-BY version of the CC license, then ToIP is still in violation of the Sovrin Glossary CC-BY-SA license and all Sovrin Glossary terms and definitions need to be removed from the ToIP repositories.

[talltree]

Michael, with the terms wiki <https://wiki.trustoverip.org/display/HOME/Terms+Wikis> architecture that we are putting in place, each participating group (such as the Sovrin Foundation if it chooses to participate) will maintain its own GitHub repo. Secondly, each entry in a terms wiki will include its own licensing info, which will be included in any glossary that includes that term. So "the license will follow with the term". This should address any IPR around any term in any participating term wiki. =Drummond

…

On Fri, Aug 6, 2021 at 3:45 AM Michael Herman (Trusted Digital Web) < ***@***.***> wrote: If ToIP is still using the original CC-BY version of the CC license, then ToIP is still in violation of the Sovrin Glossary CC-BY-SA license and all Sovrin Glossary terms and definitions need to be removed from the ToIP repositories. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#47 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZOITNYCIZIBL6MVIA7OLLT3O4M5ANCNFSM4Z7VL6LA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[mwherman2000]

If ToIP currently has any version or subset of the Sovrin Glossary in any of its repositories (which I believe it does), then it is in violation of the Sovrin Glossary license terms.

[mwherman2000]

For completeness, the second, totally separate and separable requirement is one stipulated for any and all content received and accepted by ToIP: good old "Section 6" of the JDF Project Charter version 5.0.1:

6. Conditions for Contributions. A Steering Member, General Member, or Contributor may not make any Contribution unless that Steering Member, General Member or Contributor is the exclusive copyright owner of the Contribution or has sufficient copyright rights from the copyright owners to make the Contribution under the terms of this Project Charter and applicable Working Group Charter. Working Group Charter. The Steering Member, General Member, or Contributor must disclose the identities of all known copyright owners in the Contribution.
   [v.5.0.1 Project Charter Page 2 of 4]

So if you or I or Daniel or Line placed any part of the Sovrin Glossary in a ToIP repository, then each of us are in violation of our individual ToIP Project Charters they we have all signed (directly or indirectly) ...with retribution to be determined by a meeting of the ToIP Steering Committee.

This is not a CC licensing issue ...totally and completely unrelated... It's a ToIP Project Charter stipulation that stands by itself.

NOTE: Because a number of current ToIP members have received and accepted Sovrin Glossary content into a ToIP repository (this isn't disputable), a ToIP TC meeting is needed to resolve this situation for each ToIP member that has been directly involved with the receipt of the content.