Linux in the field

C

Curt Wuollet

Hi Mike

I would say that yours is a good example of making it work rather than simply assuming it can't be done. I have been trying to do much the
same with a PLC form factor, PC compatible, hardware platform for MAT or other, preferably Linux control software. Showing that the problems
are relatively easy to solve gains a lot more traction than discussing them. My recent enforced vacation virtually wiped out this effort and I
still haven't managed to find the time and resources to proceed, but the approach is much the same.

For users who don't want to know, it could be treated in much the same way as any other PLC product. although I don't see myself writing
Windows tools. Because it would be really Open, anyone with a burning desire could do so and contribute them to the community. People with
sophisticated needs or tastes could do nearly anything possible with Linux, which would raise the bar for automation platforms considerably.

Since I am from a T&M background this could answer the gap between automation and autometed testing as well. And the growing need for hard or soft realtime with PLC functionality could be met fairly easily on this platform. Currently I am torn as to whether I can go it alone and publish a free design, or gather up a few investors and
make a product out of it.

It's not at all that I want or need to make money from it, but that a ready to run product with spares, support, etc. might have a bigger impact and do more to further the cause. Just as many are struggling to get their arms around a suitable software model, I am thinking hard to find a hardware model where there is even less precedent. SoftPLC's Tealware and Grayhill's modular product haven't set the would on fire.
And very few people could or would make their own from a reference design.

Something in the middle is needed. A way to do the hard parts without doing a full blown manufactory and raising burden. And all of it while staying Open and giving the customer a clearly better deal. Stuff you can buy and/or use is what's really limiting Linux in the field. And a platform that is as user friendly as Linux and already commoditized. It's a tall order, but quite doable. I can feel it. I know I can do it. I just want to build a winner for all parties.

Regards

cww
 
> > Alex Pavloff:
> > > Here's the other thing: The drivers can't be GPLed. LGPLed,
> > > *yes*, but I don't think that any integrator is going to write a
> > > bunch of code so as to control the widget machine and just give
> > > that away to anyone that asks. Sure, small programs that twiddle
> > > a few bits and turn on a motor, yeah, but I can't see any
> > > integrator spending weeks on a project and just giving the
> > > machine-specific code away.

Jiri Baum:
> > In reality, it's not such a big problem, because:
> > - The GPL requires the integrator to give the code to the client, but
> > not to anyone else. Indeed, the integrator can be under NDA not to
> > give the code to anyone else, and that's quite OK under the GNU GPL.

Mark Blunier:
> The argument was that the integrator would not his code spread around
> - assuming that the integrator owned the code. <

The integrator is being paid by the client; as such, the client has (should have) final say as to who may or may not have the code, etc.

> So there are times that a LGPL license might be more palatable to
> integrators that do not want their code redistributed. But I wouldn't
> go so far as to say GPL shouldn't be used, but rather some people may
> prefer LGPL over GPL. <

Never the end-users, though, as far as I can see.

> > - There is no publishing requirement, merely a right.
> > - The integrator gets paid by the hour to make the machine work (or
> > by the estimated hour to make the machine work). Whether that code
> > ends up on one machine or a thousand makes no essential difference.
> It makes a very big difference. When we have a company A come in and
> put in a distillation system, even though we paid them to design the
> process, it is there design. We can't take their engineering drawing
> and sell or give them to company B to have them build another system
> just like it. <

Precisely. If you decide that company A no longer meets your needs and you want company B to take over that part of your supply, you will have to pay for that part of the design *again*, even though you've paid for it once already, and then have to live with having a mixture of two different designs.

Much better to insist that company A use the GPL in the first place and then simply have company B take over when circumstances so dictate (or some other licensing arrangement that allows this).

This means, of course, that company A will have to be paid for the design in full (that is, in cash rather than in lock-in), but that's fairer all around anyway.

> > > This is one of the issues that has to be addressed -- directly --
> > > by anyone wanting to push GPL software into machines.
> > Most of the packages make no such statement about user programs,
> > anyway, so that the stepladder might have completely different
> > licensing than the automation package running it.
> They should make such a statement. They should be very clear as to
> when the copyright holder considers the user program a modification of
> the main program if it is something that has its own license. <

They should, true.

