Should Developers Manage Copyright Like Photographers Do?

While fighting the forces pulling me out of bed this morning, I had an idea: would everyone benefit if copyright on source code was managed more like copyright on photographs? I think everyone would win, and no one would lose. I’d like to hear your thoughts as well.

I am a Java developer/architect by day, but a hobby photographer as well. When I take pictures of someone, I own the copyright on those images by default (unless it’s work for hire – more on that in a moment). I can do anything I want with those images.

The two standard modes of doing commercial photography are Work For Hire, and the default. Work for hire is an exception to the default copyright rule where the creator of the work owns the copyright. It essentially states that if the work is “made for hire” the employer owns the copyright – corporate authorship. This is how software is developed. If you’re a photographer who works for a big company and photographs products for their catalog, you are probably doing work for hire, just like most corporate employees. You’re a cog instead of an artist. There’s nothing wrong with that, but the copyright situation makes the distinction clear.

Now a wedding photographer, or a sought after photographer usually works on a different model. The client pays for the photographer’s time at the shoot, and licenses the images for specific use. The photographer maintains full rights and the copyright of the image. There are many variations on this type of contract, but that’s the basic picture of it. The photographer can use the image in their portfolio, and dependent on the contract with the client, may be able to sell it again later.

I’m not suggesting that developers bill for their time and then negotiate usage rights as well. That wouldn’t sit well with the corporations. What I AM suggesting is that developers maintain copyright over their work. I envision it working like this:

The developers sign a contract with their employer stating that the work they produce belongs to them (copyright-wise), but is released to the company under the Apache License (for example – although a specific license might need to be created for this) for their use and modification as the company sees fit.

There is also a clause based on corporate secrets and IP which would prevent the developer from publishing or releasing code containing sensitive corporate information (production system passwords, how much kick-back Apple gets on iPhone contracts, etc…). Developers would have to make the code somewhat generic, and remove client specific things (like moving the package out of the client’s namespace into the developer’s own namespace for instance), before they could release or reuse the code.

Here are the Benefits:

The developer owns their work. I think this would make them take greater pride in their code. Ideally feeling more like an artist and less like a cog will instill greater pride. Plus the ability to reuse and release the code with your name on it means more eyes will see it and associate the quality with you personally.

A developer can easily build and maintain a portfolio of code they are proud of. This enables potential employers to examine this body of work during the hiring process, just like looking at a photographer’s portfolio before engaging their services. Coding style, attention to detail, etc… will show through in the portfolio and can allow the potential employer to ask specific technical questions based on the code, instead of asking random technical questions.

A developer will build a toolbox of useful code they own over time, and will bring this toolbox to each job they have. This reduces the development cost and time of every project they work on. Their employers will save money versus how it is done today. Also, reusing code that has been tested and refined overtime should elevate the overall code quality across the application. All without cost to the company.

The developer can opt to make some or all of their code available online, building the communal toolbox for that language/framework. Again benefiting all projects, commercial and otherwise, by providing field-tested, working, higher quality code which reduces the time and cost of future development.

While there are specific instances where this arrangement would not work out (authors of Google’s super-secret ranking algorithms for instance – although I think that would have to be covered in the trade secret section of the contract), I think in the majority of situations I see lots of upside, and no downside for any of the parties involved.

5 Comments

Speaking as a programmer, I don’t understand why the photography business works that way. If I hired a wedding photographer, I would expect work-for-hire terms – I don’t care that “it’s always been done this way”.

Allowing developers to own their code within proprietary software companies sounds like full employment for lawyers. If you want to own your code, go work for an open source company (technically the company still holds the copyright, but practically it doesn’t matter).

I’d say it works that way because that’s how copyright law is written. The whole work-for-hire thing is an exception to the standard copyright situation.

If the developer contractually has to license their code created at the office under a license like the Apache license, and they still have the standard contract language around trade secretes, etc… There is very little need for lawyers being involved beyond updating the contracts with more clear language.

Other than not wanting to hire a photographer under anything other than work-for-hire (a whole other discussion), if we can assume that contract/license issues can be dealt with in a straightforward fashion, do any parties involved lose given my proposal above?

@Crave Truth: yes, I know it is an option. I know it’s not common. What I’m hoping for is a real downside to the idea, instead of a sarcastic comment about employers being unlikely to go along with that. The real question is would they actually lose anything by doing so? Or would the long term rewards be well worth the shift for everyone.