HOW TO PIRATE SOFTWARE - Part Two |
| by Wayne M. Krakau - Chicago Computer Guide, April 1998 |
| This is a continuation of my column on piracy. It’s not really about how to do it. It’s about how to avoid it, as viewed by a non-lawyer working out in the trenches. This article is meant as a practical guide, not a legal treatise. If you try to treat my advice with the same authority that you would attribute to true legal advice from a lawyer specializing in this field, you have my sympathy. |
| The first type of piracy on this month’s menu involves custom or semi-custom software. ("Semi-custom" being my term for a base, standard set of software modules that have customized enhancements or add-ons.) |
| The critical factor for this type of software is the basic concept of ownership of software. If, as a normal part of an employee’s job, as described in that employee’s official job description, while on company premises, using company supplied computers and software tools, a person writes new software for the company or enhances or adds onto existing company-owned software, then the employer owns the software. If the employee writes software under any other circumstances, the outcome could be debatable, though, from the examples that I’ve seen, the employer has an advantage in these debates, depending, of course, on the circumstances. |
| If the person writing the software is not an honest-to-God, W-2 issued, employee, the software belongs to the writer, not the company, and that person can decide exactly what rights the company has to the software. The only way around this is through a written agreement giving either complete ownership or specific rights of use of the software. A verbal agreement is explicitly excluded from qualifying. Even if you videotape the verbal agreement, only a written agreement counts. |
| What does this esoteric theoretical nonsense mean in the real world? It means that the freelancer or even large programming firm that you hire to write software for your company owns that software and has complete control over its use unless you get your rights to that software stated in writing. Just paying for the labor of writing is not enough. Licensing issues must be spelled out in the written contract. If actual ownership, as opposed to licensee’s rights is at issue, a separate clause should be added to the agreement showing that ownership is transferred in return for something specific, such as a particular dollar amount allocated to the purchase. (The amount doesn’t have to be large.) |
| All of this means that, without such an agreement, the software that you thought you "bought" is really only has a limited implied license. Even if you have some type of agreement, it would typically be written by the software company and be so totally one-sided in their favor that it would be worse than useless. |
| If your firm adds more standalone PCs or network workstations at your existing site, then you might be covered under that implied license, subject, of course, to a judge’s opinion. If you install the software at another branch of your company, install it on a second LAN at your existing site, or decide to market the software, then you are in trouble. Even if you have a copy of the source code, you might not have the right to modify it. Even showing it to another programmer in an attempt to bail yourself out of a lack-of-support problem might be prohibited. Reverse-engineering the data structure in order to extract data to allow you to either switch to a different program or simply create custom reports can be prohibited. Those one-sided license agreements can be killers. From my observations, there are very few written agreements in the real world, and most of those that do exist are severely skewed in the writer’s favor. |
| Frankly, if you do anything to upset the writer, you are in trouble. Suppose you are extremely dissatisfied with the response to bug reports and/or enhancement requests from the writer and you decide to withhold payment - even long after the original software was "purchased" (at least from your point of view). The writer can go after you in court, and might even be able to stop you from using the software at all. Even without going to court, the writer can simply stop helping you. Without a current, up-to-date copy of the source code and the legal right to use it, you are stuck. Most people caught in this situation don’t have any copy of the source code, much less a current one. |
| This series of columns was inspired by an episode of this type. I received a call from a potential client whom I had met previously while demonstrating specialty software. They were having reliability problems with the firm that both maintained their network and wrote their custom software. Coincidentally, they had plans to improve the software and sell it to similar organizations in the future. |
| I asked the obvious questions about ownership, contracts, and licensing rights, and got all the wrong answers. As I write this, the potential client is seeking legal help. They don’t have the full source code for the program that drives their organization and the developer won’t give it to them. Their contract explicitly forbids them from showing the portions of source code that they possess to non-employees. They are also forbidden from reverse-engineering the file format to extract data. They have no distribution rights, but the software company can sell the software (which was designed based totally on information provided by the client) to anybody, including competitors of this client. |
| The kicker is that even if the client’s legal council (not software specialists) reviewed the contract prior to signing (I haven’t had a clear answer as to whether they reviewed it or not), they probably wouldn’t have fully understood the implications of the contract. I would like to assume that they would have realized that a specialist was needed. Based on the "Pay Me Now, or Pay Me Later" concept, some legal specialist will eventually make money out of this situation. |
| Next month, this piratical adventure will continue. I haven’t caught my parrot yet, or retrieved my rum, but I have had a "pointed" lesson on not running with sharp objects - like my cutlass. Ouch! |
| �1998, Wayne M. Krakau |