December 2010

Monthly Archives

  • Departing Employees GONE WILD!

    I have been tracking this case (Starwood vs. Hilton Hotels), as it has some really practical things to remember for every software or SAAS company regarding protecting their confidential and trade secret information (especially when some of your employees go to a competitor). As it was settled in December 2010, I can now (from the perspective of a software copyright attorney), give you some useful insights and takeaways.

    Background: Without going through the long details, 2 top level employees of Starwood who worked on developing the W brand of hotels went to work for Starwood’s competitor (Hilton Hotels), and apparently took with them 100,000 documents. Hilton was planning on creating a similar boutique hotel brand to the Starwood W Hotels, and probably thought that hiring these Starwood employees would help them grow into the new market for boutique hotels. Well long story short, Hilton now cannot (by court order) develop–for 2 years–a competitive boutique hotel chain, must have federal monitors supervise their strategic decision marking, and (according to the NY Times) must pay Starwood $75 million (all of this before they even started competing with Starwood). All I can say is WOW. This is unprecedented, and simply started from hiring 2 Starwood employees.

    Ok, so what do you need to know about protecting your confidential and trade secret information (at least from the perspective of a company that could lose its key employees to a competitor).

    1) ‘Identify’ and ‘Mark’ Your Confidential and Trade Secret Information

  • 3 Things You Need in Your Open Source Policy!

    If you operate a software based business you are likely using some open source code in your software. There really is nothing wrong with that, as it is really common now (and probably a best practice). But what is your process to review and track this code, and the associated license terms? Well, here are 3 thoughts from a software licensing lawyer that may help.

    1) Written Policy. Think through (a) what situations makes sense for your company to use open source code (maybe with functionality that is not core to your offering), and (b) what type of licenses you will allow and won’t (maybe try to avoid GPL licenses if you distribute your code to your customers). For example, you may allow licenses which only require notice (i.e. attribution) that the code is distributed with yours. Oh yea, don’t forget to write this down in a policy and let all your developers know about it.

    See below for an example of attribution.

    Microsoft Open Source Policy - Aber Law Firm

    2) Tracking Process. Tracking where you use the open source code and the associated license terms is critical, and I suggest very easy to do (along the way at least). Your process could be as simple as a spreadsheet with the name of the open source code, listing of which of your products (and versions) it is included with, any requirements of that license, and a copy of the license agreement. This tracking process is super simple if you implement it along the way

  • FBI Hostage Negotiator And Software Customer Negotiations.

    What a FBI Hostage Negotiator Can Teach You About Software Customer Negotiations.

    I read a really interesting negotiations book, and thought about a few takeaways for every software or SAAS company in their customer negotiations (maybe even as a software negotiations best practice).

    Background: The book by Gary Noesner came out in September 2010 and is called Stalling for Time: My Life as an FBI Hostage Negotiator. It has all the kinds of things you would expect to find in a book written by the retired head of the FBI’s Crisis Negotiations Unit (here is a podcast on the book from NPR): stories about estranged husbands holding their wives hostage, the Branch Davidian shootout in Waco, the DC sniper incident, etc. etc. But what is really interesting, and I think useful, are some pearls of wisdom regarding dealing with irrational people and people under lots of emotional stress. So here are a few things you may be able to use in your next software or SAAS negotiations.

    1) Behavioral Change Stairway. I had never heard of this concept before, but it may be useful to you. This is how it works: a) you show interest, b) you respond emphatically (which leads to rapport), and c) only then do you attempt to influence. This makes sense, as during any negotiations with a customer, you need to show interest and listen to them, and then show them you understand their concerns and issues (you don’t have …

  • Software OEM Agreement

    Here are 3 things every software company can learn from SAP being sued under a software OEM agreement. Without going into the nitty gritty of the details of the case, here is a summary of the facts:

    • SAP distributed and sublicensed certain AMC Technology software embedded with a SAP product.
    • When the software OEM agreement expired, SAP tried to provide ‘specific instructions to its customers’ on how to use the AMC software with the new version of the SAP product, when the customers actually could not do this (the OEM agreement specifically stated that post termination SAP could only sublicense the AMC software with the ‘then current version of the SAP software’).
    • SAP tried to argue that its customers could use the AMC software with the new version of the SAP software, but the court correctly said no way.

    Ok, here is what you can get out of this case.

    1) You Can’t Grant More Rights Than You Have. This is a fundamental part of property law, and actually dates back hundreds of years to when people tried to grant more rights to buyers of real estate than what they (the seller) had (it is kind of common sense too). This is the first example I have seen where this legal concept was applied in the software OEM agreement world, so it is good to see that it is still true (at least in this context).  So remember, you can’t grant more rights than you have, and as

  • Forrester’s Software Licensee Bill of Rights.

    A Software Lawyer’s Take on Forrester’s Software Licensee Bill of Rights.

    As a software lawyer that represents software and SAAS companies, I thought my perspective on the Forrester Software Licensee Bill of Rights may be useful to you (this is something that may come up during your customer software negotiations). In case you missed it, this report actual came out in 2009, but you know, I missed it too.

    Forrester's Software Licensee Bill of Rights - Aber Law Firm

    Most of it I am ok with (see all the yellow highlights), but what I have highlighted in red I don’t (or don’t understand).

    (1) Choose Any Implementation Partner. While this sounds good on its face, there may be valid reasons why a software company does not want just anyone implementing their software (you know, training, expertise, know-how, confidentiality, competitive issues, etc.).
    (2) Pay for Actual Usage. While this sounds good too, I think software companies should be free to determine their pricing models (plus reporting on actual usage would be really complicated/hard). Remember, that if the license is more restrictive the price for the license should/will be lower.
    (3) Licensee Free to Share Modifications. As most software is not provided in source code this is not even an issue, but if it were, I can understand why a software vendor would not want this to happen (e.g. derivative works/extensions to their software could create other software products that the vendor would instead like to capitalize on . . . seems fair to me).
    (4) Freely Transfer Software (regardless