[jsword-devel] Re: JSword license

Chris Little jsword-devel@crosswire.org
Tue, 30 Sep 2003 12:30:37 -0700 (MST)

On Tue, 30 Sep 2003, Mike Kienenberger wrote:

> Mike Kienenberger <mkienenb@alaska.net> wrote:
> Chris, don't bother answering this.   Even if it's legal to do what I did, 
> it seems to clear to me that there's some opposition to any of the Sword 
> Project data being used by anything other than GPL code.

There exists to good reason to access our data except through our library.
If you need to provide access to the whole set of books we offer, 
clean room re-implementation is prohibitively difficult.  If you need just 
a few books, you should use them in some other format anyway. (OSIS e.g.)

> It bothers me that some of you seem more eager to spread the "Gospel of GPL" 
> than the Gospel of Jesus Christ.

This is a terrifically bad argument.  Or maybe just a grossly flawed 

The volunteers who have brought the SWORD Project to where it stands today 
have given well over a hundred thousand hours of their time to provide
millions of copies of scripture in nearly 100 languages to people all over 
the globe.  The only limitation we've put on those who wish to extend our 
work is that they follow the same rules we do, as described in the GPL.

This protects our work from misappropriation by commercial interests.  

If you can't follow our license, try finding someone else who gives you 
anywhere near as much freedom as we do.  They don't exist.

> > [W]ere code released that violated our license, we would probably begin 
> encrypting all data
> > and compressing using different algorithms or granularities.
> By the way, this would violate the GPL license if done effectively.  :-)

Not at all.  All our work is GPL licensed, and all the code necessary to 
do this has been present since the 1.4 branch.  It would simply increase 
the number of data formats to reverse engineer 2-3 times.  Not to mention, 
it's pretty much impossible to claim that you'd done a clean room 
implementation that correctly handled our encryption.