It would be a significant understatement to say that I hate the whole topic of intellectual property (IP) law as it’s applied to software. Yet, a week barely goes by where I don’t have to negotiate something about IP with a client. That’s part of the “fun” of being a consultant, I guess.
The topic that bothers me most in negotiations with clients is that of driver code ownership. When somebody hires us to write some code, they typically want to own what we’ve written for them. At first blush, this might seem reasonable – they’re paying, they should own it, right? But when you actually stop to think, specifically, about how we write drivers for Windows, ownership is probably both impractical and undesirable. Let me explain.
Unless you’re just starting out, almost anyone who develops Windows drivers brings a lot of specialized skill and expertise to the task. You’ve “been there before.” You know what potholes are in the road to completion of a working driver, and you know how to avoid many of those potholes before falling into them. Despite this fact, writing drivers for Windows (or, any operating system, really) largely follows a formula. There are a set of pre-defined entry points. You do a set of common, well-understood, things in these entry points. You do these things in ways that are well defined and agreed. Or, at least, if you’re doing a good job that’s what you do.
It stands to reason, therefore, that after you’ve written your first five or ten drivers you’ve already written much of the code that will form the infrastructure of any future driver you’ll have to write. And even if you haven’t written a dozen drivers on your own yet, there are tons of Microsoft-supplied samples that provide you the basics on which you will build. And if you’ve written zillions of drivers over a period of almost 20 years like we have here at OSR, you have a lot – and I do mean a ton – of code that does all sorts of cool driver-related things.
Having this code, and being able to reuse it, is terrific for everyone involved. It’s good for you, because you don’t have to start from scratch and write yet another clever incarnation of an EvtDriverDeviceAdd routine (or whatever). Thus you are saved from being consigned to the pit of hopeless tedium, coding and debugging stuff that you’ve written before and understand well enough that you probably won’t pay enough attention to writing it the Nth time. It’s also good for the people who are paying you to develop the driver, because they get code that’s already been written, debugged, and probably even field-proven, and they get it much more quickly than they would otherwise. It’s a classic win-win, don’t you think?
Well, that’s what I think. Unfortunately, this probably runs afoul of the idea that you can transfer “copyright, plus all right, title and interest” in the code you’re delivering to whoever’s paying you for it. If you started with a sample from the Windows Driver Kit (WDK) and either modified the sample or cut and pasted parts of the sample into the new driver you’re developing, you do not own that code. At best, you’ve created a derivative work. See the WDK samples? They all have a copyright at the top of each module that looks something like the following:
Copyright (c) 1995-1999 Microsoft Corporation. All rights reserved.
That copyright means that Microsoft owns the code, and is providing you with some specific rights to use it. What are those rights? You need to read the license to know. But you sure as hell don’t own the code. And you can’t validly give to others what you don’t yourself own. Thus, there’s no way that you can write a driver using this code and provide “copyright, plus all right, title and interest” in the code to whomever pays you to write the driver. And, by the way, it doesn’t matter whether you’re working as a consultant or as an employee. If you’re an employee, check both your employment agreement and your company’s policies. Your employer might have a clause that says that you will provide unencumbered rights to the work you produce unless you tell them otherwise.
By the way, deleting the copyright and replacing it with your own doesn’t change the situation, either, except that deleting the existing copyright hides what is now your theft. And, before you laugh… let me assure you this happens all the time. It is not the least bit uncommonfor us, here at OSR, to be given a driver to work on that has only the copyright of the company that engaged us at the top – but the code was clearly lifted directly from one of the samples we hand out in one of our classes. Or, the driver is nearly identical to a sample in the WDK.
Assuming you’ve taken a pre-existing sample, and added some new and original stuff and thus made your new driver substantially different from the sample, you’ve created what’s known as a “derivative work.” And you own the new, original, parts that you’ve added. To signify this ownership, you can add your copyright to any existing copyrights on the work. Congratulations. Go ahead… add that copyright.
But here, once again, things can get tricky in the driver world. Let’s say you’re working on a driver for a USB device. You start with the KMDF USB FX2 sample in the WDK. But your device implements some unique vendor commands to do clever, device-specific, things. So, you make a few changes to the code – you know, you change the parameters to the WDF_USB_CONTROL_SETUP_PACKET_INIT_VENDOR call. You change the completion routine to do some additional stuff. Whatever. But, you’ve change the code, right? So, you can own, at the very least, those changes you made?
Well, I’m told it depends. Does changing the values plugged-into a macro make the code original and substantially different?
Or, perhaps you’re working on a filter driver where you forward a request and get it back in your completion routine. Are you really going to code the way you set up your send options from scratch? You’re not going to look for, and maybe cut and paste, an example of calling WdfRequestSend? I mean, how many ways can you even call WdfRequestSend to make it “original”? And you’ve never written that code you’re using in the completion routine before?
Here at OSR, if I’m writing code for a driver, I’m probably going to start with one of the drivers we’ve already written. And as I change that original driver, I’m going to be looking at, and liberally cutting and pasting from, many of the other drivers we’ve written over the years.
The point is that, save proprietary APIs and the rare invention, most drivers – and particularly most device and filter drivers – have little truly new and original content. There are only so many ways to write “status = IoCallDriver(DeviceObject, Irp);” or “WdfRequestCompleteWithInformation(Request, STATUS_SUCCESS, 0);” or many of the other statements that form the vast majority of the driver code that we all write. And much of the delta between the original driver with which we start and the driver code that we deliver might very well have originated from some other project. Again, here at OSR if I need a hash table to look some stuff up based on a string key, I’m going to head right to the depot to see if I can find someplace else where we’ve already written a string hash table implementation.
To repeat what I said at the outset of this pontification, this is all good – very good, in fact – for everyone involved. This is true as long as nobody decides they need to own the code that’s being produced. Who actually owns the code really shouldn’t matter. What matters is the license granted to the code by the actual owners.
The license that you get to the code, whether it’s code from the WDK or code we at OSR write for a client, dictates how that code can be used. As long as the license allows the user to do with the code what they want (create derivative works, redistribute, sub-license, or whatever) for the length of time they need, ownership shouldn’t be an issue.
So, if I’m writing some driver code based on an OSR driver I wrote a few years back, and I grab some hash table code from another project, and then cut and paste and modify some code for my DpcForIsr, as long as I’m in a position to be able to grant the rights required to use that code, all should be well. Ownership is not necessary. Rights are necessary.
So, I’m asking the driver world to face-up to the issues of code ownership and licensing. Please, think a little about these issues the next time you’re coding-up a driver for your corporate masters. If you’re using code you got from taking a seminar, or from the WDK, or from (heaven forbid!) Code Project, don’t just blithely cut, pastes, and delete the copyright. And don’t guarantee that you can transfer ownership of code that you never owned in the first place.
And if you’re a manager responsible for getting driver code written for your company, I respectfully ask you please: Don’t insist on owning the code that’s produced. Rather, steadfastly ensure that you get the rights you need licensed to you. In addition, if you have a set of proprietary APIs, be sure you own those APIs. If you’re licensing the rights to an invention that’ll be used in the code, understand that you still own the invention. Don’t put your driver developers or third party partners in the position of having to determine if changing the fields in a hash table package qualifies as making that use substantially different. And, most of all: treat as highly suspicious any guarantees you receive that you’ll own all the driver code that is produced. Almost nobody writes driver code in a clean room, starting with an empty buffer in the editor.
———-
It is a sad commentary on the state of our society that we feel the need to attach the following to this article:
IMPORANT NOTE: Neither OSR, The NT Insider, nor Peter provide any legal advice. Do not rely on the contents of this publication, and certainly do not rely on the contents of this column, for definitive legal information or advice regarding any topic, particularly involving intellectual property law. Your mileage may vary. Professional drivers on a closed course. Do not attempt. No purchase necessary, void where prohibited. Silica Gel – Desiccant – Do Not Eat. Caution: contents may be hot. Offer not good after curfew in sectors R or N.
Peter Pontificates is a regular opinion column by OSR Consulting Partner, Peter Viscarola. Peter doesn’t care if you agree or disagree, but you do have the opportunity to see your comments or a rebuttal in a future issue. Send your own comments, rants, or distortions of fact to: PeterPont@osr.com.
OSR Open Systems Resources, Inc.