Source protection (in general)

[strantor]

What is your perspective? Are you a Maintenance Tech? Systems Integrator? OEM Engineer?

What are your thoughts on the topic of source protection? Is it a scam meant to keep customers beholden to an OEM in perpetuity? Is it the only way your company can exist without being run out of business by copycats?

My perspective: Self employed 3rd party Field Service and Control Systems retrofit/design for the past 15 years, and have occasionally accepted offers of short term or longer term "permanent" employment from clients when times were tough, but never stopped being self employed (on the side) during those times. I'm currently in one of those periods of "permanent" employment, the longest one yet, for the past 3 years. In my role I design, build, and program control systems for certain production equipment that we build in-house and I assist the Maintenance department with higher-level troubleshooting endeavors.

I'm currently assisting my day job employer vetting options, sourcing a new OEM for a production line, and every one of them I have spoken to (all European, which is relevant for reasons I hope someone can shed light on) have been very unaccommodating on this topic. I ask if they will provide unprotected PLC programs and the answer is predictably a diplomatic version of "absolutely not, idiot. Not even with a NDA." The reasons they cite are commonly "because you'll make changes that will kill someone" and "because any changes you make, will render us wholly incapable of ever providing support for that machine in the future." With some particularly pointed badgering I did get one of them to confess that "we make very little money on sales. The bulk of our profit comes from service, and if we gave everyone the ability to cut us out of service then we would go bankrupt."

My thoughts: As 3rd party Field Service, a significant portion of my work has been supporting older equipment and/or equipment for which the OEM has gone belly-up. No drawings available, no PLC program backup, and if I can't get it running then it either becomes a controls retrofit job or it serves brief duty as a monument in memorial to productivity, before being recycled. For that reason alone I would never purchase or recommend purchase of any equipment for which at least a protected copy of programs is not provided for safekeeping.

But I have deeper concerns than just safekeeping. In my opinion, if I am (my employer is) going to spend several millions of dollars on a production line then I (my employer) should actually own that line. Paying vast sums of money for the privilege of giving the hardware a parking spot and putting it to use while the OEM retains sole ownership over the knowledge of how it works and the ability to troubleshoot it, does not constitute ownership. That is what I think of as being closer to a perpetual lease, and if leasing is the business model that the OEM actually wants to operate under, then they should simply present it that way. Stop falsely presenting it as a purchase when you'll never let your customers actually own what they "bought."

I've never felt the need to password protect any PLC code that I've created, but I am also not an OEM so I don't have what might be relevant experience from their perspective. I always download the complete program with comments and no password for the benefit of "the next guy" because that guy will probably be me, but if it isn't, that's fine too. I think that password protecting a PLC program (and holding the password hostage from the people who paid for the equipment) defeats the whole purpose of using a PLC. The original purpose of PLCs was simplify relay controls in a way that maintenance and electricians would find intuitive and still be able to troubleshoot. Who gives a rat's apples if electricians can or can't understand something that they can't even access? If you're going to make the program inaccessible then you might as well just program it in C# and run it on a computer. If you're a Maintenance Manager and you want all your programs password protected so that the new hire kid doesn't screw around and turn a palletizer into a bloodthirsty man-smasher, fine. But if you're an OEM don't treat customers like they're new hire kids.

Or am I wrong?

 

[robertmee]

I am owner of my company and a systems integrator. You will never own my code. It is my intellectual property. When I program your equipment, I am licensing you to use the program in your facility for the purpose for which it was provided. You can modify it to your hearts content, but at that point you release me from any liability for inoperability of code, and if someone gets hurt, that's on you.

While that may seem Draconian, it's necessary to protect my business and my livelihood. From a liability standpoint but also economic. I have had customers take my code, and shop it to other integrators during competitive bid processes...giving my code away for free to other competitors to copy. I have walked into plants and found my code operating equipment I never touched, shared from other plants or to other integrators.

So while I understand your position of ownership, and for that reason I don't password or lock my code, at the same time you have to consider while you may operate ethically, others do not.

 

[strantor]

