Konzept #858

Write specification for rights management

Added by Alexander Blum about 5 years ago. Updated over 4 years ago.

Status:ErledigtStart date:12/02/2019
Priority:NormalDue date:12/05/2019
Assignee:Alexander Blum% Done:

100%

Category:-Estimated time:3.00 h
Target version:Prototype 1.1) API Specification

Description

This description is copy&pasted from #691 and are a first draft of specifications on right management.


We have 3 different right subjects:

  • authorship
  • copyright
  • performance (= ancillary copyright?)

We have possibly several different right objects:

  • music
  • lyrics
  • cover
  • layout
  • text (as in liner notes)
  • ...

We have the dimensions of

  • Identification ("Right holder")
    • all 3 right subjects might be transferable or not, depending on the legal system
    • if transferred, the right is "represented/owned by" or "licensed to" (?) one or more parties (persons or companies, usually collecting societies/labels/producers)
  • Accounting (utilization/allocation/distribution)
    • the distribution key is defined by the collecting society, e.g. composition/performance/text (similar to the old impwiki page), which already relate those 3 right subjects
    • depending on the type of utilization, different right holder want to be asked for permission and have a piece of the cake
    • what rights are relevant for distribution? what about e.g. those "flat rates" for publisher?

I might be unsatisfied with the current (theory of) models of those things, because

  • The concept of copyright owners as general pointer does not allow to track, why it is a copyright owner (hard to administer later on?)
  • We have different ways to express the transfer/representation of rights, e.g.
    • Creation Tariff Category -> Collecting Society
    • Creation Contribution / Performance -> Neighbouring Rights Society
  • We have both implicit and explicit definitions of right subjects, e.g.
    • Creation Contribution / Composition -> authorship and Creation Tariff Category -> copyright
    • Creation Contribution / Text -> authorship + copyright
  • We have different ways to model right objects, e.g.
    • Creation -> Music (full object)
    • Creation Contribution / Text -> Lyrics (field of "sub" object)
  • We might have different kind of objects relevant for distribution (release contribution could be a step towards a more general representation)

Related issues

Related to collecting_society - Konzept #691: Usecases and structure for copyright owners Erledigt
Related to collecting_society - Konzept #692: Do we need/want release contributions? Erledigt
Related to collecting_society - Datenbank #949: Implement the rightholder database structure Erledigt 01/27/2020 02/10/2020

History

#1 Updated by Alexander Blum about 5 years ago

Maybe table:

  • Rechtsgrundlage
    • Type: Urheberrecht/Leistungschutzrecht/...
    • Dokument?
  • Rechtsobjekt
    • Contribution/...
  • Rechteinhaber
    • Von/Bis/Party
  • Rechtewahrnehmer
    • Von/Bis/Party

#2 Updated by Alexander Blum about 5 years ago

  • Estimated time set to 3.00

#3 Updated by Alexander Blum over 4 years ago

  • Target version changed from 3) Testing phase III to Repertoire 3) Testing phase III

#4 Updated by Alexander Blum over 4 years ago

  • Project changed from repertoire to collecting_society

#5 Updated by Thomas Mielke over 4 years ago

#6 Updated by Thomas Mielke over 4 years ago

#7 Updated by Alexander Blum over 4 years ago

  • Due date set to 12/05/2019
  • Target version changed from Repertoire 3) Testing phase III to Prototype 1.1) API Specification

#8 Updated by Thomas Mielke over 4 years ago

  • Start date set to 12/02/2019

#9 Updated by Alexander Blum over 4 years ago

  • Related to Konzept #691: Usecases and structure for copyright owners added

#10 Updated by Alexander Blum over 4 years ago

  • Related to Konzept #692: Do we need/want release contributions? added

#11 Updated by Alexander Blum over 4 years ago

Database structure

[Mixin] Rightsholder:
    subject
        interface?
    object
        interface?
    contribution
        interface?
    successor
        interface?
    right
        [List: "Copyright", "Ancillary Copyright"]
    from
        [Date]
    through
        [Date]
    territory
        [-> Country]
    collecting_society
        [-> CollectingSociety]

CreationRightsholder(Rightsholder):
    subject
        [-n-1-> Artist; soft required]
    object
        [-n-1-> Creation; soft required]
    contribution
        [-> Dependant List; soft required
                right == Copyright: "Lyrics", "Composition"
                right == Ancillary Copyright: "Instrument", "Production", "Mixing", "Mastering"]
    successor
        [-n-1-> CreationRightsholder]
    instruments
        [-1-n-> Instrument;
            mandatory if right == Ancillary Copyright and contribution == "Instrument"
            invisible else]


ReleaseRightsholder(Rightsholder):
    subject
        [-n-1-> Artist; soft required]
    object
        [-n-1-> Release; soft required]
    contribution
        [-> Dependant List; soft required
                right == Copyright: "Artwork", "Text", "Layout"
                right == Ancillary Copyright: "Production", "Mixing", "Mastering"]
    successor
        [-n-1-> ReleaseRightsholder]

Creation:
    rightsholders
        [-1-n-> CreationRightsholders]

Release:
    rightsholders
        [-1-n-> ReleaseRightsholders]

Decisions

  • "Leistungsschutzrecht" = ancillary copyright (neighbouring rights > ancillary copyright)
  • All subjects are artists for now. This won't be possible for phonographic rights, as they might be represented by (or transfered to?) Labels, Publishers and probably Parties in general
  • CreationContribution is not needed anymore, might be rewritten to CreationRightsholder
  • CreationRole is used only for Instruments and should be renamed into "Instrument"
  • Territory could also be sets of countries - it is unclear, if the tryton Country Object is meant for that (to decide with Udo)
  • Country does not make sense in some cases (e.g. Contribution == "Instrument"), and should be invisible for these cases. It might be, that all ancillary copyright contributions do not make sense, but this needs further specification. For now it is ok to be visible in all cases
  • The choice of the collecting society for a tariff category will be made on creation level, not for each creation artist

#12 Updated by Alexander Blum over 4 years ago

  • Status changed from Neu to Erledigt
  • % Done changed from 0 to 100

#13 Updated by Alexander Blum over 4 years ago

  • Related to Datenbank #949: Implement the rightholder database structure added

Also available in: Atom PDF