Creative Commons, Broken?

I am both an enthusiastic supporter of Open Source and photographer, these two forces collide in the form of the Creative Commons or ‘CC’; a free licensing scheme for all creative works with similar ethics and principles behind the common Open Source software licenses like the GPL or BSD.

I have been licensing my photography work under a CC-by-sa-nc for over a year (that’s creative commons, attributation, share-alike, non-commercial for those of you that are yet to be ofe with the CC) and recently ranted at my good friend Simon Hailstone about his ‘all rights reserved’ approach to his own photography. I proclaimed loudly that, given a CC-nc license your work will propagate and permutate the many layers of the internet increasing aweness of your work while protecting you to take legal action against any one revenue stream that may be abusing your work enough to fight about.

His retort was both well informed and accurate, pointing me in the direction of a number of bog proclaiming that the CC was in fact useless in the licensing of creative works. The usual FUD (fear, uncertainty and doubt) was expelled on the basis that the CC options were confusing and often mistaken, or that the CC was only a free-for-all approach to licensing work. However, one issue did interest me, it is possible to later revoke CC licenses. This does not effect those works that were obtained prior to the revocation; however it does open up the following issue:

Given the current CC suite commercial users are open to copyright trapping with the following pattern:

1. Register a work with an authority retaining non-commercial rights.
2. Publish your work under an open CC license, for instance on Flickr.
3. Await a commerical organisation to (legally) use your work for some commercial gain.
4. Revoke the CC rights for commerical use, removing evidence of previous CC licenses.
5. Accuse the commercial organisation of illegal use and file a compensation claim in the courts.

In this case the court would wrongly side with the prosecution since hard evidence can be found that the work was in fact licensed before the use of the work by the commercial organisation. This issue is that, when purchasing stock images, a company has a record in it’s financial accounts of a transaction concerning that work. Even if that transaction was or $1 it would protect the company from such claims. However, given the amount of freely available work on sites such as Flickr, a company can obtain a myriad of work for free. The issue here is that, aside from a copy of the work (perhaps with an accompanying license which is easily faked) the defence is virtually useless.

The result here is that our prosecution wins the case and awards the photographer:

• The cost of registration with the authority (<$100)
• The cost of the court case
• The earnings raised from the unlicensed use of the work
• And possibly damages depending on how the work was used.

This is not the first time this has been addressed as an issue; a while back FlickrCash.com was created in order to register a license for images on Flickr. However FlickrCash charged considerably over the odds for this service and was taken to court for abusing licenses (it wasn’t), gaining enough momentum for Flickr to force its closure.

So now we’re back at square one: only, the solution would appear to be

We need a low cost (potentially free) way of recording a work’s licensing that can be used as a winning defence in a court of law.

With my background rooted in Computer Security I propose the following registration protocol:

Note: at this stage I’ll be flummoxing into some cryptographical notation which will bore you, skip to the last paragraph if you’re not interested:

Given:

• A one way hash function H where H(Z) denotes the processing of work Z with the function H
• A PKI system with public key k and private key s
• A digital sigature scheme using the above PKI
• A work W
• A License L
• A Licensor A
• A timestamp T
• A certificate authority CA with public key CAk and private key CAs

A work W is registered by licensor A with license L at time T authenticated by certificate authority CA with the following, simple protocol:

1. A creates a key-pair Ak and As, keeping As secret.
2. A registers it’s public key Ak with the CA using a registration protocol (at a promised vetting level)
3. A sends As(A,W,L,T,H(H(A),H(W),H(L),H(T))) (where , denotes concatenation) to the CA
4. The CA verfifies the signature on A,W,L,T,H(H(A),H(W),H(L),H(T))
5. If successful the CA verifies H(H(A),H(W),H(L),H(T)) using A,W,L,T
6. If successful the CA stores and responds with CAs(A,W,L,T,H(H(A),H(W),H(L),H(T))
7. A verifies the sigature on CAs(A,W,L,T,H(H(A),H(W),H(L),H(T)) and H(H(A),H(W),H(L),H(T))

The token CAs(A,W,L,T,H(H(A),H(W),H(L),H(T)) can then be published with work W and verified simply with the CA by any potential licensee, guaranteeing it with a mathematically challenging (and supportable in court) way of proving that the work was gained legally.

The only issues here are that:

• The certificate authority must promise a certain level of vetting on the publisher of the work.
• The certificate authority must retain the keys of all registered users and work at a cost
• The ethics of an open source license is contrary to any registration protocol.

However if we take that the service is run at cost-price and supported by an organisation such as the EFF I beleive we have a sufficient level of defence and a service which may well be of use for all creative professionals publishing outside of the medium of code.

Comments would be greatly appreciated.

Update

Additionally the CA can be replaced by a Transparent Trusted Third Party with the following:

Given the same assumptions as above, replacing the CA with a TTTP with keypair TTTPk, TTTPs.

1. A registers a public key Ak with the TTTP
2. A publishes As(A,W,L,T,H(H(A),H(W),H(L),H(T))) along with Ak,A,L,T and work W.
3. The licensee verifies As(A,W,L,T,H(H(A),H(W),H(L),H(T))) with Ak
4. If successfull the licensee uses the work W

In the case of dispute the TTTP is invoked thusly:
1. Licensee passes the TTTP A,W,L,T, As(A,W,L,T,H(H(A),H(W),H(L),H(T))).
2. TTTP verifies using stored public key for A, Ak.
3. If successfull the TTTP issues to the licensee a defence token D=TTTPs(A,W,L,T,H(H(A),H(W),H(L),H(T))).

Now you can use any public signature, for instance OAuth or Ident.ca using the ‘register and forget’ mentality, if you forgive the military overtones.

Again comments welcome.

American Airline A300, With WiFi Please

In what will now become a great tradition, well okay this is only the second year, I hereby list my top three (not too much to ask right?) digital ideals that I would like realised and wrapped in a pretty bow fro Christmas 2009:

1. OpenScrobble: I appear to have a bewilderingly large number of media sources in my life. Last.fm for work, an iPhone when I’m on the move and Boxee/FrontRow/iTunes at home, I’m also soon to be investing in an AppleTV for my telly-box. I love the way boxee has a social element and I love the way my iPhone scrobbles back to last.fm but I want it for all my media players. Thusly I propose ‘OpenScrobble’ an open standard for sending, storing and receiving media player information inc. plays, rating etc.
2. Decentralised Social Networks: This one is a rollover from 2008 and I’ll continue to blab about the user id/password anti-pattern and the annoyances behind walled-garden approaches (without sounding too much like @psd. This is particularly interesting when combined with Christmas want no. one.
3. Wireless skies: I know American Airlines are already trialing this with mobile phones but I beleive there is no reason why a fat 3G pipe cannot be carried from the plane along an ethernet to each seat on the craft. I think I speak for all digiphiles when I say the most irritating thing about a long haul flight is that you must consider your entertainment options long before you board. Come to think about it I’d be happy if all airports themselves had WiFi too a la Bratislava, Slovakia.

And that’s it… lets wait and see what Santa’s Elves can do!