Control

GPL licensing questions - RMS Speaks

  • Thread starter Davis Ray Sickmon, Jr
  • Start date
D

Thread Starter

Davis Ray Sickmon, Jr

OK - I got a response today from Richard Stallman concerning the GNU license as it would apply to the LinuxPLC project.

The original text is below, but, summed up here is the answer - no problem. As long as they are excuting something like a bytecode or interpreted
program, GPL does not affect the program they write.

The quick thing to note - RMS admonished me about the usage of Linux instead of GNU/Linux. <GRIN> *SIGH* I hate that... And I did email him back to explain what a PLC was.

-----------------------------

> I am a somewhat member of the LinuxPLC project, which is dedicated to
> developing an alternative to closed-source style development PLC
projects.

Could you tell me what PLC is? Also, what does this program have with
Linux? Perhaps you're talking about the GNU/Linux system, and calling
it "Linux"; many people do that, but it would really help the GNU
Project if you would call it "GNU/Linux" instead. See
http://www.gnu.org/gnu/linux-and-gnu.html for more explanation.

> The important question is - if
> the Logic Solver for LinuxPLC is GPL'ed, is the programs (bytecode)
written
> to run on top of the LinuxPLC's Logic Solver automatically GPL'ed?

No. For an interpreter, the user's program is its data; it is not an
extension of the interpreter. (You can easily make it completely
clear that this is your view of the license, by including a statement
about this in the README for your program.)

Thus, programs designed to be run as bytecode on your interpreter do
not have to be free software, if they are distributed separately from
your interpreter.

However, if the program and the interpreter are linked together in a
combined executable, that combination has to be free. So in that
case, the program would have to be free.

If you want to change that, I can advise you of how to do so.

-------------

Davis Ray Sickmon, Jr
http://www.midnightryder.com

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Johan Bengtsson

If I interpret this corectly it would basically mean:
If the ladder program is converted into byte-code and read by an interpreter - no problem
If the same ladder program is converted into machine-code and executed directly by the processor - it have to be free

I don't intend it to be like that.
I do further don't intend every program using this to automatically have to be free. Like said before by me and others, for example I/O drivers made by some companies could, in my opinion, be non-free. It would of course be better if they are free, but in the choosing between having
them non-free or not having them at all... well

I think it should be the same for other add-ons to the system.

It is allowed to run non-free programs in Linux, or am I wrong?
That is what I would like to see, since I think it will spread it more and eventually make all (or most) of those things free.

/Johan Bengtsson

----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
D

Davis Ray Sickmon, Jr

> If I interpret this corectly it would basically mean:
> If the ladder program is converted into byte-code and
> read by an interpreter - no problem
> If the same ladder program is converted into machine-code
> and executed directly by the processor - it have to be free

Well, I don't know that anyone was going to write a compiler that compiles Ladder (or language of choice) to native processor commands. In that case - it does get more interesting. And I'll explain how to get arround that...

1) Unless you plan on the logic solver being linked directly into the PLC programmers executable code, there's no problem. Make the logic solver libraries LGPL. Then they can be linked against, without a problem.

2) If the program is compiled at runtime (IE - when you start the Logic Solver, and it runs, it loads the PLC program, compiles it to native code,
and then starts the code running) there's no problem.

3) The intent of GPL is - if you take GPL code, add in proprietary code, and run them together, it's all GPL. In that case, the only situation that is of any concern is if the Ladder program and the logic solver are 'mixed' at compile time, and the compiled binary is distributed to anyone.

If you write a ladder compiler (IE - ladder, STL, whatever to native code) then LGPL the code that goes into the libraries that are linked at compile
time. The proprietary of the program remains proprietary, and the libraries are only an important consideration if the PLC program developer for some reason makes changes to the LGPL'ed libraries that are linked in.

By using LGPL and GPL in appropriate places, the PLC program is still free, and the work of this group is still protected. However - if everyone were to become completely opposed to GPL'ing the system, just holler. There's plenty of other licenses out there, and I can find the one that applies to this situation pretty easily.

> I don't intend it to be like that.
> I do further don't inted every program using this to
> automatically have to be free. Like said before by me and
> others, for example I/O drivers made by some companies
> could, in my opinion, be non-free. It would of course be
> better if they are free, but in the choosing between having
> them non-free or not having them at all... well

