"Software licenses" for PLC applications

J

Thread Starter

Jason Greff

Hi everyone. I've seen some discussions of this topic over the past year, but I'd like to try it again. Let me begin by telling you a little about our company.

We work primarily (although not exclusively) in the water and wastewater business. Usually when we provide control panels for a job we are bidding a job "lump sum", and we are bidding to a specification written by a consultant. Often the consultant may include verbage about warranty, as well as supplying copies of the PLC source code. We have never turned on any "code protection"
bits in the PLC, which means our code is freely accessible to anyone with the right hardware and software.

We consider ourselves an integrator, not an OEM. We don't typically provide a "canned" application, although many times the equipment and software may be very similar to another job.

Some companies like to get service calls because they can charge exorbitant amounts of money for a service trip. We don't like service calls. Most plants have technicians or electricians in charge of maintaining the plant. We would prefer NOT to get a call every time a small issue occurs. Often the call originates under the guise of a warranty issue, only later do we find the cause
to be unrelated to our code and equipment, but getting paid at that point is difficult. In addition, we are often chasing additional work with the customer, and we would prefer not to offend them or send them to our competitor.

Sometimes a warranty period can be difficult to determine, since we might be making changes to a program as part of a new project with the same customer. Customers might also be interested in making minor code changes themselves as a part of maintenance (a limit switch is out and they want to jumper around the input).

The reason for this preamble follows. A business consultant asked us if we included a license as part of our PLC source code. We do not, and have not. I think in the past our attitude has been that the customer typically owns the code (at least after the warranty period). The consultant then asked if we ever "re-use" code, meaning start with one customer's code and then modify it
for a new job we might be working on for a different customer. His assertion was that if the customer owns the code, we would be violating the law by using this code on another project.

We are now considering using a license, at least in certain cases. Having some familiarity with GPL's and open source, I have considered some type of GPL where we own the code but allow our customer the use of it - also allowing them
the right to modify it if necessary. We would retain ownership of the code, allowing us to re-use it, and also preventing others from profiting from it.

My questions are:
- Is anyone else doing this, or have you looked into it in the past?
- Has anyone had a lawyer look at it?
- What other issues have I missed that might have a bearing in this discussion?

Thanks for your comments.

Jason Greff
Instrument Control Systems
 
T
I am reminded of an interview I saw of the creators of a program called Visi-calc. It was the first computer spreadsheet. Being academics, they did nothing to protect their program or idea. He was asked what having failed to protect their intellectual property had cost. The response: "hundred of millions of dollars."
Your PLC code is not likely to be worth hundreds of millions, but there are cases where you may want to protect that code with a limited license. No matter what the case, you should make it clear to your customers in your contracts just who owns the software, who can use it and modify it, and who can re-use it if needed. You'll prevent future legal headaches. Something to consider: you build a system for a customer, customer thinks he owns the software, and he likes the system. A year later, he wants another system like the first, but this time you don't get the bid. The guy who gets the bid puts
in the second system, and copies the software you wrote. If the customer owns the software this is OK, and your competitor profited from your work. If however there is some kind of limited licensing you're in control, and increase the likelyhood that you'll win the second contract since your competitions software engineering cost will be greater than yours.
 
Not knowing what end of the business you are in, let me ask: Are you using a limited license? Have you had a lawyer "bullet-proof" it? How do you customers like it (I'm guessing they don't)?
 
M

McAlpin, Steve

Hi Jason

I am the Control System supervisor for a major municipal water company and if an integrator came to me saying he had a license for the PLC code
he would not get our business. We pay for the code and therefore it is ours to own. Just like buying a car. I can see your point, this is just
what I feel in relation to the subject.

Steve McAlpin
Control System Supervisor
Calleguas Municipal Water District
2100 Olsen Road, Thousand Oaks, CA 91360
Phone: (805) 579-7148 fax: (805) 579-3721
Cell Phone: (805) 501-9037
E-mail: [email protected]
 
