skip to main page content CETIS: Click here to return to the homepage
the centre for educational technology interoperability standards

skip over the long navigation bar
Home
News
Features
Events
Forums
Reference
Briefings
Press centre

Inside Cetis
what is Cetis?
Contact us
Cetis staff
Jobs at CETIS


 




Syndication
XML: Click here to get the news as an RSS XML file XML: Click here to get the news as an Atom XML file iCAL: Click here to get the events as an iCalendar file

Background
what are learning technology standards?
who's involved?
who's doing what?

CETIS Groups
what are cetis groups?
what difference can they make?
Assessment SIG
Educational Content SIG
Enterprise SIG
Metadata SIG
Life Long Learning Group
Portfolio SIG
Accessibility Group
Pedagogy Forum
Developer's forum

Subjects
Accessibility (310)
Assessment (74)
Content (283)
Metadata (195)
Pedagogy (34)
Profile (138)
Tools (197)
For Developers (569)
For Educators (344)
For Managers (339)
For Members (584)
SCORM (118)
AICC (18)
CEN (34)
DCMI (36)
EML (47)
IEEE (79)
IMS (302)
ISO (21)
OAI (24)
OKI (20)
PROMETEUS (12)
W3C (37)

print this article (opens in new window) view printer-friendly version (opens in new window)

Have your say on your rights

The rumbling conflict over intellectual property rights in the digital age has reached e-learning. Whether you primarily produce learning content or consume it, ways of expressing your rights are going to be defined, most likely by the language that the IEEE LTSC Digitial Rights Expression Language (DREL) workgroup will be working on. Fortunately, they are gathering requirements now to make sure that language expresses what you need it to express.

It is becoming clear that digital rights management is not a simple, one stop solution. Just slapping some kind of software lock on a learning object or other digital resource is not enough; the lock doesn't know who can open, under what conditions.

For that, a rights policy needs to be formulated that defines who can do what to which resource under what conditions. And in a way that is acceptable to whoever holds the rights to the resource. But a policy (or licence, if you like) is a human agreement. Computer systems need to read it too in order to make sensible decisions about it. Like telling a software lock to open or close.

A DREL is the machine readable form in which a rights policy is written.

That means that the feedback that the IEEE DREL group is after only relates to what kind of policies a DREL needs to be able to express. It is not concerned with what a rights policy should look like, nor how a rights policy is to be enforced (if at all). Policy is a matter for the content producer, and rights enforcement a matter of what a particular institution's VLE or repository is able to do.

That still makes a DREL a pretty cricitical component of the whole rights management infrastructure. It's abilities and limitations determine what kinds of freedoms or restrictions an author can slap on content, or a user will have to live with.

While it seems that that sort of thing may seem more relevant to publishers and libraries, it does affect pretty much anyone in the education field. Any educator or academic produces lots of content, and consumes lots of content. It's part of their job. Rights assertion, therefore, goes to the heart of educators' livelihoods.

But there also requirements on a DREL that go beyond just the kinds of rights it can express. And that, irony of ironies, concerns the intellectual property rights that rest on the DREL itself.

The situation is that the IEEE DREL group is not interested in making a new DREL from scratch. As a standards body, it is much more interested in standardising what people already use. There are plenty of DRELs already in use, so no need to add another. The job is more about choosing an existing DREL that satisfies the needs of the e-learning community, and extends it if need be.

Great stuff, but the problem is that most of the existing DRELs have not just copyright, but also patent claims on them. Should any DREL bits that make it into the IEEE LTSC standard be encumbered with patents, two things can happen: either the patent holder agrees that it will not require licensing restrictions from whoever is doing something with the standard, or it can impose a "reasonable and non-discriminatory" license. Which means that it won't be too outrageous, and will be the same for everyone.

Except that such licenses are pretty much incompatible with open source software. Most open source licences require that the code is re-useable and modifiable by anyone, without restriction. A separate licensing requirement for a part of, say, an open source VLE means that that VLE is not available to anyone without restriction. Certainly one to bear in mind when formulating educational requirements on a DREL.

The main focus of the requirements gathering exercise is about actual use scenarios. Just narratives (or formal use cases) that illustrate what you'd like to be able to do with content rights if there were or is a DREL that does what you want it to do.

More detailed information and contact information is available in the DREL Requirements Request for Input document (36 kb, PDF)

Related items:

Comments:

copyright cetis.ac.uk
Creative Commons License This work is licensed under a Creative Commons License.

syndication |publisher's statement |contact us |privacy policy

 go to start of page content