See above, and see my vote. LGPL libraries, and GPL core if it's a 'bytecode' or 'interpreter' situation. That matches the situation
perfectly. LGPL it all if everything is just going to be libraries linked into a compiled program. See bottom for a further comment on this.

Also - there's an important issue. GPL works great even in situations where proprietary code needs to be introduced for a I/O driver. Since I don't figure I/O drivers are going to be compiled directly into the system (if so - wow. There's going to be a bit of unnessisary code included in every LinuxPLC - IE, the drivers you aren't using <GRIN> Not good for embedded applications, but, I don't know if that's a problem or not), then the
manufacturer talks to the Logic Solver/PLC program combo using IPC or some other method without acually being a part of the compiled program. The last part of what I said is the most important - there's a million ways to get
arround any situation concerning GPL as long as they don't add code directly in, but, instead us it as a library that the LinuxPLC calls or using some sort of interprocess communication scheme (which can get pretty interesting anyway - run your I/O drivers on one machine, and you PLC program on another would then be a realistic option, except for the added couple of ms of lag.)
You can also just make the part where I/O drivers talk an LGPL'ed license, and then make your headers for new licenses completely open, and they use the headers to build new drivers for the system without any concerns of the GPL.

GPL & LGPL is flexible, except for one area.

And as for weither or not code compiled for the native environment is GPL or not - GCC is GPL'ed, and it's libraries are LGPL (glibc for instance.) When you write a program, compile it, and link against glibc, there's no problems - your program falls under your license, not the GPL'ed version of GCC (it only produces native code without including any part of it's self in
the result code) or the LGPL of the libraries it links in.

And if this is still a concern - no problem. Wait a couple of days for Richard Stallman to reply to me again, and I'll have the answer of how to make it work. (Since he mentioned he would show me how to get away with that situation, I alread asked for him to tell me, just in case it ever became important.)

> I think it should be the same for other add-ons to the system.
>
> It is allowed to run non-free programs in Linux, or am I wrong?
> That is what I would like to see, since I think it will spread
> it more and eventually make all (or most) of those things free.

Linux does not restrict users to GPL-only programs. In fact, one of my debates about RMS's comment about it being GNU/Linux is that not everything on Linux is licensed under LGPL and GPL. There are pleanty fo things for Linux that are 'non-free'.

> /Johan Bengtsson

Quick thoughts:

HUH?! Are you really going to take a PLC program, and compile it to native code? In that case, all the work is almost done - just write a Ladder to C compiler, write your libraries that handle things like timers and I/O (no small feat ;-), and link them in at compile time using GCC. Of course - you loose ****ALL**** flexibility that PLC normally has - for instance, compiles
are going to be longer, going into the PLC program and observing it directly isn't going ot be an option, etc. Native code bad. Native code is bad. Can I say that again? Native code bad. <GRIN> You'll end up loosing tons of stuff you are normally used to working with in a PLC. But I could be wrong, and if I am, please point me the right direction on how you won't loose that flexibility, and why compiling the PLC program as native code is a good idea.

Davis Ray Sickmon, Jr
http://www.midnightryder.com
...I'm not a lawyer, but, I seem to end up playing one for various OSS
projects....


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Johan Bengtsson

Wow, thanks for that reply,

>HUH?! Are you really going to take a PLC program, and compile it to native
>code? In that case, all the work is almost done - just write a Ladder to C
>compiler, write your libraries that handle things like timers and I/O (no
>small feat ;-), and link them in at compile time using GCC. Of course - you
>loose ****ALL**** flexibility that PLC normally has - for instance, compiles
>are going to be longer, going into the PLC program and observing it directly
>isn't going ot be an option, etc. Native code bad. Native code is bad.
>Can I say that again? Native code bad. <GRIN> You'll end up loosing tons
>of stuff you are normally used to working with in a PLC. But I could be
>wrong, and if I am, please point me the right direction on how you won't
>loose that flexibility, and why compiling the PLC program as native code is a good idea.
>

No, I am not going to do that, and even when someone eventually is going to do a part of that (I am almost sure someone will) it will still "only" be the logic solver part that is compiled - ie it will still be using the shared memory and so on. All (or most of the) flexibility will be lost, but this is only an option for making the already (will be) fast logic solver to be even more faster at the price of flexibility.
(Do not start flaming about online changes and so on, it will surely be done, but the people using this option is going to want the speed rather than online changes), or perhaps just link in
some nice C code inte the ladder program or something. I just wanted to make sure we allow for this to happen.


