Getting Started With Open Source Policies

Earlier this month I had the opportunity to work with Adam Cohn, Senior Corporate Counsel at Cisco Systems, to present a session on "Effective Open Source Development Business Practices" at the Practicing Law Institute's Open Source session on Free Software 2009: Benefits, Risks and Challenges in Today's Economic Environment. With companies of all types and sizes becoming familiar with and using open source software, creation and implementation of open source policies was a focus of our talk.

The structure and contents of an open source policy, as with any company policy, must be tailored to the particular needs of the company. As a result, this post does not focus on the specific contents of a policy (but see this article by Stormy Peters, Executive Director of the GNOME Foundation, with a "how to" on open source policies, including ideas on specific topics to cover within such policies). Instead it targets initial considerations in defining the term "policy," determining whether you need a policy, how open source fits into your risk profile, and if and how open source fits into your business strategy. Next, it offers tips on how to align your policy with your business strategy for maximum effect.

(Note: The content in this post is based on the PLI presentation, but are mine alone and do not necessarily represent the views of Adam, my co-presenter, or our respective employers.)


Initial Considerations

What does "policy" mean?

The term "policy" will have different meanings between companies, between departments within companies, and between individuals within companies. As a result, as you undertake the exercise of determining whether you need a policy and implementing the agreed upon policy, ensure everyone involved has a clear understanding of the meaning of "policy." For example, policies are implemented for a number of different purposes from minimizing operational risk (such as a manufacturing quality check process) to satisfying legal obligations (such as financial policies in support of Sarbanes-Oxley reporting obligations). Looking at this another way, a policy could be something as simple as a set of operational actions, a more complex set of review and approval guidelines, or a vision statement on what open source means to the company. Often, a "policy" will address many of these needs at once.

Do you need a policy?

Not everyone needs a true policy, and even when a policy is necessary, it should be tailored to address the particular needs of a company. Start by identifying the specific problems you are trying to solve, which might span from telling staff that open source software should not be used at all, to implementing robust processes to both use open source in product development and distribute software under an open source license. Also determine whether a separate, standalone policy is needed. You might be able to address the problems you identify through minor updates to existing policies, such as policies on use of intellectual property or review and approval procedures for product development and distribution.

What is your risk profile?

By identifying the risks your policy should address, you will be better able to make your policy meaningful. For example, your company might have a particular sensitivity to one of the following types of risks: (a) fear that use of open source, along with related review and approval procedures, will result in the inefficient use of resource as compared to the perceived benefit; (b) fear of lack of warranty or infringement indemnity; (c) lack of understanding of community needs and dynamics; and (d) lack of understanding on customer concerns and expectations concerning your use of open source. Companies that use open source sparingly for internal purposes alone might view (a) and (b) as bigger risks than (c) and (d) and should adjust their policies accordingly. By contrast, companies that are not involved in open source communities and that frequently distribute closed source products containing open source components might be more concerned about (c) and (d), and they would have different policy needs.

How does open source fit into your business strategy?

As with risk profile assessment, companies must also identify how open source fits into its business goals and adjust its use of open source and related policies accordingly. The results of a year-old Gartner survey indicate that virtually all technology companies use open source software. But, mere use of open source software alone likely should not be deemed an open source business strategy. By contrast, frequent use of open source for revenue generating purposes almost certainly constitutes an open source business strategy. Consider the following broad guidelines for when a business strategy might warrant a robust open source policy:

• Minor policy should be considered: (a) Incidental use of open source in product development; (b) Use of open source in development for internal use

• Robust policy could be helpful: (a) Frequent inbound use of open source in product development; (b) Participation in open source community projects; (c) Sponsoring an open source community

• Policy is strongly recommended: (a) Open source development tools with proprietary “crown jewels”; (b) Services business for a community project; (c) Dual license strategy

Aligning Your Policy With Your Business Strategy

Policies are often designed primarily to address risks or satisfy legal obligations. By contrast, strategies are used to indicate a companies goals to be achieved over a particular time. Policies and strategies cannot exist in a vacuum, and each depends on the other. Policies cannot be narrowly tailored to address important risks unless a strategy exists to help prioritize those risks. Similarly, strategies will not be successful unless proper policies are in place to assist in effective implementation and avoid or mitigate risks. As a result, companies should make alignment of open source policies and strategies a high priority.

