What is Unsaid is Important Sometimes

Over at Computerworld there is this piece — How Open-Source Software Can Affect A Company’s Value This is like the second or third piece I have seen by these authors on the issue. I know they are probably trying to drum up business, but the consistency almost sounds like Jihad, and at a minimum is alarmist for no reason. I would direct the reader, go through the posting then come back here for the fisk.

My main argument to the whole article is — compared to what? Well as compared to commercial proprietary software is what. So lets take it on.

Open source has complex legal restrictions that can create copyright and patent compliance issues and corporate transaction challenges for companies that rely heavily on customized software or that distribute software to partners or customers.

Uh, so does using Microsoft code. Your company buys 500 copies of Project but a BSA audit finds you have 1100 copies in use, don’t think that free passes are in the offering. You’ll shovel out for the 600 additional licenses, the fine, the audit, and the legal fees. Last I checked I am not aware of a BSA audit for Open Office has ever occurred.

The Open Source Initiative standards group has approved nearly 70 open-source licenses, each with different terms. These licenses typically fall into one of two categories. The first is described as an attribution-type license, and it generally imposes few obligations beyond requiring that an acknowledgement of the authorship of the software be included in some manner, such as in source code comments and help files.

There are well over 4000 mainline products one can buy from personal computer single user use all the way up to mainframe multiuser OS’s. And those are just the popular ones. There are probably 5x that many that are used every day. And what’s important about that? Everyone of them has a EULA and not a one of them is ’standard’. They all have the stamp of the legal team that was hired to do the writing. It gets even worse when a major corporation is using 8 variants of a single class of product whose licenses have morphed over time. Each stands as its own use and restriction rules.

Now a company if they are smart would negotiate a comprehensive use agreement for all the products from a single vendor. The Fortune 10k do this all the time with companies like Microsoft, Apple, and IBM. It simplifies their work. But even so, there are can be outliers even in a comprehensive agreement that just did not hit the radar screen. Bottom line: It is not simpler staying with closed source either.

The second, more common and more demanding type of open-source license is the reciprocal-type license, also known as a “viral” or “copyleft” license. Reciprocal-type open-source license terms can be complex and ambiguous. Generally, any company that uses open source and either modifies or distributes it will need to have a thorough program in place to ensure compliance with the applicable licensing requirements.

Somewhat erroneous. It depends on what you intend to do with the code. If you are going to distribute or sell an add-on product that requires modifying the original code base; then yes most copyleft licenses require you provide that code base free to all comers.

But what is left unsaid by this observation is when you are NOT required to. Lets say you take AbiWord source code and develop a plug-in that again requires modifying the Abi code base. But this time only for internal purposes. Are you required to post the modded code base out? In most cases no. It makes your company more efficient which allows you to beat your competitor. But you are not required to release the code change so long as you stick to that arrangement. Nor are you required to publish the plug-in code even if you modified the Abi code base and released it.

Oh and consider, if you were using MS Word, you would have never started the plug-in. You don’t have access to the source so you are dead in the water before you start.

Failing to comply with open-source license terms is not merely a breach of contract. Noncompliant use of open-source software also can result in copyright infringement, with increased possibilities for injunctive relief that may force product recalls or expensive alternative software development. It can also lead to enhanced damages and a fixed penalty of up to $150,000 per work infringed, as well as liability for the other party’s attorneys’ fees.

Excuse me, but that is the case even in proprietary software utilization. ‘Nuff said.

Another risk that arises from using open source is that its pedigree often is unknown and always is uncertified. Using open-source software may expose a company to claims that it has infringed the intellectual property rights of others. Open-source licenses provide no warranties or other guarantees that contributors to the source code did not copy the protected work of others, nor do these licenses provide any indemnification to protect against third-party claims for such infringement.

This is also the case with proprietary software vendors. Having observed that Verizon was caught using the exclusive product of a third party unawares by the system provider. Total fact. I was there watching the software company employees march in protest on our sidewalk.

Ironically many companies, HP and IBM for example, have come forward to commit to legal relief against particular suits regardless of circumstance for Linux users. Most prominent example has been the SCO green mail IP suit. Won’t see that happen with Microsoft.

Additionally, an acquiring company will want a general understanding of the origin of all of the software used and distributed by the target company. Part of that exercise involves understanding open-source use and which license requirements apply.

Due consideration? You bet. It goes to the basis cost of the company as a whole. Stark reality. I would question the good faith valuation of anyone who claims that the software assets of any company are $X if they have not completed a system wide audit. Primarily because such system wide audits are rarely conducted to that depth.

