Unclear benefit to separation between Copyright and Right

[alexanderattar]

Hello @TimDaub and team,

I hope you've been well :)

I am continuing to model some data via coala ip and picking up on development where we left off with js-coalaip. I have read the proposed rational for splitting Copyright and Right into separate entities (https://github.com/COALAIP/specs/blob/master/README.md#copyright-semantics), but the benefit from doing so continues to be unclear to me. The difference seems to be that Rights are designed to be transferable, whereas Copyrights are designed to only be created during the registration of a Manifestation (please correct me if this is wrong). In it's current form there isn't a percentageShares field on the Copyright so an additional Right object would have to be created even for the initial copyright holders and then the source field would have to link back to the Copyright. Given the idea that there could be RightsAssignments to change ownership of the Right object it seems like the Copyright would become invalid after such an assignment.

My suggestion is to conflate these models to eliminate duplication by either adding the "rightsOf": "<URI pointing to a Creation (usually a Manifestation)>", field to the Right type or allowing the source field on the Right to also point to a Creation. Another possibility is adding the percentageShares field to the Copyright type (I am not sure it makes sense to have this on both Copyright and Right, but there should be a way to indicate the initial owners share percentage prior to any subsequent assignment). Interested to get your thoughts / suggestions.

Cheers,

[godfreyrust]

Hi Alexander, Tim. I haven't reviewed COALA seriously to date (as author of the LCC LEM and RRM specs), but we are preparing a range of formal LCC specs and I had reason to look at what a formal mapping of COALA to the LCC would mean, so I may be making other comments. In relation to Alexander's comment here, without reviewing the specifics carefully I'd be very cautious indeed about splitting out any separate top level Right object. I think by "Copyright" you mean an original (typically creator's) copyright claim: that can be identified if needed by a RightType on a Right. (As a point of detail responding to Alexander, an original copyright claim must have a percentage share, as the rights in any co-authored work are normally immediately shared). Original copyright is simply a type of RIghtsAssignment (from a RightsLaw) and should be given no special status as it may be superseded or traded like any other right: its only special characteristic is that it is always at the head of a chain of rights - but the identity of an original copyright owner is not necessarily known, or may (often) be disputed, so any spec or system which requires it will run into problems. If you stick with the single Right object you should be able to avoid creating "edge cases": if you split you are likely to start multiplying complexities and parallel processes. Happy to discuss this further if it remains an issue: just putting down a marker here.

Best

Godfrey Rust

[listenaddress]

It seems we can use Right to create Copyright objects.

From the spec:

We base the structure of the Copyright entity on the Right entity’s, but as only a subset of the Right’s properties pertain to Copyrights (e.g. “territory”, “validFrom”, etc.), we do not require implementations to subtype Copyrights from Rights. However, semantically, and for the purposes of discussion, we treat Copyrights as a subtype of Rights.

And in terms of linking to a Creation, Right has a property called Right_Creation for that (see section 3.7 http://www.linkedcontentcoalition.org/phocadownload/framework/The%20LCC%20Rights%20Reference%20Model%20v1.0.pdf).

[TimDaub]

Hi,

as motivated in the specification:

Although RRM Rights are capable of representing both full copyrights as well as derived licenses to Creations, we split these two concepts into different entities to better represent them within distributed ledgers.

The copyright entity was initially added as a way to make Copyright transfers possible, meaning they should be transferrable via a RightsAssignment on the ledger. However by following what @godfreyrust is saying, notably that the LLC RRM Right has a field RightType that allows the keyword "Copyright", RightsAssignment on a Right with RightType "Copyright" would still be possible on distributed ledgers.

I hence do not see a reason to still have a separate copyright entity.
Is anyone here OK with representing copyright as a Right with RightType "Copyright"?
@sohkai, @gmcmullen Any input?

[godfreyrust]

Hi Tim - that works for me and LCC/RRM.

[sohkai]

@TimDaub Combining the two sounds good.

Making rightsOf mandatory when the RightsType is Copyright and optional when the RightsType is a SourcedRight seems cleanest. source would also not apply for Copyrights.

[alexanderattar]

@sohkai would this imply that rightsOf could be a field on the Right entity? So essentially required fields from Copyright would be merged onto Right

[sohkai]

@alexanderattar Yes, they would have to be merged with some notion of "optional" and "required" depending on the type.

[alexanderattar]

Cool! I think that makes a lot of sense.

[godfreyrust]

Alexander/Tim: I've been looking in the specs for some clarification on the meaning of "Copyright" in COALAIP (as it isn't an RRM Term and its use here appears to be a little different from its legal meaning). Above the "Copyright Semantics" section in the spec it speaks of the "Copyright or parent Right" - is there another definition elsewhere that I have missed? I am assuming that the term "Copyright" in COALAIP is intended to mean the original group of rights assigned to a creator (or creators) by law (what I would call the OriginalCopyright). Copyrights are often sold to, assigned to or inherited by others, not merely granted under license, so a Copyright owner is not necessarily the original Copyright owner. A Copyright can be sold or assigned on a temporal or territorial basis, so there can be multiple Copyright owners both by time and place. It is also often unknown on what basis a party is claiming a Copyright (or indeed any more a limited Right): they may be the original Copyright owner, they may have acquired the Copyright permanently at some point in the past, or they may have acquired Copyright (and therefore licensing rights) under an agreement for a period of time and a particular place. Because rights may be claimed at any point in the chain depending on the context of use, it is commonly the case that a claim will not be supported by details the "upstream" chain of rights (although that is obviously one of the market problems which blockchain helps to address). For these reasons it may be sensible to clarify the meaning of "Copyright" as it applies in COALAIP, and also not to prohibit the use of "rightsOf" in relation to a Right with type Copyright. It would be possible, or course, to introduce a more specialized right type of OriginalCopyright, for which tighter constraints could be applied as proposed.

