Can someone give a clearer definition of what is "normally" allowed with the GPL? I read thru the one at www.gnu.org, but it is not so clear. How is it interpreted in real life?

1) Could someone implement "closed" modules to run under LinuxPLC if they supplied the whole thing? GPL seems to say as long as the GPL system is supplied as a whole, all the small parts MUST follow GPL.

2) What you say about XFree86 sounds like some people took the open source code, modified it & since (I guess) they supply it as a stand-alone add-on to GPL Linux they can by-pass the GPL. At least that's how I read the GPL.

I think we say much the same thing "The automation application very likely implements trade secrets of the client" says to me that they want to create small modules which are closed & yet include it in the whole. Yes, they may
not be charging $300 each for those modules, but the fact that you must pay $25,000 to have them do the project or you don't get those closed modules means the end is the same to me.

Can someone familiar with all the "commercial" versions of Linux (RedHat etc) comment on them - do they include any binary-only tools? I have RedHat 5.2 on an old Pentium-Overdrive machine, but have not looked at the source sections enough to see what has source and what does not. My reading of the GPL says that no, they are not allowed to do that. Do they in reality? Maybe
the fact that Linux comes on one CD-ROM and their tools on another CD-ROM makes them "stand-alone" enough?

I cannot offer any coding help if everything I do must be source code published in full. Some can be published - things like an Allen-Bradley DF1
drive is no real competitive advantage for me to hoard. However - as you say - certain trade secrets may be required and the guy who signs my paychecks (& who is NOT computer savvy enough to understand) will not approve of anything which he feels hurts the company.

Best Regards
- Lynn Linse

> -----Original Message-----
> From: Dan Pierson [mailto:[email protected]]
>
> > From: Lynn Linse [mailto:[email protected]]

> > I agree with Dan Pierson that in the end there has to be some way to make money with the LinuxPLC. If users can create (& charge for) various custom functions blocks, then I think the LinuxPLC has a real chance
for success. < <
>
> I'm happy that you agree with me, but that's not what I meant ...<

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

 

> From: Lynn Linse [mailto:[email protected]]

> Can someone give a clearer definition of what is "normally" allowed with the GPL? I read thru the one at www.gnu.org, but it is not so clear. How is it interpreted in real life?<

I really want to defer legal interpretations of the GPL to Ken's (or another) lawyer, but here are some comments on how I've seen it handled in practice.

> 1) Could someone implement "closed" modules to run under LinuxPLC if they supplied the whole thing? GPL seems to say as long as the GPL
system is supplied as a whole, all the small parts MUST follow GPL.<

It depends on how your module is implemented.

- If it links to or otherwise *includes* GPL'd code then it must be GPL'd. Example: a module written in C and linked with the LinuxPLC.

- If it is a separate executable that cooperates with a GPL'd executable it does not have to be GPL'd. Example: a stand alone module that talks to the LinuxPLC via sockets.

- If it is non-executable data that is used by the GPL'd code then it does not have to be GPL'd. Example: the "P-Code" output of an automation development tool that was executed by a P-Code interpreter in the LinuxPLC would not have to be GPL'd unless the license of the automation development tool required it.

- If the automation development tool was simply GPL'd, the license would probably not require GPL'd applications. Example: a GNU Emacs
extension written in Emacs Lisp does not have to be GPL'd.

> 2) What you say about XFree86 sounds like some people took the open source code, modified it & since (I guess) they supply it as a stand-alone add-on to GPL Linux they can by-pass the GPL. At least that's how I read the GPL.<

Not all open source software uses the GPL. XFree86 does not as far as I know. Flame wars between fans of different open source licenses are a Slashdot feature that I hope we can avoid .

All of this points out my FUD concern with the GPL. It's complicated enough that it's all too easy for people to be scared it whether or not
they need to be.

Dan Pierson

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

 

On Fri, Jan 07, 2000 at 01:49:07PM -0800, Lynn Linse wrote:
> Can someone give a clearer definition of what is "normally" allowed with the GPL? I read thru the one at www.gnu.org, but it is not so clear. How is it interpreted in real life?<

These licensing issues are nothing if not confusing and divisive, and I'm not sure I've ever read a description of any of them that didn't get challenged on a number of details.

A part of Larry Wall's article (mentioned in another post, October 1999 http://www.linux-mag.com) might address the sort of concern you mention (below). He says that "the GPL was
preventing people from using Perl", and that the Artistic License was added (to Perl) alongside the GPL to reassure the "business people".

The Library GPL was (I think) written to address these sorts of concerns, so that LGPL'd code could be used in closed source systems.

The license(s) for the Linux PLC (and related efforts) obviously needs to address the concerns of those who would use it, and I don't think it should necessarily exclude commercial interests.

> 1) Could someone implement "closed" modules to run under LinuxPLC if they supplied the whole thing? GPL seems to say as long as the GPL system is supplied as a whole, all the small parts MUST follow GPL. <

