Proprietary rights to controller's programming

Interestingly I recently read another forma on this exact subject who owns software after it’s development.
I don’t remember exactly where so I can’t post a link.
My take away from it I this
If you are a paid employee hourly or salaried then your employer owns all the software you develop while you are working for them. If you are a contractor developing software for a specific purpose then you own the software with a license granted for its use by your client for the one time. Now you are free to reuse the software as you see fit or to grant your client as many licenses as you want or to sell then or anybody else additional licenses as you wish. You may also at any time reuse the software or any part of it as you want no restrictions.
Of course if you have a contract with your client then it should spell out the terms for use and copy rights.
I know I have developed code that has been copied and reused many times by other without consulting me. I as I think most of us, just assumed that if we contracted to developed software the end product belonged to the client paying for it and they could copy it and reuse it as they wanted. But I always reserved the right to reuse my own code. Now I will have to rethink that and maybe issue a license for each copy. I know before I do anything either way I want to consult a lawyer.
As for a client modifying your code after you turn it over to them it’s going to happen. But as all of us should know you touch it you own it. The trick is proving that it’s been modified if something bad happens. I know I have refused to do jobs if the client wanted something that I felt was unsafe. I would rather lose a job and client then have somebody get hurt on something I built or programmed.

I think it depends on the system, liability and initial contract.

Where I work we are about to go to court because someone signed a contract for a company to develop a crappy solution with iFix and no one requested that the IP be a deliverable of the project.

In other instances, I've seen suppliers quoting for a commented version of the code and in other instances code could not be altered at all due to liability. Most of these companies actually moved on from regular automation platforms and developed their own to get code control as a benefit from a custom made platform.

If getting work done by external contractors, one of the contractual deliverables is documented, electronic copies of drawings.

When you're building a plant with an expected minimum life of 50+ years, modifications will need to be made.

We try and avoid package plants wherever possible, and work with suppliers who will custom build control panels to accommodate our specified automation system so we can minimize spare parts.

We are 2 years away from handing back a plant we have been operating for 23 years. PLC logic has been migrated / converted 3 times. I would have much more grey hair if we didn't have original code and the right to modify it!

This was always a bone of contention between our sales guys and us (the software developers), till this happened

Had developed a software for an underground parking system. The entry and exit was on the left side of the structure. After lots of haggling (mainly within ourselves) it was decided that the software should be handed over to the client.

8 months later, we get a call from the client that there has been an accident at one of their sites

On enquiring, it was found that they had been using our software as is and had installed 3 more such systems. At the site of the accident, they did not realise that the entry and exits were on the right side of the structure.

Interesting discussion that could go on and on....

We get different machines from different vendors, from many countries.

One that I heard about was company A providing a resin/glue machine in PLC5 format, with a co-processor involved, which had "black-box" recipes i.e. no access to the client. It was to be upgraded to ControlLogix with a "more open" format as the processor could do all required computations this time. The Client's Engineering Manager had to sign his life away on the promise of not divulging said code to a 3rd party, nor use it elsewhere (there is another unit still on PLC5 format). But you look at the code, and unless you are the original programmer, it would take a while to figure out the format of the indirect addressing as to make it work, or make additions to it....

Another packaged unit came on CompactLogix from a German company, and then we realised that some of the functionality was password protected. We spoke to the Irish SI who was commissioning on their behalf, but he was under strict instructions not to divulge said password...so now we have 2 machines that have parts locked out to us, for a unknown reason, as the machine is only a decanter, a very small part of our overall install.

So now, on our specification when ordering, we have the clause in their that software shall not be password-protected....we shall see how effective that is, as we also have a clause in there that states that all PLC documentation has to be in English, and that gets ignored at times, with German and Italian being the main culprits - I even have to deal with a Windows PC totally in the German language, as it is of a version that cannot be changed without a total re-install.

When it comes to Safety PLCs, we get given the password to access when required, and we are not that daft as to go and modify that part of the code....

Amen to what mk42 said.

I can testify to that copying of our engineering work is a real threat that is happening to us on a daily basis.
Because of that our standard machinery is heavily protected, and we do not open it up under any circumstances.

