Podjela autorskih prava i uvjeti raspodjele sudionika
Pravila za kreiranje, prihvaćanje, upravljanje verzijama i plaćanje ugovornih tantijema među sudionicima.
1. Temeljno načelo
Royalty Split bilježi kako se prihvatljivi prihod raspoređuje među sudionicima. Royalty Split sam po sebi ne prenosi autorska prava, prava na master snimku, izdavačka prava niti druga prava intelektualnog vlasništva.
2. Vlasništvo nad pravima i raspodjela prihoda razlikuju se
Osoba može primiti ugovorni postotak prihoda bez posjedovanja istog postotka mastera ili skladbe. Vlasništvo i pravo na plaćanje moraju se evidentirati odvojeno.
3. Split Vrste
X2 može podržavati podjelu glavnog prihoda, raspodjelu skladbe ili izdavanja, raspodjelu prihoda Label i druge ugovorne raspodjele sudionika. Svaka vrsta mora biti povezana s odgovarajućim izvorom prihoda i kontekstom prava.
4. Sudionici i uloge
Podjela može identificirati sudionike poput umjetnika, producenata, istaknutih izvođača, vlasnika mastera, tekstopisaca, izdavača, administratora ili drugih ugovorno ovlaštenih osoba ili entiteta.
5. Provjera postotka
Aktivna konačna podjela trebala bi uzeti u obzir cjelokupni primjenjivi skup dodjele. Nacrti tijekova rada mogu identificirati nedodijeljeni dio, ali nedodijeljeni iznosi ne mogu se automatski platiti drugom sudioniku.
6. Pozivnice i prihvaćanje
Sudionici mogu primiti pozivnicu koja identificira relevantnu imovinu ili rad, ulogu sudionika, postotak, datum stupanja na snagu i osnovu za dodjelu. Sudionici mogu prihvatiti ili osporiti predloženu raspodjelu.
7. Provjera
Prije isplate, svaki sudionik mora ispuniti potvrdu korisnika, poreza i plaćanja potrebnu za odgovarajuću isplatu. Provjera profesionalne uloge potrebna je samo ako sudionik koristi uslugu ili potvrdi ulogu koja to zahtijeva.
8. Statusi
Podjela može koristiti statuse kao što su NACRT, NA ČEKANJU PRIHVAĆANJA, DJELOMIČNO PRIHVAĆENO, AKTIVNO, OSPORENO, OBUSTAVLJENO, ZAMIJENJENO i RASKINUTO.
9. Datumi stupanja na snagu i određivanje verzija
Svaka podjela trebala bi imati datum stupanja na snagu i, gdje je relevantno, datum završetka. Promjene prihvaćene podjele trebale bi stvoriti novu verziju umjesto tihog prepisivanja povijesnih postotaka.
10. Redoslijed izračuna
Osim ako primjenjivi ugovor izričito ne predviđa drugačije, podjele sudionika primjenjuju se na kvalificiranog nositelja prava ili grupu sudionika nakon primjenjivog X2 ugovornog udjela prihoda. Pojedinačni porez po odbitku, naknade za isplatu ili pretvorba valute mogu se primjenjivati na svakog sudionika zasebno.
11. Zakašnjeli prihod
Zakašnjeli ili ispravljeni prihod trebao bi koristiti podjelu primjenjivu na relevantno razdoblje prava ili ugovornu osnovu umjesto automatske upotrebe trenutne podjele.
12. Sporovi
Ako sudionik osporava dodjelu, X2 može zadržati samo pogođeni dio kada je to tehnički i zakonski moguće, dok se nesporni iznosi nastavljaju kroz normalno računovodstvo.
13. Retroaktivne promjene
Podijeljene promjene prema zadanim postavkama primjenjuju se prospektivno od datuma stupanja na snagu. Retroaktivna prilagodba može zahtijevati suglasnost sudionika, ugovorne dokaze, ispravak utvrđene pogreške, sudsku ili pravnu odluku ili drugu dovoljnu osnovu.
14. Sudionici bez punog X2 pristupa
Sudionik može biti pozvan e-poštom i može dobiti ograničeni pristup dovoljan za prihvaćanje podjele, pružanje potrebnih podataka o korisniku i primanje vlastite dodjele tog sudionika bez primanja širih profesionalnih dopuštenja.
15. Nezatražena izdvajanja
Nezatraženi udio sudionika ili udio na čekanju ne postaje automatski X2 prihod ili udio drugog sudionika osim ako važeći ugovor ili primjenjivi zakon izričito ne predviđa drugačije.
16. Naknade
X2 može uključiti običnu podijeljenu administraciju u relevantnoj usluzi dok primjenjuje objavljene naknade za usluge ili naknade za korištenje na složeno povijesno usklađivanje, automatizaciju poduzeća, skupni uvoz ili druge specijalizirane operacije.
17. API pristup
API-ji za podjelu autorskih prava mogu koristiti zasebne opsege čitanja, stvaranja, ažuriranja, pozivanja, prihvaćanja i osporavanja. Vrlo osjetljive prisilne promjene ne bi trebale biti dostupne putem uobičajenih dozvola razvojnog programera.