I am owner of my company and a systems integrator. You will never own my code. It is my intellectual property. When I program your equipment, I am licensing you to use the program in your facility for the purpose for which it was provided. You can modify it to your hearts content, but at that point you release me from any liability for inoperability of code, and if someone gets hurt, that's on you.

While that may seem Draconian, it's necessary to protect my business and my livelihood.

I don't think that's draconian at all! It's perfectly reasonable and I think it should be the norm. The way I worded my post may have sounded like I (as a customer), having purchased a machine, would expect to own the code inside it, and some might construe "own the code" to mean "free to sell/copy the code." That isn't what I meant though; I meant it along the lines you described. Your point of "as soon as you modify it, I am no longer liable" is a perfect solution and one I have proposed to the OEM of equipment we already own in response to the "you'll modify it ways that kill people" argument, but they would not accept the proposal. Even when offered a document releasing them from all liability in exchange for passwords, they won't budge. They say there is no way to prove the code has or has not been tampered with. They insist that a non-cooperative relationship with the customer bent over a barrel is the only way they can protect themselves. And maybe they're right? I don't know the intricacies of European law but this does seem to be much more prevalent with European OEMs, which is why I wonder if there is any merit to the argument.

I am sorry to hear about your experiences with you code being shared without your permission, that sucks. I don't know how to prevent that with 100% effectiveness other than by taking the measures employed by these European OEMs but I don't think those measures are the right answer. They are too extreme. You can have them sign agreements (EULA) that open them up to lawsuits for sharing it but I don't see how you could possibly prove who stole what and who sold what to whom, etc. I think it is just a risk of doing business and like with all risks it sometimes blows up.

 

[plvlce]

You will never own my code. It is my intellectual property. When I program your equipment, I am licensing you to use the program in your facility for the purpose for which it was provided. You can modify it to your hearts content, but at that point you release me from any liability for inoperability of code, and if someone gets hurt, that's on you.

Owning something and having the right to copy it are two different things; indeed copyright law (and much of what is called 'intellectual property') is built upon just such a distinction.

Despite the title of 'intellectual property', copyright is not actually a property right.*

By your logic, if you go out and buy the latest bestseller you don't own that book, you are just licensed to read it (as that is the purpose for which the book was provided).


*in the US and in the English law from which it descends; I can't speak for other jurisdictions.

 

[cardosocea]

As a commissioning engineer in the past, locked blocks were a bit of a godsend until the engineering manager that stipulated the guidelines retired and people forgot why they had to be in place. You open a program and you have 90 FB or FC and have to find your problem, the ones that were locked had been tested and were deployed for X time in Y facilities, so that would remove anywhere between one third to one half at times and you could look elsewhere.

As an end user, if it's a machine I want to be able to see within the code online or you have to convince me that the HMI is a unicorn that will tell me what to look for. If that's not on offer, then you're out of the bidding process. I will however, push for them to produce a document to be able to take us to court should we copy and use the code elsewhere without their permission.

If I write a process description for someone to write control code as defined, the code and all the rights that come with it are the sole property of the company paying for the job and an NDA is signed as well before showing the process to be automated.

There's no right or wrong, and there will be different situations and industries as well where some things make sense and some not.

 

[durallymax]

This is common with OEMs. An OEM program is supposed to be straightforward, well tested and distributed over multiple copies of the machine to offset those development costs. Very rare to get any copies of source code in any other industry and vendor lock is common (going to GM for re-programming of your car).

You're unlikely to win the battle against the OEM. What this turns into is vetting the OEM in other ways. This program is on multiple copies of a standard machine, it should be refined and not require maintenance (we have done programs where the machine functionality is locked away in locked FBs/AOIs but other areas are left open for interfacing). Vet their reputation for issuing quality software and how they respond to bugs. I realize this is tough as they're often boutique OEMs in niche industries, but it's a small world, talk to other customers. In some cases they will offer the source code for an additional fee.

There's always a risk of the OEM dropping off the face of the earth. There should be no reason they cannot provide a compiled bootable copy of the program.