Intellectual rights is one thing. Safety is anothe thing.
Now imagining what it would take for us to accept opening the programs and other engineering work to the customer or another 3rd party:
With safety PLCs more and more being the norm, and since we are still responsible for the safety of a machine, even after it has been handed over to the customer and the last payment has been paid (*), the only way would be that we ripped of the name plate with the CE marking, and sent a document to the customer/3rd party that the Declaration of Conformity to EC standards is no longer valid. The customer/3rd party would then have to provide the Declaration of Conformity to EC standards before the machine could be allowed to be used in the production.

*: Same as any other piece of equipment out there. If your hand is cut off in a machine, and you have followed the safety instructions, you will sue the manufacturer of the machine. It is irrelevant that you have bought and paid for it.

Now, custom plants and machinery is a different matter. We do open up the access to the programs, and we provide full program documentation.
We usually provide the Declaration of Conformity, but we document everything and state that any subsequent change that affect the safety require a renewed risk assesment and Declaration of Conformity. This can then be done by us (a new contract) or it can be doen by the customer or a 3rd party.

JohnCalderwood said:

When it comes to Safety PLCs, we get given the password to access when required, and we are not that daft as to go and modify that part of the code....

Click to expand...

Wow. The only explanation must be that the vendor is desperate for the sale.
I wonder how you handle who is responsible for the safety then.

Someone is taking a gamble here. The questions who (!). It may actually turn out extremely bad for you or your company.
If a serious accident happens, cue the legal battle over who is responsible for the safety.
I can imagine that the vendor demands the checksum to be investigated, and if it is not the same as when the machine was delivered, he can/will wash his hands completely. It does not matter if there is no difference with respect to the safety or the accident. You could have tampered with the safety, and when the accident happened, changed the program functionally back to the state before the accident.
You change the program --> You can land in jail.

JohnCalderwood said:

So now, on our specification when ordering, we have the clause in their that software shall not be password-protected....we shall see how effective that is, as we also have a clause in there that states that all PLC documentation has to be in English, and that gets ignored at times, with German and Italian being the main culprits - I even have to deal with a Windows PC totally in the German language, as it is of a version that cannot be changed without a total re-install.

Click to expand...

This is as effective as whoever signs off on accepting the machine.

We were getting a machine designed and programmed in Germany, I was reviewing the code. They designers said we don't have to give you the code. I referred them to Section 2 subpart I paragraph 37 in the contract. They reluctantly show me the source code which was commented in German. You should have seen the color drain out of their faces when I pointed to Section 2 subpart I paragraph 37(a) which said all comments shall be in English. Hey, but there was less than 50,000 lines of code--easy peasy.

Another time we got a PLC from Italy. I wasn't on acceptance review panel. We got a PLC programmed in Italian. No one could figure out what they had done. We ending up re-writing the entire PLC code from scratch (in English).

We have it stated in our specifications that we own all software and all code developed for a project. No passwords may be configured without our permission. We do not touch the programming during the warranty period. And we will not accept any bids that do not follow this spec.

This all stems from the one time we allowed a vendor to password a program during the warranty period. The programmer made a change that disabled a high temperature shutdown on 2 very expensive in-line pressure pumps for a reuse distribution system.

I actually watched the guy do it and informed him what he did. This guy basically told me to mind my own business. Six weeks later I get called out because the pumps are not producing pressure. I went to the site and the pump cases were so hot you could not touch them.

We called the contractor to come out and check the issue. The guy said it was a pump issue not a code issue. The pump manufacture disputed it. We had to sue to get the password. The code in PLC did not show the thermals disabled. But my password protected backup copy, which they were require to provide every time they made a programming change, did.

It seems that separate issues are being blended together, one of liability due to potential code changes after commissioning and one of protecting IP

Liability - this is the reason that CLX has a safety signature / safety lock. If in the future it does get unlocked and modified (which is one of the main reasons for using a safety PLC vs standalone) the signature will need to be deleted before making changes. For AOI signing them is the same principle - it doesn't stop somebody viewing code or changing something in the future - but it will tell you that it has been opened up (also useful for versioning to keep track of AOI development)

From a troubleshooting point of view there is nothing more frustrating than working your way backwards to find a black box that is locked so that you can't even view logic in there! I get that people want to protect their IP but there is a balance. I've seen examples of people "locking" their AOI / programming etc. just to hide how bad the programming is, or it seems that way anyways - don't think people will be trying to copy an example of using one-shots and latches to create one shots and latches....