N
Jason: Walt Boyes sent your post to me as something that CSIA (The Control Systems Integrators Association) should be looking at. My response is that, we have been. Our Best Practices and Benchmarks Committee is, I believe,
trying to deal with this important issue at this time as part of an overall effort to help our members with Terms and Conditions. I'm going to pass this on to Denny Mosher the Chair of that committee for comment. BTW, if you're an S/I please come join us we're dedicated to addressing problems (especially business problems) that Systems Integrators encounter. Check us out at "http://www.controlsys.org":http://www.controlsys.org

Best

Nels Tyring
CEO of TVC Systems
and
Member for Liaison of the CSIA Executive Council
 
B
It is my understanding that developing software under a contract, in the US, the person who pays the contract costs owns the full rights to the software. Before the contract is signed it would need to include the ownership rights if these rights are to be assigned to any one else other than the person or company paying the cost. The law in Canada on this point is a little different. In the US, as it is in Canada, contract law is very specific and is strictly adhered to by judges in both countries. In every case ownership rights of the software should be clearly stated in any and all contracts.

Bob Pawley
250-493-6146
 
B

Bruce Durdle

Ask your "business consultant" if he has ever taken a proposal written for one customer and re-used bits of it for another. Perhaps a paragraph or two? Perhaps a sentence? Perhaps a word here and there in common?

Or does he expect that, if you work on a hardware design for one client, (say draw up a control panel), you will not use those same drawings as the basis for the next client who wants to put a similar installation into the
same size panel.

Unfortunately, when business consultants and lawyers come into the room, commn sense seems to fly out the window!


Bruce.
 
J
Jason,

It sounds like you want to turn your standard PLC programs into software products instead of custom software. In the state of California, software products are subject sales tax, custom software is not. On a lump sum contract this means you would have to assign a fair market value to your standard PLC programs and pay the sales tax on them, your competitor would not.

That's just California and the tax implications may be different in your state, but it is something to consider.

You are also putting lawyers into the equation that determines the price of your products and services, the lawyers will make the money from this, not you.

Has it really come to that ?

Jay Kirsch
 
C

Curt Wuollet

This is a really interesting tightrope to walk as the customers interests and yours can directly conflict. Some people are up front that they want all the source and may have their in house people build system number two. I know of very bad feelings that have resulted from locking a part of the code. And some people would shop around with the IP. I don't think in any case it's a good idea to agree not to use the code or similar again as it's very likely that you will. After all, most applications have a lot in common and a court is unlikely to understand the fine points. Taking a stand against your customer is bad business. I think the open approach with a non-exclusive clause may be the best approach combined with absolute clarity and a meeting of the minds up front. It's easy to lose the business either way if the customer is unhappy with the deal. In my consulting biz, if you pay me to write it it's yours, but I'm clear that it may look a lot like the last thing I did or the next and that's to their advantage because code reuse saves them money. It's quite a bit different if the process or machine represents a valid competitive advantage that is important to the customer or you are made privy
to trade secrets or in the rare case, actually invent something significant.

Regards

cww
 
M

Michael Griffin

I will begin by saying that I won't attempt to offer you any legal advice, but I can perhaps offer you some practical advice.

GPL is intended for code which is freely distributed and used - rather the opposite of what you are trying to achieve. I think you are looking for some other sort of limited license whereby you retain ownership and so can re-use it as you see fit. Your customer would free to use or modify the code you provided, but is not free to re-sell or distribute it indepedently of of the original system you provided. This would seem to "cover" you if by some odd chance you got into a legal battle with a customer who had gone mad.

However, this leaves the issue of "preventing others from profiting from
it". The example is sometimes cited of the customer having someone else duplicate a machine and then loading the existing program into it. Regardless of whatever your "license agreement" stated, would you really consider suing your customer in court over this point? Unless the answer to this is "yes", then it shouldn't be a consideration in your decision.


--

************************
Michael Griffin
London, Ont. Canada
************************
 
There is only one license that will work in this situation.

The issue, Steve, is that if you think you "own the code," you may also think you own the rights to reproduce the code, instead of just the application of the code that was written for you.

There are only a few ways to write code for example, to control a 5-pump pump station, or to control a deep-well pump wellstation...and no matter what, integrators re-use sections of code. They "template" projects, too, and that helps hold costs down.

The GNU license and similar legal fictions enables the code to be licensed, and still available to you, and to the integrator, and both of you can use it, re-do it, and have other people work on it than the original integrator.

