Software and Copyrights II

In this post, Lawrence Lessig describes shortening copyright terms for software, and placing source code in escrow for release into the public domain upon copyright expiration. (This isn't his first writing on the topic, it's just a recent example.) Dave Winer objects to this idea:

My core objection to the doctors of You-Give-Me-Your-Source is that there's an art to what you give. Ask anyone who actually knows my work, not people who put me in the same league as $30 billion companies. I give you a lot of my code, but not all of it. Apple does the same with theirs, but they flip it around. No one knows which approach is "right." It's arrogant to think you can dictate the terms of gifts, esp when you aren't yourself immersed in the art.

My core objection isn't about "art", "gifts", or the copyright term, it's the idea of being forced to give away source. Not because I don't want to give it up, but because it's too hard to regulate. Lessig wants source code to be escrowed and then released when the copyright term expires.

That's a terrible idea. I write software. I give away the source to quite a bit of my stuff. That collection isn't terribly useful to a large number of people; it was mostly written to satisfy my own needs. I didn't write it for the consumption of others - it's been released in case someone else might find it useful.

Then there's other software that I'm writing (that's more useful, and hopefully more in-demand) that I'd like to be able to sell for a profit. And even with that I plan to expose a fair amount of the source. But not all of it. And I'm not planning to give it away.

I see several problems with a source code escrow. This is where we see the problems in having a lawyer propose laws to regulate something about which he knows nothing. No offense Larry, but please stick to some other industry.

First of all, how do you implement it? Who is in charge - the US Patent and Trademark Office, or the US Copyright Office at the Library of Congress? Or maybe a new Federal agency: the US Office of Source Code Escrow? Am I required to send The Agency a CD containing the source to every release of my software? Or just major releases? (Just what constitutes a major release, anyway?) What if I'm using a subscription model where I release a regular, frequent stream of upgrades?

Then there's the problem of what gets put into escrow. You say you want my source code. We've got to think about file formats. We could probably go with plain old ASCII text files. However, some developers will want to submit Unicode - especially those working with overseas partners or those who plan to deploy internationally. (And apparently somebody out there still uses EBCDIC?) And what about developers who use proprietary file formats (whether home-grown or based on commercial development tools)?

Let's just assume that we settle the file format question successfully. (The Agency will issue a 347 page regulation describing acceptable file and media formats. Media formats should be easy, right?) But having just the source code is pretty much useless without some other things: documentation, for one. I'm not talking about the user manuals here; many software projects produce a fair amount of specifications about how and what the software is supposed to do. Some projects produce huge volumes of this kind of documentation; some of it is very detailed. Much of the source code would be close to useless without the documentation. So it makes sense that, if we're going to escrow source code, we need to include project documentation as part of the source.

Which brings up another problem. What about those parts of the documentation that reference source code which still has time before the copyright expires? I guess it isn't really a huge problem. Software firms just have to hire a couple of lawyers (probably not even full-fledged lawyers, lackeys will do) to file requests with the USPTO to have portions of their source code documentation redacted for a period of time. And the USPTO will have a team of drones to find and remove (only temporarily, of course) the offending portions of the documentation -- or to deny the request (subject to appeal).

Documentation isn't the only ancillary requirement. You also need access to the same development tools, build scripts, and execution environments. Oh, and test plans. Wow, this is getting to be a lot of stuff. I wonder who will get the storage contract for The Agency.

(I should have a paragraph here wondering whether or not we need to escrow every version of every file. Having change histories is key to understanding the code. But I'm not going to, you already get the point.)

(I should also have a paragraph questioning the copyright date of different source code versions. I don't know a whole lot about the details of copyright law, but I'd think that when large chunks of code are changed to implement new features it would qualify for a new copyright term. I won't ask this question though. Again, I think you get the point.)

Now that we've got all the stuff that needs to be kept, I see another problem lurking. Since documentation, test plans and all the rest will give away a big chunk of the crown jewels of software creators - including future strategic directions - I can see many developers cutting down on documentation, cutting down on comments in code, deliberately obfuscating code, and generally expending effort to circumvent the system. Which means that instead of spurring innovation, we may achieve the opposite effect of redirecting productive resources into one of 1) bureaucracy, 2) lawyers to perpetuate the bureaucracy, 3) compliance specialists, or 4) regulatory avoidance.

Or you'll get developers (like me) who will probably decide to not copyright our works under such a system. I would probably resort to using technology for better copy protection (even though copy protection is doomed). Or maybe we'd change careers. Again, this would be a misdirection of resources that could be productively engaged in producing better software. Isn't that what we were after in the first place?

© Copyright 2003 Brian St. Pierre. Last update: 1/8/2003; 11:20:30 PM.