Protecting Code

[Peter Nachtwey]

What features or policy should there be for protecting
1. source code
2. binary code.

Should we have a back door to unlock the code or should the end user be forced to go back to the OEM to unlock the code and make changes. I don't want to have a back door but that will also limit our ability to help the end user in a jam.

A second issue is protecting parameters and variables from erronious writes and changes. We have a look only mode in our older software setup software. We can add that feature to our new setup software but:
1. Should we have a look only mode for the HMI?
2. Should we have a look only mode for the PLC?

Issues.
1. The customer needs to be able to move the code from one controller to another spare in the event of a failure.
2. The OEMs don't want people to copy their programs

No good deed goes unpunished. We store the source code on the motion controller in both binary and source forms. Many of you thought that saving the project on the controller ( PLC or Motion ) would be a good thing. Now I am getting hit with requests to be able to copy protect the source code AND the binary code. I can see we have put our foot in it now. The users and OEMs will have different opinions, but I would like to hear some.

 

[BudW]

We never give out the source code for our Leak Test computer / system. We do consider the code proprietary as we sell the system like a black box as far as the computer (PC104) goes. We have been asked and sometims told we need to supply the source code but this product is a standard product.

I assume this type of system is probably different than the equipment you are talking about.

 

[Peter Nachtwey]

We never give out the source code for our Leak Test computer / system.

You must have the code with you when you go to the field. Your choice is to have an option not download the source code then.

I assume this type of system is probably different than the equipment you are talking about.

Yes, since our controller is not really that much different from a PLC I was looking for a PLC type of solution that PLC people, OEM and end users, would be comfortable with.

 

[504bloke]

We are only small and in the UK, but have never protected code and most of our customers (who are on the ball or have been bitten before) all ask for the PLC & HMI Source code including documentation.

 

[allscott]

There is no question the OEM should be able to protect their code. However, what happens if the OEM goes out of business or their programmer guy gets hit by a bus and nobody knows the password?

I had an OEM go out of business on me and I was stuck with a machine I could not get access too. The PLC vendor refused to help me unlock the code and I was stuck with a broken machine and ended up putting in a different PLC and rewriting the code myself.

I think the PLC, or motion controller, or whatever should have a back door that the manufacturer of the controller can have access too in case of emergency.

Technically the OEM is the customer of the controller manufacturer so I wouldn't think that they would want to circumvent the code protection but if that OEM goes out of business.....

I also like the idea of having the source code in the controller. But I would think it would be nice from an OEM standpoint to not HAVE to put the source code in the controller if they choose not too.

my $.02

 

[Peter Nachtwey]

There is no question the OEM should be able to protect their code. However, what happens if the OEM goes out of business or their programmer guy gets hit by a bus and nobody knows the password?

Can't the passwords be held is some escrow type account? This is my preference. I would prefer not to be involved. This saving source code feature is a can of worms.

I had an OEM go out of business on me and I was stuck with a machine I could not get access too. The PLC vendor refused to help me unlock the code and I was stuck with a broken machine and ended up putting in a different PLC and rewriting the code myself.

I can understand the PLC vendor's position. They don't want to be a part of a copyright infringment case.

I think the PLC, or motion controller, or whatever should have a back door that the manufacturer of the controller can have access too in case of emergency.

There would have to be a procedure to make sure the rights to the code were released. That still could takes days.

Technically the OEM is the customer of the controller manufacturer so I wouldn't think that they would want to circumvent the code protection but if that OEM goes out of business.....

I still think the escrow account is good. It could be that we are that place. This would allow us to repair and restore to orignal condition any modules but still keep the source private from all other parties. We would still have to have permission from the company that hold the password to unlock the controller for repairs. I will bring this up.

I also like the idea of having the source code in the controller. But I would think it would be nice from an OEM standpoint to not HAVE to put the source code in the controller if they choose not too.

my $.02

I think that option is a given. That is what BudW prefers too.

 

[CharlesM]

I don't think anyone likes to lock out their source code. 95% of the time I think it's a waste. However I do think in some cases you have to protect yourself. Also at times you need to keep someone else's fingers out of it.

I still think the escrow account is good. It could be that we are that place. This would allow us to repair and restore to orignal condition any modules but still keep the source private from all other parties. We would still have to have permission from the company that hold the password to unlock the controller for repairs. I will bring this up.

That sounds good. I would never want to keep someone out if I could not support them myself.

I don't just sell a control I sell a complete machine. So my view may be a little different. The software is a small part of a larger system. If someone wants to copy it they will have to do a little more than just copy software. However I know that if I send one of my machines to "some" countries that in 2-3 years they will have a complete copy. Maybe not as good but very close.

 

[OkiePC]

What features or policy should there be for protecting
1. source code
2. binary code.
.

I think you (actually the OEM) should have the option to do neither, either, or both, depending on the skill-set of the end user(s)

Should we have a back door to unlock the code or should the end user be forced to go back to the OEM to unlock the code and make changes. I don't want to have a back door but that will also limit our ability to help the end user in a jam.
.

Either your company or the OEM will need to assume the role of tech support for the end user if they are sold a locked system.

If they can't get in, somebody eventually will need to.

If you make it difficult (signed form for the backdoor key), you will keep the honest people honest.

If you make it impossible (no backdoor) you will burn bridges with the end user who is your final customer, but the OEM will "feel more secure" about their intellectual investment.

A second issue is protecting parameters and variables from erronious writes and changes. We have a look only mode in our older software setup software. We can add that feature to our new setup software but:
1. Should we have a look only mode for the HMI?
2. Should we have a look only mode for the PLC?

Issues.
1. The customer needs to be able to move the code from one controller to another spare in the event of a failure.
2. The OEMs don't want people to copy their programs
.

I think that there will end up being multiple (maybe as few as two?) levels of protection, and you will have to decide which variables can be accessed by different parties involved with maintaining the system.

Allow the programmer to assign the protection to some degree for certain parameters? They should also be able to range check data entries to help head off the erroneous ones.

The more flexible the controller is, the more power the OEMs will have to either lock things down, or free themselves from resposibility by leaving them accessible.

IMO you should give the OEM all the options and allow them to discriminate how they're administered. Then they have the tools to control their programs, or the freedom to leave things wide open. How can they complain, then?

If the customer buys a locked controller, they must do so knowingly.

We have fourteen machines with a locked SLC program and it is definitely a difficulty at times, since we are qualified to troubleshoot and edit code, but it relieves us of responsibility for errors too, so it's not as bad as I thought it could be.

We don't blame A/B for the locked controllers at all, we just call the OEM and make them handle issues that we are prevented from accessing. We are able to deal with cloning controllers in these SLCs via EEPROM modules. We keep one spare EEPROM...it is rarely used, but works just fine without compromising the OEM secrets.