As the control system integrator business grows larger, these legal issues are going to be thrashed out, and hopefully they'll be done before they get thrashed out in court.

Walt Boyes

---------SPITZER AND BOYES, LLC-------------
"Consulting from the engineer
to the distribution channel"

[email protected]
21118 SE 278th Place
Maple Valley, WA 98038
253-709-5046 cell 425-432-8262 home office
fax:801-749-7142
--------------------------------------------
 
But this scenario is about open control. The only reason for proprietary code is to prevent someone else profiting from your intellectual endeavor. It is ALWAYS cheaper to come in for project #2 and just swipe the code you worked hard to write.

The defense, in the absence of licensing or other controls, is to charge enough money that the first implementation of the code pays for any reasonable use afterward.

If Microsoft had done that with Windows, it would have cost US$15K a copy.

Remember when UNIX and mainframe software was that expensive?

The big problem with open control is that nobody has yet created a business model that protects the actual author of the original work, and allows the author to profit from the work. What open control does is to permit the integrator and the end user to profit at the author's expense...just see if it doesn't.

If this is okay to you, fine. If you are a code developer, and you think this is fine, I'd like to see your financial statement, or your proof of sanity certificate. You either are already independently wealthy, and don't care, or you are nuts.
 
J

Jeremy Pollard

But Steve - would you 'prosecute' the intergator if he used some of the code for another project assuming you could/would find out.


Cheers from:

Jeremy Pollard, CET
[email protected]
On The Web - http://www.tsuonline.com
PLCopen North America - [email protected] www.PLCopen.org
the Training Factory, Inc.
Programmable Controller Support Systems
The Software User Newsletter ONLINE
The Crazy Canuckian!
8 Vine Crescent, Barrie, Ontario L4N 2B3
705.739.7155 Fax 705.739.7157
 
B
OTOH, the customer paid for you to develop this custom software for you. If I were the end user, I would be real offended if you then tried to make me pay for it again. My theory is that the software belongs to the entity that paid for its development. If you have some proprietary PLC code (not very likely), then you might want to protect that little chunk, but I doubt its really worth the effort. Software is usually such a tiny part of the cost of any system thats its probably not much of an issue.

On a personal level, if someone tried this blackmail approach with me, they would not get any business from me ever again. And I would make sure everyone in the business knew exactly why I was no longer buying from them.

BTW - the customer was the main entity who profited from reuse of the software he paid for. If your bid was too high, or he was unhappy with your work, thats a good reason to go elsewhere the second time around.


Bob Peterson
 
B
I'm not really sure what makes software so special in this regard, and can see a lot of problems if either party tries to enforce legal rights.

A few years ago, I was working for a consulting firm who specialised in small cogen plants - 3-5 MW electricity, 50 t/hour steam. We did several jobs with the same burner manufacturer who were responsible for providing the burner and the associated control panels and safety systems - usually PLC-based.

The burners were similar in design - only the fine detail was different to meet the particular requirements of the fuel being fired in each case.

The control functionality for each was similar - only differences being in the fine detail of displays and the particular requirements of the way in which the burner logic interacted with the GT logic.

Now, if the control functions were implemented in relays, I'm sure that no-one would have:

a) expected each burner or relay connection diagram to be totally re-invented from scratch, without the use of cut and paste or copying - in fact, our customerts all placed a premium on previously proven systems (one retrofit into an existing boiler house placed major constraints on boiler design and meant a new layout had be used - we had to work hard to convinve the owners that there were no proven alternatives).

b) having sold the system, forbidden the owner from making alterations to panels, relay wiring (provided they accepted responsibility) or even the burners if they so wished, and marking up the drawings appropriately; or employing another consulting firm or engineering firm to design suitable additions and alterations, again modifying the original drawings.

c) if additional equipment had been added to the powerhouse, making the new control panels, displays, etc, as close as possible in layout to the existing ones.