Work done as an SI for an end-user should always remain open for the end-user to do as they wish. That is a custom program they paid the dev time on, not that useful to anyone else and there's not much proprietary magic going on there. Relying on source control for repeat business is a poor model. Your work speaks for itself, if done well the customer is likely to call you back to service it as it's faster/cheaper to just have you work on it and you're more likely to have repeat business.

 

[arpus4KM]

Here is my opinion as an SI in the field and office for multiple areas of this issue.

I write programs from scratch for customers and work on the development of projects from start to finish. After we finish a project, the customer gets everything. Absolutely everything. They can have the prints, program, HMI, backups, tech documents on all hardware. And we will even write custom troubleshooting and operation guides if that's what is needed, and the troubleshooting guides can include information on how sections of the program work.



In my opinion, the argument of a machine's code being intellectual property stops if anything is different. There are only so many ways you can map I/O, or step through logic, etc etc. Of course all those things together make a very specific machine and it would be illegal (if copyrighted) to take the code from an existing machine and then build copies of that machine and then start selling those machines yourself with the code from the copied machine. But if you don't have a copyright on the IP then you aren't going to get anywhere in court. It's definitely going to be frowned upon, but it won't be illegal.


The reason we don't care if the customer gets the docs is that 95% of customers will still call for help even if they have the program and everything else. Most don't have anyone on-hand that knows enough about the overall system as programming to troubleshoot anything more complex than a bad output.

The other part of why we do this is because when we go out to a customer who has a machine that needs to be repaired, there is nothing more infuriating than finding a locked controller. The customer needs to get this thing running, it's a thursday and the OEM has an office party friday so nobody is answering phones until tuesday for some reason, and they honestly don't care. When they finally reply they ask a hundred times if they can send someone from 6 states away to come and change an output to a new point and charge 12,000 for it. They claim liability as the reason but also forget that anything electrical can be rewired by anyone that gets in the cabinet and it can cause unexpected behavior the same as changing a program.



Another point of contention is that I've ran into quite a lot of machines and systems over the years, some only going back to 2005-2010 that the OEM is gone and they never provided any material with the build. When finding the original paperwork you see a clause that says they will not provide backup programs under any circumstances and calling (xxx)xxx-xxxx to request service is the only option in the event of a controller failure.


In the end, companies that have been in business for at least 40 years and find out they can't refurbish the machine they spent 5 million on only 15 years ago end up never calling that manufacturer again because they don't want to deal with the headaches. they rip out the old controls and go with an SI upgrade where they get the new documentation and backups so they can control their own process from now on. Wonder why there are so many OEMs that only stay in business for 10-15 years....

 

[robertmee]

This is common with OEMs. An OEM program is supposed to be straightforward, well tested and distributed over multiple copies of the machine to offset those development costs. Very rare to get any copies of source code in any other industry and vendor lock is common (going to GM for re-programming of your car).

You're unlikely to win the battle against the OEM. What this turns into is vetting the OEM in other ways. This program is on multiple copies of a standard machine, it should be refined and not require maintenance (we have done programs where the machine functionality is locked away in locked FBs/AOIs but other areas are left open for interfacing). Vet their reputation for issuing quality software and how they respond to bugs. I realize this is tough as they're often boutique OEMs in niche industries, but it's a small world, talk to other customers. In some cases they will offer the source code for an additional fee.

There's always a risk of the OEM dropping off the face of the earth. There should be no reason they cannot provide a compiled bootable copy of the program.

Work done as an SI for an end-user should always remain open for the end-user to do as they wish. That is a custom program they paid the dev time on, not that useful to anyone else and there's not much proprietary magic going on there. Relying on source control for repeat business is a poor model. Your work speaks for itself, if done well the customer is likely to call you back to service it as it's faster/cheaper to just have you work on it and you're more likely to have repeat business.