Once a company explores the "Initial Questions" identified above, it should consider the following recommended actions to check for compatibility and identify areas where additional consideration is needed:

• Determine whether an operational "how to" guide is sufficient, or is a vision statement appropriate. A hybrid approach is likely most appropriate.

• Identify the specific business cases that would benefit from a policy (see the discussion on "How does open source fit into your business strategy?" above).

• Assess the impacted functional areas. Think broadly, beyond the development and legal teams. Your HR (employee participation in outside projects), IT (internal security), finance (lack of indemnification; revenue recognition), and other departments might also need guidance on how open source will impact their functional areas. Also think outside your company to assess the impact on your customers, partners and the open source community.

• Assign appropriate review and decision-making authority. The more important open source is to your business strategy, the more important it is for your managers to understand what open source issues they can approve, and the proper escalation paths.

• Test hypothetical business cases. While this concept is relatively simple, it can provide a meaningful sanity check before implementing a policy in a complicated business. For example, this type of review might identify that employees do not understand open source issues enough to implement the policy and strategy, which might require more training.

• Manage conflicts with other policies and strategies. For example, a company that rarely uses open source might have an supplier indemnification policy that would not be appropriate if it decides to use open source software more frequently in its operations. Open source components often don't have the warranty and indemnifications protections these companies are used to seeing.

Companies should review their policy/strategy alignment regularly to ensure both that their strategies accurately reflect their use of open source, and their policies address the particular needs of the company.


More Information

You might also find the following web links interesting as you continue your own research into open source policies (note that I do not necessarily endorse or agree with the content in these links, but they provide other perspectives on the policy discussion):

• Black Duck Software - Offers a whitepaper entitled, "Creating and Implementing an Open Source Policy: Five Steps to Success" (registration required)

• ABA Section of Science and Technology Law - Offers both a model open source software policy outline and a model open source software review/approval form that might server as starting points for a policy. These documents were drafted in 2005 by Heather Meeker of Greenberg Traurig, LLP, who is known for her frequent involvement in open source issues, and they are available for reuse and distribution under a Creative Commons license.

• Open Logic and Stormy Peters - Offers a heavily reference "how to" guide for policy creation. As referenced earlier in this post, the article provides more detail on the specific types of content that you might consider adding to a policy. Note: Open Logic also offers papers on how to write an open source policy and open source policy best practices (registration required).

• Digium - This open source telephony software/equipment provider shows (in multiple blog posts here and here) potential customers how to assess whether open source is right for them and to what degree. This is an example of a "policy" designed to promote a particular type of software by a particular provider.

Not Your Ordinary Communities and Contributions

Few terms are more central to the free and open source ("FOSS") movement than "community" and "contribution." The common definitions of these terms are:

Community: a unified body of individuals as - a state or commonwealth; the people with common interests living in a particular area; an interacting population of various kinds of individual in a common location; a group of people with a common characteristic or interest living together within a larger society; a group linked by common policy; a body of persons or nations having a common history or common social, economic, and political interests; a body of persons of common and especially professional interests scattered through a larger society.

Contribution: a payment (as a levy or tax) imposed by military, civil, or ecclesiastical authorities usually for a special or extraordinary purpose; the act of contributing; the thing contributed

But these terms mean so much more in the context of FOSS. Anyone who sponsors, participates in or contributes to a FOSS project needs to understand not only the importance of these terms, but also how their meaning has changed over time.

Starting Point
The community is the core of any FOSS project. Consistent with the common definition, a FOSS community has traditionally been a self-defining group of people and organizations that share the common value of exchanging ideas and intellectual property in the pursuit of creating the highest quality software using an open development model. Until recently, there has been little need to define the community in any greater detail because membership was open to all and carried no obligation to participate, which resulted in the attraction of like-minded participants.

FOSS contributions have traditionally come from individual developers and companies alike. They typically included any materials submitted to the project under a standard set of terms commonly accepted and understood by the community. Again, because the community traditionally shared common values, there has been little confusion as to what constitutes a contribution and what the receiving FOSS project could do with it.

