Allen, This issue sound me also like Napster or even worse: like the atomic bomb. It depends who has it (do you trust Saddam?) and what it’s used for, for good or for wrong and who can be harmed (potentially or in fact). Just to have another angle of this issue: As a system integrator we were awarded by customer Z to develop a system to automate a piece of machinery. Our scope of supply comprised both Nuts & Bolts and PLC programming. The system really worked fine. The code was left unprotected and proprietorship rights were somehow transferred to Z. Some time later customer Z, purchased a similar used piece of machinery from a broken competitor and opened a bid to quote for the new project. That lead to an Order placement to another company (System integrator?), who offered a much lower price than ours. They just copied our scheme and cloned our code !!. Of course we filed a suit but..... If we had lock-protected it, they maybe had to develop a new one and comeptition would be fair, except if customer Z had “proven” they owned the code (and as I said, they somehow did) to somebody having a wand to overcome such protection ( Hi, Allen ! ) and hand it under the table. Some times customers behave unethically like this to cut costs. I think your dilemma of giving out or not your method is like trying to play God's role becoming a judge on issues and situations that maybe are out of one’s reach. Being in your shoes I’ll rather keep this ‘wand’ securely or I’d even get rid of it, to avoid harm to those fair players in this ‘Integrators community’. Hopefuly it will take some time until somebody makes this or some other method publicly available. As a last thought, I belive code lock protection is also related to marketability of the application, that’s why OEM protect their codes, besides other issues such as warranty and security. Don’t screw them !

 

At 02:23 PM 2/26/2001 -0500, you wrote: >As a system integrator we were awarded by customer Z to develop a system to >automate a piece of machinery. Our scope of supply comprised both Nuts & >Bolts and PLC programming. The system really worked fine. The code was left >unprotected and proprietorship rights were somehow transferred to Z. Unless otherwise specified, if the customer paid for the complete development of the program, then shouldn't they own it? Bill Sturm

 

<<snip>> > if the customer paid for the complete development of the program, then > shouldn't they own it? snip>> If one pays attention to the drawings that come with your equipment, they usually state that the drawing and everything on it remains the property of the vendor. Is PLC/MMI code any different? Are both of these instances similar to the 'licensing agreement' that we have to deal with in the PC world? I realize that usually a licensing agreement exists because when you sell a lot of copies of the same program that no one customer can actually own (all rights to) the program. As an engineer you don't want your program to get changed without your knowledge because it is 'perfect' and for other (engineering, safety, liability) reasons. Or, you don't want someone to benefit from all of your hard work (ideas, etc) without paying for it. As a customer, you feel the need to change, add, or improve. You don't want to have to call (read - pay) someone in to make 'minor' changes. As a vendor, a locked down program can be a sure fire way to make more money in the future. And, you don't want your competition to learn your methods, etc. without paying for it. I believe that the wording of the purchase order or contract should be used to specify that the customer is the owner of the software, etc. The vendor will either accept or not. Of course, the customer has to know enough about these things to know to make this specification. Grayg Ralphsnyder

 

If the customer is paying for all costs of the development then the customer has a strong interest in owning the source code. Most system integrators I know agree with that idea and respond accordingly. However, if it is a fixed bid Turnkey system, the system integrator is developing a product for the customer and the customer is not paying for anything more than a "turnkey" product, why do they have an inherent right to own all the intellectual development behind them product (unless specifically requested in the RFQ)? When you purchase an automobile you buy a product, not the engineering it took to develop and manufacture it (a questionable analogy but something to think about). An even better analogy is purchasing software. Read the End User License Agreement of any software package. It tells you that paying money gives you the right to USE the product only. You can not resell even part of it without their written permission (and some more money of course). (And no I am not trying to get into a discussion about shrink-wrap license abuse). I do not believe there is a blanket rule that can be applied to all situations as there are both customers and system integrators who try to do unethical things for short term financial gain. That is why business is no longer carried out with just a handshake. Robert Holman Automation & Controls Engineering, Ltd.

 

No flame was perceived. I was just running out some of the permutations for which there may be valid reasons for locking the processor. Anthony Kerstens P.Eng.

 

I know this is is a bit late, but as an ex OEM & now an end user I have sat on both sides of the fence.

Many systems are specifically written for the end user & are unique, this means that the development of the software is paid for by the end user & should remain the property of the end user, some are, as discussed by development of a standard product & should remain the property of the OEM.

However there are a lot of OEMs out there that use this kind of protection (under the guise of "letting your engineers loose on this will cause more problems & callouts" etc.) just to make more money out of the customer.

In my current position as site software engineer I have come across a number of PLC's with passwords or "locked" code that were specifically written at the end users cost, these include Mitsubishi, AB & siemens (all of which I now have a way in).

Yes I have found ways to unlock these, only one I have not tried yet is the "OEM LOCK" on AB, must give it a try to satify my curiosity.

I have come across all sorts of software & find it amazing how many engineers are so naive to think they can write some "PLC code" that is unique, quite honestly I can't think of why a good engineer would entertain stealing raw code from a plc to duplicate on another as it would probably be as quick to re-write it with the proper documentation given that he (or she) would have to decipher what it did to modify it should it be required.
Like A Nelson said I could probably make some money removing passwords etc. but I would rather give the information away given correct proof of ownership but that would take up too much of my precious private life.
I know there is a product on the net called Canopener to remove the nowhow protect from siemens s7 blocks (if you pay them a fee for it).

I cracked that one some time ago but refuse to release how as I believe Siemens have a right to protect their own blocks that use this.

Finally, to all those good engineers out there who do not protect & supply documented code to the users who have paid for it, keep up the good work, in my opinion you are the ones who are the good guys (gals) showing other people your code is done professionally & not trying to hide a botch behind a password.