GNM_RCS_Rights_for_Content_TS

• 1. .Introduction

     1. Purpose

The document GNM_RCS_Rights_Management_FS.docx is the functional specification that describes what business functions RCS supports in relation to rights management.

This document is one of a set of technical specifications that provide details of how those functions are implemented in RCS.

• 1. Scope

This document focusses on the rights and rights properties held against commissions and contracts in RCS, and its relevance to content. Separate documents deal with all other aspects of rights management in RCS including rights defaults, rights approval, and the publishing of rights data.

This document is intended as a high-level technical document outlining how the relevant business functions are implemented in terms of software modules.

Importantly, this document does not aim to provide the level of detail that would be required in a programming specification in areas such as program structure, detailed business rules, data integrity, validation, locking considerations, data security, and calls to/from other software modules, performance considerations, and so forth.

For details of program logic and coding, the reader should refer to the program files themselves.

• 1. .Rights on commissions & contracts

When a commission or contract is created default rights are copied from the default rights profiles to the commission of contract (collectively referred to as the arrangement). The profile used is selected according to the date of the arrangement, the format of the content being supplied, whether a licence or assignment of copyright has been agreed, and whether the content being supplied is a new commission, existing stock, or from a full-time or part-time staffer.

The rights profiles are defined in the following tables:

• • RIGHTS_PERIODS (each record is a different profile)

  • RIGHTS_MANAGED (where many rights are listed per profile)

  • RIGHTS_DEFAULTS (listing many properties and their defaults for each right)

  • With foreign key lookups to the RIGHTS and RIGHTS_PROPERTIES tables

  • And values constrained by optional lists of allowed values defined in the tables RIGHT_PROPERTY_VALUES and RIGHTS_PROPERTY_UNITS

Commissions are always single-format, whilst contracts may be multi-format. A profile is required for each format that applies.

Of copy of the relevant rights profile(s) is copied into the following tables by database triggers:

• • ARRANGEMENT_FORMATS (identifies the rights_period i.e default for each format agreed)

  • ARRANGEMENT_RIGHTS (the list of rights)

  • ARRANGEMENT_RIGHTS_DETAIL (the properties of those rights)

This set of data is then available to the user, presented in a “rights palette”, and the user is able to make changes as required.

• 1. .Rights palette

The “Rights palette” or “Rights tab” is the visual presentation within RCS of rights that have been agreed for a commission or contract. The Rights palette is a tabbed canvas that is used throughout RCS in many screens. It is defined in one Oracle Form (rcs_comm_010_pc.fmb) and sub classed (inherited) elsewhere via an Object group called RIGHTS_PALETTE.

• 1. Summary tab

Taking a text commission, an example of the Right tab is shown below:

The palette opens on the Summary tab which shows the most important rights information in an easy to read format.

The Charter button at the top of the screen opens a web page showing the Freelance Charter, which is GNMs overarching tersm with contributors in relation to the supply of content.

.

• 1. Edit tab

The rights and properties that have been agreed can be edited in the Edit tab, as show below. The left hand side lists the rights, and the right hand side lists the properties of the highlighted right.

The user can define whether the right has been acquired, and if so what the detailed properties of each right acquisition are.

If the acquisition of a right is non-standard i.e. doesn’t match the defaults in the rights profile then it is highlighted in red as seen in the example below. The same highlighting occurs for rights properties. This draws the user’s attention to unusual aspects of an arrangement.

The “Approve” button allows Rights department users to approve the entire set of rights as shown, whilst a “Reset” button allows a Rights department user to reset the rights back to a copy of the original defaults. These buttons are not available to other users.

If any other user changes any rights or properties of any rights after they have been approved then they will be queued for review again.

The “Group copy” button allows the properties of the highlighted right to be copied to all other rights that belong to the same rights group, saving the user time copying and pasting between rights.

• 1. Other terms tab

Besides the detail of the rights and their properties two longer text based fields are available on the Other terms tab: one for the Copyright notice that must be published with the content, the other for any Special terms that also apply.

If either field is given a value the rights are deemed non-standard and a message is displayed on the screen to instruct the user to make sure the rights and properties reflect any special terms as best they can.

.

• 1. Administration tab

The Administration tab is only accessible to Rights department users and the RCS administrator.

This tab allows the user manage more complex changes to the rights agreed:

• 1. Change the underlying profile

The rights department may determine that the commission of contract has been agreed on the wrong basis e.g. rights for a new commission were recorded when the content actually came from stock, and so they can change the profile. Changing the profile will often impact the rights and properties that are agreed and there may be different defaults.

The change is made by the user selecting the required profile criteria of Arrangement type, Copyright position and Source of content, then pressing the “Find profile and apply” button.

• 1. Process single assignments

Assignments of copyright may be processed as single assignments in this screen, or umbrella assignment against the contributor. Assignments require contracts to be issued that must be signed and returned by the contributor, whereas licences do not. Signature boxes are added to the commission letter when required.

• 1. .Rights on content

RCS keeps track of content published in print and on the web. All content is supposed to be processed in RCS, which means it must be matched to a commission or contract, or disregarded with a reason specified, or identified as staff content. The rights in an item of content are the rights associated with the action taken i.e. the rights on the commission or contract or disregard reason, or for staff content GNM copyright is assumed (i.e. all rights).

RCS tries to process as much content as it can as soon as it knows about it. The remainder must be matched manually. (The matching processes are described in another document in this documentation set.)

Right against individual items of content cannot be modified, as each item of content does not have its own profile (except where just one item of content is matched to a single commission).

• 1. Multi-matching

If an item of content is matched to more than one commission or contract then the rights that apply to the content are deemed to be the most restrictive rights agreed amongst those commissions and contracts.

• 1. Unprocessed content

When content has yet to be processed RCS needs to make an informed guess as to what rights might reasonably be expected to apply.

This guess should only be temporary, as an accurate rights position is reached as soon as the content is processed.

• 1. Identifiable content

If the contributor can be identified from a contributor tag (web content) or by-line or caption, or from IPTC header data on pictures, then RCS will review the rights of that contributor’s last 10 arrangements with GNM, and assume the most restrictive rights.

• 1. Unidentifiable content

If the contributor cannot be identified RCS will simply assume the rights defined against the set of defaults that could reasonably be expected to apply.

End of Document