Where Are We Now?
With the growth of the open source movement, the concept of free software has taken on competitive and commercial traits, which has impacted the meaning of "community" and "contribution." Those who sponsor or participate in FOSS projects need to take note of the changes.

In the case of communities, we can no longer assume that the FOSS project sponsor and participants share common values. At a minimum, sponsors and participants might be divided between those that advocate for pure free software principles, and those that use the community for purely strategic purposes in support of a commercial advantage.

The nature of contributions has also changed. Some FOSS project participants might contribute for the purpose of advertising an alternative product or fork, or to incorporate code allowing for easier integration with a commercial product. In addition, the traditional "anything submitted" contribution model, which promoted free exchange of ideas and is the most beneficial to the community as a whole, is less relevant. More recent contribution models include the option for contributors to declare which of their submitted materials are deemed not to be contributions. The legal terms that apply to contributions are sometimes also subject to the influence of commercialization by being narrowly focused on the sponsor's objectives to the detriment of the community's needs as a whole.

How Should FOSS Project Sponsors Respond?
FOSS project sponsors (whether non-commercial or commercial) should carefully consider how to respond to this evolution in the meanings of "community" and "contribution". They should spend more time defining their FOSS goals, more closely monitor FOSS activities and contributions, and implement measures that will further their goals and ensure that the appropriate elements of the community work in their favor.

Specific actions for consideration by FOSS project sponsors include:

• Posting a definition of goals for content, community and participation. This might include a statement of purpose for the project, a definition of community values, and a code of conduct for participants.
  

• Creating separate discussion boards and mail-lists for contributions in support of the project, general discussion about the project without contribution, and discussion of other projects or any other matters not related to the sponsored project.

• Monitoring contributions and discussions to ensure that they are posted to the proper boards and lists, and to ensure that contributions do not contradict the applicable participation model and community values.

• Avoiding alienation of participants even if they appear to contradict community values. For example, even when a project participant uses a project discussion board to promote its own commercial activity, the sponsor should first decide whether to object to that practice. If it chooses to object, it should do so in a way thatfosters inclusion and participation in a rational, pro-community manner, while minimizing the perception that the sponsor is hindering project discussion or participation.

