|
|
| Home - Industry Article - Oct 03 Issue |
Are You "OSS-SOL" or "OSS-OK"?
continued... page 2 |
3. OSS Changes Your Prospects" Procurement Processes and Standards
Preparation beats inspiration. Planning and synchronization is better than fast-talking improvisation.
What do you say when your prospect asks "Is there any freeware in your products?" How will your reps reply, when the RFP now requires you to "Disclose any open, free, or other non-proprietary code in your product design, development tools, delivered version, or documentation"?
Be ready. Vendors are encountering such interrogation from their recent leads. Also, in recent months customer-centric contract negotiating seminars have added open source to their recommendations of "what to watch out for, from those rascally vendors." And lawyers advising your prospects are telling them to get new disclosures, warranties, and potential penalties if a tech vendor includes OSS without approval. Finally, MIS managers and their bosses want more assurances that software and network security won't be compromised by uncertain code in the post-9/11 era.
Customers and prospects have been sensitized to these new issues by the SCO v. IBM and Red Hat v. SCO lawsuits, their widespread publicity, and angry Internet postings by OSS-favoring geeks. Now, in the post-Enron, Sarbanes-Oxley law era, corporate managers worry that "things aren't always what they seem -- or need to be." This increased caution and diligence includes the history and contents of software offered by vendors. You have the need to know now about OSS in your wares.
4. OSS Might Impair Your Partnering Potential, or May Help It Someday
Microsoft has over $49,000,000,000 in cash (as of its 9/5/03 10-K report to the S.E.C.). Want some?
Microsoft continues to expand its goals, product offerings, aid to friendly symbiotic vendors, and cash reserves. (Any surprise?) But it resists and even battles both Linux and other OSS, urging instead the benefits to customers of the traditional, proprietary business model for software development, licensing, and support. Its "shared source" initiative is sometimes viewed as a begrudging, small, but necessary adjustment to the OSS revolution.
Recently-disclosed documents show that Microsoft will prohibit an OEM licensee from mixing Microsoft code with OSS code or processes. Such "identified software" (it doesn't have to be called "open source" or "freeware", which might make it harder to find in your code base) can't be mingled with a partner's code. (Can you blame Microsoft or other vendors for such prohibitions, given the potential adverse effect on software proprietary rights of the stronger, restrictive forms of OSS licenses?)
In the future, resellers, integrators, VARs, and other potential business partners may decide who they ally with and who they'll avoid in part on "whether or not there's OSS inside, how much, and how well it's been managed and documented."
On the other hand, a coherent, well-managed "OSS usage and risk management strategy" can make your company more desirable and hence more competitive. Other business partners might smile on a cost-cutting, nimble product strategy -- a modern-style business model that deploys OSS.
So robust, pro-active OSS management in your company's strategy, product development, marketing, and technical support may impact your "business ecosystem," for good or bad.
5. The OSS Devil Is In The Design, Development, and Documentation Details
There are significant differences in OSS code, OSS licenses, and OSS development groups ¨C the particular impacts on your customers, company, and career lie "in the details". You need to know the rules, the players, the new lingo, the new decisions to be made, and the new processes to implement in order to compete well in this modified ballgame of software.
If your coders, product managers, or tech support personnel use free code from the Web and its bands of smart coder donors, they can obligate your company to release source code to the world, if your output is a "derivative work" and the GPL applied. If your products take from "the community" of "open" coders, then your formerly "closed" (i.e., traditional, proprietary) products may be required to be licensed on terms dictated by that reused, upstream component code ¨C not your company's "standard" contract. And there are other potentially applicable OSS requirements, depending on the particular code and license involved and how the code is used. (This scenario assumes the OSS code is included in a product. Most OSS licenses have little or no high-risk impact -if- the code is changed and used -only- within the user/licensee operations. But, does that cover subsidiaries, employee home equipment, sharing with your supply chain via an extranet, or other types of software "distribution"? No one knows yet. And nobody wants to be a test case.)
But some OSS licenses are permissive. Your developers can bake the raw material of some (but not most) freeware into your company's proprietary, object-code-only products with impunity. It all depends on the particular code and how it's used.
And there are several dozens of common OSS licenses. On top of that, some OSS developers modify the license terms ¨C so your engineer's assumption that a download is "standard" may be heartfelt, but dead wrong. (Remember the old joke re. " 'assume" makes an 'ass out of you and me" "? It might also make "a sue me".)
In any event, many OSS licenses include major ambiguities or holes that can impact operations. For example, do your OEMs, VARs, and other resellers get the certain right to modify the upstream code? Can they set up their own indirect channels, for the portion of the software that your company doesn't own?
Code is real estate, in the software business. Your team should check in detail all the titles, maps, zoning, easements, flooding, termites, and other "rules of the land" underlying your business ¨C i.e., the code components, provenance, and licenses - before your build your "shopping center" or "skyscraper" (i.e., your business) on top of them.
6. OSS Changes Your Exit Strategy Scenarios
Got stock options? Got good odds of a home run (or at least a "triple" or "double") financial result if your company gets bought out? Think that your company will be one to escape the predicted consolidations among the ranks of enterprise software vendors?
Maybe you'll be fortunate. But you need to know that there's a new, OSS-specific threat. It's this: the terms of recent merger and acquisition agreements among tech vendors ban or restrict OSS. So "exit via acquisition" has a new barrier (or at least a very tight filter). The usual "t's & c's" of tech mergers have changed, in a way that's much tougher for the target companies.
Studying the contractual terms of the new era of tech acquisitions in recent weeks reveals a new hurdle, not contained in the mergers of prior years. It's in these deals, and more: EMC-Documentum, Lawson-Apexion, eBay-Fairmarket, Click2Learn-Docent, EMC-Legato, Hyperion-Brio, Interwoven-iManage, RealNetworks-Listen.com, Filenet-Shana, Mercury Interactive-Kintana, Veritas-Precise Software, Mercator-Ascential, Informatica-Striva, Autonomy-Virage, Epicor-ROI Systems, SSA-Exe Tech, Ross Systems-chinadotcom, and others. And the list is growing monthly.
First, the buyers (folks with bigger bucks that your customers) now ask target companies to swear that they never baked any OSS into any part of a product. Can your company promise that? Knowledgeably? Accurately?
Second, some buyers require a warranty that no OSS obligations will apply to them, if and when the deal closes. Now they require contractual assurances that the acquiring company won't be obligated to follow those messy OSS obligations after and if the deal closes. They demand they won't be required later, by the target company's prior development decisions, to:
(a) give source code to anybody and everybody,
(b) give the world the right to modify the product as desired, and
(c) use only the same licensing terms that flowed down from "upstream" (rather than proprietary, traditional license terms).
Third, some acquirers demand that the target company specify the particular ways and days that OSS was used in the research, design, development, or documentation of products. That is, you must disclose and list the particular genealogy and "provenance" of all OSS in your code base and product line, as a condition to being bought out. "Product provenance certainty" is a new buyer value or requirement in the OSS era.
These anti-OSS requirements, contained in the recently disclosed acquisition agreements of other software and tech companies in the last few months, have a current impact on you. They mean that your company needs a comprehensive OSS management plan in place now. The challenges to a sales team's selling and training plan is only a part of the new OSS puzzle.
OSS and You: Action = Survival
If you have robust, smart, consistent answers and processes implemented and tuned up to address the new OSS questions and challenges, then maybe you'll get that question that you want: "OK, where do I sign?" You can be OSS-OK, rather than OSS Strictly Out of Luck, if you act.
In a later issue, we'll suggest "homework" resources, particular needed actions, and additional OSS questions that you'll face, to help both your company and you survive the new OSS era.
Henry W. (Hank) Jones, III is a 23-year software/tech. lawyer, consultant, executive, trainer, and writer who has worked with over 100 software and other information technology vendors. He operates both technology law and consulting practices from Austin, Texas. Hank is an alum of the senior management teams of 3 publicly traded tech vendors, where he served as a "utility infielder," head in-house counsel for two, and V.P., I.P. Dev. for a third (Ashton-Tate, QMS, and U.S. Robotics). He also has worked as a senior software and technology lawyer and manager inside Accenture, (Arthur) Andersen, 3Com and in private practice. Hank has spoken on and chaired panels on open source and other software business topics at COMDEX, Software Publishers Association, Austin Software Council, and many other industry groups. He has conducted sales, licensing, and negotiation training workshops, process reviews, and other special projects for various technology vendors. Hank welcomes feedback on this article (512-695-4673 or memphishank@aol.com).
© HWJ 2003.
 
|
|
|
