Enhanced Machine Controller

On Wed, Nov 19, 2008 at 06:42:47PM +0000, Leslie Newell wrote:
> I would like to write a plugin for SheetCam that provides a simple front 
> end to EMC. This would integrate motion ontrol and CAM in one package. 

An alternative plan that would integrate them somewhat but not force
the user to learn a new front-end would be to just cause SheetCam to
load/reload the file in AXIS when the user does the export.  This
would be a trivial change you could make by calling the axis-remote
program.

% axis-remote -?
axis-remote: cause AXIS to open, reload its opened file, or exit

Usage: axis-remote [--ping|--reload|--quit|filename]
       axis-remote [-p|-r|-q]

Les,

You might consider using the telnet interface emcrsh, documented here:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Emcrsh

If you write your interface to the specification without copying any of the
server side code, there should not be a problem with GPL or other licensing.
The interface is plain text, so it is easy to test over a telnet session,
and 'help' is supported over the telnet session as well.

This interface also supports as many simultaneous connections as telnet will
handle, but will allow only one session to be "in control". IOW, any number
of sessions may monitor the CNC, but only one may issue commands. It does
not interlock with any local interfaces such as Axis, however.

Regards,
Eric

I would like to write a plugin for SheetCam that provides a simple front end
to EMC. This would integrate motion ontrol and CAM in one package. 
The problem is that SheetCam is closed source as I need to make a living out
of it.

Can this be done without violating the EMC license?

If it can, is it possible to have two GUIs controlling EMC at the same time?
For instance SheetCam could provide a basic position display and
run/pause/stop controls. For anything more sophisticated, the user could use
Axis or any other GUI.

On Wednesday 19 November 2008, Leslie Newell wrote:
> I would like to write a plugin for SheetCam that provides a simple front
> end to EMC. This would integrate motion ontrol and CAM in one package.
> The problem is that SheetCam is closed source as I need to make a living
> out of it.
>
> Can this be done without violating the EMC license?

Except for a couple of files that are copyright of MS and/or have 
non-commercial restrictions attached, non of which you would use, you may do 
what you like with the EMC code - The only restriction is you can not claim 
copyright.

> If it can, is it possible to have two GUIs controlling EMC at the same
> time?

Yes, you can have multiple GUIs attached, although it does open up some 
safety/security questions.

Hi Chris,

Yes I had spotted that one but I was looking fro a bit more control than
that. Currently the Mach plugin on the Windows version does something
very similar.

Thanks,
Les

Chris Radek wrote:
>
> An alternative plan that would integrate them somewhat but not force
> the user to learn a new front-end would be to just cause SheetCam to
> load/reload the file in AXIS when the user does the export.  This
> would be a trivial change you could make by calling the axis-remote
> program.
>
> % axis-remote -?
> axis-remote: cause AXIS to open, reload its opened file, or exit
>
> Usage: axis-remote [--ping|--reload|--quit|filename]
>        axis-remote [-p|-r|-q]
>
>
> -------------------------------------------------------------------------
> 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
> Emc-developers@...
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

Hi Eric,

That is interesting. I wonder what sort of performance penalty there
would be using this interface? To get a reasonable display update rate,
there is going to have to be a lot of polling going on...

Thanks,
Les

Eric H. Johnson wrote:
> Les,
>
> You might consider using the telnet interface emcrsh, documented here:
> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Emcrsh
>
> If you write your interface to the specification without copying any of the
> server side code, there should not be a problem with GPL or other licensing.
> The interface is plain text, so it is easy to test over a telnet session,
> and 'help' is supported over the telnet session as well.
>
> This interface also supports as many simultaneous connections as telnet will
> handle, but will allow only one session to be "in control". IOW, any number
> of sessions may monitor the CNC, but only one may issue commands. It does
> not interlock with any local interfaces such as Axis, however.
>
> Regards,
> Eric
>
> I would like to write a plugin for SheetCam that provides a simple front end
> to EMC. This would integrate motion ontrol and CAM in one package. 
> The problem is that SheetCam is closed source as I need to make a living out
> of it.
>
> Can this be done without violating the EMC license?
>
> If it can, is it possible to have two GUIs controlling EMC at the same time?
> For instance SheetCam could provide a basic position display and
> run/pause/stop controls. For anything more sophisticated, the user could use
> Axis or any other GUI.
>
>
>
> -------------------------------------------------------------------------
> 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
> Emc-developers@...
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

Paul,
I assume Leslie Newell is asking about emc2.  The vast majority of emc2
is covered by one of two Free Software licenses, GPL2 and LGPL2.1.  I
know you are aware of this, Paul, because you are the former developer
who added the GPL2 notice block to many of the source files!  For
example:
    http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/emc/nml_intf/emc.cc#rev1.2

Jeff

Les,

I poll position and status information over a network 10 times per second
without any problem at all. I have also tested with 8 or so simultaneous
connections again without any noticeable degradation. You won't get the
granularity that Axis provides in its live plot, but if you just match the
step number with the associated vector you can do a quite adequate live plot
for most situations.

Regards,
Eric


That is interesting. I wonder what sort of performance penalty there would
be using this interface? To get a reasonable display update rate, there is
going to have to be a lot of polling going on...

At least two header files that are likely to be linked with any user
interface of emc2, emc.hh and emc_nml.hh, include GPL2 notices, and thus
cannot be used in proprietary (or indeed any non-GPL2) software.

Likewise, at least one source file which is likely to be linked with any
user interface of emc2, emc.cc, includes a GPL2 notice.  Likewise, these
cannot be used in proprietary software.

Jeff

Hi Paul,
> Except for a couple of files that are copyright of MS and/or have 
> non-commercial restrictions attached, non of which you would use, you may do 
> what you like with the EMC code - The only restriction is you can not claim 
> copyright.
>   

Are you sure? Most of the source files I have looked at are licensed 
under the GPL. Due to the viral nature of the GPL, any software that 
links to any code containing the GPL also has to be GPLed. At least that 
is my understanding of the matter. Header files are a bit more vague and 
there appear to be many arguments as to whether GPLed header files can 
be included in non-GPL code or not.


>
> Yes, you can have multiple GUIs attached, although it does open up some 
> safety/security questions.
>
>   

Interesting. I suppose the thing to do is experiment and see what happens.

Thanks,
Les

On Wednesday 19 November 2008, Jeff Epler wrote:
> At least two header files that are likely to be linked with any user
> interface of emc2, emc.hh and emc_nml.hh, include GPL2 notices, and thus
> cannot be used in proprietary (or indeed any non-GPL2) software.

Those two files (should be just the one) define the data structures used in 
the PUBLIC interface.

> Likewise, at least one source file which is likely to be linked with any
> user interface of emc2, emc.cc, includes a GPL2 notice.  Likewise, these
> cannot be used in proprietary software.

You really need to do a full audit and understand just what gets linked where 
before making bogus claims.

Thanks Eric,

That is useful information. I suppose the thing to do is experiment and
see what happens.

Les

Eric H. Johnson wrote:
> Les,
>
> I poll position and status information over a network 10 times per second
> without any problem at all. I have also tested with 8 or so simultaneous
> connections again without any noticeable degradation. You won't get the
> granularity that Axis provides in its live plot, but if you just match the
> step number with the associated vector you can do a quite adequate live plot
> for most situations.
>
> Regards,
> Eric
>
>
> That is interesting. I wonder what sort of performance penalty there would
> be using this interface? To get a reasonable display update rate, there is
> going to have to be a lot of polling going on...
>
>
> -------------------------------------------------------------------------
> 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
> Emc-developers@...
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

Paul,

So if I stick to using NML and RCS then I can talk directly to EMC? Are 
there any docs on this side of things?

Les

> Those two files (should be just the one) define the data structures used in 
> the PUBLIC interface.
>
>   
>

On Wed, Nov 19, 2008 at 10:53:44PM +0000, paul_c wrote:
> Those two files (should be just the one) define the data structures used in 
> the PUBLIC interface.

Whether the interface is "public" is the wrong question, Paul.  You
muddy the waters by bringing an irrelevant and confusing term into it,
which I assume is your goal.

