Linux And SOX: Compliance Issues May Be Overstated

The freewheeling world of open-source software has unsettled the financial reporting community lately with rumors that using improper versions of the popular Linux operating system might violate the Sarbanes-Oxley Act.

The twisty discussion was sparked last month when Wasabi Systems, a Virginia-based developer of Linux-based data storage software, suggested that other software makers might be violating SOX if they had built new Linux code into their software products but did not share that code with the open-source community. Sharing code—which cuts development costs—is a requirement for anyone who wants to use the Linux operating system.

Jay Michaelson, Wasabi’s founder and general counsel, published a white paper that essentially said if companies don’t share their Linux code, they are violating Linux’s general license and do not have clear title to ownership of their software. That, in turn, risks violating the attestations in SOX Section 302, since the ownership status of intellectual property like software is material information under Sarbanes.

Most legal experts and open-source software devotees largely discount Michaelson’s argument as self-serving; even Michaelson, interviewed last week, now says that “this is just a theory, not more than that,” and it has not faced scrutiny from regulatory agencies or a court. However experts do acknowledge that the controversy underscores the need for all companies to review their policies and licenses for both commercial and Linux software regularly.

Olson

While the immediate debate is specific to Linux developers—since they would be the ones on the hook for violating Linux’s license, not companies that purchase and use such software—a lesson still exists for everyone, says Greg Olson, an executive at open-source consultancy Olliance Group. “Companies where a significant piece of their values lies in intellectual property have to be careful about the ownership and licensing of that IP,” he says.

According to Olson, who co-founded the open-source email firm Sendmail, intellectual property management is at the core of the open-source software challenge. “What companies need is a policy, and a process to deploy that policy, to make good decisions managing their IP,” he says. The policy should, for example, specify what kinds of licenses are required, and what licenses require a higher level of review. And much like compliance with SOX, such policies should be monitored continuously, and relevant employees (usually engineers) be trained on why compliance is important.

At the Boston-based Free Software Foundation, which owns the Linux general license, executive director Peter Brown dismisses Wasabi’s claims as “rather silly.” Self-policing by the open-source community should be enough to crack down on Linux scofflaws, he says, without government agencies stepping into the fray.

EXCERPT

The excerpt below is from "When GPL Violations are

Sarbanes-Oxley Violations," published by Wasabi Systems Jan. 17, 2006:

The Sarbanes-Oxley Act’s requirements relative to ordinary software development are fairly straightforward. If companies list their intellectual property as an asset—as all software companies do—their executives must state that they have procedures in place that prove that the company indeed owns these assets. This includes routine procedures such as protecting intellectual property from disclosure, making sure employees have assigned any rights they might assert, and ensuring that ownership claims do not violate the rights of any third party. The requirements are fairly straightforward: if a company represents that it owns something, it must also be able to document its control processes.

With open source software development, however, the situation is more complex. In this case, there are many steps along the way in which software ownership may be compromised, including violating the terms of the open source license. Specifically, if a company modifies GPL-governed software, it is required by the terms of the license to make its modifications (i.e., derivative works) open source as well. Failure to do so results in nullification of the right to use, sell or otherwise distribute that software. Effectively, a violation of the GPL means that the software company does not duly own its software. Thus, any representation that it does would violate the Sarbanes-Oxley Act.

When GPL Violations are Sarbanes-Oxley Violations (Wasabi Systems; 17 Jan. 2006)

“Clearly to me this is one of those unintended consequences of which no regulator is going to be too frothed about,” Brown says. “It’s just someone speculating … Lots of companies have been under Sarbanes a number of years and none of this has been mentioned previously.”

Flaschen

Others aren't so sure. David Flaschen, audit committee chairman at publicly traded Paychex and advisor to open-source solution provider Black Duck Software, believes this issue transcends Linux and is very real. “Complying with open source software licenses is neither silly nor trivial,” says Flaschen. “Open source is being adopted as a mainstream approach to developing software productively as it should; however, licenses for open source vary in complexity and consequences from benign to truly malignant.” Flaschen, who penned a 2004 guest column for Compliance Week on this topic (see box above, right), adds that companies without a policy on open-source software “and workflow tools to ensure compliance with their policies are doing so at substantial economic risk.”

Errant Linux code became an issue in 2003 when computer equipment giant Cisco Systems acquired Linksys, a small maker of wireless networking gear. Some Linksys code was found to be noncompliant with Linux’s general license; Cisco subsequently released the code and apologized. Also in 2003, SCO Group—inheritor of the intellectual property for the Unix operating system—sued IBM for more than $1 billion, alleging Big Blue misappropriated SCO's Unix technology and built it into Linux.

The FSF handles about a dozen Linux license violations a month, says Brown. Usually developers report discoveries of noncompliant code, and the FSF alerts the offending company with a request that the code be disclosed. “In 90 percent of the problems, organizations just didn’t realize the full extent of the requirements,” he explains. “Typically, they’ve made a small error… We don’t want to penalize companies.”

Still, Michaelson insists that Linux license violations spotlight a larger issue: nobody wants to comply with the license. “If you spend $500,000 to create code, you think it’s yours,” he says. “You don’t want to give it away.” Wasabi published its white paper, he says, specifically because so many computer and software resellers came to him questioning the wisdom of various workarounds manufacturers were inserting into their Linux code.

Linux compliance is now a growing issue thanks to the popularity of the Linux operating system. Venture capital firms don’t want to invest in firms where code may be non-compliant, nor do other companies want to acquire firms with messy code, Olson says. Collaboration and sharing of programming code also means that companies must maintain an audit trail of where the code originated and who owns it, Olson adds, although software tools now exist handle this.

Michaelson’s statement and Wasabi’s Web site, however, go a step further, suggesting that lawyers must oversee development. Says he: “[Linux] compliance should be part of your overall compliance regime, not just left to the engineers.”