> > This is the same as using the gcc (GNU C compiler) to compile a
> > program: it says nothing about the license for the program, even
> > though the gcc is GPL.
> Its close, but not the same. Gcc code can run after its been compiled
> without gcc being installed. It is probably more similar to using
> binary modules compiled separate from the Linux kernel. <

Note that binary modules in the kernel are a special exemption granted by Linus, and tend to be a lot of bother to use.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
> > > "Automation" on Linux also requires conventional software tools as
> > > well (e.g. Python) as alternatives to things like "VB" which are
> > > used on Windows.

Jiri Baum:
> > We have python; any others that we should cover?

Thanks for the list, Michael - I'm definitely saving it for future reference...

Michael Griffin:
> C/C++,

Natively supported by the MatPLC.

> Java, Borland Kylix (Delphi),

Not familiar with them, but they shouldn't be particularly difficult; just a question of writing a small wrapper around the MatPLC library.

> and Labview

Labview is proprietary, so it's up to them to be compatible with us. Not much we can do about it. We might be able to use something like Modbus to interface to them, but that would always be a kluge.

> You wouldn't need to provide too much detail on these other languages,
> other than to point out where to get more information on them.

Right.

> As well as langauge compiler or interpreter, most projects need
> additional components. GUI builders,

For now, we use glade, which is a general-purpose GUI builder.

> math and signal processing libraries,

MatPLC has a "DSP" module which does some of this.

> databases,

We can log to a database right now, but not very flexibly. Of course, a python script can be used to do that, or anything else that goes between a database and a MatPLC setup.

> 1) Machine OEMs who use PC based controls in standard machine designs, in
> particular ones who write their own proprietary software.
> - Soft logic system. Some sort of motion control is typically
> needed with these.

Classicladder is the preferred one, it's a graphical ladder thingy. Other than that, we have a simple mnemonics compiler, and the IEC languages are in progress.

Motion control we don't have, but we're in communication with the Orocos and EMC controller projects, which each have that.

> - CNC control.

See the EMC controller project. Interface with the MatPLC is currently being discussed and planned.

> - Computer based custom MMI. This would be just a "widget" set
> and not a large scale "MMI system".

MatPLC has this.

> - Drivers for I/O systems (Profibus, etc.).

We have a few of those, but not nearly enough, and most of them are through the Hilscher cards.

> - Web browser for the help system.

Yeah, use a standard web browser.

> - Web server for reporting production statistics.

Juan has an on-line demo which links MatPLC to Zope and does this kind of thing, but the howto is not all there. I don't remember the URL, but there's a link from our homepage (http://mat.sf.net).

> - How to do the above on a diskless system (solid state drive).

Largely the same as normal - Linux doesn't make much of a distinction between different kinds of drives. The only specialty would be executing the programs directly from the drive (XIP - eXecute In Place).

> 2) Automated production test equipment.
> - Programming languages (Python, etc.).
> - Widget sets (for MMI).
> - Database for logging test results.

As above.

> - Data acquisition board drivers.

COMEDI is the standard library for this; linking MatPLC and comedi is near the top of the to-do list.

> - Drivers for interfacing to PLCs (Profibus, Modbus, etc.).

As above.

> - Bar code generator (for serialised labels).

No idea, here; a quick search shows that linux should be able to generate UPC-A, UPC-E, EAN-13, EAN-8, ISBN, code 39, code 128 (b and c), and interleaved 2 of 5, but I've no experience with it.

> 3) Interfaces to IT systems.
> - Drivers, drivers, and more drivers.

Yeah.

> - Web servers, XML stuff, etc.

XML has been strongly pushed at the Linux in Automation workshop, but I don't think anyone is using it yet.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
M

Michael R. Batchelor

Unless the customer has an explicit "work for hire" agreement, or the integrator works on-site "at the customer's direction" the code belongs to the integrator by international copyright law. Most customers will disagree with this, and my little 5 man two room integration firm isn't going to take on Ford Motor Company's lawyers to argue it, but those are the rules.

MB
--
Michael R. Batchelor - Industrial Informatics, Inc.
Contribute to society: http://www.distributed.net/ogr/
MB
 
M

Michael Griffin

On June 12, 2003 17:44, Jiri Baum wrote: <clip>
> Precisely. If you decide that company A no longer meets your needs and
> you want company B to take over that part of your supply, you will have
> to pay for that part of the design *again*, even though you've paid for
> it once already, and then have to live with having a mixture of two
> different designs.
<clip>
> This means, of course, that company A will have to be paid for the
> design in full (that is, in cash rather than in lock-in), but that's
> fairer all around anyway.
<clip>