The files from the emc2 source distribution that I cited bear a GPL2
notice.

When a program incorporates a GPL2 source file (for instance, by
inclusion or by linking), that program forms a work based on that GPL2
source file.  The implications of this are spelled out at length in the
GPL2 license, and are amplified on in the GPL2 FAQ
    http://www.gnu.org/licenses/gpl-2.0.txt
    http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html

Leslie, please ignore Paul on this topic.  Nowadays he's just a troll,
and this is his favorite trolling topic.  The advice from Chris Radek
and Eric Johnson is much better and to the point.

Jeff

On Wednesday 19 November 2008, Jeff Epler wrote:
> Paul, because you are the former developer

Who the **&* are you to decide who is or isn't a "developer" ?

Hi Les

On Wednesday 19 November 2008, Leslie Newell wrote:
> So if I stick to using NML and RCS then I can talk directly to EMC? Are
> there any docs on this side of things?

Not much in the way of documentation, but then the API is simple to use. 
Probably http://www.isd.mel.nist.gov/projects/rcslib/NMLcpp.html is the most 
useful guide.

Contact me off list (or by phone) if you need any help in that area.

On Wednesday 19 November 2008, Leslie Newell wrote:
> Header files are a bit more vague and there appear to be many arguments as
> to whether GPLed header files can be included in non-GPL code or not.

Agreed - I would strongly recommend legal council from someone versed in 
software & international copyright law.

As far as I can see there are a number of options:

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.

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.

3) Use the Telnet application. Assuming there isn't too much overhead
this bypasses the GPL issues completely.

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.

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.


I want to stay legal without annoying the EMC developers. This is not
worth getting into a fight over.

Les

Hi Paul,


> Not much in the way of documentation, but then the API is simple to use. 
> Probably http://www.isd.mel.nist.gov/projects/rcslib/NMLcpp.html is the most 
> useful guide.
>
> Contact me off list (or by phone) if you need any help in that area.
>   
Thanks. I may take you up on that offer.


> Agreed - I would strongly recommend legal council from someone versed in 
> software & international copyright law. 
>   

To be honest, I want to end up with something that is 100% legal and the
EMC developers are happy with. In the end, I need to make a living out
of SheetCam. The amount of profit I get from adding a UI to EMC is
likely to be negligible so it is not worth getting a lawyer involved to
try to wangle through loopholes.

Les

Les,

FYI, there is already a hook in emcrsh for a binary equivalent protocol, but
I have so far not needed to implement it. There are several networking
issues, and I do not claim to be an expert in networking, however, as I
understand it, a standard 10 Base T / 100 Base T Ethernet packet is
approximately 1500 bytes in size. Which means, at least in the most
simplistic communications, that unless the text form of the message exceeds
1500 bytes, while the binary packet does not, you will really see no
difference in performance, because both forms are still taking one packet.

The client side library I am using is smart enough to pack multiple discreet
messages into the minimum number of packets, provided they occur close
enough in time. On the server side, I just have not looked into the
existence of a similar library or if the library I am using is doing the
same thing.

Another bandwidth saving technique I considered is the ability to tag
certain information to broadcast only on change, but no more often than a
specified interval, and perhaps with a certain dead band. The most likely
candidates for this technique would be the position and status information.
This technique is already fully compatible with the existing protocol.
Again, I did not implement this, because the performance I had been getting
was more than adequate for my purposes.

If you find otherwise, I will be glad to work with you in implementing any
of these techniques.

Regards,
Eric


3) Use the Telnet application. Assuming there isn't too much overhead this
bypasses the GPL issues completely.

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.

Thanks Eric,

To be honest, I was thinking more of the overhead in parsing the text
either end than efficient network transfer.  Presumably if I am using
local sockets then the packet size isn't an issue. I envisage most users
having SheetCam and EMC on the same machine. I will experiment with
emcrsh and see what can be done with the existing setup.

Thanks,
Les

Eric H. Johnson wrote:
> Les,
>
> FYI, there is already a hook in emcrsh for a binary equivalent protocol, but
> I have so far not needed to implement it. There are several networking
> issues, and I do not claim to be an expert in networking, however, as I
> understand it, a standard 10 Base T / 100 Base T Ethernet packet is
> approximately 1500 bytes in size. Which means, at least in the most
> simplistic communications, that unless the text form of the message exceeds
> 1500 bytes, while the binary packet does not, you will really see no
> difference in performance, because both forms are still taking one packet.
>
> The client side library I am using is smart enough to pack multiple discreet
> messages into the minimum number of packets, provided they occur close
> enough in time. On the server side, I just have not looked into the
> existence of a similar library or if the library I am using is doing the
> same thing.
>
> Another bandwidth saving technique I considered is the ability to tag
> certain information to broadcast only on change, but no more often than a
> specified interval, and perhaps with a certain dead band. The most likely
> candidates for this technique would be the position and status information.
> This technique is already fully compatible with the existing protocol.
> Again, I did not implement this, because the performance I had been getting
> was more than adequate for my purposes.
>
> If you find otherwise, I will be glad to work with you in implementing any
> of these techniques.
>
> Regards,
> Eric
>
>
> 3) Use the Telnet application. Assuming there isn't too much overhead this
> bypasses the GPL issues completely.
>
> 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.
>
>
> -------------------------------------------------------------------------
> 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
> Emc-developers@...
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

Les,

I don't think the time to parse is much of an issue, because even an
inefficient parser is going to execute orders of magnitude faster than the
transmission time over Ethernet.

Regards,
Eric


To be honest, I was thinking more of the overhead in parsing the text either
end than efficient network transfer.  Presumably if I am using local sockets
then the packet size isn't an issue. I envisage most users having SheetCam
and EMC on the same machine. I will experiment with emcrsh and see what can
be done with the existing setup.

Eric H. Johnson wrote:

>Les,
>
>I don't think the time to parse is much of an issue, because even an
>inefficient parser is going to execute orders of magnitude faster than the
>transmission time over Ethernet.
>  
>
Err - there's no particular need to actuall y transfer packets over 
ethernet, is there?

Wouldn't a local socket work just as well?  (or did I miss that this is 
supposed to be a remote user interface? :) )

- Steve

Steve,

Yes, you are correct there, but even the loopback socket seems to have some
non-trivial overhead, like on the order of 1ms. For a parser to parse a
single line of text (less than one packet size), as we are discussing here,
even 1ms is an eternity on most processors usable by EMC2.

I also see that Sheetcam is available for both Windows and Linux. I don't
know if Les was planning on supporting this interface for both versions, but
ISTM it would make a convenient gateway for the Doze version, which would
require communicating over a network.

Regards,
Eric

Err - there's no particular need to actuall y transfer packets over
ethernet, is there?

Wouldn't a local socket work just as well?  (or did I miss that this is
supposed to be a remote user interface? :) )

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).

On Thu, Nov 20, 2008 at 04:22:05PM +0000, paul_c wrote:
> 
> 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.

This is true.

> 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..

This is true.  To do real machining you pretty much have to write a
program out and have task open and read it.  Passing one line at a
time by MDI is the only thing you could do with just NML, and that's
a bad approach because motion would not be smooth.

> 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.

This is probably not true because motion.h, motion.c, control.c, are
all GPL2.  Jeff already posted this link but it's relevant again.
The FAQ admits it's a fuzzy area.

http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MereAggregation

> 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 bet humans are pretty slow compared to these kinds of operations.
This is just a GUI.

> > 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).

I have not seen any fight, just a lot of statements of fact and a few
statements of misinformation and those are being politely corrected.

Chris

Hi Paul,

> Not gonna happen - Anyone who questions the validity of (L)GPL status is 
> dismissed as a "troll".
>   

IMHO, this would be a good candidate for LGPL but if the powers that be 
say no, then I just have to live with it.


> Or you could use Tcl/Tk.
>   

Wouldn't that still be linking to EMC? The GPL specifically includes 
interpreted languages. I am also not that keen on learning yet another 
programming language.


> 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..
>   

