Yesterday, I took some time out of my day to attend the Google annual shareholder meeting.

This meeting is more of a formality than many such meetings held by public companies.  As of the record date, the officers and directors held a total of 70.2% of the voting power of the company — so, obviously, everything has (or should have) been decided before the meeting.

Perhaps because of this, the formal portion of the meeting was a dry speed-reading session of various folks reading their portion of the Proxy Statement out loud.

In contrast, the complimentary on-campus lunch on the patio and the product demos prior were a big hit with those in attendance, as was the informal presentation and post-vote question and answer period.

Eric Schmidt’s presentation included a great Chrome ad, and some fun Internet facts, such as:

-10 years ago, there were 300M users on the Internet, today there are 1.2B.

-Today, there are 800 exabytes (1 EB = a billion GB) of information on the reachable Internet.

-Every minute there are 24 hours of video uploaded to YouTube and about 1/2 of those videos receive comments

-Eric said, “If you’re not using Chrome, you need to try it — everyone else is starting to use it.”  I chuckled internally when I heard this, since I was sent to building 43 to print my shareholder proof, and the browser they presented to me was Firefox.

-Google Translate is translating 160M pages/day.  And Larry, when asked by the man behind Willworkforjustice.blogspot.com, said that he thought translate was the Next Big Thing. (Note — for more info check out this Play-by-Play post on the meeting)

Other than that, several folks took the microphone to give heartfelt praise and thanks to Google for their stance in China, and several others took the microphone to denounce and complain about the horrid handling of the proxy materials (Eric Schmidt asked  Patrick Pichette to personally meet with each of the grumpy folks after the meeting — I bet that was fun).

My favorite microphone participant was the very excited woman from Frederick, MD, who drove all the way across the country in her Google-themed car (with a brief stop in Topeka) to make a personal plea for Frederick, MD (with a second request on behalf of Topeka) to win the Google Fiber-Optic City contest.

All-in-all, it was a great way to spend a couple of hours.  Given that it’s down the street from my office, I think I may take the afternoon off to attend next year as well.

Every software start-up company I’ve ever worked with uses (or did use) some form of open source software. And yet, high level executives and board members at many of these companies, when asked whether their company uses any open source software, would regularly answer, “No” without hesitation.

Where is this disconnect coming from? Open Source Software is often perceived as “risky” or “untested” or “a liability nightmare” or, in the worst case, “an infectious disease” by some business folks, while most technical software people believe the correct use of open source software to carry minimal risk.

Risky?

There are risks associated with using any third party’s software. When that third party is unidentified, not bound by a support agreement, based out of a foreign country, and/or impossible to get a hold of, then yes, it is fair to say that using it would be “risky” when compared with an established company with a business reputation to protect and an SLA to cover errors.

Untested?

In some case — it’s true. There are many untested open source projects out there. These tend to be associated with a handful of developers instead of an active community, and a little due diligence should be able to help a start-up understand whether this particular ill is a problem with the open source software they are considering using.

A Liability Nightmare?

This is, by far, the most complicated issue I face as an attorney who deals with open source issues. At its most basic, the liability equation associated with open source software is the same as that associated with any third party component. The third party would like to disclaim liability for your use of their product.

The benefit of many proprietary software licenses is that the licensor may provide limited coverage for Intellectual Property claims related to their software. But, most software publishers go to great lengths to limit the amount and type of liability they will cover relating to a third party’s use of their software.

The typical open source license expressly disclaims all liability associated with the use of the software — effectively, it comes “AS IS” on a pure “BUYER/USER BEWARE” basis. On the other hand, if you read the license agreements of proprietary software carefully, you will find that most software (unless you pay quite a bit for it), comes with an express limitation on liability that is on the order of magnitude of the purchase price. It is consistent with the approach taken by proprietary software publishers that open source authors are liable for damages related on the order of magnitude of the license fee they receive (e.g. $0).

An Infectious Disease?

One flavor of open source licenses places conditions of “freedom” upon the use of the licensed code. The most famous of these licenses are the GPL, LGPL, and the AGPL. Essentially, these licenses require, as a condition of some uses or distributions, that software code combined with code licensed under these licenses must also be made available under the same license.

These conditions make these types of licenses “viral” because they may extend the license terms to some of the additional code (e.g. the start-up’s code) that the licensed code touches.

The key word in the previous sentence is *MAY.*

Actual Risk

The thoughtful evaluation of the issues outlined above and a comparison of the likely downside against the monetary benefit of using an open source component brings a start-up to understand what I call the “Actual Risk.”

By far, the most complicated part of the Actual Risk evaluation is the technical and legal analysis related to viral licenses. However, a technical read of the license by a knowledgeable tech attorney and code review with an engineer is likely to provide a good engineer or architect with comfort that the start-up’s use of a particular open source component is not subjecting the start-up’s code base (or the portion of the code base that they care about keeping proprietary) to any “viral” risk.

The Resource Risk