Good engineering practice requires re-use of original designs, and there are often few alternatives. You don't see many square wheels on cars - lucky Henry Ford didn't have a licensing attorney breathing down his neck. So there will be a LOT of similarities between totally independent systems. If I am developing an HMI for a client, I want to be able to make my new displays as close as possible in layout, colour selection, etc, to any existing ones on the same plant, without worrying about infringing "copyright". On the other hand, the fee I charge for my work does not just cover the time I spend directly on that client's HMI, but also covers a proportion of the time I spend in making myself familiar with the technical requirements for the job through CPD activities, stickybeaking on the list, reading journals, etc. So no client has exclusive rights to any elements of my work - unless I directly implement a new control technique developed by that client.

The problem seems to arise through a confusion between "engineering design" and "commercial design". In the latter case it is probably acceptable to regard a "design" produced for a client as thier property, and there are numerous logo or trademark wars as a result. But, our marketing friends don't live in the engineering world, and seem to have great difficulty appreciating the differences. But that's heading off in another direction where major rants are likely, so we won't go there.

Coming back to my original point ... If an engineering design includes hardware and software elements, the same considerations of intellectual property rights surely apply to all elements of the design. To say that software has to be treated differently from hardware is not recognising the reality that the two are often intimately linked and there is no clear-cut demarcation between them.

Bruce
 
R

Robert McDonald

I figure if your providing an out of the box, OEM type, solution for less than the cost of ground up development (a lot less) then you are really providing off-the-shelf type software and should be able to license such. The client has the choice then of buying you're significantly cheaper licensed version or paying more for a full blown development which they own.

If however you're developing special code, 98% of the time, for the client's case, then they are paying for the development and own the software.

Your either selling a solution pre-built or being commissioned to create one.

Just my thoughts...

Regards,
Robert McDonald
[email protected]
Tristar Electrical
South Australia
 
R

Ralph Mackiewicz

> The reason for this preamble follows. A business consultant asked us
> if we included a license as part of our PLC source code. We do not,
> and have not. I think in the past our attitude has been that the
> customer typically owns the code (at least after the warranty period).
> The consultant then asked if we ever "re-use" code, meaning start
> with one customer's code and then modify it for a new job we might be
> working on for a different customer. His assertion was that if the
> customer owns the code, we would be violating the law by using this
> code on another project.

If the customer owns the code you would be violating their ownership rights if you reused it. The critical question is "does the customer own the code?". If you have never formally transferred ownership to your code, have never signed a license with a customer granting them ownership of the code, done the work that generated the code as a "work for hire", or signed a purchase order contract that contained a clause granting ownership to the buyer then the answer is: You own the code.

Lacking any formal declaration of ownership, US law defaults ownership of any creative work (including software) to the author. It doesn't matter if the customer pays. The only time the ownership defaults to the buyer is when there is a specific agreement of ownership (like a purchase order contract or license agreement) or when the work is done specifically as a "work for hire". "Work for hire" is a legal term that means the person who pays for it owns it.

> We are now considering using a license, at least in certain cases.
> Having some familiarity with GPL's and open source, I have considered
> some type of GPL where we own the code but allow our customer the use
> of it - also allowing them the right to modify it if necessary. We
> would retain ownership of the code, allowing us to re-use it, and also
> preventing others from profiting from it.

It is a very good idea to specify the ownership rights for software you develop. The typical SI customer probably expects that they can do whatever they want with the software you develop. Most may not care about ownership as long as they are free to do what they want.

IMHO, as long as the software is not especially proprietary or unusually innovative it is better for the SI to retain ownership and grant the customer sufficient rights for them to use the software in any way they see fit.

> I am the Control System supervisor for a major municipal water
> company and if an integrator came to me saying he had a license for
> the PLC code he would not get our business. We pay for the code and
> therefore it is ours to own. Just like buying a car. I can see your
> point, this is just what I feel in relation to the subject.

There is a real cost and performance benefit to the customer of working with SIs that can reuse code from other projects. If you only work with SIs that can't or don't reuse code you are paying more than you need unless you have a real secret or proprietary process you are trying to protect. The typical buyer of water treatment systems should really seek out SIs with experience that can use code from previous systems. If all water plant operators insisted on exclusive ownership rights to everything developed then the experience of the SI becomes less important because nobody can reuse any code developed in the past anyway. You will end up paying a lot more.

> It is my understanding that developing software under a contract,
> in the US, the person who pays the contract costs owns the full
> rights to the software. Before the contract is signed it would need
> to include the ownership rights if these rights are to be assigned
> to any one else other than the person or company paying the cost.
> The law in Canada on this point is a little different.

