Open source developers continue to struggle with how they can work with commercial entities and still keep some measure of control over their code, and vice versa. But a recent plan crafted by an open source software pioneer may offer another option to solve this conundrum.
The issue of contributing to open source projects maintained by commercial companies is not some sort of incongruity between open source software licenses and for-profit business interests, as many FUD-sters would have you believe. It's not the licenses that are the problem, but rather the copyright: who owns the code?
When a software developer creates a particular piece of code and wants to contribute it to a larger project, there needs to be some sort of agreement (formal or informal) as to what kind of license the contributed bit of code (the "incoming" license) will have in relation to the license of the larger project (the "outgoing" license). Ideally, you want the incoming license and the outgoing license to match up, because you wouldn't want, say, the incoming license be GPL and the outgoing license be a BSD license.
When the project is manage by a commercial company, things get a little more complicated. These companies typically want to make really sure their investment in the software is protected, so what they usually do is formally ask contributors to sign a Contributor License Agreement (CLA), which usually require contributors to not only certify the code they're turning in is clean, but also grant the project full rights to control the license of the contributed code within the project indefinitely.
FLOSS development has used CLAs for a long time, but recently they have gotten a lot more attention and use i, now that so many commercial companies are jumping into open source development.
Because of the increased use of CLAs in FLOSS development, Project Harmony was launched in 2010, an effort spearheaded by Canonical general counsel Amanda Brock. Brock and Canonical clearly want to get some sort of standardization around CLAs because Canonical and its partners like to use them.
But CLAs tend to make potential contributors nervous, since ceding control of one's code raises the possibility that the new copyright holder (the company managing the project) could one day ultimately take all of those contributions and potentially close the license for the project to create a proprietary project on the backs of the open source contributors.
This nervousness is what Bruce Perens, author of the Open Source Definition, is trying to solve with his idea of a covenant between commercial entities and open source contributors--a covenant he has implemented in his work on the HPCC project for Lexis-Nexis.
Perens wrote up his idea earlier this week as a white paper on the HPCC site, and it's a lot of backstory to digest, but well worth a read, since it's an idea worth exploring.
Basically the idea of the covenant is to make things fair for all parties when code is contributed to an open source project. Perens explores the idea of paying for the work done by contributors as a way to even the scales, such as what MySQL used to do instead of accepting community contributions directly. But while this is one way of being fair, it's a difficult business to figure out the inherent value of each code contribution.
This led Perens to work with Lexis-Nexis and come up with this arrangement for HPCC:
"[HPCC] is to be dual-licensed under the Affero GPL 3.06 and a commercial license. In exchange for each copyright assignment from an Open Source developer, the company will covenant to continue to support and maintain the Open Source version of their product for a period of three years--they won't take it private during that time. The three-year clock will start anew every time there's another copyright contribution. If the company cannot continue to support and maintain the product as Open Source, HPCC systems promises either to contribute the product to a non-profit under permissive licensing like BSD, or to remove the developer's contribution, and all others for which the three-year clock is still running, from the product. Thus, the Open Source developer is assured that the work won't be taken private for a significant amount of time after his/her contribution, and the continued participation of Open Source developers provides a strong incentive for the company to never take the product private."
Basically, this means that if a company wants to take code proprietary, they would have to wait three years from the date of the last community contribution, or else remove any contributed code made in the prior three-year period. If the company can't do this, or fails to support the project, the code is to be donated to a non-profit under a permissive license.
This is a good step in the right direction, but there are questions about how this would actually work. I keep coming back to the "support and maintain" part of the covenant. What's the definition of a company supporting and maintaining the code as an open source project? Is it a full-on contribution ecosystem, or just applying security patches?
Then there's regulation--if an outside community member wants to use the code after presumably the three years have passed, what's to stop the company from asserting copyright by saying "hey, we were working on this as open source, it's not our fault you didn't know it."
And what non-profit would get the code? A foundation, most likely, but is it an existing foundation or a new one to be created for this particular project? Because if it's the latter, the commercial entity could still hold strong sway over the project by controlling seats on the new foundation's board. Any development that deviated from the goals of the company via the foundation would have to be forked. The permissive license would allow this, but it would create a lot of unwanted strife.
I am not saying this is a terrible idea... it has a lot of merit to it, and it neatly gets around the core problem many developers have with CLAs: control. But if such a covenant were to be used more often, I think some of the details would need to be worked out before this could be a more universal solution.
Read more of Brian Proffitt's Open for Discussion blog and follow the latest IT news at ITworld. Drop Brian a line or follow Brian on Twitter at @TheTechScribe. For the latest IT news, analysis and how-tos, follow ITworld on Twitter and Facebook.