> 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