I have been involved in 3 such assessments as the acquiring team. We never ventured beyond the data centers and assessments of the work floor environment was taken on the faith of invoicing alone. Another words, good luck. Besides the valuation in software product is in the productivity that is garnered not the invoice price. When was the last time you heard someone initiate a Operation Research evaluation of a target acquisition? Never to perfunctory at best. Why? Because usually the acquirer is going to rip the guts out of most of it and replace it with their processes and procedures, that’s why.

Target companies that use “not for commercial use” open-source software for commercial purposes will need to obtain a different and generally more costly commercial license, if such a license is even available. Depending upon the structure of the acquisition, third-party consent for assignment may be needed for continued use of the software. Additionally, if company employees have contributed software in any collaborative open-source projects, their participation may require corollary contribution of company intellectual property or a promise not to assert intellectual property rights to the code or software developed in the project.

Two pieces to this. Second part first. Any company worth their salt has their IT staff under both non-compete and development property agreements as part of their employment contract. Anything I developed for my previous employer or my current one are their exclusive property unless otherwise agreed to.

On the collaborative piece, again its part of the employee contract with most firms. You can’t knowingly place the company at risk without consent. Not only that but the more progressive firms are becoming willing participants in collaborative FOSS efforts due to the synergy and economy of scale advantages. So much so that many companies actively contribute personnel, money and resources to the effort. The payback can be that huge.

The first part. ‘Not for commercial use’ software exists. However I will point out that it is done for two reasons. mitigation of suit by a lone programmer who does not want the hassle. There is a commercial license available from the vendor. Most of this type of licenses are in use for evaluation software from my experience. You the user are expected to buy the commercial product thereafter. That treads onto moral issues beyond the scope of this piece.

I should point out that the whole item is moot in so complying. Red Hat being the best case example. Oh sure I could run out and load Centos OS, a RH code clone, on all my servers, perfectly legal by the way. But as a practical matter would I? When I am a startup maybe. But once I reach that 15th server or so, my support costs escalate as staff search for answers. Solution? Walk over to Red Hat, buy support contracts and slowly convert over time. The knowledge access damps my support costs. Money saved.

The Sarbanes-Oxley Act (SOX) requires executives of a public company to certify that the company has procedures in place to provide accurate financial statements and has the related internal controls necessary to produce those statements. Such controls include being able to verify ownership of material assets. Failing to establish procedures to ensure compliance with open-source licenses may indicate a lack of procedures necessary to verify ownership and use of intellectual property.

“…Failing to establish procedures to ensure compliance with open-source any licenses may indicate a lack of procedures…”. There, fixed it for them. Fact is this kind of compliance would be required of ALL software product not just FOSS. The authors ought to apologize to you for not stating otherwise.

In conclusion, I could hit a few more nits, but will pass this time. But I do want to bring up a critical point. If I were to tell you the the technological air your firm breathes is dominated by Open Source and has been for more than 30 years would that change your assessment of the risks being outlined by the authors? I mean there is a good chance you have been using it forever and nobody has either sued you, devalued your company or even considered it an auditable factor in your day to day operations. Would that make you take note?

Well most likely you have and don’t even know it. The product is called BIND — Berkeley Internet Name Domain. Its the basis for the name services (eg DNS) that we use every day. So unless you are 100% a Windows shop, right down to using them for routers then you have BIND in house. Its comes standard on most Unix/Linux systems. Its featured in practically every Cisco Router product. Even AD, Windows equivalent service, emulates many of BIND’s features and actively inter-operates with it.

BIND was developed under a federal grant. Its been around since 1985 and has been under active development ever since. It is currently maintained by the Internet Systems Consortium. Regardless of the spin that the Microsoft crowd might throw, BIND is still what binds the Internet Name Space together. Pun intended. Fact without it the ‘Net would essentially fall apart as we know it.

Would the authors suggest that the valuation or purchase of a company be affected by the fact that the firm, and 90% of the others on the planet, due to the use of BIND. I would suggest quite the opposite. That any company using AD has more exposure to risk and should be downgraded accordingly.

Is there any FOSS license agreement that scares me? Yes, Eclispe. I have read that agreement three times and it concerns me. I would suggest if you use that product in development you have your legal team do their own assessment. Pay particular attention to ownership issues related to any product you develop on that platform.

So Dear Reader, I suggest that you do your homework. Consider all the factors and not fall victim to the perceived exclusive risks of FOSS when in fact those same risks are present in all software choices that are made on a day to day basis.