Licensing

J

Thread Starter

Johan Bengtsson

This raises another issue briefly touched while it still was on automationlist, licensing:

If it is not too early to discuss this I would suggest something in the spirit of this:

The base code is free! No one can make it non free!

The induvidual parts like I/O drivers and logic engines and som one are free, parts can be added that are not free. Some (or all?) of the "basic" parts is allowed to take as an example to build their own non free part.

In this way I/O vendors may add a driver without giving the actual code away.

Other may add a very good controlling engine non free and so on.


This gives the project more substance and a possible money maker without making the entire project non-free.

Of course should the license be written in a way that it is completely impossible to interpret PLC code to automatically be free.

What do you think about this?


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


-----Original Message-----
From: MIME :[email protected] [SMTP:MIME :[email protected]]
Subject: Re: FW: FW: FW: LinuxPLC: Real Time? Take Two

Stan Brown wrote:
>
> On Sat Jan 22 08:00:32 2000 Curt Wuollet wrote...
> >
> >Hi All
> >
> >Reality time. Directly attached IO cards are the only "native"
> >IO this project has. If you want the best performance, this is
> >what you will be using. No fieldbus, no network, will ever come
> >close to what you can expect from optimised IO on the bus.
> >Every PLC comes with native IO and this is ours. That said, we
> >should be looking at some. In a sense, Ethernet IO is "native"
> >since networking is a big part of Linux, but, It is very early
> >in it's development and not at all standardized. Use IO boards
> >where you would use IO modules on a standard PLC and you will
> >gain all the same benefits, simplicity, speed, and function.
>
> AB makes cards that allow a computer (that;s us) to be the I/O
scanner
> for thire RIO. I ension supporting this very ealry in the project.
>
> Dont' other PLC vendors make such cards?
Hi Stan,

Yes, they certainly do, but, I expect their support for this project to be less than enthusiastic and it's extremely difficult to write drivers without cooperation. It's not easy with cards where they give you all the information you need. Some may give you the information, but, only under an NDA. This is worse than no cooperation, because it legally pollutes the project if any of it gets in. I would expect we can find an independent that is sympathetic and wants to become the reference provider of IO boards for the project. Almost all board vendors make as much money selling drivers and libraries as they make on hardware. I'm hoping the buying power of this group will sway a
board vendor to address this market. We, of course will graciously accept any cooperation from the PLC makers who would like to sell us
IO. That's where their money is also. We already have a board vendor who would like to help on some proprietary IO. ...<clip>

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
Well that is an interesting concept, but I think it would put us in the license writing bossiness.

To the best of my knowledge there are presently 2 major schools of Open Source software.

One is derived from the Berkeley license. It says to paraphrase "Take me and do whatever you want" As a result a company or individual can take this code and sell compiled only versions of it, with or without modifications.

The other school of thought is the GNU school. To paraphrase that it says "If you use this code, even part of it, in anything, then you must give away the source code to all, including your modifications.

I don;t think either one of these will do what you want.

Anyone want to comment on the LGPL, and whether it might apply?


--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.


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

Davis Ray Sickmon, Jr

In this case, the GPL would not make the code developed on and executed on the 'LinuxPLC' part of the GPL code.

Developing a brand new license is never really a good idea - there's plenty of licenses out there, almost each is taylored to a particular style of
development and distribution. GPL, LGPL, and BSD licensing are the most known, and more likely than not, the most enforceable licenses (why? The
amount of thought and time put behind the license over the years.) Quick rundown of the 3 biggies:

GPL: The code is free. If the software is development software, the code developed using the development software is not required to be under the GPL. If you make modifications to the original package, you have to make it available to anyone who you have given a copy of the pre-compiled binaries. (Most people believe that GPL is a free-for-all license. It isn't.
It just means if I give someone the binary, either by selling it or giving it away, I have to give them access to the source. When they have the binary or the source, they have the rights to do anything they want to with it, including giving it away, or incorporating the source into other GPL projects.)

BSD: The code is optionally free. Anyone can use the source to produce any type of direvitive project they want, without having to give the source away.

LGPL: This is designed for libraries. You can use the library in any fashion you want, but, you have to privide the source to anyone who wants
it. If you modify it, the same restrictions apply as with the GPL. However - any this is the important part - you can produce software that
links to the library, and they do not have to be GPL'd. They can be distributed under any license - the LGPL only applies to the license.

The reason for the difference between GPL and LGPL. Cygwin32 is a good example of a horrendous use of the GPL where the LGPL would have been
better. When you compile something under Cygwin32, you link to a GPL'd library. Suddenly, your project is GPL - it overrides any other license. However, if they would have used the LGPL instead, then the only restriction is you have to provide the source. If it had been a BSD license, then nothing is required at all. BSD's downside is that anyone can take the LinuxPLC project, compile and package it, and sell it off, without the authors ever seeing a dime, or any
of the changes made to the project. LGPL is good, but, the form of the project has to fall in such a way as to allow the LGPL to actually apply to it.

There's also a host of other licenses like the Artistic License which is normally applied to Perl stuff.

Not knowing what the final form the LinuxPLC package will take, GPL will probably work best if I/O drivers don't have to be integrated directly into the LinuxPLC project (IE - it is, or can be, a separate process that talks to the LinuxPLC, and doesn't require any of the code from the LinuxPLC to be integrated into the I/O driver, with the exception of some non-GPL'ed header
files). BSD works good under any situation, but has some problems (and usually seems to be view with scorn from the Open Source community at large
because nasty commercial things can be done with BSD licensed projects.)