I think what was being discussed wasn't an "integrator", even though that was the term used. There are a lot of applications involving off the shelf equipment where although the general theory is common knowledge, the actual methods, equations, and algorithms used are secret. If you buy a balancing machine, you are not really paying for the manufacturer's software and assembly manhours. You are paying for their detailed knowledge and experience of the application area which is incorporated into the hardware/software design.

For the customer, there is no benefit in having "the design in full". This level of sophistication is far beyond most customers, and even further beyond any typical third party "integrator" they may wish to hire.

If you are not aware of the type of equipment I am talking about, then you are missing your main opportunity. These sorts of companies are the ones who are most likely to be interested in "Linux in automation" in the near future. They provide a finished product, they have service departments, and they already provide ongoing support for their customers. Their customers buy a finished product, and don't specify what sort of "computer stuff" goes into it. If any application is going to introduce Linux into the factory in an obvious way in the near future, this is it.

You're not going to get the interest of these people though, unless you can provide a way for them to use drivers (Profibus, Modbus, etc.) without putting the entire application under GPL. Either you grasp this nettle firmly and deal with it, or else write off your best prospects.

--

************************
Michael Griffin
London, Ont. Canada
************************
 
M

Michael Griffin

On June 12, 2003 18:07, Jiri Baum wrote: <clip>
> > - Bar code generator (for serialised labels).
>
> No idea, here; a quick search shows that linux should be able to
> generate UPC-A, UPC-E, EAN-13, EAN-8, ISBN, code 39, code 128 (b and c),
> and interleaved 2 of 5, but I've no experience with it.
<clip>

