Some time ago, I worked for a consulting services company that assembled solutions for their clients using open source licensed software as the building blocks. Clients needed education, however, when it came time to understand who owned the resultant work. Historically, in a from scratch world, all the newly written software was owned by the client as a “work for hire.” If the solution was built up around proprietary products, appropriate licenses were needed. It doesn’t quite work that way in an open source enabled world.
We started by spelling out in the master services agreement that some work might be developed from open source licensed software and as such was owned and licensed per the OSS project’s own goals. This was generally an easy discussion because clients realized the enormity of the savings they were receiving not having necessarily to buy licenses or to have us implement everything from scratch. There would be more flexibility and choice in how their long-term maintenance would work.
The more interesting discussions happened around changes we necessarily made on the open source licensed packages themselves. While most of the work was done on OSS licensed under fairly permissive terms, so still owned by the client as work for hire, it was still in the client’s long-term interest if the changes went back into the mainstream development of the OSS project.
The cost of living on a fork gets daunting over time from several angles. There’s the cost of needing to make the changes again, if a newer version of the OSS project is desired with new features and possibly critical bug fixes. This cost may not be simple if different developers are involved that need to come up a learning curve. There’s the lost opportunity cost of not having the new features available long term. Everything works better from the economics perspective if changes made can be contributed back and negotiated into the main development tree.
One such incident around 2006 involved our developers adding key features to the ActiveMQ OSS-licensed project, then managed by LogicBlaze. We needed to get the client to contractually release the copyright of work we had done for them on the condition we assigned the copyright to LogicBlaze for inclusion in the project. LogicBlaze insisted on copyright assignments for contributed work to ActiveMQ in those days. We were also fortunate that LogicBlaze developers were interested in our changes. While the economics of collaborative development is compelling, the average corporate lawyer will intervene and insist the ownership of the work is tracked and licensed appropriately. It’s interesting to see how this has changed now that the ActiveMQ project is an Apache Software Foundation project, and LogicBlaze was acquired by IONA.
I didn’t encounter this level of legal due diligence from consultant and client to OSS-licensed project again until last summer when a contractor well known for his expertise in the MySQL and Drizzle communities shared his stories of needing similar clauses in his contracts with corporate clients and needing to spend similar time educating clients' legal departments to ensure all work flowed back to the projects and the engineering economics didn’t fall apart through legal interference.
As the use of open source licensed software continues to grow and thrive in the IT departments of the world, I’m curious if this is a new area where people will need education to understand the economics and legalities at stake. I would love to hear from consultants, IT managers, and lawyers alike what they’re seeing (and doing) in this area.