[Odrl-version2] Make it Simpler?

[Steven Rowat]

Hi,

I also agree. I find the Jamkhedkar et al. paper has several 
convincing arguments. I'm glad it's being discussed!

I would like to add the following two thoughts:

1.
Such simplification will help to solve the problem of individual 
versus corporate/bureaucratic control of the DRM system. That is, the 
current large-scale monolithic DRMs will likely be weighted in favour 
of large organizations that can control who gets entry into the 
system (a danger I outlined in more detail in my web discussions of 
this issue). I believe that individuals creating work that gets used 
by individuals, without large group control, is a potentially 
enormous benefit of the Internet and DRM working together. It seems 
clear to me that a simplified REL with smaller extensions that can be 
developed and modified by third parties (including by non-profit 
groups) will allow these two poles of that continuum (individual 
versus group control) more likelihood of co-existing. For instance, 
the total needs of the following scenario:

music file created by A -> downloaded for a fee by B -> can be played 
anywhere but not changed or resold.

are far simpler than the needs of:

music file created by A -> can be resold by corporation X as long as 
it is only changed via parameters Q -> can be resold by corporation Z 
as long as A gets N% of the royalties that Z pays X - can be played 
once on hardware B or M, but not transferred to hardware L, or....

Anyway, you get the picture. The second scenario can go on forever.

What the Jamkhedkar paper is telling us is that there is a core idea 
about 'muisic file created by A' that is all the REL needs to 
specify; and that most of what is in both the above scenarios is not 
part of this. I believe that making a core simplified REL will make 
it far more likely that the first scenario above can become a 
reality, since the extra parts required to be built by 'middleware' 
are also simple. If we wait for a REL that can satisfy the second 
scenario, then it seems likely that either it won't happen at all, or 
that the costs of delivering the functions will be so high that most 
them will be exlcuded for individuals - possibly even all of them.

2.
Since both Xrml and ODRL are developed and developing, such a 
refocusing will allow them to specialize and cease to be antagonists. 
I suggest it makes the most sense for ODRL to become the core REL, 
and for XrML to fragment and specialize in middleware implementations.

Consider these three quotes from the paper:

"...this simplification will require manufacturers of rendering
devices to support only the core of the language, allowing
heavy-duty rights management functionalities to be implemented
on the server side, where they belong."

and:

"Because rights are much less transient than technology, their 
expression should not
be tied to any language. "  

and:

"Thus, the core REL should not specify how
rights should be created, authenticated, communicated, audited,..."


These ideas suggest to me that the core DRM REL should be concerned 
with long-term human rights; essentially with ethical standards being 
met; standards that have evolved over millennia. The middleware 
interacts in real-time with the current social structure to implement 
this, in both hardware and software. I suggest that, like morality, 
any general human language is free. Any implementation of a language 
for the purpose of buying and selling, or distributing, in real-time, 
does not need to be free and usually isn't. Therefore the ODRL, which 
is free and defined as remaining as such, is more appropriate for the 
core, and XrML, which charges a fee and is defined as remaining as 
such, is more appropriate to develop the middleware extensions to the 
ODRL core.


Steven Rowat



>  > This is just an idea - and I welcome comments from the WG.
>>
>>  (and happy new year to all!)
>>
>>  Cheers
>>
>>  Renato Iannella
>>  ODRL Initiative
>>  http://odrl.net
>>
>>  [1] <http://portal.acm.org/citation.cfm?
>  > id=1179522&jmp=references&coll=GUIDE&dl=GUIDE&CFID=15151515&CFTOKEN=6184
>  > 618>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.odrl.net/pipermail/odrl-version2/attachments/20070116/c2ecb314/attachment.html