[alexanderattar]

Thanks for the research @godfreyrust. This is a distinction that has also confused me. My assumption was that the Copyright schema satisfied the OriginalCopyright situation but then upstream changes would be cast to the Right with RightsAssignments propagating the proliferation of Right ownerships. I wasn't involved in the initial design of the spec though so this could be incorrect. These models seemed to overlap and I wasn't sure of the immediate value of separating them from an implementation perspective (especially when accommodating for relational systems). @sohkai's idea of using a RightsType made sense to me, but maybe I'm missing something if retaining the provenance of OriginalCopyright is a necessity. Is this also something that could be handled with RightsType? I'd be interested to see what others think about it.

[TimDaub]

Thanks for looking into the specification @godfreyrust.

@godfreyrust "Copyright" in COALAIP is intended to mean the original group of rights assigned to a creator (or creators) by law (what I would call the OriginalCopyright)

Yes, we didn't define that properly I believe.

@godfreyrust Copyrights are often sold to, assigned to or inherited by others, not merely granted under license, so a Copyright owner is not necessarily the original Copyright owner. A Copyright can be sold or assigned on a temporal or territorial basis, so there can be multiple Copyright owners both by time and place. It is also often unknown on what basis a party is claiming a Copyright (or indeed any more a limited Right): they may be the original Copyright owner, they may have acquired the Copyright permanently at some point in the past, or they may have acquired Copyright (and therefore licensing rights) under an agreement for a period of time and a particular place.

That's how we looked at Copyright when we drafted the specification.

@godfreyrust For these reasons it may be sensible to clarify the meaning of "Copyright" as it applies in COALAIP, and also not to prohibit the use of "rightsOf" in relation to a Right with type Copyright.

What I'm reading here is:

• Clarify in the spec that Copyright is referring to @godfreyrust's definition of OriginalCopyright, namely: "Copyright, as we write about it in COALAIP, is the original group of rights assigned to a creator (or creators) by law."

@sohkai: Making rightsOf mandatory when the RightsType is Copyright and optional when the RightsType is a SourcedRight seems cleanest. source would also not apply for Copyrights.

For the sake of simplicity, I would simply call all references "rightsOf". Independent of RightType. So remove source completely and use rightsOf instead. I hope that is all right with you :D

@alexanderattar @sohkai's idea of using a RightsType made sense to me, but maybe I'm missing something if retaining the provenance of OriginalCopyright is a necessity.

The provenance of Copyright can be retained either by using RightType or by using a separate Copyright entity. The point to make it a separate entity was that I believe we wanted to separate RightType: Copyright from the other RightTypes as it stood out to us to be transferrable as a token on the blockchain. We can however do the same by reintroducing the RightType:Copyright to the Right entity.

I hope I understood everyone correctly here. If not, let me know. Here's a list of things to do before resolving this issue based on the comments that we got:

• Update the specification so that it contains a definition of Copyright similar to what @godfreyrust defined it (OriginalCopyright).
• Remove Copyright entity from the spec and introduce RightType:Copyright to the Right entity
• Remove source from Properties and instead allow rightsOf independent of RightType
• Clarify that with RightType:Copyright provenance via tokenized Right entity (e.g. ERC721) can still be retained
• Do a review with the involved parties in this conversation.

I'm planning to do this change pretty soon, as we need it for a project we're working on.

[TimDaub]

I created a PR in #29 for the involved parties of this thread to review.

[alexanderattar]

Awesome @TimDaub! Thanks for compiling the above discussion, summarizing and taking the initiative to open a PR with the proposed changes. Sorry, been pretty heads down working on a pretty aggressive timeline for some upcoming things for Ujo so have not had time to review in detail yet, but from reading the above I believe it all makes sense. I will take a second look at the PR tomorrow and circle back if I have any questions 🙏

[godfreyrust]

Thanks @TimDaub I'll review this asap and post back.