I can't speak for Canada, but this is not true in the US. A program is only a "work for hire" if it is specifically agreed to by the author. If you buy a book from an author it only gives you ownership of the book, not the story contained in it. If you buy a system that contains software without specific arrangements on the intellectual property contained in it you own the system, not the intellectual property.

Regards,

Ralph Mackiewicz
SISCO, Inc.
 
R

Ralph Mackiewicz

That's a laugh. Pretty stupid academics if you ask me. Under US law copyright protection is automatically granted upon publication. You only have to file copyrights with the government, generally, when you need to sue someone.

It is not surprising these guys from Software Arts (the creator of the first spreadsheet: Visi-Calc) would blame anything other than their own bonehead missteps. I personally bought VisiCalc for my Apple II+ many many years ago (BTW, it was copyrighted). That software was protected by the law to the exact same extent that Mitch Kapor of Lotus was protected when he later published 1-2-3, put Visi-Calc to shame, and created one of the most successful software products and companies in history. Everyone in their right mind dumped Visi-Calc in a heartbeat once 1-2-3 came out.

What would have protected Visi-Calc was a software patent on the spreadsheet itself. Back then, in a rare display of foresight, the US government would not grant patents on software and business processes. Software Arts is a good example of why software patents are a bad idea. If Software Arts had been allowed to patent the spreadsheet, Lotus Development would never have been born. Lotus thrived without patent protection (until they also became non- innovative). The academics at Software Arts would have been able to be the same non-innovative company they were and still have had no competition for 17 years. One of the most important killer apps that enabled the entire PC industry to grow was 1-2-3. The people at Software Arts were never able to do anything beyond Visi-Calc. Would the technology world today been as advanced if one of the most important reasons for owning a PC in the mid-1980s never existed?

Those academics who blame everyone else should look to themselves for their own failure, not to the law.

Regards,

Ralph Mackiewicz
SISCO, Inc.
 
M

Michael R. Batchelor

The operative principle here is usually the copyright law of the country where the work is performed. In the USA, the only place I'm really familiar with, the work belongs to the integrator unless you specifically assign it to the customer if you bid the job as, "I'll supply you a system to solve this problem."

If, OTOH, you are there by the hour working at the direction of the customer for the original development like a temporary labor agency then the code belongs to the customer.

Now, most jobs are a tangled combination of the two. I give the customer a quote, they accept, then the inevitable modifications wind up eating up some more time and I bill for the extra hours. "Who owns the code?" you ask. Well, that's probably an issue for a few lawyers to make a lot of money. But the guiding principle would be not the entity that paid for it, but the entity which took the risk of loosing money on the job.

MB

--
Michael R. Batchelor - Industrial Informatics & Instrumentation, Inc.
Linux is like a wigwam...
No windows, no gates.
Apache inside.
 
H

Higginbotham Ricky

I guess the question that I have is, why is this any different for SIs than anyone else. Theres no difference between the code I write to control a process and code some other contractor writes for neworking PCs or even web site design. The function of the code doesn't matter any more than it matters if I write a romance novel or a screen play. Copyright laws still apply I assume and contracts are contracts whatever the business, aren't they? What I'm getting at is that this problem has probably been hashed out, and in courts, before now. I don't know the answers, but I think we just need to look outside our disipline. What little I've read about similar issues with web site design say the code "belongs" to the developer unless an agreement has been reached otherwise. The customers just have a unlimited write to use it (exactly what that means I'm not sure).


Speaking of tricky questions.
Even if if you get the second bid, who says you can use your old code? If it dosen't belong to you (you gave up your rights via contract, etc), you have no write to copy paste it, even if its your customers code, without your customers permission. Who has authority to give you that permission? GPL says your boss probably doesn't, so your contact at the company you're working for probably doesn't either. Do you have that permission in writing, should you? Its all mostly a mental exercise but interesting
nonetheless.

Who would really sue you for something as ridiculous as that? ....

Then again companies go out of business every day for making the wrong assumptions and not worring about those silly little contracts...


Richard Higginbotham
Speaking for me
 
Top