There is bar code generation software for Linux (I don't recall what it is called), but I believe it prints to ordinary laser printers. This is fine for applications which print on paper, but is no good for proper label printers.

"Label printers" are generally thermal transfer printers which print on rolls of label stock, and can handle various difficult media including things like foil. They typically use a printer language like "IPL" (Intermec Printing Language) or "ZPL" (Zebra Printing Language). These printer languages are generally human readable (if somewhat cryptic) ASCII text.

Now that I think of it a bit, I'm not sure that bar codes would be a big problem with these printers, as it is possible that the printers may generate the bar code graphic internally from ASCII text. I would have to check some manuals to see if this is so. I've only used bar codes for constant data, and I haven't used them for serialising (yet), so I haven't checked this point carefully.

Label design software would be nice though. Normally, you can buy label design software where you draw the label on the screen and it writes the label printer "program" for you. It would be nice to be able to run this software on the system that has the label printer hooked up to it so that when you introduce a new label you can "tweak" the label design on the spot as you try it out. This is a lesser issue though.

I seem to have used a lot of words to say that maybe there isn't a real problem here after all. I will report back on this if I can remember to check it out at work.

> > - Web servers, XML stuff, etc.
>
> XML has been strongly pushed at the Linux in Automation workshop, but I
> don't think anyone is using it yet.
<clip>

XML is a buzz word you have to have. You want to be able to say "we have XML" to show that you have your full complement of jargon. There are lots of XML parsers for Linux, so availability of tools is not a problem. The problem is going to be figuring out ways of making use of it.

I can see a use for XML though as a form of electronic data sheet. The XML tags would get embedded in the actual data sheet. You can read the data sheet, and your machine can read it too. This sounds a lot less cryptic than GSD files, especially if you could edit it in OpenOffice using some form of template. This might be a good standardised way of creating configuration or initialisation files that are self documenting.

--

************************
Michael Griffin
London, Ont. Canada
************************
 
M

Michael Griffin

Further to my discussion with Mr. Baum in a previous message on printing bar codes (Thursday the 12th), I checked into printing bar codes on a typical label printer (Intermec in this case), and yes this appears to be a built in feature of the printer. These are generated on the printer itself and not via some magic software in the computer. In other words, there should be no problems using typical label printer features with Linux.

I believe there is a Linux bar code generator program for use with conventional printers. I don't however know if conventional printers are ever used for industrial label printing. If they are, then that bar code generator could be useful.

--

************************
Michael Griffin
London, Ont. Canada
************************
 
> > Mark Blunier:
> > > The argument was that the integrator would not his code spread
> > > around - assuming that the integrator owned the code.

Jiri:
> > The integrator is being paid by the client; as such, the client has
> > (should have) final say as to who may or may not have the code, etc.

Michael Batchelor:
> Unless the customer has an explicit "work for hire" agreement, or the
> integrator works on-site "at the customer's direction" the code
> belongs to the integrator by international copyright law. Most
> customers will disagree with this, and my little 5 man two room
> integration firm isn't going to take on Ford Motor Company's lawyers
> to argue it, but those are the rules.

Which is why the client should insist on the GPL (or similar) up-front rather than being unpleasantly surprised afterwards.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
C
I have personally used Zebra printers with Linux, no problem. I also wrote software to generate barcode labels on an ordinary epson inkjet once upon a time for a hospital system. The Zebras work well, but are kinda spendy, both initially and in consumables. A good inkjet will cut the cost per label way down. It might be hard to write the software now as half the printers are Winjunk and the rest are so dumbed down that you can't get the technical information you need on raster graphics methods. Fortunately, the Linux ghostscript driver source can be mined for much useful information. But, a quick google for Linux barcode shows that you wouldn't have to roll your own anymore. This was a big deal 10 years ago.

Regards

cww
 
P

Peter Whalley

Hi Michael,

That's the default situation in most jurisdictions if the contract says nothing to the contrary. Many clients however will explicitly require in their contracts that they get assigned copyright. If so then that's what they get.

The problem arises however when the SI or consultant is either re-using code developed on a previous project and wishes to retain rights to use this in the future or is producing code on a project but would like to be able to use it in the future or is using code under license but doesn't own it (very common if you use libraries or boiler plate text).

In the first case the client is not paying to have the code produced but is just paying to make use of the code for this project. In all my contracts where the client requests ownership of IP I put in a caveat that it only applies to material created specifically as part of the project.

In the second case you may not charge the full cost of development because of the future value of the work done or you may assign ownership to the client but on the condition that they license you in reverse to allow you to use the code for other projects in future.

At the end of the day IP rights are defined under contract not on the basis of what anyone thinks is fair or reasonable but have not bothered to document. And yes sometimes might is right.

This is not legal advise. If you need legal advice see a lawyer.

Regards

Peter Whalley
 
R

Ralph Mackiewicz

Mark Blunier wrote:
> > > The argument was that the integrator would not his code
> > > spread around - assuming that the integrator owned the
> > > code.

Jiri Baum wrote:
> > The integrator is being paid by the client; as such, the
> > client has (should have) final say as to who may or may not
> > have the code, etc.

Michael R. Batchelor wrote:
> Unless the customer has an explicit "work for hire" agreement, or the
> integrator works on-site "at the customer's direction" the code
> belongs to the integrator by international copyright law. Most
> customers will disagree with this, and my little 5 man two room
> integration firm isn't going to take on Ford Motor Company's lawyers
> to argue it, but those are the rules. <

Your take on copyright law is correct. My personal opinion is that most customers aren't really interested in "owning" this code anyway. They will typically just want to have the flexibility to use what they paid for internally. I suspect that most integrators don't have a problem with their customers using the code they produce for a project more liberally than what a strict interpretation of copyright law would allow. I think having integrators own the code is better for the user in the long run. Integrators that are allowed to retain this stuff will be more productive on the next job if they don't have to redo it again to avoid using pre-existing code (assuming that you could even identify what was prexisting and what wasn't). Integrators that own code will be motivated to improve it. As long as the integrator treats the user reasonably, as the vast majority do, the original user reaps the benefit in subsequent projects. Besides, there is very little truly original code produced unless it is the first project done by the integrator. All code produced is generally a by-product of the code previously produced by the same integrator. This happens even if the code is not copied instruction by instruction. After a couple of projects, a user isn't paying the entire cost anymore. This is one of the many reasons why users like experienced integrators.

Regards,
Ralph Mackiewicz
SISCO, Inc.
 
R

Ralph Mackiewicz

Michael Griffin wrote:
> > > - Web servers, XML stuff, etc.

Jiri Baum wrote:
> > XML has been strongly pushed at the Linux in Automation workshop,
> > but I don't think anyone is using it yet.
<clip>

...snip...snip...