What does everyone really feel they need for a license for LinuxPLC? I can probably find the 'perfect fit' if ya'lls tell me what you need. (I'm a lurker here at the moment, but, I've been involved in a couple of Open Source projects before, and read most of the licenses available. I'm also still trying to decide which license works best for a project I'm working on now called JaguarMMI (Ken - screw it, I decided to get rid of the Politically Correct HMI designation ;-) which is an Open Source MMI package.)

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman
 
S
On Sun Jan 23 19:06:25 2000 Davis Ray Sickmon, Jr wrote...
>
Very good summary <snipped>.

Thanks for writing it up.
>
>Not knowing what the final form the LinuxPLC package will take, GPL will
>probably work best if I/O drivers don't have to be integrated directly into
>the LinuxPLC project (IE - it is, or can be, a separate process that talks
>to the LinuxPLC, and doesn't require any of the code from the LinuxPLC to be
>integrated into the I/O driver, with the exception of some non-GPL'ed header
>files). BSD works good under any situation, but has some problems (and
>usually seems to be view with scorn from the Open Source community at large
>because nasty commercial things can be done with BSD licensed projects.)

Probably means that all of the tasks need to be GPL'ed and the shared memory interface libraries need to be LGPL'd.

At least thats my take on it.


--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.


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

Curt Wuollet

Hi guys

Any code I contribute will be GPL, let the chips fall where they may. I want zero chance of some company hijacking the work of others and selling it as their own. In this market, history teaches that free and open are very novel concepts so it must be squeeky clean. There is plenty of money that can be made using the project without selling it. As long as we are careful around libraries I don't think there will be any problems with code that runs on the PLC staying private.

Curt Wuollet,
Wide Open Technologies.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
> GPL: The code is free. If the software is development software, the
> code developed using the development software is not required to be under
> the GPL. If you make modifications to the original package, you have
> to make it available to anyone who you have given a copy of the
> pre-compiled binaries. (Most people believe that GPL is a free-for-all
> license. It isn't. It just means if I give someone the binary, either by
> selling it or giving it away, I have to give them access to the source.
> When they have the binary or the source, they have the rights to do
> anything they want to with it, including giving it away, or incorporating
> the source into other GPL projects.)

This may end up being an important point as far as clients are concerned.

If the licence of linuxPLC ends up requiring the source code to the control program to be supplied with the binaries, then the consultants doing the
automation can't overcharge for maintenance.

This feels like the Right Thing to do, but it may be that it's overly idealistic. Opinions?

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
 
S
For the project itself code, I personally prefer the Berkeley style copyright over the GPL. The GPL tends to potion code using it for use in other non GPL projects. This has resulted in much duplication of effort in the Open Source community.

However since certain members of this project are adamant about the GPL for our code, I can live with it.

We must be clear to come up with a way to avoid it confusing the issue that the application code (user code that runs on our engine) is _NOT_
GPL'd by inference, but can be proprietary.

Maybe someone needs to start a discussion with RMS on this. Volunteers?

--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M
This has been discussed both here and on the Automation list many times before.

As has been said, giving away the application code (ladder, IL, SFC etc.) is something that often gets done, but is often the last thing you want to do.

The reasons for not giving away the application code range from the economic to the legal.

Examples:
1) As an OEM, I would be loathe to give away application code that may fall in to the hands of a competitor giving him/her an advantage over me.

2) Many customers do not have the ability to control access to ladder listings, disk files etc.This could (and has in the passed) lead to
unauthorised modifications being made to the code. In many circumstances, these modifications could prove to be dangerous.

My understanding is that there is no requirement to give away application source (and that is what Davis is saying), if there were I could see no
reason to use the LinuxPLC. Mind you the the possibility of unauthorised persons modifying the PLC source in a hazardous way is also a very real
risk.

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

Davis Ray Sickmon, Jr

Well, I could email him real quick. I pretty much know the answer all ready, but, getting clarification from 'the man' wouldn't be a bad thing. Of course, we'll have to listen to a bunch of rhetoric on how we should be giving our customers the application code too ;-) (For those who have never had a conversation via email with RMS, or never followed one with him... he's a bit militant about it.)

Davis

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

Davis Ray Sickmon, Jr

Below is the request for information that I sent of to the Free Software Foundation (I went through [email protected] because if it's been asked before, they can just send me a quick 'stock' answer. If it's a new concern, then they pass it on to Richard Stallman) I stated the concerns as best I could, based on what I know (IE - if I was wrong in my thinking, point it out, and I'll send a second request that better states the question, but, email flames to dev/nul)

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

Greetings!
I am a somewhat member of the LinuxPLC project, which is dedicated to developing an alternative to closed-source style development PLC projects. Right now, we are investigating licensing issues, and we would like a
clarification of how GPL licensing would affect the LinuxPLC project. Here's the major concerns...

The LinuxPLC would be a 'logic solver' - basically, the developer writes a program of on top of the logic solver, which handles determining
how I/O is handled. The program in question isn't compiled code, but, is some sort of interpreted bytecode (as far as I know, the final
implementation of this is not decided, but, this should be a good enough description - I'm new to the project, so my knowledge of what level of
development is complete could be faulty.) 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? We are trying to avoid that situation, as there are times where liability may prevent companies from making the source for the program that runs on top of the Logic Solver available to the purchaser (A PLC runs equipment, some of which can be quite dangerous when a customer tampers with the program. An ammonia based cooling system, for example, can have quite explosive results with a minor change to the logic, causing it to open the wrong valve at the wrong moment!)

According to my interpretation of the GPL, the bytecode that runs on top of the Logic Solver would not automatically under the GPL. But, we
would like confirmation of this from RMS or someone else there at the Free Software Foundation.

If that is NOT the case, and the bytecode running on the Logic Solver is indeed automatically infected by GPL, what license will prevent that from becoming an issue with this project?

Thanks in advance for any information.

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

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

Hopefully, I'll get an answer back soon, and when I do, I'll post it on here.

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


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