/Johan Bengtsson

----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
D

Davis Ray Sickmon, Jr

> Wow, thanks for that reply,

Hehe - sorry, a bit much I'm sure. I'm a windbag by nature - and for some reason, I don't come equipt with a non-verbose mode when I'm explaining
something ;-)

> No, I am not going to do that, and even when someone eventually
> is going to do a part of that (I am almost sure someone will) it
> will still "only" be the logic solver part that is compiled - ie
> it will still be using the shared memory and so on.
> All (or most of the) flexibility will be lost, but this is only
> an option for making the already (will be) fast logic solver to
> be even more faster at the price of flexibility.
> (Do not start flaming about online changes and so on, it will
> surely be done, but the people using this option is going to want
> the speed rather than online changes), or perhaps just link in
> some nice C code inte the ladder program or something. I just
> wanted to make sure we allow for this to happen.

OK - point taken. For those who know what they are getting into, yep, it would be a cool option. Might also come in handy for embedded situations using less powerful processors where you need all the raw speed you can get. I just assumed it was a 'now' statement, not a WDIL thing.

Hm. In that case - things get interesting <GRIN> If it's compiled and runs beside the logic solver and they cross-communicate, well, no problem. If the logic solver it's self becomes a single entity with the PLC program, compliled together, GPL is a problem. Of note - that also just means only the customer has to have a copy - they don't have to publish it on the web, update LinuxPLC, etc. GPL only applies when you give the compiled binary to someone else outside of your own organization. Hm. I guess one fundamental problem is, I don't understand how the Logic Solver, the compiled PLC program, and the I/O drivers, etc. are going to interact in a situation like that. I'm going to assume that everything is going to be done as library calls from the compiled PLC program, but, heck - it could be done in any fashion, since it's not really been planned out yet <GRIN>

Davis Ray Sickmon, Jr
http://www.midnightryder.com


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M

Mark Hutton

Think in terms of loadable function blocks, CARs and the like (SAM - S??? Application Module for the SLC), C co-processors for the 984 (I forget what the loadable modules are in Concept), Which may be in 'ladder' or may be compiled code.

Future work.

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Davis Ray Sickmon, Jr
>
> > Wow, thanks for that reply,
>
> Hehe - sorry, a bit much I'm sure. I'm a windbag by nature - and for some
> reason, I don't come equipt with a non-verbose mode when I'm explaining
> something ;-)
>
> > No, I am not going to do that, and even when someone eventually
> > is going to do a part of that (I am almost sure someone will) it
> > will still "only" be the logic solver part that is compiled - ie
> > it will still be using the shared memory and so on. All (or most of the) flexibility will be lost, but this is only
> > an option for making the already (will be) fast logic solver to
> > be even more faster at the price of flexibility.
> > (Do not start flaming about online changes and so on, it will
> > surely be done, but the people using this option is going to want
> > the speed rather than online changes), or perhaps just link in
> > some nice C code inte the ladder program or something. I just
> > wanted to make sure we allow for this to happen.
>
> OK - point taken. For those who know what they are getting into, yep, it
> would be a cool option. Might also come in handy for embedded situations
> using less powerful processors where you need all the raw speed you can get.
> I just assumed it was a 'now' statement, not a WDIL thing.
>
> Hm. In that case - things get interesting <GRIN> If it's compiled and runs
> beside the logic solver and they cross-communicate, well, no problem. If
> the logic solver it's self becomes a single entity with the PLC program,
> compliled together, GPL is a problem. Of note - that also just means only
> the customer has to have a copy - they don't have to publish it on the web,
> update LinuxPLC, etc. GPL only applies when you give the compiled binary to
> someone else outside of your own organization. Hm. I guess one fundamental
> problem is, I don't understand how the Logic Solver, the compiled PLC
> program, and the I/O drivers, etc. are going to interact in a situation like
> that. I'm going to assume that everything is going to be done as library
> calls from the compiled PLC program, but, heck - it could be done in any
> fashion, since it's not really been planned out yet <GRIN>

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