Michael Griffin wrote:
> I can see a use for XML though as a form of electronic data sheet. The
> XML tags would get embedded in the actual data sheet. You can read the
> data sheet, and your machine can read it too. This sounds a lot less
> cryptic than GSD files, especially if you could edit it in OpenOffice
> using some form of template. This might be a good standardised way of
> creating configuration or initialisation files that are self
> documenting. <

IMHO, XML is an excellent way of creating configuration/installation files that are self documenting. If XML was popular years ago, concepts like the Device Description Language and Profibus GSD files would be much more widely used than they currently are in their IA specific formats. For instance, the IEC61850 standard is using XML for the basis of a substation configuration language (SCL) that enables the configuration of substation devices to be described in an open manner.

Regards,
Ralph Mackiewicz
SISCO, Inc.
 
G
This sort of software is available for Linux. Here are some highly capable commercial offerings:

http://www.nicelabel.com/nicelabel/nlbl_ver_linux.php
http://www.unibar.com/
http://www.labelsoftware.com

Here's the most capable open source package I found:

http:/ http://www.kbarcode.net/

From the project's Freshmeat page:

KBarcode is a barcode and label printing application for KDE 3. It can be used to print everything from simple business cards up to complex labels with several barcodes, such as article descriptions. KBarcode comes with an easy-to-use WYSIWYG label designer, a setup wizard, batch
import of labels (directly from the delivery note), thousands of predefined labels, database managment tools, and translations in many languages. Even printing more than 10,000 labels in one go is no problem for KBarcode. Additionally, it is a simple xbarcode replacement for the
creation of barcodes. All major types of barcodes like EAN, UPC, CODE39, and ISBN are supported.

Regards,

Greg Goodman
Chiron Consulting
 
On June 14, 2003, Michael Griffin wrote:
> There are a lot of applications involving off the shelf equipment
> where although the general theory is common knowledge, the actual
> methods, equations, and algorithms used are secret.
...
> You're not going to get the interest of these people though, unless
> you can provide a way for them to use drivers (Profibus, Modbus, etc.)
> without putting the entire application under GPL. Either you grasp
> this nettle firmly and deal with it, or else write off your best
> prospects.

In other words, you think we should write their code for them, but not expect them to give anything back?

(The GPL doesn't require people to contribute back; but it does encourage it.)

I agree that there are certain applications for which proprietary code is an advantage, though they are probably much more rare than you think; but part of the cost of writing proprietary code is that one may not use the great treasury of code that is Open Source.

There are sufficient other markets in which the MatPLC can thrive without compromising the core principles upon which it is built.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
L

Lynn at Alist

On June 12, 2003, Jiri Baum wrote:
>The integrator is being paid by the client; as such, the
>client has (should have) final say as to who may or may not
>have the code, etc. <

Of course, "receiving the code" is not the same as actually having it. I once was contracted to evaluate the "source code" some big company had been given as part of a contract 4 years earlier. Unfortunately, at hand-over some idiot just looked at all the thousands (literally) of files of code and said "Yup, looks like the source is here". They may even have run a "Make" to confirm it could recreate the code.

Unfortunately, they didn't look through the code itself. The contractor had run some form of filter thru 95% of it. Literally all comments were striped, all variables and function calls had been renamed to things like int2345 and func0345(). And the 5% that missed the filter had all comments and variable name in a foreign language.

So in effect they had nothing really usable - even though they had the source code. ;^]

- Lynn
 
On April 25, 2003, Patrick Allen wrote:
>Is there something out there and I'm just missing it? <

This entire thread missed it! Hint do a search with Google and type "soft PLC" or "Linux HMI".

We have available complete Linux solutions for most of the past decade and have many installations running very successfully in different parts of the world. Not just HMI but a client server system that does all control, HMI,
trending, etc. We are developing for the Chinese market right now with a large effort for substation automation.

We are staging an acceptance test in Europe for their system next week, and plan to go into a second round of independent quality testing in China for the last week of June. We invested a few 100 thou on this project as well as the customer.

With this effort we have developed a great version of automationX for Linux. We are debating a plan to release this software under a "free" license program for certain parts of the world, like North America. Parameters would
be to limit the variable count to support around 100 I/O, have a nominal registration fee to cover issuance of the license.

Right now the penetration of Linux is small - the question is would even free software increase the number of users?

Regards,

Paul Jager
www.mnrcan.com
 
