Proprietary rights to controller's programming

This can be an interesting topic that I have wondered about. I do ask not to knock's on anyone's specific practices here. It's just general discussion.

Once a program is written for a controller, who is the legal owner of that program? I know all software comes with pages up on pages of legal jargon in the end user agreement but what about the program itself?

For example, my widget maker has an extensive program that was written by company A. Later on down the road, we want to amend the program to add of modify the process however we want to go through company B, our local company we typically use versus the original company since they are several states over. It turns out the program is password protected or encrypted, blocked, locked, what ever so we contact the original programmer and they deny you access because they claim the program is their property, not ours.

I have actually ran into this once a couple years ago however, the situation worked itself out. It came up recently in water cooler jabber and wondered, what would happened if the original programmer for what ever reason felt like he was in the right and played hardball. I certainly understanding proprietary rights with software but what I am talking about is like Microsoft claiming legal rights for every Word or Excel document one generates.

Take away the end user agreements and the hard sale of programming entity. Can a programming entity lay legal claim to a controller's programming? What if its a standard program for the widget machine maker for their machines they churn out on a regular basis? What was your experience, how was it dealt with and what was the end result?

to me, there are 2 things

1. A standard machine, made as a product, sold as a product. Company x has invested millions in the machine design

They are sensible to protect some or all of the IP. I dont like that approach but i can sympathise

2. You have a custom machine. You paid the development. You own that code imho

What did it say in the PO when you got the machine from company A

Would you allow china (for example) to rip off your machine and sell at lower than your base cost because they have all your hours of code for free?

As an end-user who mostly purchases custom-built machines for automotive parts manufacturing, we specify in the PO that we own everything at delivery. We own the mechanical designs, the electrical designs, and all the code in every programmable device. We get all the drawings and confirm that nothing is password protected before we make the final payment.

This get's more complicated when we buy a system that is somewhat "off-the-shelf", like if we purchase a big RO water system or some type of stand-alone machine. In those cases there is some negotiation regarding the mechanical design (they don't let us say that we own it) but I've never run into anyone that wanted to hold back on the PLC code.

There are a lot of "It Depends". 1. Can someone else create a dangerous situation with changes in the program? 2. Is this a common built machine for sale to the masses? If the answer is yes to either question then the company A, (The machine maker), should lock or block anyone from making changes. There are other conditions where this would also apply such as legal liability.
3. If it is a custom built machine requested by the customer then the purchase contract should specify in writing, (not a verbal statement), who has the rights to what, including the operating program(s). This is difficult to answer either yes or no. I'm sure others will has differing opinions.

Whatever is in the sales contract applies.

Another consideration
A sells programmed device to B.
B makes changes to programmed device and causes a catastrophic event.
B restores programmed device to "as delivered" and sues A for <fill in legal phrase>.

I worked on a program for automotive parts--a machine that built frames for Silverado Trucks. It had about 100 robots and 20 processors-10 safety and 10 standard. The program was large and complex. Most of it was "canned" logic, meaning it came from another job. I asked my boss how they could do that, and he said we wrote it in the beginning, so we can alter it in any way and re-sell it on another similar machine.

As a contractor, the code in the robot, or hmi, or plc, or camera, etc belongs to me until I've received payment for it.

I have a situation now where a client has not paid me for the s/w (which works fine) because he is at odds with the supplier of the mechanics; which doesn't look good for getting sorted out. I may have to resort to legal action to collect, even threatening to sue for a portion of the profits made from use of the software I supplied.

I am not a lawyer, etc, etc.

I agree with everyone on what "should" be expected on serial machines vs custom equipment.

Copyright rules are different in different countries, but, at least in the US, anyone who writes anything automatically owns the rights to it, unless writing it violates someone elses copyright (plagarism, etc). There isn't any need to register something, or send it to yourself via the mail, although doing so can sometimes help narrow down a date you wrote something, if there is a conflict later. As an employee of a company, your rights are automatically assigned to your employer for anything you write on the job (work for hire), although many employers make you sign an explicit acknowledgment of this as part of your onboarding paperwork, to keep things simple.

If there isn't anything specific in the sales agreement stating that the end user owns the code, the rights to the code fall to the programmer, which is usually the machine builder/integrator.

To respond to one of the original examples from OP, Microsoft claiming rights to any document written in Word would be analogous to Rockwell claiming that it owns any code you write in Studio 5000, and just as silly. This is a very different situation from the rest of the post. A fairer comparison would be someone buying a laptop with Windows on it, and being surprised when Microsoft wouldn't give them the source code or let them make any changes.

As far as I am concerned the customer can have the password after a year and a day after practical completion has been granted - out of warranty.
The only caveat I would put on that would be something that is truly proprietary - put it in an FB and password protect the FB.

With the merger of machine safety systems into the control systems, I cannot see allowing field modifications to the controls, unless there is a clear way to completely sequester the safety functionality. Safety issues and lawyers go hand in hand and believe me, when a lawyer smells blood in the water after an accident, you're having a contract that says that you turned over the IP of a product to the end user who may have altered it is like being in shark infested waters on an inflatable air mattress...

We general have custom or at least semi-custom machines. We very specifically put in the contract as a deliverable the code that runs any machine. i.e. we own the code when we buy it.

In most cases this is not a problem as the vendor is unlikely to re-use the code elsewhere. In a couple of instances we had to agree not to resell copies (but we could transfer machine and code together to a third party). Any contractor that insisted they owned the code and would not deliver the code as part of the machine simply didn't get the contract. (Too many instances of supplier went belly up or was unable to support it in a timely or cost-effective manner).

There is the issue of liability should we change something and cause damage. But that really isn't much different than trying to prevent changes to the hardware. A standard disclaimer that any modifications voids any warranty is generally sufficient.

I generally don't password protect my projects, but I do put a clause in that any changes to the program or wiring must first be approved by me before being implemented for my liability protection.

I'm not an attorney and I don't even play one on TV. However, there are some key questions:

1) Who is "at risk" for the programming. The term in this context essentially means financial risk for the cost of programming. In other words, if the programmer works for a machine builder and the cost of the programming is built into the cost of a machine, the builder is at risk and owns the programming.

2) Is the program a "work for hire". In other words, if an end user pays a programmer to develop a program the programmer was providing a work for hire and the end user owns the rights.

3) is there any contractual agreement or other documentation that specifically identifies the rights to the program. For example, I made sure that every system I did included language clearly stating that the program was proprietary information and was only for use at the single site of the original purchase. Any program documentation was only provided after the end user executed a single site license agreement stating that they understood my restrictions. I didn't password protect programs, because if I got hit by a truck I couldn't leave the end user - typically a municipality - hung out to dry.

Good feed back from everyone. Thank you.

Most of my OEM customers who didn't sell the PLC program along with the machine were in the packaging machinery business. Most of their machines were well-tested standalone units, and the heart of the machinery was the motion control and PLC program.

They could sell the machines to their customers at a lower price if they could prevent the machine design from being ripped off or shared with competitors. Their machinery typically lasted under ten years before wearing out.

One had an interesting business model: they leased the machines to their customers and charged by the runtime hours, with a service agreement that gave the customer periodic maintenance and replacement of wear parts. On those machines we OEM locked the program to the CPU serial number so the customer couldn't circumvent the runtime counters by substituting a new CPU.

As a custom machinery maker now, all of our work is for-hire and all of the PLC code is turned over to the clients.

But being an industry veteran, you bet I keep very, VERY good records of what I turn over to a customer. I've been blamed for post-installation modifications too many times.