Chris Little wrote:
FFI Squeak's Foreign Function Interface.On Fri, 17 Jan 2003, Jimmie Houchin wrote: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.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?
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.
Yes, RMS does view Squeak/Smalltalk in this manner.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.)
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 _______________________________________________ sword-devel mailing list [EMAIL PROTECTED] http://www.crosswire.org/mailman/listinfo/sword-devel