Not anymore. That's the crux. Once upon a time, you built relationships with your customers. Whether production, engineering, maintenance....you established trust and relationships, did good work, and could count on repeat business. 80% of my customers have moved away from that model and now use corporate purchasing departments far removed from the facilities. It's a 3 bid process, where the PM or Engineer sends a loose scope to purchasing who then blindly finds three SIs to bid. Most of my competitors don't know the process from a hole in the ground, and bid low because they have their $30/hr technician who knows how to get online with a PLC writing the code. My actual customers are frustrated because it costs them time and money to hire me after the fact to fix the **** they get. But Purchasing doesn't care. Their bonus check is based on low bids, not actual performance after the fact.

I am busy to the gills, so I'm not losing work that I need, but I hate to see my customers who I've serviced for 25 years, suffer now because of bean counters. It's unfortunately permeating everywhere and becoming the standard mode of operation. On the bright side, most of the good SIs I know just no bid anymore. Hopefully that will wake up purchasing eventually as they now complain they can't get 3 bids. I routinely see SIs from random industries that have never worked on the equipment I do, invited to bid, just to satisfy the 3 bid requirement. It's infuriating.

 

[JLand]

If they're truly worried about the safety ramifications of giving you the source code then they should be fine with giving you the source code but not the ability to unlock the safety program. Any process an OEM is that concerned with safety over should likely require a safety PLC.

Unless, of course, they aren't using a safety PLC, but that'd be silly if they're so concerned about safety.

 

[Steve Bailey]

I have been in the automation business long enough to realize there is very little out there that is truly unique and could be considered proprietary. It's my opinion that most of the time software is locked, it's due more to the ego of the programmer than protection of trade secrets. If you're truly concerned that your customers will copy your code and use it to compete with you, then perhaps you should be dealing with a different set of customers.

 

[kekrahulik]

It is in our spec that all code, prints, etc is handed over to us with no protections. This includes any AOI's (Add-on instructions) that are used. For a safety processor, you can lock down safety and get a safety signature, but we get the password to that. And yes, if we unlock it, we then take responsibility.

When we contracted with a European company to build an new production line, they about choked when I told them they could rip up the purchase order if they weren't planning to give us the PLC code. Their response was "we don't provide that to any of our customers". They expect their customers to have a support contract where you call them for any help. Believe me, their code was nowhere near good enough to not need modification.

 

[arpus4KM]

I have been in the automation business long enough to realize there is very little out there that is truly unique and could be considered proprietary. It's my opinion that most of the time software is locked, it's due more to the ego of the programmer than protection of trade secrets. If you're truly concerned that your customers will copy your code and use it to compete with you, then perhaps you should be dealing with a different set of customers.

I've copyrighted XIC to OTE functions. Anytime someone uses a rung that has a direct XIC to OTE, I get 2 cents.... it's a lucrative business.

 

[plvlce]

It's unfortunately permeating everywhere and becoming the standard mode of operation ... It's infuriating.

So true.

 

[arpus4KM]

So true.

I've seen plenty of bids turned down because it smells of a minimum bid requirement and no real work coming. the corporate policy of finding the lowest bid by throwing a line out to a bunch of SI's is ****, and they know it. These get turned down pretty quick.

 

[joseph_e2]

When we're down and the OEM is halfway around the world, password protected code is a fast way to get a lot of folks very irate. Add in language barriers and communication delays and I'm done with it. As an end user who needs the machine to run, code must be unlocked unless you're available 24/7 without charging and can effectively diagnose issues remotely. May be an unpopular position, but I've been burned multiple times.



This is especially true if it's a one-off machine from a new or small OEM but even from larger companies. I don't know how many times I've walked up to a machine where the machine builder is either out of business or that division was closed and they did "sneaky stuff" to keep end users from seeing what's going on.


Example: We had a stock feeder with a servo drive. The drive has an unused COM port that normally allows online monitoring but is disabled by a compiled startup script. To get online, you have to disable the scripts, which keeps the system from running. All we could do is an offline upload/download to replace the drive. No diagnostics possible. The OEM just said that they'd closed down that division and didn't have any records. I was THIS close to gutting it and starting over but we were able to get it running with a replacement drive faster.

If you're an OEM or SI and want me to be a repeat customer, make my job easier, not harder.



/Rant