A recent thread from the Linux kernel developer's list (http://kt.linuxcare.com/kt19991227_48.html#1) might be interesting to read in this light. Someone wanted the kernel to accomodate binary-only modules, but met with "some" resistance from the leading developers. The bottom line seems
to be that the strength of Linux lies in its source being open, and there is no way the Linux effort is going out of its way for binary-only modules; instead it is the responsibility of
the binary module's developer to adapt to changes in the open source Linux kernel. OTOH, there is no restriction to say that people can't provide those binary modules, or kernel patches
to make them work, just that those efforts will not be made part of the kernel.

Since the Linux PLC effort is open, it should be no great problem for commercial interests to keep their products current, and even to accomodate different versions. If they diverge and go off in other directions, then they risk incompatibilities
with future versions of the open system, but that is at their (customer's) risk.

In my view, the selected license needs to protect the work put into the project, maintain acknowledgement of contributors, and ensure that the project can't be hijacked and made closed
and proprietary. I don't think these concerns are contrary to the needs of particular manufacturers wishing to take advantage of, and hopefully contribute to, the effort.

> I think we say much the same thing "The automation application very likely implements trade secrets of the client" says to me that they want to create small modules which are closed & yet include it in the whole. Yes, they may <

Per the above-mentioned discussion, it would be the responsibility of the manufacturer to see that their module works with the open sourced system, but not the other way 'round.

> not be charging $300 each for those modules, but the fact that you must pay $25,000 to have them do the project or you don't get those closed modules means the end is the same to me.<

That sounds like the free market working to me. No manufacturer will be forced to open their code, and they are free to pursue the market as they see fit, including benchmarking/comparing
their systems against the open source stuff.

I suspect that there may be a feeling that this will be unfair to those with proprietary interests. I'd imagine that the owners of toll roads weren't too pleased with the advent of
the public road system either, or ferry owners with bridges, but that's progress. Roads and bridges are in society's interests, and in the end probably open up more opportunities than they overrun. That's how I view the Linux effort as well, something like an open, public infrastructure that can support a plethora of applications, both open and closed.

> Can someone familiar with all the "commercial" versions of Linux (RedHat etc) comment on them - do they include any binary-only tools? I have RedHat 5.2 on an old Pentium-Overdrive machine, but have not looked at the source sections enough to see what has source and what does not. My reading of the GPL says that no, they are not allowed to do that. Do they in reality? Maybe
> the fact that Linux comes on one CD-ROM and their tools on another CD-ROM makes them "stand-alone" enough? <

I'm only directly familiar with one (SuSE), not all, but one difference between distributions is how they handle those binary tools. I think Debian takes the "pure" road, and only
distributes open source systems, but SuSE delivers pretty much everything available, and I think RedHat is similar.

I've tried some of the binary-only offerings, e.g., WordPerfect v8, but for practical reasons prefer to stick with the open source stuff, where possible. Binary-only means that users are limited to the provided documentation and the application developer's support to get to the bottom of tough problems. In open source, by contrast, it is possible to look at the code
to see *exactly* what is going on, if one has to. This is not to say that this is necessarily practical for Joe User, but it is possible, and even guaranteed.

> I cannot offer any coding help if everything I do must be source code published in full. Some can be published - things like an Allen-Bradley DF1 drive is no real competitive advantage for me to horde. However - as you say - certain trade secrets may be required and the guy who signs my paychecks (& who is NOT computer savvy enough to understand) will not approve of anything which he feels hurts the company.<

My hope is that amoung the "products" produced by the Linux PLC effort will be well-defined interfaces between components, which should allow even proprietary interests to also take advantage
of the work.

--
Ken Irving
Trident Software
[email protected]


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

 

I think the important thing to remember about licensing is twofold:

1. The goal should be as much opensource, freely available material as possible.

2. there are legitimate concerns about proprietary material that might make it into a project. there has to be a straightforward way to protect this type of material. my suggestion is that the legal beagles word it such that
application programs are not required to be open, nor is any subroutine, function or other software construct that an implementor considers to be
proprietary. if i spend $500,000 determining how to do something, I do not want to give it to my competition for free.

there should also be a provision allowing commercial products to be add ons to the basic package. that will encourage developers to develop products for it.


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

 

On Fri, Jan 07, 2000 at 01:49:07PM -0800, Lynn Linse wrote:
> I think we say much the same thing "The automation application very likely implements trade secrets of the client" says to me that they want to create small modules which are closed & yet include it in the whole. <

Actually, I don't think that's a problem - I'd interpret GPL as "anywhere the binary goes, the source must go also". So in this case, you'd be
required to give the source of those modules to your client, but not to any other party.

Any lawyers around?

That said, we may want to use the LGPL for some parts of the project. LGPL is designed so that proprietary programs can link agains LGPL libraries. OTOH, it may leave the project vulnerable to Microsoft-style "embrace and
extend" tactics.

[<rearranging>]
> 2) What you say about XFree86 sounds like some people took the open source code, modified it & since (I guess) they supply it as a stand-alone add-on to GPL Linux they can by-pass the GPL.

X isn't GPL. Also, many linux libraries are LGPL, allowing their use in proprietary programs.


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