• Treating conditional contributions (i.e., contributions made under terms other than the sponsor's standard terms) as invitations for negotiation to be handled in the same manner as other commercial inbound licenses. Sponsors should not grant exceptions to conditional contributions because that risks contradicting community expectations and undermining the purpose of the project.
  

• Weighing a number of factors when faced with a choice between accepting a conditional contribution or not obtaining any rights to the contribution at all. Specific considerations include: the value of the potential contribution; the scope of rights offered; consistency with the sponsor's commercial strategy; consistency with community values and expectations; perception in the community; and consistency with free software principles. An assessment of these factors could lead to a number of outcomes from a decision that the contribution will not be part of the project, to a decision by the sponsor and contributor to enter into a commercial relationship.

Judgement Day for Commercial Open Source ... How Did I Miss It?

In a recent Business Week online article, Peter Yared, founder and CEO of San Francisco startup Transpond, describes "The Failure of Commercial Open Source Software". While Yared makes a case that the commercial open source software business hasn't lived up to the hype that it will "change the world," he reaches too far in declaring its failure. A more appropriate conclusion would be to recognize that commercial open source only recently reached broad acceptance as a business strategy and is on a strong growth trajectory. We must measure its success in that context.

Yared's arguments are diverse, but they fail to account for important indicators of open source success:

1. Minimal number of liquidity events for open source businesses. As identified by one of the commenters, several prominent examples of open source liquidation events are missing from Yared's list, including Zimbra, Trolltech and Sleepycat. In addition, the article uses 2003 as a benchmark year, allowing only 6 years to measure exit success. According to a September 2008 MoneyTree Report by PricewaterhouseCoopers and the National Venture Capital Association, the average seed-financing to exit life cycle of a venture-backed company is 8.6 years. As a result, any conclusions about the success or failure of open source businesses, many of which were started within the last 6 years, are premature at best.

2. Continued success of proprietary vendors. Not only is this irrelevant to measurement of open source success, but it fails to acknowledge the growing role of open source in proprietary companies. Companies like IBM, Microsoft, Adobe and Oracle, are milking revenue from their established proprietary business models while they also distribute open source software to generate revenue, influence development communities and drive broader adoption. In addition, measuring open source displacement of proprietary software misses the point, particularly in the short 6 year time frame here. Open source targets adoption opportunities through grass roots growth, which takes longer (but is less expensive) than the hard-hitting direct sales approach of proprietary companies.

3. Success is limited to commodity businesses; Enterprises are not likely to add open source businesses to their lists of approved vendors. These assertions fail to take into account the growing reach of open source throughout the software industry. While it is true that many of the more successful open source companies to date have been in the infrastructure and commodity business, we are beginning to see significant adoption of enterprise and end user open source applications (such as Alfresco, SugarCRM and others). Matt Asay further amplifies the limitations of Yared's assertion by identifying SpringSource as an example of an open source company that innovates and targets enterprise-friendly software development, which is outside the category of traditional commodity software.

4. Cost savings of open source are overstated. This contradicts the conventional wisdom that cost savings is one of the primary reasons companies adopt open source. In an April 2009 Forrester report, 75% of survey respondents said "Reduced IT costs" are critical or very important in their decision to use open source software. In addition, a panel of venture capitalists at OSCON proposed that open source companies can typically save up to 30% in sales and marketing costs as compared to proprietary companies, which leads to quicker profitability, quicker exits and happier investors. Even so, the article is likely correct with respect to mature open source businesses. In two March 2009 Open Sources blog posts, Savio Rodrigues compares the income statement of Red Hat to those of Microsoft and Tibco. In both cases, he concludes it is unlikely that mature open source vendors will be more capital efficient than commercial vendors.

5. SaaS will overtake open source. The general trend away from installed software applications to SaaS and cloud systems is undeniable. As Matt Asay explained on his Open Road blog in May, cloud computing is the natural conclusion of open source, because cloud computing is the ultimate expression of the open source principle that services, rather than the software supported by such services, are the most valuable component of a product offering. But SaaS and cloud business models are having significant growing pains of their own. Customers are concerned about the portability of data, freedom from vendor lock-in, security and standardization and other matters that must be resolved before achieving broader commercial acceptance. (It's a bit ironic that open source software might actually be the best way to address these concerns.) SaaS and cloud businesses appear to be subject to at least the same level of skepticism as open source. As a result, it seems unlikely that SaaS and cloud business models will replace the open source software business in the near future.

6. Open source benefits do not lead to monetary gain. Yared observes that his company uses open source but typically does not pay for it other than contributing code back to projects. This is a common practice and it implies an impending failure of commercial open source. Yared concludes that these factors do "not mean every successful open source project can sustain a commercial company, especially when they are delivering complicated applications rather than simple plumbing." No doubt this is true, but it is also true of proprietary business models and does not lead to the conclusion that commercial open source has failed.

It is fair to question when open source will become as reliable an investment as other technology businesses. In this regard, Yared's article raises some important points for discussion. However, rumors of the failure of open source business models are greatly exaggerated, and any pronouncement on the success or failure of open source is premature.

Show Me the Money at OSCON - Venture Capital and Open Source

To my pleasant surprise, Mark Radcliffe (notable open source attorney) announced last week on his blog that his law firm, DLA Piper, would host an open source legal track to run in parallel to the OSCON trade show in San Jose this week. The schedule included a diverse mix of topics that pushed the boundaries of typical legal presentations on the issue of open source. I found the talk on venture capital and open source the most interesting. The panel consisted of 3 seasoned venture capitalists (Josh Stein of Draper Fisher & Jurvetson, Mark Gorenberg of Hummer Winblad, and Vivek Mehra of August Capital) and an experienced open source attorney (Vicky Lee of DLA Piper).

Venture capital is a hot topic of discussion. Several tech publications and blogs are reporting, based on a report issued earlier this week by PricewaterhouseCoopers and the National Venture Capital Association, that venture investment has shrunk to pre-tech-bubble levels, the slow economy is putting a damper on venture capital, and venture funding in the tech industry is down over 50% year-over-year from 2008 to 2009. At the same time, however, the tech sector seems to be attracting more investment in recent months. The panelists at the OSCON session on "Understanding Venture Capital Investments in Open source Projects" seemed to have an enthusiastic view of investment in open source companies.

The panel described several elements that go into their determination of what is a good open source investment. The most fundamental points, however, came during the second session by Larry Augustin on "Choosing a License: Ensuring that Your Intellectual Property Strategy Matches Your Goals". Augustin emphasized that: (1) open source is only a tool and an open source business model alone is not enough to guarantee success or to warrant funding by venture capital firms; and (2) quality is critical to ensuring customers want to purchase a product regardless of whether it is open source or not.

Beyond these fundamental points, the panel discussed the following elements:

1. Successful Business Model

• Copyright Ownership - This is an immense benefit because it provides maximum flexibility as a company grows.

• Clear Distribution Rights - Ownership of all the copyrights in a product eliminates uncertainty about distribution rights. When third-party components are involved, however, clarity on rights is important.

• Disruption, Platform and Infrastructure - Venture investments are most desirable in quality companies that focus on specific areas: (1) market disruptors in an existing industry; (2) technology that can become a platform; and (3) technology that focuses on infrastructure (because it is most likely to help companies reduce costs).
  

• Free is a Negative - Serious customers do not find as much value in free products as products that they must pay for (Larry Augustin emphasized this point in the second session).

• Support and Services - Companies that do not own their code and generate revenue only from services are susceptible to competitors.

• Open Core - This is the current popular favorite of open source business models and it has a proven record of generating revenue, which is attractive to venture capitalists for obvious reasons.

• Community - Open source products that spring from existing communities or that are developed in parallel with newly created communities can both be successful, but they present distinct tradeoffs. Existing communities provide an available user base that drives quick adoption, but the likelihood of multiple contributors complicates the intellectual property ownership issues.

2. Benefits to Venture Capital Investors

• Lower Cost - While the first wave of financing is typically the same for open source and proprietary companies, the second wave often results in significant savings, which the panel estimated to be 30% or more. Specifically, the availability of open source software and related ecosystem allow open source companies to spend less on sales and marketing, which greatly reduces operating expenses.

• Quicker Adoption - Because end users always have access to open source software, companies are able to avoid the lengthy proof-of-concept and testing cycles that occur when releasing a product for the first time. The panel felt this could save open source companies up to 2 years of development and testing time.

• Easy to Build a Channel - Open source communities are well suited to perform localization, vertical market and other customization for products, which allows open source companies to enjoy the benefits of channel distribution without devoting sales and other resources.

• Early Revenue and Exit - The lower cost and quicker adoption enjoyed by open source companies mean that these companies are likely to begin generating revenue and profits more quickly, which means that investors are likely to reach an exit opportunity more quickly too.

3. Net Results for Venture Capital Investors: When open source investment opportunities are carefully screened with the business model considerations above in mind, the benefits inherent in open source companies make these types of investments relatively safe for venture capitalists. At a minimum, investors should not view open source companies as being inherently more risky that other startup venture investments.

In closing, the panel indicated that approximately 15% of their holdings are in open source companies. While this is a significant amount of investment, the percentage is likely to grow over time as new software companies arise and existing ones revisit their business models. At the same time, the 85% of holdings that are not in open source companies is a good reminder that a good idea will attract investors because it's a good idea, not because it's open source.

Expanding Open Source Enforcement Strategies

What comes to mind when you hear "open source enforcement"? Probably the names "Busybox" and "Software Freedom Law Center". These organizations are good examples of the "cease and desist" style of enforcement in the open source context. But an enforcement strategy should go beyond "cease and desist" to also include other considerations such as alignment with business strategy, product development and business model considerations, and promotion of open source education.

A. Aligning Enforcement Strategy With Business Strategy

Enforcing intellectual property rights always sounds like a good idea. Unfortunately, the typical cease and desist and litigation strategy has significant pitfalls including requiring vast resources and risking the loss of goodwill with customers, partners and the community. Aligning enforcement strategy with business strategy clarifies which enforcement activities will have maximum impact while minimizing risks. The question is, how do you align these strategies?

Looking at the size and goals of a company is one place to start. Many open source vendors today are relatively small and privately held. These companies prioritize rapid growth, building adoption and proliferating products over converting customers to cash. These companies could reasonably choose to avoid tricky enforcement issues under the theory that any customer, paying or free, in or out of compliance with a license, is one more customer that can be converted to cash sometime in the future.

By contrast, other open source companies are either publicly held, or privately held and on the verge of generating a return on investment. Accumulating customers is not the focus of these companies, but the traditional cease and desist and litigation approaches to enforcement of unauthorized copies could be seen as a quick way to make money for investors.

B. Building Enforcement Success Into Your Product

Enforcement begins with the choices you make as to features to include, the license that applies and the business model. For example, DRM (digital rights management) is a dirty word in the open source community, but it can be a valuable tool in enforcement. Companies with a subscription model can use DRM tools, such as a digital fingerprint, to track subscription periods and to confirm whether particular installations are eligible for support and services.

Licenses make a difference in enforcement too. The popularity of GPLv2 is due in large part to its viral terms, which make the mere threat of enforcement enough to drive compliance, particularly with traditional proprietary software companies. GPLv3 offers an even more intriguing range of enforcement options because it allows licensors to easily apply their own conditions for enforcement opportunities.

A company's chosen open source business model makes a difference too. As mentioned above, companies with a subscription model often worry about enforcement because they want to ensure the services and tools they provide are only available to licensed servers. By contrast, companies with an open core model might not be as concerned with unauthorized availability of the software because they make their money by enabling additional features or functionality.

C. Safety in Numbers

One of the most successful enforcement strategies adopted by proprietary software companies could be a model for open source enforcement strategies too. Many of the leading software companies are members of the Business Software Alliance (BSA), an organization that not only organizes anti-piracy and license compliance programs, but also promotes public policy initiatives including intellectual property and development policies. Possibly the greatest advantage of the BSA is that it allows licensors to pursue enforcement strategies collectively, thus allowing enforcement resources to be pooled while avoiding the risk of individual members losing goodwill. The uniformity in approach also creates predictability in license rights and when enforcement is appropriate.

Open source companies could come together to form their own Open Source Software Alliance (OSSA) and realize the same benefits. Ideally, the proposed OSSA could also partner with the Free Software Foundation to add credibility to the positions it takes and bridge the gap between the open source and free software movements. Unfortunately, the gap between open source and free software is likely too big for the FSF to endorse an organization like the OSSA.

These are just a handful of ideas that I hope will help open source companies break out of the "cease and desist" box to realize that enforcement means so much more than adversarial confrontations and litigation.

Word Play

Judge Learned Hand, among the most celebrated American jurists, once wrote, "The language of law must not be foreign to the ears of those who are to obey it." Yet, law is very complex. Lawyers are in a never ending quest to express complex thoughts in as simple a way as possible. Words are a lawyer's tools of the trade. Some of the commonly used words are descriptive, some are fanciful, some are latin, and some are beyond explanation.

Here is a short selection of legal terms I have always found interesting -- not necessarily because of their legal import, but sometimes just because I like the way they sound. Also, please take the survey on the right and tell me which of the words on my list is your favorite, and leave a comment if you have others you would like to share.

Caveat Emptor
Meaning: Buyer beware.
Interest Factor: This deserves to be on the list if for no other reason than it played in prominent role in a Brady Bunch episode, no doubt inspiring an entire generation of children to choose a career in law. Aside from the pop culture reference, it is good advice.

Clawback
Meaning: A provision in a financial arrangement that enables the recovery of prior payments. (Clawback is more appropriately categorized as a financial term, but it is directly related to legal documents.)
Interest Factor: Much of the discussion on our current financial crisis revolves around clawbacks on executive compensation, particularly for executives from failed companies or companies receiving government subsidies.

Cramdown
Meaning: A bankruptcy term describing a situation in which a court imposes an involuntary reorganization plan at the expense of some classes of creditors.
Interest Factor: This term immediately caught my attention in bankruptcy class in law school. Not only is it perfectly descriptive of what happens in bankruptcy, I also always though it would make a great name for a rock band.

Disparate Impact
Meaning: A theory of liability in employment discrimination cases that relies on a showing that a protected class of people is wrongly treated differently even though employment policies are applied equally.
Interest Factor: News reports on Judge Sonia Sotomayor, President Obama's Supreme Court nominee, frequently include references to her role in a ruling by a panel of Second Circuit Judges in Ricci v. DeStefano, a case concerning whether a test for hiring firefighters in New Haven, Connecticut had a disparate impact on minorities.

Expressio unius est exclusio alterius
Meaning: The expression of one thing is the exclusion of another.
Interest Factor: This latin phrase is one of the foundational elements of logical thought and has applications well beyond the law. When interpreting contracts, it stands for the important principle that parties agreeing to include a list of items are presumed to have intended to include only those items, and other items must not be inferred. Applying this in a broader context, the more detail one provides, the more exclusive the description. Simple, powerful and true.

Jus Cogens
Meaning: A fundamental principle of international law accepted as a norm. Genocide and slavery are common examples.
Interest Factor: I will always remember the distinctive German accent in which I first heard this term spoken ("juice kookens") . A guest German law lecturer introduced this legal concept to our international law class in law school. While this term is valuable in its recognition that certain principles are almost universally recognized as boundaries of conduct, care should be taken to ensure the term is not mistakenly applied so broadly that it interfere with legitimate discussion and dissent.

Res Ipsa Loquitur
Meaning: A thing that speaks for itself, often abbreviated as "RIL".
Interest Factor: Along with "expressio unius...," this is one of the classic latin terms used in legal writing. The term is most often seen in the context of tort law when the cause of an injury is apparent on its face, but direct evidence is difficult to find.

How does this tie into open source? It doesn't ... at least not directly. However, it is interesting to note that many of the most popular open source licenses avoid the use of traditional legal terms and virtually all avoid latin terms. This is likely due to the fact that developers rather than lawyers wrote the first comprehensive free software licenses (like GPL).

This is just a small sampling of the wonderful world of legal terminology. Please share your favorites!

[Note, the "meanings" above are drawn primarily from the Nolo Press legal glossary, the Law.com dictionary, the FindLaw legal dictionary, the free legal dictionary, and Wikipedia.]

Back to Basics

Open source business models are a hot topic these days. Blogs are filled with in depth discussions on open source topics such as choosing the right license, building a strong community, and deciding which software should be open and which should be closed. This blog is no stranger to open source business models. While it's easy to jump right into the intricacies of open source (for an example of the level of minutia that arises in the open source business model conversation, see this link with a "simple" chart summarizing the different types), the truth is that open source means nothing unless is fits within a good business strategy. That's why I say it's time to get back to basics.

The most basic question for any business is, "how will we make money?" The answer is never as simple as "use open source." In the software industry, like any other business, a good business strategy starts with at least three fundamental elements: developing a product, attracting attention, and delivering value. Open source is simply a new spin on traditional approaches to implementing a good strategy and it can play a role in each of these ares.

Developing a Product: Regardless of whether a software product is open or closed source, it still goes through the same types of development milestones from concept phase to general availability. Throughout this process, the developer must decide how to allocate resources for quality testing, bug fixing and feature inclusion. One of the great virtues of open source as a development model is that it can speed development time and product quality by leveraging the community's input particularly in identifying and fixing bugs, but also in identifying high-priority features.

Attracting Attention: A great product isn't worth much unless people know about it. The mere mention of "open source" attracts attention, which makes it a fantastic marketing tool. The freedom that comes with open source software ... freedom to try it, modify it, play with it ... makes it easy for users to choose your software over the competitors' offerings. Even better, open source freedom includes the freedom to distribute, which means users can deliver your software to even more potential customers.

Delivering Value: Finally, it's not enough to develop a product and attract attention. Ultimately the product must provide users with something valuable... something worth paying for. Having a strong relationship with an open source community means that a software developer has a clear view into what users deem important. The open source development model allows developers to deliver products that address customer needs directly, which makes those products more valuable to users.

Adopting an open source business model is not a guarantee of success, but its disruptive power can complement a traditional business strategy and improve chances for success. For lawyers advising clients on open source strategies, it's very important to avoid the paralysis of legal analysis that comes with open source. Lawyers need to understand the fundamental business strategies of their clients and the industry as a whole. In short, never forget the basics.