Hi all,
It is subtly yet obviously different than simply using Linux where you are not responsible for licensing issues. I think the best course is the
one with the least licensing hassles. For that reason, I would make absolutely sure we keep GPL and proprietary stuff separate and we may even have some problems with stuff that's reverse engineered from the major vendors. That said, if we are going to affect this very proprietary and litagious world, we are going to have to run
protocols that will never be free or open. The customer code issue will be much easier to handle than straightening out the 'Tower of Babel". Ensuring that our intent is to do good for the community and not simply steal business will go a long way towards avoiding these problems. It's hard to litigate against the public good and very bad PR if you do. Gifts of drivers with strings attached will have to be scrutinized carefully as they could concievably shut us down by using IP (intellectual property) as a trojan horse. That's why I try to reject money making ideas that would compromise the "for the community status" of the project. I know this upsets some people, but, selling parts of the project substantially changes the legal position and defensibility of some of the things we will have to do.

Curt W.



[email protected] wrote:

> If I interpret this corectly it would basically mean:
> If the ladder program is converted into byte-code and
> read by an interpreter - no problem
> If the same ladder program is converted into machine-code
> and executed directly by the processor - it have to be free
>
> I don't intend it to be like that.
> I do further don't inted every program using this to
> automatically have to be free. Like said before by me and
> others, for example I/O drivers made by some companies
> could, in my opinion, be non-free. ...<clip>


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Jack Gallagher

If I understand Curt correctly than I agree with his assessment of this project. It seems to me that most of the computing industry is going to a
services oriented business structure, rather than commodity based.

I think the main goal of using this tool for profit should be only for the engineering hours expended in customizing it to a specific job or writing a program for it. Selling proprietary ladder logic programs? That does not make sense to me.


********************************************
Jack Gallagher
SES CO Inc.
3 Vision Drive
Natick, MA 01760
Phone: (508) 650-9147
Fax: (508) 650-9310
e-mail: [email protected]
********************************************


-----Original Message-----
From: [email protected] [mailto:[email protected]]On
Behalf Of Curt Wuollet

Hi all,
It is subtly yet obviously different than simply using Linux where you are not responsible for licensing issues. I think the best course is the
one with the least licensing hassles. For that reason, I would make absolutely sure we keep GPL and proprietary stuff separate and we may even have some problems with stuff that's reverse engineered from the major vendors. That said, if we are going to affect this very proprietary and litagious world, we are going to have to run
protocols that will never be free or open. ...<clip>


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Jiri Baum

Davis Ray Sickmon, Jr:
> Well, I don't know that anyone was going to write a compiler that compiles
> Ladder (or language of choice) to native processor commands. In that case -
> it does get more interesting. And I'll explain how to get arround that...

Well, gdb gets around it, doesn't it :)

> Quick thoughts:

> HUH?! Are you really going to take a PLC program, and compile it to
> native code? In that case, all the work is almost done - just write a
> Ladder to C compiler, write your libraries that handle things like timers
> and I/O (no small feat ;-), and link them in at compile time using GCC.
> Of course - you loose ****ALL**** flexibility that PLC normally has - for
> instance, compiles are going to be longer, going into the PLC program and
> observing it directly isn't going ot be an option, etc. Native code bad.
> Native code is bad. Can I say that again? Native code bad. <GRIN>

Well:
- observing the PLC program is no problem, as long as you keep the source code for it, and have access to the data areas.

- on-line changes are hard but not undoable. Basically recompile (or part-recompile), load, and switch-over between scans.

- more likely, though, the compiled code might be just snippets; say a C function doing a couple of arithmetic operations, with the bulk of the program in ladder.

- alternatively, the compiled program might be an adjunct to a logic engine, running some mysterious calculations or algorithms (FFT, neural nets, whatever). You might not need on-line changes, or the on-line changes might just apply to parameters (weights in a neural net).

- the compiled program might be proprietary, in which case you don't get on-line changes even if you stand on your head.


Jiri
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
You must log in or register to reply here.
Thread starter Similar threads Forum Replies Date
M To GPL or Not To GPL (was: linux Modbus master) Modbus 2
C GPL to be tested Open Control 0
K Rtlinux and GPL LinuxPLC Project 2
K GPL and ownership, was Schneider's interest in Control.com / LinuxPLC General Automation Chat 0
R Compiled code (was GPL licensing questions - RMS speaks) LinuxPLC Project 0
Similar threads
To GPL or Not To GPL (was: linux Modbus master)
GPL to be tested
Rtlinux and GPL
GPL and ownership, was Schneider's interest in Control.com / LinuxPLC
Compiled code (was GPL licensing questions - RMS speaks)

You May Also Like

Top