Investors and potential acquirors will want their own attorneys or possibly even code auditors to assess the Actual Risk, regardless of how correct the start-up’s own analysis may be. This investigation and analysis is a time and resource drain that can be minimized by good record keeping, but can never be entirely eliminated. Even in the event of zero Actual Risk, a company will incur some Resource Risk in connection with their use of open source software.

The FUD Risk

No matter what the final conclusion may be after the Resource Risk and the Actual Risk have been assessed and assumed by a start-up, there is the risk associated with the fact that a board member or a CEO will have to answer “Yes” to the question “Do your products contain open source?” A board member or CEO may not have the time to understand the outcomes and analysis of the folks who have willingly taken on the Resource Risk and the Actual Risk. If challenged, a board member or CEO need to feel confident that they can answer the question honestly, without incurring undue scrutiny or concern. In my opinion, the biggest risk associated with the use of open source software (assuming there is no Actual Risk that hurts the start-up’s business) is the FUD risk.

The best way to combat the FUD risk is to educate board members and CEOs so that they can comfortably speak about the company’s intelligent use of open source software as a cost reduction tool in areas where the Actual Risk is minimal or non-existent and the Resource Risks are less than the costs of the proprietary alternatives.

I wasn’t particularly scientific or orderly about my spring crops.

It shows:

Who knew?  The plants grew to be taller than me.  I just harvested my first batch of at least 2 pounds tonight and I’ve got a couple more to come.  I planted them because a) they fix ambient nitrogen into the soil and b) while E thinks they are too much work because they have to be peeled twice, I get nostalgic about Italy when confronted with big, full, ripe, Fava Pods.  The actual food that can be used and gratuitous references to The Silence of the Lambs are a bonus.

The leeks, of course, are always worth it.   But the carrots:

I should have planted earlier.  Smarter.  Around where the tomato seedlings would be going, perhaps.   Instead, I had to harvest entirely too many tiny carrots to prepare the beds for amending and the addition of the tomato seedlings.  Too much effort for too little food, but I’m much too proud to admit defeat.  So here we are:

Ahhh… hindsight.  At least the french chefs consider the baby vegetables a delicacy.  It’s so rare that I have the opportunity to cook a delicacy on accident…

For a winter/spring harvest recipe delight making use of the baby carrots: visit Biting Tongue.

J.I.T.

On Demand.

The Cloud.

In the garden, this philosophy looks like medium sized tomato plants that have not yet been put into the ground despite a date in April in a temperate region of California. Sure, given how close we are to the bay and our average last frost date, we could have planted our tomatoes. We could be fully committed, and done with the major physical labor of amending the beds and putting in the plants.

But, the recent rains and cold weather have made me quite glad that we exercised some caution. We refrained and waited to plant — so we’ve been taking the plants out into the sun when it’s nice and taking them into the garage to protect them when it’s too cold, or too wet (like today).

As a result of waiting until the last possible moment to be irrevocably committed to the ground and exposure to the elements, we will experience less loss and will have the freedom to optimize where appropriate.

Yet another garden analogy that works for startups.

California’s strong public policy against non-competition agreements is one of the reasons why Silicon Valley exists.

In most states, at the time of hiring or during employment, employers can require employees to sign an agreement not to compete with the employer’s business after termination of employment, so long as the agreement is *reasonable.* Each state has a different interpretation of what is *reasonable* but in general, in those states, the agreement must be limited in three ways:

1. The scope of the business that is considered competing,
2. The territory where the employee is not allowed to compete, and
3. The length of time during which the employee may not compete.

In California, however, Business and Professions Code 16600 expressly prohibits employers from requiring employees not to compete with them after their employment has ended, in any way (regardless of how employment may have ended):

Except as provided in this chapter, every contract by which anyone is restrained from engaging in a lawful profession, trade, or business of any kind is to that extent void.

This policy in support of “freedom of movement” of employees is very strong in California. In 1872, just seven years after the abolition of slavery and indentured servitude via the 13th Amendment, the legislature parted with the English common law “rule of reasonableness” standard for non-competition agreements and enacted Civil Codes 1673-75, the precursors to today’s Business and Professions Code 16600-16602.

The courts have applied these statutes and the public policy over the years to show that unless you fall into one of the narrow statutory exceptions (set forth in 16601-16602.5) where a non-competition agreement is acceptable, the contract is void, and, in fact, may be the basis of tort claims against the employer who required you to sign it.

This means that in California, an employee could leave Google and immediately start a software start-up in Mountain View, whereas in Boston, that same Google employee may be subject to a contract that would mean she couldn’t start a software company in the same location for a year, or possibly even longer.

This provision does not give employees permission to utilize their former employer’s trade secrets in their new businesses, of course, but it does give them the freedom to apply their generally applicable skills in a new venture that may be competitive with their former employer.

We can thank the California legislators of 1872 and the judges who have applied this law and the policy in support of each individual’s right to work in his or her chosen profession for helping to create an environment where so many new technology companies can be started and thrive.