[sword-devel] Sword license

[Jimmie Houchin]

Chris Little wrote:
> On Fri, 17 Jan 2003, Jimmie Houchin wrote:
>>>If you want to use Sword as a library of any sort (linked statically or 
>>>dynamically) it requires that your work be GPL since we are not LGPL 
>>>licensed.
>>
>>Does this mean I could not use the Sword libraries as a plugin?
>>Would this also affect using the libraries via FFI in Squeak?
> 
> If you're using Sword code in another work, that work has to be GPLed.  
> Plugins are still compiled & link GPL code, so they also have to be GPLed.  
> I don't know what FFI is, but I imagine all these situations are verboten 
> by GPL.

FFI Squeak's Foreign Function Interface.
http://minnow.cc.gatech.edu/squeak/1414

"""
FFI, the Squeak Foreign Function Interface, is used to call functions 
located in shared libraries that are not part of the Squeak VM nor its 
plugins. It also provides means to read and write memory structures that 
are associated with the use of those shared libraries. A typical use is 
to directly invoke operating system APIs. As such, applications that use 
FFI can only be used on the platform(s) that support the particular API 
being used. C conventions are used throughout, though the external 
function could have been written by any language capable of generating 
object code that follows C conventions.

Technically what happens is you define what the interface is, the 
parameters, types etc. Then when you make the call, the FFI logic 
assembles the data from the Squeak Objects into the proper structures 
according to the routine calling conventions for your architecture, and 
of course manages the return values. So no magic but perhaps just a 
little assembler in the plugin to properly deal with all the registers 
and condition flags.
"""

I don't currently know how to do FFI. I just knew it is an option in 
Squeak. The GPL may rule that out. I don't know.

>>Understood. I am not really to my understanding, not looking for a more 
>>free license. Only one which doesn't affect the rest of the Squeak 
>>environment. I don't believe the email program, web browser, mp3 player, 
>>solitaire game, etc. all inside of the Squeak image should become GPL 
>>simply because I am writing a Sword frontend.
> 
> GPL isn't quite this viral.  Licensing one program under GPL can't affect
> the licenses of programs for which you don't even own a copyright.  I'm
> not really clear on what these Squeak images are, but I don't think they
> make as much difference as everyone seems to consider them to.  The
> incompatabilities may be possible to slip through the system library
> loophole in the GPL.  (If RMS really did comment on GPL/Squeak
> incompatability then it sounds like he's seeing the speck in Squeak's eye
> and ignoring the motes in GPL's.)

Yes, RMS does view Squeak/Smalltalk in this manner.
One of the Squeak listmembers is an IP Attorney who has had 
correspondence with RMS on this subject. RMS is quite hostile to such.

"""
Andrew C. Greenberg wrote:
Thread: LGPL and SqueakMap
12/22/2002 9:49 PM
FSF has been remarkably hostile to Squeak and Squeak-L, and has no
interest in catering to monolithic images.  Indeed, FSF is hostile to
use of LGPL for the most part.  Their view is that the world should be
GPL'd.
"""

Because all source in Smalltalk is all together in a single monolithic 
image (file). FSF/RMS do not view them individual but singularly.
As such GPL code can't be used in Squeak (not honestly), because it does 
impact other code which it has no authority. Since it has no authority, 
it can't be used. Hope that makes sense. :)

> If we get the GPL stuff in Sword replaced, you might be able to talk Troy 
> into granting you a non-GPL license for your particular work.  But linking 
> a binary seems like it voids part of your intent in creating a 
> cross-platform reader.

Linking (plugin) or FFI weren't my preferences.
They seemed to be an option in lieu of writing my own Sword Module 
reader. However, the licensing potentially affected even writing the reader.

My main goal is to produce an open source, very cross-platform, very 
powerful Bible software program with a large variety of available texts.
The Sword project seemed/seems like the best place to plugin and do this.

> Can I mention again that I think an OSIS-based (be it native OSIS or some
> kind of OSIS-derived indexed format) reader would be a really cool program
> to write?  We've got export paths already written to convert most of our
> module types to valid OSIS documents and Harry Plantinga at CCEL is
> creating lots of OSIS documents from ThML ones too.  There should be
> thousands of OSIS documents by the end of 2004, between CrossWire, CCEL,
> ABS, and others contributing to efforts to create a library of texts.

I do fully desire to be able to use OSIS documents.

To me Sword project is the most open Bible software availalbe.
This is why I chose this project.

Texts wise, what would I miss out on by going an OSIS route?
Would there be documents unavailable, but available via Sword?
Would the Sword Modules (not libs) offer features not available via OSIS?

Thanks again for all your help.
I really didn't attend to dominate the list. :)

Jimmie Houchin