[Odrl-version2] Followup on Legal stuff about contracts

[Alapan Arnab]

Hi Susanne and others,
I had a discussion with a law professor (Prof Julien Hofman) in my
university with regards to ODRL v2.0, and you were right with regards to
contracts and form. Currently ODRL is a language to express licensing
agreements, and in most countries (all the countries he is aware of),
licensing agreements are formless, and sometimes would not even require
signatures. However, in most legal systems it is often recommended that
licensing agreements have some elements to remove legal ambiguities
should disputes arise. So,, there is obviously a need to refine my
section 2; but here is a short summary of the recommended elements:

1. Jurisdiction and Dispute Resolution
These elements go together and are very useful in resolving contract
disputes speedily. In dispute resolution, the parties resolve to go to a
mutually agreed party to arbitrate their dispute and is often a cheaper
avenue to pursue. Should this fail, or if a party does not wish to take
this route, they can choose to sue the other party. Jurisdiction
determines where a party can be sued.

2. Choice of law
Because of the international nature, it should be possible to choose
which law governs the licensing agreement. This is potentially very
important in DRM. For example, in EU copyright directive, the rights
holder does not have to provide for fair use clauses while copyright law
in most countries do not have such restrictions. Thus, it would be
advantageous for music labels to base their licensing agreements under
EU law rather than, say South African law.

3. Time of Contract
For licensing agreements, time of contract is often necessary although
not mandatory.

4. Place of contract
Licensing agreements should not have a place of contract. A court needs
to decide the place of contract when deciding whether it has
jurisdiction.

5. Signatures
As I mentioned previously, signatures are not mandatory but recommended.
In any case digital signatures are a security mechanism.

6. Liabilities
This is probably the most important part for most contracts. It could be
interesting to provide different pricing models according to the
liability risk carried by the supplier. For example, if the ODRL license
covers software, the rights holder could provide the software at a very
low price but with no guarantees on performance while at a much higher
price with guarantees on performance or number of bugs.

7. Lifetime
In an electronic medium, the lifetime of a contract (or offers etc) is
important as there are very few precedents (if any) that can be used in
case of disputes.

8. Offer, Counter-Offer and Requests
Although the text in my section is correct, there are some problems
encountered in a scenario where a client makes a counter offer.
Specifically, electronic transaction law in some countries insist on
certain regulation regarding consumer protection from the party that
makes the offer. Thus, when a client makes a counter offer, (s)he would
be required to abide by such regulation removing the potential for
anonymous negotiations (from the client). Thus, it is suggested that we
only use the terms Offer (from the rights holder) and Request (from the
client).

9. Country of residence (for client)
Depending on the country of residence for the client, the rights holder
has to abide by certain consumer protection legislation etc. For
example, in the case of a EU citizen, a rights holder outside the EU
cannot store personal information unless they have signed a safe harbour
agreement.

10. Tax
I am not sure if the payment model takes care of tax issues, but this
could be an element under legal section.

11. Fair Use policy
In my ACM-DRM paper last year (which is an evolution from my ODRL
workshop paper) I detailed using negotiations as a mechanism to enable
fair use.

The professor suggested that we have an element in the license that
details the rights holders position on fair use and how to approach for
fair use. Thus, if the license agreement is based in Europe, (s)he can
state that fair use is not offered etc.

--------------------------------
Ok, I hope that all made sense and I didn't make any typos etc.

Alapan
-- 
Alapan Arnab
Data Networks Architecture (DNA) Laboratory
Department of Computer Science
University of Cape Town
Rondebosch, 7700
South Africa

Tel: +27 21 650 3127
Web: http://people.cs.uct.ac.za/~aarnab/
Blog: http://idiots-mind.blogspot.com
----------
"You must always believe that you can be the best, but you must never
believe you have achieved it".
Juan Manuel Fangio