[sword-devel] DRM entries in .conf files

[Chris Little]

> 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. :)

--Chris