[sword-devel] DRM entries in .conf files
Sun, 16 Dec 2001 19:48:03 -0800
> Understood. It would considerable effort and time to
> implement a DRM solution. It would be interesting to think
> about and discuss though. Don't you think the likes of Thomas
> Nelson would be more likely to grant access to there
> translations if we could demonstrate there protection?
I agree. I'm okay with allowing copyright holders to prevent user X
from giving their content to user Y. I'm not okay with copyright
holders telling user X what he may do with their content once he's paid
for it, so long as he doesn't violate their copyright. I don't like DRM
implementations that allow for content expiration, limiting printing,
limiting viewing, etc.
If you can think of a good solution that protects the content that can
fit within our system, I'd love to hear it (assuming you can explain it
in small words that I would understand). :)
Our current implementation is at least as secure as any of the others
I've seen. Our content is really & truly encrypted, rather than relying
on key files that tell them they should be unlocked. But our weak link
is that content is secured by a single key (per module) rather than
unique keys for each user. And it's relatively easy to just copy the
whole tree to another computer (but I think that's probably the case
with all Bible software).
> I understand what CopyrightHolder, CopyrightDate and
> TextSource refer to, but I am lost on the purpose you intend
> for License and QuoteLimit. Can you elaborate?
License indicates the type or terms of the license. Examples would
include "public domain", "non-commercial use", "permission to distribute
granted to CrossWire", etc.
QuoteLimit would be the maximum number of verses/chapters/books a user
is allowed to quote, frequently 500 verses provided that the entire text
of a single book is not quoted.
> > Separately, I would add a "Writable" field, indicating that a module
> > may be written to. This would be set for modules like personal
> > commentaries and modules that are being used in distributed editing
> > systems. And possibly a "WriteKey" field to hold a unix crypt()
> > password, or some kind of MD5 hash if Mike prefers :), to be checked
> > whenever a write operation is attempted. (But the hash can't use
> > either the module or the .conf file since both can be modified.)
> OK, now I'm confused. I thought you didn't want to try and
> protect the content?
These are just indicators to a front end that they should/should not
attempt to write to a given module. If there's no Writable field, they
shouldn't write. If there is and there's a WriteKey field, it's
contents should be used to determine whether a user has permission to
write to the module.
For example, suppose there's a public distributed editing setup for the
Leningrad codex. User A has proven that he has a good command of
Hebrew. User B doesn't know the difference between aleph and bet. User
A should be allowed to help, but User B should not; so User A is given a
password and User B is not. Somewhere along the line, that password
gets checked against the value in WriteKey to confirm that User A has
got a valid password for editing the file, so the engine allows him to
do so. There's also a really good argument that this shouldn't be
handled by Sword at all, and the front end should do user permissions
and authentication independent of Sword. :)