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,
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
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 summa
On Fri, Nov 28, 2008 at 12:43:00AM +, 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 examp
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.statu
On Wed, Nov 26, 2008 at 02:47:56PM +, 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
On Tuesday 25 November 2008, Matt Shaver wrote:
> If we're in trouble, so is the GNU Radio project.
> 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 Debia
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
On Tue, 2008-11-25 at 08:58 +, 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 fi
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
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 redi
On Sat, Nov 22, 2008 at 07:39:10PM +, 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 Ep
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 - Wi
bugs because only a couple of people can
work on the code.
Steve Stallings
> -Original Message-
> From: Mario. [mailto:[EMAIL PROTECTED]
> Sent: Saturday, November 22, 2008 9:32 AM
> To: [EMAIL PROTECTED]; EMC developers
> Subject: Re: [Emc-developers] Controlling EMC
>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 w
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
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
int
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
> From: [EMAIL PROTECTED]
> Subject: Re: [Emc-developers] Controlling EMC from a non-GPL application
> Date: Fri, 21 Nov 2008 21:38:48 -0800
> To: [EMAIL PROTECTED]
>
>
> Hi Chris,
>
> As I understand it Ez_Trol was written by weber systems under
> contract t
From: [EMAIL PROTECTED]
Date: Fri, 21 Nov 2008 21:03:34 -0800
To: emc-developers@lists.sourceforge.net
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
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 de
> 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
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 lic
On Fri, Nov 21, 2008 at 11:38:00PM +, 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 a
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 direc
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 us
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
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 noth
Chris Morley wrote:
>
>
> > From: [EMAIL PROTECTED]
> > To: emc-developers@lists.sourceforge.net
> > 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
On Fri, Nov 21, 2008 at 12:40:08AM +, 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 se
On Thu, Nov 20, 2008 at 11:26:42PM +, 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 fi
> From: [EMAIL PROTECTED]> To: emc-developers@lists.sourceforge.net> Date: Thu,
> 20 Nov 2008 23:26:42 +> Subject: Re: [Emc-developers] Controlling EMC
> from a non-GPL application> > On Thursday 20 November 2008, Leslie Newell
> wrote:> > When the
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
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.
> > 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
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
On Thu, Nov 20, 2008 at 04:22:05PM +, 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 muc
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 net
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 dom
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
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
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
emcr
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
appro
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 offe
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 EMC
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/rc
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" ?
-
This SF.Net email is sponsored by the Moblin Your Move Developer
On Wed, Nov 19, 2008 at 10:53:44PM +, 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,
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.
>
>
>
-
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
> conn
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
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 ha
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
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
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:
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 interf
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 thi
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
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
On Wed, Nov 19, 2008 at 06:42:47PM +, 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 lear
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
60 matches
Mail list logo
