Open Source and the IP Clause

This article reflects my lay-person's understanding of employment and intellectual property. It is not legal advice of any kind. I am not a lawyer. Don't assume that any of this is correct. This is based on drips of information I've picked up over the years. Corrections are very welcome.

As I've mentioned recently, I've switched jobs in the past month. One of the things I always worry about is the dreaded intellectual property clauses in most modern employment contracts. You may be surprised to find out that most companies in the know are willing to modify these, traditionally, draconian clauses if you phrase the request correctly.

The Problem

Commonly, these sections claim ownership of all IP, in all forms, for the company, with very little restriction. In more than one case, I've seen contracts that claim ownership of all IP developed on and off the clock, regardless of whether or not the work is related to what the business does or may do. This, of course, means that anyone interested in doing any kind of open source development, or even research of any kind, will not necessarily own such work.

I like to get involved in open source projects so having the freedom to do so is worth something to me. I found that simply being up front and asking the employer for modifications to the contract, if necessary, is the best way to go.

The Changes

In the most recent contract I was presented with, the company claimed all rights over everything developed while I was employed. Having one or two projects I'm interested in working on that are entirely unrelated to the company's stated business, I asked for changes to the contract.

I did not provide specific language for the changes I requested. I asked the company's management and general counsel for the following privileges.

• Ownership and the right to develop source code, written work, and IP in any other form provided it did not compete with or interfere in the company's stated goals and business.
• The right to release any IP, in any form, under a license of my choosing, citing the GPL, LGPL, BSD, APL, MPL, Creative Commons, and other licenses as examples of the type of license I may select.
• The right to participate in standards groups and bodies, user groups, and conferences, presenting any IP that I would own, under these changes.

Some of that is redundant. I asked for these things this way because I wanted to make very clear what my intentions were; to effectively disclose to the public, any IP I developed during my employment that was unrelated to the business.

As concessions, I offered that the company would be allowed to dictate the following.

• Whether or not I disclose for whom I work. They have the option of requiring me to state for whom I work (i.e. if they feel it helps them in some way).
• If any IP was in a shady grey area about whether or not it was in conflict with the business's goals or primary line of business, it would remain unreleased by me.
• I must select a license that allows the company to use said IP. Restrictions on their use of said IP was acceptable (i.e. I license something under GPL which limits their usage in some cases).
• They may opt to review work for conflict with their business.
• I am still (obviously) subject to, and aware of, the non-compete clauses in my contract.

Reality

It's not utopia. I don't even know if it's all enforceable; like I said, I'm really not a lawyer (and they are). I probably won't develop anything worth their time, but I want the option to try. More importantly, we, as potential contributors to open source work and standards, have the obligation of protecting projects and bodies to which we contribute. I don't know how effective the changes are that I requested, but certainly in its original form, that contract could be problematic to an open source project if I had contributed something and my employer wasn't happy about it.

I hope more companies, especially those that thrive on open source software and standards (even if only indirectly; I'm looking at you, Oracle, Java, and Microsoft shops), become more tolerant of what is required to generate such IP. Better, of course, are those that can directly contribute company owned IP, but by simply not attempting to exert ownership of the minds of their employees, a company is taking a huge step in the right direction. At least in my (non-lawyer) opinion.

Mixed Language Architectures

I've recently switched jobs. I won't get too much into that. I hate interviewing and recruiters even more. More importantly, my new home is full of smart people and a snazzy set of problems to solve.

The CTO at this company was dealt a bad hand. Before either of us were hired, a functional, but severely damaged PHP application was built by contractors for the main web site. Put away your flame throwers; that's a comment about the situation and has zero to do with the language. Because we're not far into the life of this company or the application, there's an opportunity to fix what doesn't work, and the underlying (lack of) architecture doesn't work.

In an effort not to drastically upset time lines and ongoing projects, our CTO had to come up with an approach that would increase capacity, scale, and inject design principals and best practices into what already existed. The current application did not allow for the features the business folks wanted down the road. It needed love and attention.

The plan was to leave PHP for the presentation logic, templating, and rendering, but to gut major pieces of business functionality and implement them as services that exist in a middle tier. These services are written in Java and served up as web services for easy consumption by the PHP front end layer as well as by third party applications for integration. The PHP layer retains some ability to cache results from the service layer, where necessary, but ultimately, the real heavy lifting in business logic takes place within the services, themselves.

The advantages to this approach are:

• Existing functionality can be tackled and replaced piecemeal; a much less taxing proposal.
• A very clear separation of responsibility must exist.
• Rapid prototyping can still occur in PHP which is generally better at fast turn around and testing.
• The majority of very complex configuration and scaffolding that needs to happen with Java is in the web tier and its associated frameworks. Using Java as a back end service layer lets you get strongly typed, well defined, and proven technology in a place where it's easy to work with. Frameworks and components like Spring, Quartz, Hibernate, JMS, Lucene, and solid transaction management can be exploited without having to incur the long development times that are expected at the web layer.

Surely this isn't magic, nor is it rocket science. I do find it interesting that the downside - a strained architecture - can be turned into something positive by clearly defining lines and using standards as a means of self-integration.

If you work in an environment similar to this, I'm interested in hearing your experiences, both good and bad.