I sat in on a webinar from Black Duck Software today on managing compliance when using open source software. As someone who has gone through the process of trying to resolve a GPL violation, this is something pretty near and dear to my heart.
For those who don’t know, Black Duck provides an application that helps companies identify if there is open source software in their product. My understanding is that they maintain a huge database of projects, code and the respective licenses and their software will then search for that code and produce a report. We received the output of the Black Duck software program from Cittio and, in my mind, it showed a number of violations. However, our attorney, Eben Moglen, wasn’t happy with it. The comment I remember from him was that this report was supposed to make people like him go away, and it didn’t make him want to go away.
But the report is pretty darn detailed, and while it may not solve all issues with open source used within a commercial software organization, it is a great place to start.
The main reason I attended this webinar was that Addie Welch, a legal advisor for Zenoss, was one of the presenters.
I’ve always been confused at how Zenoss is able to have a GPL’d version of their software (Zenoss Core) and a commercial version (Zenoss Enterprise) where the “core” version uses GPL’d code that is not owned by Zenoss. If one owns the copyright to the code, they can publish it anyway they want, but when that code includes third party GPL’d code, the derivative work must also abide by the license.
According the Zenoss website, they use a number of GPL’d programs, and I was curious to learn how they can separate “core” from “enterprise” such that the enterprise version does not constitute a derivative work. I was hoping to get an answer from Ms. Welch.
One reason I am curious about this (outside of the fact that I really dislike the fauxpen source business model that Zenoss uses and like to point out flaws whenever I can) is that if you look at the Zenoss Subscriber Agreement (pdf), there is a very odd clause required of all users who buy the enterprise version that forbids forking.
We used Google to search on “zenoss support agreement” and found a PDF copy of their subscription agreement. Section 12.2 states:
12.2 Forking of the Zenoss Core Software
“Forking” and “to Fork” means create derivative works of the object or source code for a product, or to distribute a product or a derivative work of a product under a new or different brand, regardless of any right to do so under any license.
During the term of this Agreement and the twelve (12) month period after expiration or termination thereof, and notwithstanding any rights under the terms and conditions of any license, you agree that you shall abide by the following rules of conduct:
(a) Neither you nor any entity controlling, controlled by, or under common control with you (an Affiliate”) shall offer, promote, distribute or otherwise make available any Forked version of any software product released by Zenoss, including without limitation the Zenoss monitoring platform, the Zenoss client libraries and any component thereof.
(b) You understand that Zenoss may make some or all of its software—which may include, without limitation, the Software—available in versions that are distributed without charge under the terms of the Free Software Foundation’s General Public License (“GPL”) (such versions the “Zenoss Core Software”). Zenoss Core Software may, at Zenoss’ sole discretion, be identical to one or more of the Software. This Agreement does not prevent You from distributing Zenoss Core Software pursuant to the terms and conditions of the GPL, provided that You comply with the Forking prohibition in subsection (a), above.
Although I am not a lawyer, this seems to be a violation of the GPL, specifically Section 6 which states:
You may not impose any further restrictions on the recipients’ exercise of the rights granted herein.
Since a fork could be considered as any modification without the express permission of the copyright holder, this “no forking” requirement seems to be a “further restriction.”
I asked this question on the webinar, but they ran out of time (sigh).
But the webinar did underscore the need for some sort of compliance procedure for commercial software that uses open source, but it failed to address the need that buyers should beware that the contracts they are asked to sign when purchasing commercial software may request that they give up some of their rights.
The right to fork is a fundamental part of open source software, and I can’t understand how a company can claim to be “open source” while striving to remove it.
We are currently auditing the licensing of Zenoss’ codebase, and it looks rather messy (although the legal review is not 100% done). It’s not just GPL compliance that is the problem, but the code includes various components under conflicting licenses as well as code that is prohibited from being used for commercial purposes.
Presumably with tools like RRDTool that are being “merely aggregated” then there is no problem using them in a commercial, closed product. GPL libraries are a completely different matter though… would kinda suggest that the “enterprise” version of Zenoss should be GPL too? There’s no problem charging for GPL code, you’ve just got to make sure you make the source available and then wait for somebody to make said code freely available. Hasn’t done Red Hat any harm?
I appreciate I’m not a lawyer, but… I was of the impression that mixing GPL + proprietary code infects the proprietary code so that it too becomes GPL?
The anti-fork provisions look pretty bogus too, though Zenoss have the lawyers somebody doing the forking probably doesn’t.