I have no intention of directly controlling movement. SheetCam will spit 
out a G-code file that EMC will then run. SheetCam will display current 
position in both DROs and on the toolpath display. It will also have the 
basic controls such as jog, run, pause etc. It is important that  G-code 
is generated because that allows the end user to modify the post 
processor for their needs.

> 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.
>   

If I experience any bottleneck problems, probably the first thing to go 
would be telnet. It would be pretty trivial to replace it with a much 
faster IPC method such as a pipe. Obviously the modified pipe version 
would also be GPLed and freely available.

> It is an issue that will keep coming up, but there isn't the desire or 
> willingness to resolve the fundamental problem(s).
>   

Making code accessible to closed source developers is often beneficial. 
For instance I use wxWidgets in SheetCam. The wxWidgets project has had 
a large amount of money and time donated by closed source developers 
because it can be used in both open and closed source projects. Also if 
you are selling a product it has to be right or you will have customers 
screaming at you. If a bug shows up it needs to be fixed as soon as 
possible. This means that any developers selling code linked to EMC will 
have a very good incentive to fix any problems and fix them quickly.

Les

> > 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.

In layman's terms what is the difference and why one over the other?
Without knowing the difference it would seem that if we could let a 
closed source use our open source software without giving them 
control over it would be a good thing.
What is the danger of having header files LGPL but the rest GPL2?
I'm not looking to start a fight just interested.

Chris Morley

_________________________________________________________________

If you modify GPLed code you have to make the modified code publicly 
available. If you write a program that contains GPLed code you are 
required to make all of your program open source. Even if you use a few 
definitions out of one GPLed header file the whole of your code has to 
be open source. If your program is linked (statically or dynamically) in 
any way to GPLed code, it has to be open source. The GPL is sometimes 
called viral because it 'infects' other code.

The LGPL is similar apart from a few exceptions. Using LGPL header files 
does not require your code to be open source unless the header files 
contain large chunks of code rather than defintions. You can also link 
to a LGPLed library without making your code open source. If you make 
any changes to the library or use significant chunks of the library's 
source code, those changes do have to be open source. The end result is 
that LGPLed code is still protected but under controlled conditions can 
be used with closed source code.

In the case of EMC, rcslib is used to allow user programs to communicate 
with the core of EMC itself. It is LGPL so I can safely use it. Think of 
it as a phone line directly connected to the guts of EMC. The problem is 
that I don't know what data to send down that link. A phone is no use if 
you can't talk! The data definitions for this are in a number of header 
files. As they are GPL I can't use them. The original GPL was a bit 
vague about headers so whoever applied the LGPL to rcslib may well have 
intended closed source applications to be able to talk to EMC. GPL2 as 
used by EMC seems to be a bit more specific.

And now a little history. EMC1 was public domain. The license 
effectively said 'do what ever you want with this code but it isn't our 
problem is anything goes wrong'.  Mach uses a modified version of the 
EMC1 G-code interpreter. Look at the Mach manual then compare it with 
the EMC interpreter docs - you may notice a few similarities :-) I 
believe Deskam and a few other control packages also use the EMC 
interpreter. Improvements made by Art and others were not fed back into 
the EMC project. Understandably this annoyed quite a few people. When 
the EMC2 project was started the EMC developers applied the GPL2 license 
to most of the original code to prevent this happening in the future.

Please note, the above is my interpretation of the situation and may be 
in error.

Les


Chris Morley wrote:
>
> In layman's terms what is the difference and why one over the other?
> Without knowing the difference it would seem that if we could let a
> closed source use our open source software without giving them
> control over it would be a good thing.
> What is the danger of having header files LGPL but the rest GPL2?
> I'm not looking to start a fight just interested.
>
> Chris Morley
>
> ------------------------------------------------------------------------
> Messenger wants to send you on a trip. Enter today. 
> <http://www.messengerbuddies.ca/?ocid=BUDDYOMATICENCA21>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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
> Emc-developers@...
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

On Thursday 20 November 2008, Leslie Newell wrote:
> When the EMC2 project was started the EMC developers applied the GPL2
> license to most of the original code to prevent this happening in the
> future. 

At the time, concerns were raised over the validity of the exercise - Duly 
ignored.. 

Now the code includes several different licenses - GPL ver2, LGPL ver2, GPL 
ver2 & later, BSD, MIT, RA, dual GPL/BSD, and probably others. Then there are 
a few files that contain problematic phrases.. i.e.:

//    This is a generated file; the "corresponding source code" is the set of
//    files used by Altera's Quartus software to generate an .rbf-format
//    fpga firmware file.

//    This program is free software; you can redistribute it and/or modify
//    it under the terms of the GNU General Public License as published by
//    the Free Software Foundation; either version 2 of the License, or
//    (at your option) any later version.

> From: paul_c@...> To: emc-developers@...> Date: Thu, 20 Nov 2008 23:26:42 +0000> Subject: Re: [Emc-developers] Controlling EMC from a non-GPL application> > On Thursday 20 November 2008, Leslie Newell wrote:> > When the EMC2 project was started the EMC developers applied the GPL2> > license to most of the original code to prevent this happening in the> > future. > 
 
So in the process of protecting parts of EMC2 from being stolen for closed 
source use. We have closed the door for any closed source from
CONNECTING/COMMUNICATING (software wise) to EMC2 ?
Thats kinda Ironic!
I'm sure that I am simplifying the situation.
What is the overall ideology of EMC2's use ?
It does seem a shame to have such great software and hard work
not be allow to really rule the world. so to speak.
If a company wanted to build a front end GUI as closed source
and connect it to an open source machine controller and sell the 
whole thing that seems to be good for us.
Sounds like Mach did this without keeping the open source- open.
The more people/compannies who use/work on the software the 
better it should be. As long as the important parts are not closed.
Again food for thought. I find it interesting and important that 
everyone know the overal ideology. 
> Now the code includes several different licenses - GPL ver2, LGPL ver2, GPL > ver2 & later, BSD, MIT, RA, dual GPL/BSD, and probably others. Then there are > a few files that contain problematic phrases.. i.e.:> 
_________________________________________________________________

On Thu, Nov 20, 2008 at 11:26:42PM +0000, paul_c wrote:
> Then there are a few files that contain problematic phrases.. i.e.:
> 
> //    This is a generated file; the "corresponding source code" is the set of
> //    files used by Altera's Quartus software to generate an .rbf-format
> //    fpga firmware file.

Paul,
Explain what is problematic about this phrase.

> //    This program is free software; you can redistribute it and/or modify
> //    it under the terms of the GNU General Public License as published by
> //    the Free Software Foundation; either version 2 of the License, or
> //    (at your option) any later version.

Paul,
Explain what is problematic about this phrase.

Jeff

On Fri, Nov 21, 2008 at 12:40:08AM +0000, Chris Morley wrote:
> 
> I find it interesting and important that 
> everyone know the overal ideology. 

This is a tough question because there is no "overall" ideology.
There may or may not be a "prevalent" ideology.

The EMC project is at least on its second "generation" of developers.
There will probably be a third "generation" in the future too.  The
various parts were written by various people.  Some we still have
contact with, some we don't.  The parts have various licenses.  This
bothers/worries some people but that doesn't make it possible to sweep
through and change the licenses to what we want, because the files'
copyrights are held by their authors.  It is why (for instance) we
can't go through and change GPL2 licenses to GPL3.

It is certainly true that the variations make the rules for
interfacing non-free code to EMC2 complex, and the rules are different
depending at what level you want to interface.

The fact remains that the licenses say what they say, and those are
the rules we will live by.  The choices to use the GPL2 in the files
where it's used were made in the past, and in a practical sense those
decisions are pretty well set.  To change licenses we would need to
get together the author(s) and subsequent contributors to those files,
and get them to all agree to change it.  Chances are this would not be
successful.

It seems to me that Leslie N is extremely cognizant of the issues (his
summary was very good) and he will be able to choose a solution that
works for him and his software, or he will find that he cannot, and
then will not.  There is no point to wondering if a different license
would make his job easier or harder.  There is also little point to
hearing everyone's opinions about whether GPL2 is the right license
for the parts of the code that currently use it, since that is not
something we can affect.

Chris