Hi Ralph

If the integrators own the code what's to stop them from charging the client ongoing licensing fees as do all proprietary software vendors?

When I hire a programmer to do work for me I make sure he gives up any rights to the code - or he doesn't get the job.

If I ran a plant I would also retain the copyright. Why should I pay for developing code, and the great expense of testing it, that my competitor can obtain for less money (maybe a lot less) or with which the software developer can make a profit at my expense? If he wanted the right to resell for his profit I would expect that our deal would involve very favorable terms for me. If this isn't happening now, it will soon change when the plant operators realize what it is costing them.

Bob Pawley
 
Right on Ralph! All integrators worth their rates will have blocks of code that they have written for themselves or others to which they can claim ownership. When I worked at Modcomp in the "old days" our standard agreement was that any original code belonged to Modcomp, while any existing code used by the contract programmer/ integrator was forever licensed to Modcomp. This is called "Intellectual Property" (IP) by the courts, and provision for the protection of IP should be in all contracts in which programming or other technology is provided by a supplier. It is even more important when the customer intends to merchandise products containing that IP. Read the fine print!

Dick Caro
============================================
Richard H. Caro, CEO
CMC Associates
2 Beth Circle, Acton, MA 01720
Tel: +1.978.635.9449 Mobile: +1.978.764.4728
Fax: +1.978.246.1270
E-mail: [email protected]
Web: http://www.CMC.us
============================================
 
M

Michael Griffin

On June 19, 2003, Greg Goodman wrote: <clip>
> This sort of software is available for Linux. Here are some highly
> capable commercial offerings:
>
> http://www.nicelabel.com/nicelabel/nlbl_ver_linux.php
> http://www.unibar.com/

These both look very interesting. The Nicelabel product has some Linux printing software for doing certain things, but not for actual label design. Their label design software is still Windows only. I'm not quite sure just what Unibar was offering.

This issue isn't very important though. If you are printing serial number labels at test stations, you don't need any special software to print the labels. The label designs are a file, and you print that file to the printer. Given that commercial label design software tends to be rather expensive, it may not really be that desireable to have it loaded on the test equipment just to let you try out new label designs.

> Here's the most capable open source package I found:
>
> http:/ http://www.kbarcode.net/

I was aware of this one. It uses a back end which generates postscript. This is good for conventional printers, but not for thermal label printers which use specialised printing languages. I haven't seen any label printers which use postscript (I rather wonder why that is so).

--

************************
Michael Griffin
London, Ont. Canada
************************
 
M

Michael Griffin

On June 19, 2003 22:30, Jiri Baum wrote: <clip>
> In other words, you think we should write their code for them, but not
> expect them to give anything back?
<clip>

I think they can write code for you, if you will let them. The things you should be looking for co-operation on are things like communications drivers, GUI widgets, and other commodity building blocks. They want to protect their trade secrets from the 2 or 3 other companies in the world that compete with them. They can share the commodity items with the hundreds of companies that don't.

> I agree that there are certain applications for which proprietary code
> is an advantage, though they are probably much more rare than you think;
The number of different applications is small, but since these machines get produced in quantity (e.g. in hundreds or thousands), the designers can afford to spend more time on the software. They will spend years on a development project, rather than trying to get a one-off out the door in weeks. They have the time to work on the sorts of things you want to do, and they have the incentive since the effort can be spread over a large number of sales.

> but part of the cost of writing proprietary code is that one may not use
> the great treasury of code that is Open Source.
I would be rather surprised if you were not aware that virutally every major business software company except Microsoft is basing the future of their business on combining their proprietary offerings with open source commodity foundations. And quite frankly your statement is simply wrong in that the GPL isn't the only open source license. Even Microsoft was able to cut and paste a lot of BSD and other stuff into Windows.

> There are sufficient other markets in which the MatPLC can thrive
> without compromising the core principles upon which it is built.
<clip>

The MatPLC is intended as a complete stand alone product. I agree that the safest thing to do with it is to license it under GPL. Anything else has too much potential for problems.

However, this doesn't address what to do about things that are essentially general purpose libraries. The most important item that comes to mind is communications drivers. Why can't they be treated under a license that requires the libraries to be open source, but allows them to be linked to a proprietary program (LGPL)?

--

************************
Michael Griffin
London, Ont. Canada
************************
 
Top