[sword-devel] Distribution/Copyright issues

Jordan Wiens sword-devel@crosswire.org
Fri, 6 Sep 2002 12:17:13 -0500 (CDT)

Along those lines, many online ebook places use your credit card number
and expiration to decrypt the encrypted file.  Of course, this assumes you
are unable to crack the decryption engine so that it outputs the raw
(unencrypted) text after you've entered the CC, allowing the unencrypted
version to be distributed, but that's besides the point.  The idea is the
same as you pointed out with personal information.  I wouldn't be suprised
if some publishers were fans of that idea as I have seen a number of
(specifically palm and pocketpc) ebook publishers using this technique.


On Sat, 7 Sep 2002, Christian Renz wrote:

> >conditions. I would be surprised if they didn't have some kind of 'no
> >modification allowed' clause, or restricted copying or restricted
> >printing.
> Actually, sword isn't at much of a disadvantage here. Even the format
> of some closed-source bible apps is well known, so that the text could
> be extracted. A slight benefit is being able to hide decryption keys
> in the software better, so that the modules themselves can be
> encrypted. However, sufficient debugging skills can render this
> benefit nonexistent. (Incidentially, I was able to extract the text of
> the TNIV from the text of the encrypted PDF at the TNIV website using
> an open-source library. Security only lasts while people are too lazy
> to break it.) I'm not advocating cracking here, of course -- just
> showing how small the perceived disadvantage of open source is.
> As for possible arrangements: We could go as far as giving the
> distribution power to the publisher. That is -- not the Sword project
> hosts the download, but the publishing company itself, on their
> website. That leaves us in the position that the company could retract
> the module any time. On the other hand, it is good promotion for sword
> when Bible publishers offer sword-compatible modules :-)
> Additionally, we could offer a encryption mode that is based on
> personal data. E.g. the user submits his name and e-mail address and
> gets a personal key. Not that this is more secure, but it feels more
> secure :-) and people will probably be less willing to give the key to
> somebody else.
> An incentive for publishers to use it would be that we make it
> possible for them -- by creating the module, creating an
> infrastructure to create personalized keys (either on the crosswire
> server or by giving them scripts to run on their server), etc. The
> less work involved for them, the more attractive it is.
> And what we need most, of course, is favour with the copyright
> holders. That's the part where the prayer comes in... Ora et labora
> ("Pray and write code").
> Greetings,
>    Christian