On Thursday 20 November 2008, Leslie Newell wrote: > 1) Looking closer, RCSlib is LGPL so I can safely use it. However the > header files that define the data types are GPL2 which means I can't use > them directly. Assuming the data types haven't changed since EMC1 then I > could use the public domain EMC1 header files.
RCSlib is public domain, as is EMC[1]. You will find the relevant data structures have had additions made, but I see no reason why you couldn't pad out the originals in order to realign the required fields. > 2) Convince the authors of the affected header files to change the > license to LGPL. The source files can still be GPL2 with LGPL headers. > This has a number of political considerations and affects quite a few > header files. Not gonna happen - Anyone who questions the validity of (L)GPL status is dismissed as a "troll". > 3) Use the Telnet application. Assuming there isn't too much overhead > this bypasses the GPL issues completely. Or you could use Tcl/Tk. > 4) SheetCam's plugin interface is structured so it can be used over a > network, pipe or any other communications interface. Therefore plugins > could be written that run in their own memory space and aren't directly > linked to SheetCam. The relevant plugin headers and source files would > have to be released under the LGPL or a modified GPL (allowing linking > to SheetCam when not used in conjunction with GPL code). This isn't a > problem. This solution would have a lower overhead than option 3 but I > don't know how much of a difference it would make in practice. How much control are you expecting from any proposed interface ? The range of "NML commands" available to a UI is limited to Load/Start/Step/Stop of a file, single axis jog, simple MDI passing, and a few basic On/Off functions. To pass a series of low level canonical commands requires a number of significant changes at the task control level.. If you wanted to bypass the task control level and handle sequencing within SheetCam, you could use shared memory to "talk" directly to the realtime code. > 5) If the Telnet option adds too much overhead then modify it to use > binary protocol rather than a text based protocol. I suppose I need to > do some testing and see how had I can push the Telnet interface. Converting to a text string, piggybacking on to telnet, and then converting back to binary is certain to incur an overhead. Only you can decide if that overhead is tolerable. > I want to stay legal without annoying the EMC developers. This is not > worth getting into a fight over. It is an issue that will keep coming up, but there isn't the desire or willingness to resolve the fundamental problem(s). ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