Chris Morley wrote:
>
>
> > From: paul_c@...
> > To: emc-developers@...
> > Date: Thu, 20 Nov 2008 23:26:42 +0000
> > Subject: Re: [Emc-developers] Controlling EMC from a non-GPL application
> >
> > On Thursday 20 November 2008, Leslie Newell wrote:
> > > When the EMC2 project was started the EMC developers applied the GPL2
> > > license to most of the original code to prevent this happening in the
> > > future.
> >
>  
> So in the process of protecting parts of EMC2 from being stolen for 
> closed
> source use. We have closed the door for any closed source from
> CONNECTING/COMMUNICATING (software wise) to EMC2 ?
> Thats kinda Ironic!
This seems impossibly restrictive, although I am not a lawyer.
I can't imagine that the GPL prevents open-source and closed-source 
programs from being run on different CPUs and communicating with each 
other.  It also seems that this shouldn't be a restriction even on the 
same computer.  The problem mentioned in some previous discussions is if 
the closed-source program needs to use definitions in GPL header files 
to communicate with the GPL program.  An obvious solution is to create a 
program, quite possibly a very simple one, to accept a file name, fetch 
a G-code file and make EMC2 aware that a new G-code file has just been 
loaded.  The "outside" program would not need to know any internal stuff 
about EMC2 to do this.

In fact, you could probably set up a specific directory, and any file 
that was copied, FTP'd or whatever into that directory would be picked 
up and run by EMC2, then deleted or moved somewhere else when done.

I really think the above is oversimplified, as workpiece limits may 
change from one job to the next, the tools have to be preset and in the 
right order, work offsets need to be set, etc.  But, I suppose with a 
fixture a known offset from machine home, a standard tool for all work 
(I'm thinking of nameplate engraving or something like that) it might be 
quite easy to preset the machine with a tool, home it, touch off the Z 
axis and then make nameplates all day without touching the EMC GUI.  
Halui can do all of this except loading the program file by name, I think.


Jon

The situation isn't quite that bad. You are allowed to use the output of 
a GPL program. For instance if you use an open source editor it has no 
effect on the code you are editing. The Telnet application is designed 
so you can operate EMC remotely over a network connection. However there 
is nothing to stop me connecting to it over a local connection. I am 
just using it's output. This is not very efficient but it is legal. I 
can rewrite the Telnet app to use a more efficient  communications route 
as long as I make my changes public.


 By the way, these rules only apply if you are diistributing compiled 
code. You can do what you want if you are only using the program 
yourself or within an organisation.

Les



>
> So in the process of protecting parts of EMC2 from being stolen for 
> closed
> source use. We have closed the door for any closed source from
> CONNECTING/COMMUNICATING (software wise) to EMC2 ?
>

Les,

Exactly my interpretation too. The Telnet interface works basically
identically to SMTP or POP protocols. While Postfix and SendMail are open
source (I believe), there is no GPL issue when closed source clients such as
MS Outlook connect with one of these mail servers.

The only caveat is to make sure to do a clean implementation of the protocol
making sure not to borrow any of the server side code when implementing a
client.

Regards,
Eric


The situation isn't quite that bad. You are allowed to use the output of a
GPL program. For instance if you use an open source editor it has no effect
on the code you are editing. The Telnet application is designed so you can
operate EMC remotely over a network connection. However there is nothing to
stop me connecting to it over a local connection. I am just using it's
output. This is not very efficient but it is legal. I can rewrite the Telnet
app to use a more efficient  communications route as long as I make my
changes public.


 By the way, these rules only apply if you are diistributing compiled code.
You can do what you want if you are only using the program yourself or
within an organisation.

On Friday 21 November 2008, Chris Radek wrote:
> The fact remains that the licenses say what they say, and those are
> the rules we will live by.

Yet you can't/won't say which licenses apply to what code or even what 
licenses are involved.

> The choices to use the GPL2 in the files where it's used were made in the
> past, and in a practical sense those decisions are pretty well set.

paul_c wrote:

>On Friday 21 November 2008, Chris Radek wrote:
>  
>
>>The fact remains that the licenses say what they say, and those are
>>the rules we will live by.
>>    
>>
>Yet you can't/won't say which licenses apply to what code or even what 
>licenses are involved.
>  
>
Each file or directory should have a license statement in it.  This will 
take the form of a single line pointing out the license name, or several 
paragraphs of license text (usually with a pointer to more information 
to be found on the web), or possibly something else.  If you're aware of 
any source files that don't have license statements (either in the file 
itself or in the directory in which it resides), please bring them to 
our attention.

Note: Statements like "there are licensing issues" or "licensing in EMC2 
is all FUBAR'ed" are not effective descriptions of a problem.  There is 
no intent on the part of the developers (that I know of anyway) to 
obscure the license status of any part of EMC2, so all it should take is 
a more detailed report of any problems to get them fixed.  This is the 
same as bug reporting, the more specific you are, the faster the bug is 
likely to be found.

- Steve

On Fri, Nov 21, 2008 at 11:38:00PM +0000, paul_c wrote:
>
> On Friday 21 November 2008, Chris Radek wrote:
> > The fact remains that the licenses say what they say, and those are
> > the rules we will live by.
> 
> Yet you can't/won't say which licenses apply to what code or even what 
> licenses are involved.

Oh please.  If you have a question about a particular file or files,
why not ask here or ask the author?  No need to be coy.

paul_c wrote:
> On Friday 21 November 2008, Chris Radek wrote:
>   
>> The fact remains that the licenses say what they say, and those are
>> the rules we will live by.
>>     
>
> Yet you can't/won't say which licenses apply to what code or even what 
> licenses are involved.
>
>   
Aren't the licenses right in EACH code file?

here's the first 10 lines or so of a totally random source file from 
EMC2, pulled off the web interface to the CVS repository at cvs.linuxcnc.org


