Notice

Just a reminder, these posts are not legal advice. This site is the personal blog of Mark Radcliffe and the opinions expressed are those of Mark Radcliffe and not those of his clients, DLA Piper or the clients of DLA Piper.

About Me:

Mark Radcliffe

I have been practicing law in Silicon Valley for over thirty years assisting startups and global companies develop and market innovative products and services. I have participated in multiple business cyles in Silicon Valley from hardware to software to internet to cloud. My projects have included developing the dual licensing business model for open source startup, developing the original domain dispute resolution policy for NSI and assisting Sun in open sourcing the Solaris operating system. Recently, I served on the US Japan Innovation and Entrepreneurship Council (one of ten members) to develop a plan to encourage the innovation in Japan and the United States. I have been working with the same attorneys since 1986 although we have merged with other law firms several times. I am now a partner at DLA Piper, a (relatively) new global law firm formed in 2005 from the merger of three law firms. The firm now has 4200 lawyers in 31 countries and 77 cities. My experience in corporate securities (particularly venture capital) and intellectual property enables me to assist companies structure the financing and intellectual property strategy for developing ane exploiting a new product or service. I and my team work with fifty startups at one time as well as Global Fortune 100. I have been fortunate enough to work with companies in software, cloud computing, semiconductor, health care IT and Web 2.0.

It is not often that the Department of Defense provides an industry with a marketing hook.  However, I can’t think of a better description of the memorandum issued by on October 16 by David Wennergren, Deputy CIO of the Department of Defense. The memorandum is entitled “Clarifying Guidance Regarding Open Source Software” (“OSS”). http://www.defenselink.mil/cio-nii/sites/oss/2009OSS.pdf and provides one of the best (and most cogent) summaries of reasons to adopt open source software. This summary is all the more persuasive because it comes from one of the most conservative IT cultures on the planet.  I have included the relevant part of the memo below:

 

There are positive aspects of OSS that should be considered when conducting market research on software for DoD use, such as: 

 

                (i) The continuous and broad peer-review enabled by publicly available source code supports software reliability and security efforts through the identification and elimination of defects that might otherwise go unrecognized by a more limited core development team.

 

            (ii) The unrestricted ability to modify software source code enables the Department to respond more rapidly to changing situations, missions, and future threats. 

 

            (iii) Reliance on a particular software developer or vendor due to proprietary restrictions may be reduced by the use of OSS, which can be operated and maintained by multiple vendors, thus reducing barriers to entry and exit.

 

                (iv) Open source licenses do not restrict who can use the software or the fields of endeavor in which the software can be used.  Therefore, OSS provides a net-centric licensing model that enables rapid provisioning of both known and unanticipated users.

 

                (v) Since OSS typically does not have a per-seat licensing cost, it can provide a cost advantage in situations where many copies of the software may be required, and can mitigate risk of cost growth due to licensing in situations where the total number of users may not be known in advance.

 

                 (vi) By sharing the responsibility for maintenance of OSS with other users, the Department can benefit by reducing the total cost of ownership for software, particularly compared with software for which the Department has sole responsibility for maintenance (e.g., GOTS).

 

                  (vii) OSS is particularly suitable for rapid prototyping and experimentation, where the ability to “test drive” the software with minimal costs and administrative delays can be important.

 

Open source companies should quote this memorandum in all of their marketing material. It has the virtue of being both correct and persuasive.

On Friday, Microsoft acknowledged that the code for the Windows 7 USB/DVD Download Tool improperly included GPLv2 licensed code and they did not comply with GPLv2. Like the GPLv2 licensed code found in the Linksys operating system, the software had been written by a consultant.  Peter Galli’s blog was very frank: 

we are now able to confirm this (inclusion of improperly licensed GPL v2 code) was indeed the case, although it was not intentional on our part. While we had contracted with a third party to create the tool, we share responsibility as we did not catch it as part of our code review process. We have furthermore conducted a review of other code provided through the  Microsoft Store and this was the only incident of this sort we could find.

 http://port25.technet.com/archive/2009/11/13/update-on-the-windows-7-download-tool-or-microsoft-to-open-source-the-windows-7-download-tool.aspx

 They will be making the source code of the relevant software available under the GPLv2 next week. They also acknowledged that they will be taking steps to avoid this problem in the future. The open source community should welcome Microsoft’s frank and appropriate response. A recent post on the FSF Europe email list noted that app stores are becoming a major source of violations and companies who host them need to consider how best to deal with the liklihood of these type of problems.

 This problem illustrates the critical nature of an open source (I would now say “third party software use policy” because so much proprietary code is also  available for download) use policy.  Yet Gartner noted last year that 69% of companies surveyed do not have a formal policy for evaluating and cataloguing OSS use.See my earlier post, http://lawandlifesiliconvalley.com/blog/?p=107.  These use policies need to cover not just internal development but all sources of code which includes code from third parties, consultants and M&A transactions.

Post tags: