July 2010

Monthly Archives

  • Reverse Engineering Software

    Reverse Engineering Software for Interoperability – LAW UPDATE July 2010

    This is a hot issue, so whether you have a software EULA or SAAS contract protecting your software, you may want to learn more about reverse engineering and its legality (i.e. looking under the hood). In essence, most software and SAAS contracts specifically state that the user is prohibited from reverse engineering the software; by the way, this is something that should be addressed in the contract as copyright law does not provide this type of protection. There have historically been no real exceptions to the contractual prohibition on reverse engineering, but in the past decade or so there has been some changes or erosion to this protection (depending on your perspective).

    1) Law Update July 2010 (iPhone Reverse Engineering for Interoperability):  Actually the Library of Congress added some new exemptions (on July 26, 2010) to the Digital Millennium Copyright Act, which originally provided that it was illegal to circumvent technological measures that effectively controlled access to a work (even if you were reverse engineering to make your product work with theirs).

    • The exemptions are (I am paraphrasing here) (a) getting around access controls to enable an owner of a smart-phone to access software apps on the smart-phone that were independently created (i.e. apps not in the Apple app store), and (b) getting around access controls to enable an owner of a smart-phone to access another network (i.e. using an iPhone with another carrier). [US Copyright
  • Collecting Sales Tax on Software

    3 PRACTICAL Things to Remember About Collecting Sales Tax on Software

    Ok this is a complex issue, but let me see if I can put together a few practical things to remember (at least from the perspective of a software attorney).

    1) This is a State Law Issue. You really have to look at the rules on a state-by-state basis.

    • Some states don’t tax software and others do (example, NY);
    • Some states only tax off-the-shelf software but not custom software (example, WI); and
    • Some states tax the software if you send a CD/media but not if it is downloaded from the Internet (example, CA).

    Takeaway: Figure out where your customers are, and then look at that state’s sales and use tax law. I wish there was a website with a chart of which states require you to collect sales tax for software license sales, but I have not found it yet… if it even exists.

    2) Don’t Kick the Can Down the Road. I have seen too many software companies say I will deal with this down the road, but then find out it is really difficult and expensive to fix later. Think about it this way, you are supposed to collect and remit the sales tax to the state taxing authority, but if you don’t you are still liable for the sales tax. It is really difficult and kinda of embarrassing, to call up your customer after the …

  • Installed (not used) or Purchased Licenses

    Installed (not used) or Purchased Licenses. Which One Does a Customer Owe You $ For?

    While most customers may say they only want to pay for software eula licenses they use (not all installed), a recent reported case involving the Los Angeles County Sheriff’s Office says they need to pay for what is installed (even if they are never used). Without going into a lot of detail, the court ruled that LA County Sheriff’s Office must pay the software vendor for the licenses installed (in the amount of $210,000), even if they were not used. Plus, the court awarded the software vendor more than twice the damages award in attorney’s fees and costs (nearly $560,000).

    QSo what is the right way to use a case like this?

    A: This is a great case to educate your customers about, if they are installing a lot of your software and saying they don’t have to pay for those copies as they are not being used. I am not saying hit them over the head with this case or rub their noses in it, but educating them on your perspective is a huge part of software negotiations.

    The goal here is not to go to court, but to me if a customer’s license ends, then the customer should return or destroy all copies of the software (just as the license agreement states). In addition, well run IT departments should not leave  unlicensed copies of software on computers …

  • Is Your Agreement a Plain English SaaS Agreement?

    Ok as a software attorney, what I am asking are your agreements simple or complex (hey, maybe even a plain English SaaS Agreement)? Have you thought about it? I find that most companies don’t really think about these kind of issues (or at least if they do, it is on the bottom of their list). Let me see if I can add this to your to do list, or help move it up the list.

    Step 1: SaaS Agreement. Your SaaS agreement should be super simple. What I mean is, your agreement should be vetted internally to make sure it is (a) written in plain English (get the legal jargon out), (b)  only includes the necessary clauses (talk to your attorney about this, as too often there are clauses in there you may not need or actualy want), and (c) as short as possible. If you have not taken this on, then do it. You will find that it is well worth the effort.

    Step 2: Negotiating Process. How are your sales teams handling the negotiation of your SaaS agreements? Have they thought through the legal and business issues (are they trained on how to respond to questions from end users and channel partners)? If the answer is yes, then great, you are probably getting your deals closed in a reasonable amount of time and building trust with your end users and partners, but if not then you have some work to do. Have your teams read ‘Getting