3rd party software proviso

As you build out the next killer app, (perhaps we should bring that description up to date. How about "killer service") it is extremely likely that you will use off the shelf (ots) software. It is in fact unthinkable in this day and age of mash ups, social networks, and open source that you would build everything from scratch, any more than Toyota would build all the parts it needs for its cars.

Given the possibility of the sale of your company here are three major things to consider when licensing 3rd party software whether open source or no.

Distribution
If you plan to redistribute your application, i.e. sell it to a customer and have it reside in their place of business you must have the right to distribute the third party software. If the software library you are using is not open source your contract with them must give you the right to distribute their library along with your software. Depending on the nature of the business this may range from an OEM agreement in which you pay royalties to the third party software manufacturer to a royalty free arrangement where you just pay for development licenses. In either case (and those in between) it must be handled in the agreement. If the library is open source then your obligation is dependent upon the particular open source license the software was created under. The most popular open source licenses today are GPL, LPGL, BSD, and MIT. GPL is by far the most prevalent accounting for nearly 68% of the projects listed on Source Forge (according to Wikipedia). In GPL and LPGL you must distribute the source code with your software as well as placing the GPL copyleft notice at the top. GPL is the least permissive of open source licenses and claims that software that uses GPL software is also GPL. The LPGL (lesser GPL) is more permissive and is commonly found in libraries whereas GPL is commonly found in applications. LPGL allows distribution of the library as a linkable (harkening back to the world of linked languages, such as C) component. I believe you still must distribute the library source code with the product, but do not need to distribute the source for your proprietary part of the product. The most permissive of all are the BSD and MIT licenses which allow you free and unrestricted use to the software, although I think they require the author headers be maintained in any distributed source. BSD and MIT are starting to become more prevalent as I see more and more new libraries and tools pop up that were created under these licenses.

If you are running your software as a service with a thin client interface (html or flash, also the newer Yahoo Widgets would fall into this category as well) and the core of your software resides on your own servers you will still need to have some agreement in place with software vendors. They may only charge you for dev licenses but could also charge on a use model (number of users, number of servers, etc.). The open source arena is easier to deal with here because you're not actually distributing your software, instead only using it internally and exposing outward some set of functionality. No mess.

Transferability
If you are a startup and you believe there is a good chance that you might be bought someday then the software that you license as part of your overall product or service must be transferable or assignable to the purchasing entity. Open source transferability follows the same conventions as distribution, so there are no additional considerations here (unless of course, you've open sourced your software as a result of embedding GPL and your buyer wants to make this software proprietary. In this case you will need to swap out the GPL code for your own or more permissive open source code). For non open source libraries and applications you will often see something like the following in a software vendor's license agreement:

Subject to the terms and conditions of this Agreement, Software_Company_X grants to Licensee a personal, nonexclusive, non-transferable, non-assignable and non-sublicenseable, limited license to use the software identified in the product schedules attached to this Agreement

This will not work for you. The provision you will want to carve out will say something like:

Licensee may assign this Agreement in its entirety in the event of a merger, acquisition or sale of all or substantially all of its assets, without Software_Company_X’s prior written consent; provided, however that for any proposed assignment Licensee may not assign or transfer this Agreement to any competitor of Software_Company_X that develops and/or sells similar technology and is listed on Exhibit A.

Companies will want the competitive carve out. Just lock it down to a limited set listed in an exhibit, otherwise the word competitive is open to interpretation.

Intellectual Property Ownership
If the intellectual property you create is built upon 3rd party software this is considered a derivative work. Again, GPL will not work for you. This is somewhat tricky overall depending on how important the role of the 3rd party software is in the creation of the IP. The best you can do here is to carve out a provision in the software license agreement that clearly defines your rights as follows.

Subject to Software_Company_X’s IP Rights in the Product and any derivatives thereto, title and ownership of all proprietary rights, including any copyright, patent, trade secret, trademark or other intellectual property rights, in and to any software created by Licensee will at all times remain the property of Licensee.

After this, pricing negotiation is easy ;)

Blue Ocean Strategy Maps

I recently read the book Blue Ocean Strategy and while the book is more focused on figuring out how to change an existing business to explore new opportunities (blue oceans, instead of red oceans where there is already much competition bloodying one another) I really liked the strategy maps concept.

Here is a blurb about Strategy Maps that I copied from the Tech Talk blog whom I think copied it from elsewhere:

Blue Ocean Strategy offers both a process and a set of supporting tools that practitioners can use to navigate. It begins with a �strategy canvas� that visually maps the current industry environment in two dimensions. The horizontal dimension includes the range of factors on which an industry currently competes and those factors in which it invests. The vertical dimension shows levels of performance against each factor, measured qualitatively. A strategy canvas is a conceptual tool remarkable in both its simplicity and its usefulness. It can be used to understand the current strategy of a company and its competitors, to communicate the strategy, and to imagine business directions. To do the latter, Professors Kim and Mauborgne recommend that a company create several alternative, radically different strategies, each aimed at delivering superior value to potential � not existing � customers by:

• Reducing cost by eliminating some factors that the industry takes for granted and reducing other factors below the industry standard
• Enhancing differentiation by raising some factors well above the industry standard and creating additional factors that the industry has never offered.
  

I think the strategy map concept might be even clearer as a spider diagram, especially if you only map yourself to a single competitor. The strength however is in the ability to quickly discern where the key opportunities lay and how you might change the playing field to your strategic advantage.

I used the strategy map with fairly powerful results recently in a board level strategy meeting.

The Deadest Guys in the Room

In the movie, "Enron, The Smartest Guys in the Room", Ken Lay is depicted as the disconnected fatherly figure who doesn't quite know, or want to know, what his son (Jeff Skilling) is up to when the son arrives with keys to a new Caddie (see scene where he is picking out the color of drapes for his private jet).

Lay was as culpable and probably more so than anyone at Enron for fostering the culture which ultimately resulted in bilking Enron investors and employees of billions of dollars. I think there is a danger in trusting one system (in this case the free market) to cure all ills. It reminds me of evangelicals who come up with crazier and crazier rationals as to why dogma is correct in the face of incontravertible evidence as the spool begins to unravel behind them.

Bottom line is that these guys believed what they were doing was good and their own hubris prevented them from admitting mistakes and adjusting their view of the world and their own business.

I believe the US and especially the US markets needed someone to go to jail and these guys were perhaps scapegoats to that end. But sometimes the goats are guilty, and for a brief shining moment, justice is served.

Ken, I hope you like the curtains for where ever the afterlife takes you :)

the holy wiki

I wrote a post a long while back about the use of Groove as an intra-company bulletin board. Well, we started having some problems with Groove back in late 2005, especially with synchronizing (auto copying of updated files up to people's computers when they login). It would pretty much lock up the computer and was overall a pretty big resource hog. Now I still like the features and think it's a pretty cool overall product, the performance characteristics became a barrier for us.

Early this year, we moved to using Jotspot. It is a fairly simple Wiki product that is easy to get started on and easy enough to use by the entire organization. JotSpot is Joe Krause's (of Excite and Long Tail fame) company and I believe they were bought by Yahoo just a couple of months ago, so their longevity is fairly assured. You can edit docs as wysiwyg or use the simple wiki markup for editing, easily create pages, and even create mini-apps by importing spreadsheets. There is a fairly low startup cost as well. I believe it's $99/year for a small group (<=10 users) and 100 pages.


We've used it a lot for asynchronous brainstorming and keeping large grained tabs on projects.

So far it's the best/easiest tool I've found for an intracompany interactive bulletin board. If you haven't used wiki's before I would highly recommend giving them a try and this is a great place to start.