/******************************************************************************
 *
 * Copyright (C) 2007 Peter XXXXX <name & email obiterated so Pete doesn't get mad at me>
 *
 *
 * This module implements a biquad IIR filter.
 *
 ******************************************************************************
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of version 2 of the GNU General
 * Public License as published by the Free Software Foundation.
<and so on...>

I'm sure there are some files that are missing proper license declarations.  It seems all the configuration files in the configs/ tree are lacking any license info, for instance.


Jon

> Making code accessible to closed source developers is often beneficial. 
> For instance I use wxWidgets in SheetCam. The wxWidgets project has had 
> a large amount of money and time donated by closed source developers 
> because it can be used in both open and closed source projects. Also if 
> you are selling a product it has to be right or you will have customers 
> screaming at you. If a bug shows up it needs to be fixed as soon as 
> possible. This means that any developers selling code linked to EMC will 
> have a very good incentive to fix any problems and fix them quickly.

How is The Smitty Ez-trol getting around the licensing problem?
I just saw it in cnczone...

Chris Morley



_________________________________________________________________

Which licensing problem?

Dave
On Nov 21, 2008, at 8:57 PM, Chris Morley wrote:

>
> > Making code accessible to closed source developers is often  
> beneficial.
> > For instance I use wxWidgets in SheetCam. The wxWidgets project  
> has had
> > a large amount of money and time donated by closed source developers
> > because it can be used in both open and closed source projects.  
> Also if
> > you are selling a product it has to be right or you will have  
> customers
> > screaming at you. If a bug shows up it needs to be fixed as soon as
> > possible. This means that any developers selling code linked to  
> EMC will
> > have a very good incentive to fix any problems and fix them quickly.
>
> How is The Smitty Ez-trol getting around the licensing problem?
> I just saw it in cnczone...
>
> Chris Morley
>
>
>
> Messenger wants to send you on a trip. Enter today.
> ---------------------------------------------------------------------- 
> ---
> 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
> Emc-developers@...
> https://lists.sourceforge.net/lists/listinfo/emc-developers

From: dengvall@...
Date: Fri, 21 Nov 2008 21:03:34 -0800
To: emc-developers@...
Subject: Re: [Emc-developers] Controlling EMC from a non-GPL application


Which licensing problem?

See the title of this thread.

Chris Morley

Dave
On Nov 21, 2008, at 8:57 PM, Chris Morley wrote: 
> Making code accessible to closed source developers is often beneficial. 
> For instance I use wxWidgets in SheetCam. The wxWidgets project has had 
> a large amount of money and time donated by closed source developers 
> because it can be used in both open and closed source projects. Also if 
> you are selling a product it has to be right or you will have customers 
> screaming at you. If a bug shows up it needs to be fixed as soon as 
> possible. This means that any developers selling code linked to EMC will 
> have a very good incentive to fix any problems and fix them quickly.

How is The Smitty Ez-trol getting around the licensing problem?
I just saw it in cnczone...

Chris Morley



Messenger wants to send you on a trip. Enter today.-------------------------------------------------------------------------This SF.Net email is sponsored by the Moblin Your Move Developer's challengeBuild the coolest Linux based applications with Moblin SDK & win great prizesGrand prize is a trip for two to an Open Source event anywhere in the worldhttp://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________Emc-developers mailing listEmc-developers@... href="nethttps://lists.sourceforge.net/lists/listinfo/emc-developers" target="_new">nethttps://lists.sourceforge.net/lists/listinfo/emc-developers 

_________________________________________________________________

> From: dengvall@...
> Subject: Re: [Emc-developers] Controlling EMC from a non-GPL application
> Date: Fri, 21 Nov 2008 21:38:48 -0800
> To: chrisinnanaimo@...
> 
> 
> Hi Chris,
> 
> As I understand it Ez_Trol was written by weber systems under  
> contract to Smithy and is simply another layer on top
> of their usual synergy.
> As far as I know it submits g-code to emc. Nothing too magic about that.
> 
> Now if you are talking about the issue of conversational programming  
> then I have no idea what they did about that.
> 
> HTH
> 
> Dave

I watched the Video and they have buttons and displays 
for controlling/monitoring The cnc while using their program.
That means they are somehow connected to EMC2.
http://www.smithy.com/milldemo.php
http://www.smithy.com/eztrolintro.php
Thats what it looks like to me anyways...

 

_________________________________________________________________

There seems to be a deliberate lack of clarity with this whole
proprietary v gpl/lgpl stuff in this thread.  It's not that the
developers are incorrect but more incomplete. You should consider this
post to be my opinion and a near rant and you might want to stay away.


On Sat, 2008-11-22 at 05:46 +0000, Chris Morley wrote:

> That means they are somehow connected to EMC2.

Yes they are and they connect both through NML and halcmd, which is a
bit like dialing up your friends on a conference call and talking.  Most
of what is happening is exactly what the use of NML (Neutral Messaging
Language) does for us.  It allows multiple graphical interfaces -- as
long as those interfaces use NML status structure calls rather than
making assumptions about the state of EMC based on something done within
that GUI.  (AXIS did a bit of this early on as did Mini.) NML allows
proprietary systems to develop NML messages and send and receive them in
a system neutral way.  

There are two Tcl/Tk based extensions to Tcl's wish shell that connect
between a Tcl/Tk based program and the NML channels.  The original,
written by FredP at NIST is emcsh.  It is commonly run on a single
computer with the rest of EMC2.  The second is the remote system emcrsh
that was written by EricJ and described in his documents at
    http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Emcrsh
I use emcsh for most all of my connections to NML and don't see any
significant loss of computer ability because of the extra messaging.
Even at 20-50 loops a second the cost is trivial and is all on the user
side of things rather than the rtai side.

Now if you prefer not to use Tcl/Tk, a similar library of NML message
classes could be developed for other languages.  In fact, a set of Java
and/or C++ NML message classes can be autogenerated using a system
maintained by WillS at NIST.  

If you prefer writing these classes in a pristine clean room way you
could study the public domain code from EMC and write the additional
codes that have been added to EMC2 to provide additional functionality
-- if you need these.  This pristine authorship of a QT4 library is what
Smithy did. (See the last paragraphs of my post for additional thoughts
on Smithy and Synergy.)

Adding the use of HAL messaging is another issue that may need a bit of
legal clarification.  My memory is foggy these days but I think that the
intent of the LGPL licensing of the source that makes up halcmd was that
it should allow a proprietary system to send properly formed, plain text
commands to halcmd.  Most of the functionality desired for SheetCam/EMC2
would not require direct HAL connections.  Again Smithy uses a
connection to Halcmd for a couple of signals.  

As for talking with the coordinate systems, tool offsets, or HAL
configuration, those are simple stand-alone files that can be
manipulated apart from EMC and their current values updated using NML
messages.  I know that some developers frown on this and want a single
funnel between EMC2 and these files but ....  If you're a software
author and can figure out a bulletproof way of handling these things,
why not.  The Smithy folk, along with the Synergy folk wrote code to
read certain blocks of a gcode file when it loads it and sets up its
tool table to conform to the tools defined during the Synergy part
drawing process. 

Smithy met with a major share of the EMC2 developers during fest year
before last and described what they wanted to do.  Smithy offered to
LGPL their QT library and make it available to others when it was
completed.  I don't believe that a formal vote was taken to either
support or work against that implementation at that meeting.  Recently,
Smithy offered their part of the GUI to the developers and are willing
to place appropriate licenses on those files.

Some of the Synergy code included in the EZ-Trol is not open and never
will be.  You can cobble together much of the EZ-Trol ability by
downloading Synergy Lite and the Smithy part of EZ-Trol (when the
developers accept it) but you will not be able to build a complete
system until you pay the Synergy license.

This whole license BS is designed and furthered in this thread to try to
obfuscate truths and scare folk away from EMC2.  If I were to add a
"Copyright 2008 All rights reserved. Raymond E. Henry" to this post, you
would be forced to honor that regardless of the nature of the software
code used to prepare, transmit, route, or receive this post.  TALKING
WITH MOST OF EMC2 is no different.  Running a gcode program through EMC2
to a machine does not make that gcode open.  Opening a set of NML
channels does not infect the software or device that has done that.

HTH

Rayh

BTW -- I was the conduit between Tom Kramer, the author of the EMC
interpreters and Artsoft.  I asked Tom for the set of files for the new
interpreter that he was working on so that I could test and comment.  He
permitted me to share them with Art.  

Those files would eventually have to be released into the public domain
because they were a work done by a USA federal employee.  They were not
complete but Art wanted them anyway.  There was NO expectation that he
would return his modifications.  He upset me when he began bragging that
he had fixed a number of bugs without noting that the code he had used
was experimental rather than released.  His followers latched onto  that
implying that EMC was not well thought out or executed.  When we asked
where these bugs were located, he was unable or unwilling to point to
any specific sections.

Artsoft's use of EMC code was not the trigger for GPL licensing.  It is
the belief of most of the developers that we are a community freely
sharing our work with each other and ask only that those modifying or
extending our work do the same.

Ray,

Adding on, halrmt is to halcmd as emcrsh is to emcsh and is described here:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Halrmt

Regards,
Eric


<snip>
Adding the use of HAL messaging is another issue that may need a bit of
legal clarification.  My memory is foggy these days but I think that the
intent of the LGPL licensing of the source that makes up halcmd was that it
should allow a proprietary system to send properly formed, plain text
commands to halcmd.  Most of the functionality desired for SheetCam/EMC2
would not require direct HAL connections.  Again Smithy uses a connection to
Halcmd for a couple of signals.  
<snip>

>He upset me when he began bragging that
> he had fixed a number of bugs without noting that the code he had used
> was experimental rather than released.  His followers latched onto  that
> implying that EMC was not well thought out or executed.  When we asked
> where these bugs were located, he was unable or unwilling to point to
> any specific sections.

So, that gives us the opportunity to *BRAG* about Artsoft MACH3 *BASED* on EMC2!
Why not to use it in counterstrike?

On Sat, Nov 22, 2008 at 3:07 PM, Ray Henry <rehenry@...> wrote:
>
> There seems to be a deliberate lack of clarity with this whole
> proprietary v gpl/lgpl stuff in this thread.  It's not that the
> developers are incorrect but more incomplete. You should consider this
> post to be my opinion and a near rant and you might want to stay away.
>
>
> On Sat, 2008-11-22 at 05:46 +0000, Chris Morley wrote:
>
>> That means they are somehow connected to EMC2.
>
> Yes they are and they connect both through NML and halcmd, which is a
> bit like dialing up your friends on a conference call and talking.  Most
> of what is happening is exactly what the use of NML (Neutral Messaging
> Language) does for us.  It allows multiple graphical interfaces -- as
> long as those interfaces use NML status structure calls rather than
> making assumptions about the state of EMC based on something done within
> that GUI.  (AXIS did a bit of this early on as did Mini.) NML allows
> proprietary systems to develop NML messages and send and receive them in
> a system neutral way.
>
> There are two Tcl/Tk based extensions to Tcl's wish shell that connect
> between a Tcl/Tk based program and the NML channels.  The original,
> written by FredP at NIST is emcsh.  It is commonly run on a single
> computer with the rest of EMC2.  The second is the remote system emcrsh
> that was written by EricJ and described in his documents at
>    http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Emcrsh
> I use emcsh for most all of my connections to NML and don't see any
> significant loss of computer ability because of the extra messaging.
> Even at 20-50 loops a second the cost is trivial and is all on the user
> side of things rather than the rtai side.
>
> Now if you prefer not to use Tcl/Tk, a similar library of NML message
> classes could be developed for other languages.  In fact, a set of Java
> and/or C++ NML message classes can be autogenerated using a system
> maintained by WillS at NIST.
>
> If you prefer writing these classes in a pristine clean room way you
> could study the public domain code from EMC and write the additional
> codes that have been added to EMC2 to provide additional functionality
> -- if you need these.  This pristine authorship of a QT4 library is what
> Smithy did. (See the last paragraphs of my post for additional thoughts
> on Smithy and Synergy.)
>
> Adding the use of HAL messaging is another issue that may need a bit of
> legal clarification.  My memory is foggy these days but I think that the
> intent of the LGPL licensing of the source that makes up halcmd was that
> it should allow a proprietary system to send properly formed, plain text
> commands to halcmd.  Most of the functionality desired for SheetCam/EMC2
> would not require direct HAL connections.  Again Smithy uses a
> connection to Halcmd for a couple of signals.
>
> As for talking with the coordinate systems, tool offsets, or HAL
> configuration, those are simple stand-alone files that can be
> manipulated apart from EMC and their current values updated using NML
> messages.  I know that some developers frown on this and want a single
> funnel between EMC2 and these files but ....  If you're a software
> author and can figure out a bulletproof way of handling these things,
> why not.  The Smithy folk, along with the Synergy folk wrote code to
> read certain blocks of a gcode file when it loads it and sets up its
> tool table to conform to the tools defined during the Synergy part
> drawing process.
>
> Smithy met with a major share of the EMC2 developers during fest year
> before last and described what they wanted to do.  Smithy offered to
> LGPL their QT library and make it available to others when it was
> completed.  I don't believe that a formal vote was taken to either
> support or work against that implementation at that meeting.  Recently,
> Smithy offered their part of the GUI to the developers and are willing
> to place appropriate licenses on those files.
>
> Some of the Synergy code included in the EZ-Trol is not open and never
> will be.  You can cobble together much of the EZ-Trol ability by
> downloading Synergy Lite and the Smithy part of EZ-Trol (when the
> developers accept it) but you will not be able to build a complete
> system until you pay the Synergy license.
>
> This whole license BS is designed and furthered in this thread to try to
> obfuscate truths and scare folk away from EMC2.  If I were to add a
> "Copyright 2008 All rights reserved. Raymond E. Henry" to this post, you
> would be forced to honor that regardless of the nature of the software
> code used to prepare, transmit, route, or receive this post.  TALKING
> WITH MOST OF EMC2 is no different.  Running a gcode program through EMC2
> to a machine does not make that gcode open.  Opening a set of NML
> channels does not infect the software or device that has done that.
>
> HTH
>
> Rayh
>
> BTW -- I was the conduit between Tom Kramer, the author of the EMC
> interpreters and Artsoft.  I asked Tom for the set of files for the new
> interpreter that he was working on so that I could test and comment.  He
> permitted me to share them with Art.
>
> Those files would eventually have to be released into the public domain
> because they were a work done by a USA federal employee.  They were not
> complete but Art wanted them anyway.  There was NO expectation that he
> would return his modifications.  He upset me when he began bragging that
> he had fixed a number of bugs without noting that the code he had used
> was experimental rather than released.  His followers latched onto  that
> implying that EMC was not well thought out or executed.  When we asked
> where these bugs were located, he was unable or unwilling to point to
> any specific sections.
>
> Artsoft's use of EMC code was not the trigger for GPL licensing.  It is
> the belief of most of the developers that we are a community freely
> sharing our work with each other and ask only that those modifying or
> extending our work do the same.
>
>
>
>
> -------------------------------------------------------------------------
> 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
> Emc-developers@...
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

On Saturday 22 November 2008, Jon Elson wrote:
> Aren't the licenses right in EACH code file?

Most, yes. But nowhere is there a list of which licences are involved or to 
which binaries they apply. Not a problem for a user (generally), but if anyone 
is redistributing this stuff, it should be - Without knowing what licences 
are used, how is anyone able to meet the Terms & Conditions ??

As has already been pointed out, there is one file (as an example) claiming to 
be GPL2, pluto_step_rbf.h - In it's self, an autogenerated file from 
pluto_step.rbf - The HDL sources are labelled as "GPL ver 2 or later"..
Now, if Epler can provide the tools to generate the intermediate rbf file then 
the GPL T&C can be satisfied.


> I'm sure there are some files that are missing proper license declarations.

You are probably correct which is why I recommended Les does an audit of 
any/all sources he wishes to use and/or distribute.

On Sat, Nov 22, 2008 at 07:39:10PM +0000, paul_c wrote:
> As has already been pointed out, there is one file (as an example) claiming to 
> be GPL2, pluto_step_rbf.h - In it's self, an autogenerated file from 
> pluto_step.rbf - The HDL sources are labelled as "GPL ver 2 or later"..
> Now, if Epler can provide the tools to generate the intermediate rbf file then 
> the GPL T&C can be satisfied.

Paul,

Thanks for giving me a chance to clarify this.

The pluto_step.rbf file is built from the source files in
pluto_step_firmware using the proprietary Quartus II development
environment from Altera.

The process of building in the Quartus GUI seems unscriptable; instead,
I describe the process in prose in the manual:
    The src/hal/drivers/pluto_servo_firmware/ and
    src/hal/drivers/pluto_step_firmware/ subdirectories contain the
    Verilog source code plus additional files used by Quartus for the
    FPGA firmwares. Altera's Quartus II software is required to rebuild
    the FPGA firmware. To rebuild the firmware from the .hdl and other
    source files, open the .qpf file and press CTRL-L. Then, recompile
    emc2.

    Like the HAL hardware driver, the FPGA firmware is licensed under
    the terms of the GNU General Public License.

    The gratis version of Quartus II runs only on Microsoft Windows,
    although there is apparently a paid version that runs on Linux. 
    http://linuxcnc.org/docs/html/hal_drivers.html#r1_8_7

As described in the gpl version 2 faq, the use of a proprietary
toolchain is not problematic in gpl2 software:
    Q: Can I release a program under the GPL which I developed using
    non-free tools?

    A: Which programs you used to edit the source code, or to compile it,
    or study it, or record it, usually makes no difference for issues
    concerning the licensing of that source code.

    However, if you link non-free libraries with the source code, that
    would be an issue you need to deal with. It does not preclude releasing
    the source code under the GPL, but if the libraries don't fit under the
    “system library” exception, you should affix an explicit notice giving
    permission to link your program with them. The FSF can give you advice
    on doing this.

    http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#NonFreeTools

(pluto_step and pluto_servo do not use any "libraries", they just use
the standard facilities of the verilog language)

Jeff

paul_c wrote:
> On Saturday 22 November 2008, Jon Elson wrote:
>   
>> Aren't the licenses right in EACH code file?
>>     
>
> Most, yes. But nowhere is there a list of which licences are involved or to 
> which binaries they apply. Not a problem for a user (generally), but if anyone 
> is redistributing this stuff, it should be - Without knowing what licences 
> are used, how is anyone able to meet the Terms & Conditions ??
>
>   
Good point!  Are you volunteering to write an overview of the license 
environment of EMC2?
> As has already been pointed out, there is one file (as an example) claiming to 
> be GPL2, pluto_step_rbf.h - In it's self, an autogenerated file from 
> pluto_step.rbf - The HDL sources are labelled as "GPL ver 2 or later"..
> Now, if Epler can provide the tools to generate the intermediate rbf file then 
> the GPL T&C can be satisfied.
>
>
>   
>> I'm sure there are some files that are missing proper license declarations.
>>     
>
> You are probably correct which is why I recommended Les does an audit of 
> any/all sources he wishes to use and/or distribute.
>   
In lieu of a truly comprehensive list of license status for every file, 
it is up to each person who has some commercial interest to understand 
the license environment and how it affects what he is doing.  You are 
quite right.  Bit, I think it is quite possibel to have a sophisticated 
software interface between licensed software and EMC2 without any 
entanglements, by using the right interface(s) into EMC2, at least for 
the kind of situation Les was interested in.


Jon

On Saturday 22 November 2008, Jeff Epler wrote:
> As described in the gpl version 2 faq, the use of a proprietary
> toolchain is not problematic in gpl2 software:
>     Q: Can I release a program under the GPL which I developed using
>     non-free tools?
>
>     A: Which programs you used to edit the source code, or to compile it,
>     or study it, or record it, usually makes no difference for issues
>     concerning the licensing of that source code.

Section 3 c)
 The source code for a work means the preferred form of the work for making
 modifications to it. For an executable work, complete source code means all
 the source code for all modules it contains, plus any associated interface
 definition files, plus the scripts used to control compilation and
 installation of the executable. However, as a special exception, the source
 code distributed need not include anything that is normally distributed (in
 either source or binary form) with the major components (compiler, kernel,
 and so on) of the operating system on which the executable runs, unless
 that component itself accompanies the executable.


Quartus does not qualify as a "major component", nor is it free, neither is 
it's output - Please read Altera's T&C. If you need clarification on what 
constitutes "non-free tools", I would suggest contacting the Free Software 
Foundation.

On Tue, 2008-11-25 at 08:58 +0000, paul_c wrote:
> Quartus does not qualify as a "major component", nor is it free, neither is 
> it's output - Please read Altera's T&C.

If we're in trouble, so is the GNU Radio project. As an example, if you
download their latest version and look in the archive file
at /gnuradio-3.1.3/usrp/fpga/megacells/ you'll find stuff that was
autogenerated by Altera's tools. Also, in /gnuradio-3.1.3/usrp/fpga/rbf/
a lot of .rbf files are included in their project's distributed files,
yet they don't distribute the development tools that produced them.

>From the GNU Radio README:
"# Compiling the verilog (not required unless you're modifying it)

If you want to build the FPGA .rbf file from source (not required; we
provide pre-compiled .rbf files in usrp/fpga/rbf directory), you'll
need Altera's no cost Quartus II development tools.  We're currently
building with Quartus II 5.1sp1 Web Edition.  The project file is
usrp/fpga/toplevel/usrp_std/usrp_std.qpf.  The toplevel verilog file
is usrp/fpga/toplevel/usrp_std/usrp_std.v.  The bulk of the verilog
modules are contained in usrp/fpga/sdr_lib"

I have to believe that if there was a problem with distributing these
files then the FSF would not have given this project their imprimatur.

Thanks,
Matt

Paul,
You are simply wrong in your interpretation of the GPL here.

The linuxcnc.org project is not alone in applying the GPL to software
that runs on FPGAs and is compiled by proprietary tools.  The GNU
project "gnuradio" is another (and you can bet that official GNU
projects have a high level of scrutiny as far as license compliance!).
Their home page is:
    http://www.gnu.org/software/gnuradio/
they do very much the same thing I have done: provide the verilog
source, the other files used by the Quartus 2 environment, and the .rbf
output files.  Take a look at the gr-gpio/src/fpga subdirectory of their
source distribution to see for yourself.

Others who believe the GPL can be applied to FPGAs are Xilinx (a major
FPGA producer), which I mentioned the last time you brought up this
crazy "FPGAs can't run GPL software" claim over a year ago:
    http://www.xilinx.com/publications/xcellonline/xcell_46/xc_pdf/xc_freesw46.pdf
-- it's actually a great article about the development of a digital
imaging system that is completely reconfigurable due to inclusion of an
FPGA, with all the code GPL'd.

The well-known website for FPGA developers, opencores.org, hosts many
GPL and LGPL FPGA projects.  They do not believe any GPL exceptions are
required:
    4.1 What license is used for opencores?

    Each author uses their preferred license. Generally licenses are
    either GNU or BSD in nature.
    [...]
    To simplify life for users, developers are strongly encouraged to
    use an unmodified GPL or LGPL (Lesser GPL) license or the modified
    BSD license.
    http://www.opencores.org/faq.cgi/section/4/4

I could go on, but there is a very clear consensus that the GPL can be
applied to FPGA software.

Now, let's look at the section of the GPL that you think shows a
problem:

On Tue, Nov 25, 2008 at 08:58:09AM +0000, paul_c wrote:
> Section 3 c)
>  The source code for a work means the preferred form of the work for making
>  modifications to it.

Check.  You get the source files I wrote, the same source files I'd
modify if I wanted to make improvements to pluto_step or pluto_servo.

>  For an executable work, complete source code means all
>  the source code for all modules it contains, plus any associated interface
>  definition files, plus the scripts used to control compilation and
>  installation of the executable.

Check.  (one part of the compilation involves manually running a GUI, but
is described accurately in prose in the manual)

>  However, as a special exception, the source
>  code distributed need not include anything that is normally distributed (in
>  either source or binary form) with the major components (compiler, kernel,
>  and so on) of the operating system on which the executable runs, unless
>  that component itself accompanies the executable.

Check.  I've repeatedly rebuilt the FPGA firmware using only things from
a CVS checkout of the emc2 source tree and things included in the
Quartus 2 development environment.  I've also compiled it using Icarus
Verilog for testing purposes.

There is NO REQUIREMENT that this compiler be no-cost, let alone Free.
You keep saying this, but it is simply not in the GPL.  It is also
specifically addressed in the GPL v2 FAQ that I quoted from earlier.
I'll quote it again:
    [Q:] Can I release a program under the GPL which I developed using
    non-free tools?

    [A:] Which programs you used to edit the source code, or to compile
    it, or study it, or record it, usually makes no difference for
    issues concerning the licensing of that source code.

    However, if you link non-free libraries with the source code, that
    would be an issue you need to deal with. It does not preclude
    releasing the source code under the GPL, but if the libraries don't
    fit under the “system library” exception, you should affix an
    explicit notice giving permission to link your program with them.
    The FSF can give you advice on doing this.

    http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#NonFreeTools

Jeff
PS I personally would like it very much if it were possible to develop
the pluto and mesa firmwares on Linux using only Free tools.

On Tuesday 25 November 2008, Matt Shaver wrote:
> If we're in trouble, so is the GNU Radio project. 
<snip>
> I have to believe that if there was a problem with distributing these
> files then the FSF would not have given this project their imprimatur.

GNU Radio's firmware is not "free" enough for Debian to distribute in Main..

 If it is OK to distribute firmware binaries without the necessary tools to 
build them, it raises the question why bundle stuff like yapps as part of the 
emc2 tarball.

On Wed, Nov 26, 2008 at 02:47:56PM +0000, paul_c wrote:
> GNU Radio's firmware is not "free" enough for Debian to distribute in Main..

Actually, Paul, the fact that Debian distributes gnuradio and its usrp
component including an .rbf firmware file[1] makes it clear that Debian
also interprets the GPL the same way as gnu, opencores, xilinx, mesa,
Matt Shaver, Peter Wallace, and I all interpret it.

If Paul's argument (that you can't build GPL software with proprietary
software and distribute the result while complying with all requirements
of the GPL) were true then Debian would refrain altogether from
distributing the binary firmwares in the usrp-firmware package, not
merely segregate it to "non-free".  "non-free" doesn't mean "we
unrepentantly violate licenses in this section"[2].

> why bundle stuff like yapps as part of the emc2 tarball.

Red herring.  

Jeff
[1] http://packages.debian.org/etch/gnuradio
    http://packages.debian.org/etch/usrp
    http://packages.debian.org/etch/usrp-firmware
    http://packages.debian.org/etch/all/usrp-firmware/filelist
        containing /usr/share/usrp/rev2/multi_2rxhb_2tx.rbf
        among other files

[2] It is most likely that gnuradio is outside of main because of the
    requirement that packages in main
        must not require a package outside of main for compilation or
        execution (thus, the package must not declare a "Depends",
        "Recommends", or "Build-Depends" relationship on a non-main
        package),
        http://www.debian.org/doc/debian-policy/ch-archive.html#s-main
    not because of any GPL violation, which would obviously cause Debian
    to not distribute the package at all.

On Wednesday 26 November 2008, Jeff Epler wrote:
> > why bundle stuff like yapps as part of the emc2 tarball.
> Red herring.

NO. It falls under the heading of what should or should not be included (or 
even code review). For example, why distribute pointless files such as 
config.log, config.status, and assorted *.pyc

> [1] http://packages.debian.org/etch/gnuradio
<quote>
If you have a USRP, you probably also want to install the usrp package as 
suggested, which lives in contrib because the FPGA bitstrings require 
non-free tools to build.
</quote>

Peter Wallace has had the foresight to release his source under a dual 
GPL/BSD, and thanks to the efforts of Seb, the drivers are free of excessive 
bloat.

On Fri, Nov 28, 2008 at 12:43:00AM +0000, paul_c wrote:
> On Wednesday 26 November 2008, Jeff Epler wrote:
> > > why bundle stuff like yapps as part of the emc2 tarball.
> > Red herring.
> 
> NO. It falls under the heading of what should or should not be included (or 
> even code review). For example, why distribute pointless files such as 
> config.log, config.status, and assorted *.pyc

Sure but the thread was about the GPL, and more specifically your
mistaken interpretation that led you to incorrectly assert that
distributing these firmwares is not allowed under the GPL.

You are not suggesting that mistakenly including a config.log in a
source package (if in fact we accidentally do that) is a GPL violation
are you?  If you want to submit a patch that cleans up something about
the packages I'd happily review it.

> > [1] http://packages.debian.org/etch/gnuradio
> <quote>
> If you have a USRP, you probably also want to install the usrp package as 
> suggested, which lives in contrib because the FPGA bitstrings require 
> non-free tools to build.
> </quote>

Yes, as it says, that's exactly what causes it to be in contrib.  What
is your point exactly?

> Peter Wallace has had the foresight to release his source under a dual 
> GPL/BSD, and thanks to the efforts of Seb, the drivers are free of excessive 
> bloat.

Yes they both do a good job!  What is your point exactly?

Chris

On Thu, 2008-11-27 at 19:12 -0600, Chris Radek wrote:
> What is your point exactly?

I think I have found out. While reading Slashdot, one of my favorite
ways to waste time, I came upon this:
http://linux.slashdot.org/linux/08/11/28/2339242.shtml

which points to this article, which is a good summary of the situation:
http://itmanagement.earthweb.com/osrc/article.php/12068_3787736

Our situation is even one step above that described in the article
because we are distributing the source and build scripts (as it is
possible) for the firmware, with our only non-free dependence being the
tools. I suppose we could make the firmware related files a separate
package, maybe "emc2-contrib"?

Past that point, we are at an impasse. Without firmware, the hardware
doesn't work. As far as I know, there are no libre firmware
"synthesizers" for the FPGAs the we use. Also I am unaware of any libre
FPGAs There was this, but it's long dead:
http://www.eetimes.com/showArticle.jhtml?articleID=161600613

There's also this:
http://fpgalibre.sourceforge.net/intro_en.html

but, if you scroll down to the "Synthesis" section, you'll find that
they have no alternative but to use the "gratis" tools as there are no
"libre" ones.

I think, for now, if we want FPGAs, then we are stuck with Quartus
(Altera) and WebPack (Xilinx). Personally, I've only recently warmed up*
to these kinds of devices (I even looked askance at PALs and GALs when
they came out for the same reasons). My reluctance to fool with them was
directly a result of this non-free tools situation. However, the
benefits of this, admittedly very clever, technology are so great that
the "no libre tools" argument is unlikely to sway most technology
consumers. If a chip maker _did_ offer libre tools, I would be their
enthusiastic spokesman!

It's possible that a "universal cnc peripheral chip" could be designed
and made this way:
http://www.mosis.com/

but I expect the cost benefit analysis would still favor FPGAs unless
considerable weight were given to libre philosophical requirements.

Puzzled but ever hopeful,
Matt

* - I actually designed some hardware that used Intel's Flex Logic,
before it was sold to Altera, but another smarter guy did all the logic
inside the device.

There are two separate questions that seem to be asked in this thread.
First, and what Paul seemed to be asking:

    Can someone distribute the binary firmware files such as
    pluto_step.rbf along with the corresponding source code and meet all
    the requirements of the GPL?

Matt Shaver and I have gathered a lot of information to show that the
consensus of the Free Software community is a clear "yes".


There's a separate question that is getting mixed in, which is

    Would the goals of Free Software be advanced if it were possible to
    develop for FPGAs using only Free Software?

This isn't a question of complying with the terms of the GPL.  The
answer is also "yes".  But that doesn't mean that those who are
pragmatic and write code for FPGAs today can't release their work under
the GPL and let others benefit from it.

The second question is a matter of Free Software advocacy, and it's
off-topic for this list.

Jeff

Matt Shaver wrote:
>
> It's possible that a "universal cnc peripheral chip" could be designed
> and made this way:
> http://www.mosis.com/
>
> but I expect the cost benefit analysis would still favor FPGAs unless
> considerable weight were given to libre philosophical requirements.
>
>   
No, much, MUCH harder than you think.  IC design software is INSANELY 
expensive, $250 K per seat per year in some cases.  And, the educational 
licenses specifically state nobody can benefit from the chips made 
through the use of these tools.  We have had a few chips made through 
MOSIS using Mentor and Cadence tools, and since it is all for government 
grant and university research, it passes muster.  I even build the 
boards commercially after the chips are supplied from one university to 
another (my customer). 

An all-digital chip is a lot easier to simulate and be sure it will 
work, but the number of potential pitfalls are enormous.  And, still, 
even making them in small quantity, the cost is quite high.  We pay 
something like $200 PER CHIP for a fairly large, mostly analog signal 
processing chip.  (Ummm, we are in the seventh generation of one of 
them, and it STILL has problems - that's my job security, taking flawed 
chips and coming up with the external hacks to make them work.)  The guy 
who does the IC design had one chip that was missing one via between 
layers, but it was connecting the main digital clock from the lead 
bonding pad to the rest of the works, so the entire chip was totally DOA.

Anyway, even a quite small ASIC through MOSIS will run about $10K 
installed in a package, for the first FORTY chips!  If those work, you 
can then get more off the same wafer for another couple grand.  MOSIS 
will NEVER be competitive with commercial chips unless you buy them by 
the thousands, and then you can just contract directly with one of the 
foundries.

What I'd really like to see work is an RT_USB driver to the Cypress 
FX2LP chip and an FPGA after that.  I'm still not too clear on the 
limitations of the USB, though, so maybe ethernet is a better choice.  
But, I've been fooling around (yes, that REALLY is the right term, I 
have NO IDEA what I'm doing yet) with the Cypress chip at work, on a 
control project that doesn't need real time or any great speed.  But, I 
have a little demo on my desk that reads 39 MB/sec and writes 31 MB/sec 
over USB.  QUITE impressive.  The FX2LP chip handles the actual 
transfers entirely in hardware, so it is as fast as the USB high-speed 
can go.  I don't know what the latency of sending a small request out 
and getting a small reply back would be, or how you might arrange to 
force a small packet to be sent and prevent it from buffering them up.  
But, it looks fairly promising.

Jon