Royaltysplitt og vilkår for deltakertildeling
Regler for opprettelse, aksept, versjonering og betaling av kontraktsmessige royaltytildelinger blant deltakere.
1. Kjerneprinsipp
En Royalty Split registrerer hvordan kvalifiserte inntekter fordeles mellom deltakerne. En Royalty Split overfører i seg selv ikke opphavsrett, rettigheter til masterinnspillingen, forlagsrettigheter eller andre immaterielle rettigheter.
2. Rettighetseierskap og inntektsfordeling er forskjellige
En person kan motta en kontraktsfestet prosentandel av inntekten uten å eie den samme prosentandelen av en master eller komposisjon. Eierskap og betalingsrett skal føres separat.
3. Delte typer
X2 kan støtte hovedinntektsdelinger, sammensetning eller publiseringstildelinger, Labelinntektstildelinger og andre kontraktsfestede deltakerallokeringer. Hver type må være knyttet til den aktuelle inntektskilden og rettighetskonteksten.
4. Deltakere og roller
En splittelse kan identifisere deltakere som artister, produsenter, fremhevede utøvere, mastereiere, låtskrivere, utgivere, administratorer eller andre kontraktsmessig berettigede personer eller enheter.
5. Prosentvis validering
En aktiv endelig splittelse bør ta hensyn til hele gjeldende tildelingspool. Utkast til arbeidsflyt kan identifisere en ikke-allokert del, men ikke-allokerte beløp betales ikke automatisk til en annen deltaker.
6. Invitasjoner og aksept
Deltakere kan motta en invitasjon som identifiserer den relevante eiendelen eller arbeidet, deltakerrolle, prosentandel, ikrafttredelsesdato og tildelingsgrunnlag. Deltakerne kan godta eller bestride den foreslåtte tildelingen.
7. Verifikasjon
Før betaling må hver deltaker fullføre mottaker-, skatte- og betalingsverifiseringen som kreves for den aktuelle utbetalingen. Verifisering av profesjonell rolle er bare nødvendig der deltakeren bruker en tjeneste eller hevder en rolle som krever det.
8. Statuser
En splittelse kan bruke statuser som UTKAST, PENGER GODKJENNING, DELVIS AKSEPTERT, AKTIV, DISPUTERT, SUSPENDERT, ERSTATTET og TERMINERT.
9. Ikrafttredelsesdatoer og versjonskontroll
Hver splittelse bør ha en ikrafttredelsesdato og, der det er relevant, en sluttdato. Endringer i en akseptert splittelse bør skape en ny versjon i stedet for å stille over historiske prosenter.
10. Beregningsrekkefølge
Med mindre den gjeldende avtalen uttrykkelig angir noe annet, gjelder deltakerdelinger for den kvalifiserte rettighetshaveren eller deltakerpoolen etter den gjeldende X2 kontraktsmessige inntektsandelen. Individuell skattetrekk, utbetalingsgebyrer eller valutaomregning kan da gjelde for hver deltaker separat.
11. Sen inntekt
Forsinket eller korrigert inntekt bør bruke delingen som gjelder for den relevante rettighetsperioden eller kontraktsgrunnlaget i stedet for automatisk å bruke den gjeldende delingen.
12. Tvister
Der en deltaker bestrider en tildeling, kan X2 bare holde den berørte delen der det er teknisk og juridisk mulig mens ubestridte beløp fortsetter gjennom normal regnskapsføring.
13. Tilbakevirkende endringer
Delte endringer gjelder som standard prospektivt fra ikrafttredelsesdatoen. Tilpasning med tilbakevirkende kraft kan kreve deltakeravtale, kontraktsmessige bevis, retting av en påvist feil, rettslig eller rettslig avgjørelse eller et annet tilstrekkelig grunnlag.
14. Deltakere uten full X2-tilgang
En deltaker kan bli invitert via e-post og kan få begrenset tilgang som er tilstrekkelig til å godta delingen, gi nødvendig informasjon om mottaker og motta deltakerens egen tildeling uten å motta bredere profesjonelle tillatelser.
15. Uavhentede tildelinger
En deltakers uavhentede eller ventende andel blir ikke automatisk X2-inntekt eller en annen deltakers andel med mindre den styrende avtalen eller gjeldende lov uttrykkelig bestemmer noe annet.
16. Honorarer
X2 kan inkludere ordinær delt administrasjon i den relevante tjenesten samtidig som avslørte tjenestegebyrer eller bruksgebyrer brukes på kompleks historisk avstemming, bedriftsautomatisering, bulkimport eller andre spesialistoperasjoner.
17. API-tilgang
Royalty-delte APIer kan bruke separate lese-, opprette-, oppdater-, invitere-, godta- og bestride-omfang. Svært sensitive tvangsendringer skal ikke være tilgjengelig gjennom vanlige utviklertillatelser.