Tel 800.661.2530 |
Third Party Demo and Test Licensing: What You Need to Know!
Ok, let me see if I can explain this issue a little better.
- Can you use third party software (for example, Microsoft's SQL Server) in your partner's demo lab for testing your software?
- Can you go onsite to a prospect and use/leave SQL Server in a demonstration environment for 3 weeks, so they can test your software?
While you may not run into this issue every day, this is becoming a much more common licensing issue. The Lady Licensing Blog did a great job of addressing this, so I thought I would give her some recognition for the post and of course, add some of my own thoughts on the subject.
So here goes.
1) Check your License Agreement. While I am sure you had thought of this, I wanted to remind you, as this is where the rubber meets the road. It is ok to look at an FAQ or other online guide, but you should make sure that the actual license agreement specifically allows you to perform the specific demo and test activities (especially offsite). The Lady Licensing Post addressed this issues in her post (with a useful chart AND the license wording).
2) An Internal Use License is Not Enough. The key here is you need the specific right to use the third party software offsite, and specifically for "End User Testing," "End User Demonstration," etc. This specific wording is addressed in her blog, but I thought I would reproduce it here as it is super important.
3) Follow the Rules and You Should Be In the Clear.
So using the language/example above, you can use the software for:
(a) Internal Testing and Demonstration. Really not big give by the vendor, but nice to have it clearly described.
(b) Demonstration Purposes where you Retain "Control and Possession." This is great, as it means you can take the software offsite, but you have to retain control and possession.
(c) Trial for End Users. If these 3 conditions are met (i) 120 day limit, (ii) removal after 120 days, and (iii) have an agreement with the end user.
So long story short, these are the kinds of things you should think about, when you need to use third party software for demonstration or testing purposes (especially offsite). Read your vendor's agreement and dissect it as outlined above, as the keys to your rights should be in langauge like this. Oh yea, talking to a software attorney is probably a good idea too (but you knew that already).
Resource:
Microsft (Partner) Licensing Benefits FAQ
Disclaimer: This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.
3 Things You Need to Know About Exclusive Software Licensing
It is not often that there is a reported case specifically addressing exclusive software licensing, so I thought I would share 3 takeaways from this 2011 case (HyperQuest vs N'Site Solutions).
I will definitely not bore you with the long and detailled facts in this case, so let's get to it.
Key Takeways:
1) If you want copyright law to protect you, then use copyright wording in your exclusive license grant.
- Ok that was a mouthful, so let me explain. There are generally 6 exclusive rights a copyright owner has (ie. reproduce, distribute, create derivative works, publicly display and perform, etc.) and these rights need to be used or refered to in the license grant, to seek protection under the copright act.
2) If too many rights are retained, then you may not receive an exclusive software license.
- This actually happended in this case, as the court decided that too many rights were retained by the grantor for an exclusive license to be granted. This makes a lot of sense, as if a party says I grant you an exclusive license but then retains rights that are inconsistent with exclusivity, then the exclusive license should not work.
3) Typically exclusive licenses are granted for certain territories, fields of use, or media.
- Yes, typically exclusive rights are granted for certain territories (example, US only), fields of use (example, for only the insurance industry), or media (example, print) so think of drafting them this way.
So next time you are working on an exclusive software license, you may want to review this case, as how the exclusive license grant is drafted really matters.
Reference:
Disclaimer: This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.
Restrictions in License Agreements: Do They Really Work?
As you know, software license agreements contain restrictions (i.e. things you cannot do with the software). Some of them are pretty common (e.g. don't reverse engineer or decompile the software or don't let a third-party use the software) but others are pretty unique. Two very recent big name court cases demonstrate that even the unique restrictions are usually enforceable; let's take a quick look.
Case #1: In this case Blizzard Entertainment (the folks that make World of Worldcraft) license agreement has a very unique restriction (see below).
Without taking you through the whole boring details of the case, the court essentially said that this restriction was enforceable and MDY (the company that made a 'bot' that allowed users to advance without actually playing the game) breached the license agreement. Oh yea, MDY also made around $3.5 million from selling the software that performed this task. So not only did MDY make software that violated this restriction, they also profited from it in a pretty big way. Court really don't like this.
Case #2: NEON Enterprises sued IBM regarding certain restrictions in the IBM license agreement (actually NEON was alleging that these restrictions did not exist). NEON made software that allowed IBM customers to move their workloads around more freely, and was making $ this way. IBM disagreed and said that their customers are restricted from doing this. It seems pretty clear to me that IBM stated in its license agreement that the IBM customer can only use certain workloads on certain processors. It appears that this was enforceable, as at the end of the lawsuit NEON agreed to a permanent injunction withdrawing its software from the market and actually giving the source code to IBM.
Here is some wording from the court order in the case.
License Restriction Takeways
- If you are licensing your software and there are unique restrictions you need to protect your software, then think about adding those restrictions to your software license agreement.
- Be careful with restrictions or capacity limitations in software you license, as courts sure seem to be enforcing them.
Can a Third-Party Access or Use Your Software?
This question may come from time to time as part of your SAAS contact or software EULA review or negotiations, so as a software lawyer I thought I would address it. Here goes.
If you have a software product or a SAAS service you should think about whether third-parties (you know people like in the picture to the left) you don’t have a contract with can use or access your software, or is it only accessible by your customer (and their employees of course).
A recently reported court case addressed this issue, so I thought I would share the result and provide some takeaways. Without going into the details of the case –which I know you really would like to skip–the court held that when the customer granted use to a third-party they violated the license agreement. Oh and by the way, the third-party was even using the software for the benefit of the customer, and the court even said no way.
So what can a software or SAAS company learn from this case?
1) Depends on the Your Value Prop. Some software or SAAS companies really care whether a third-party uses or accesses their technology, and others really don’t.
- For example, if you measure usage on say the # of transactions, maybe you don’t care if a third-party accesses your software (for the benefit of your customer) as they will use more transactions under your customer’s account, but if you are concerned that if a customer (or the third party) may receive significant value which you have not taken into account when pricing your technology, then maybe you do care about that third-party access and use. So figure it out and tell your customers/spell it out in your software EULA or SAAS contract as these are the kind of things they need to know.
2) How Do You Do It. If you plan to allow third-parties to access or use your technology, then state that specifically in your agreement. As these third-parties by their nature do not have a contract with you regarding the use of the software, you could (a) allow that access and use and make your customer responsible for their actions (and omissions) or (b) require that the third-party sign some kind of Use and Access Agreement with you and your customer (yes, a three party agreement…they do exist). If you plan to not allow this access or use, then most agreements do not address the issue of allowing this access (they often state that the software or SAAS company reserves all rights not expressly granted…and this right is not a right expressly granted). You could even go further and specifically prohibit it (maybe in the confidentiality section or somewhere else). By the way, you can even split ‘Access’ and ‘Use’ rights, so you may allow a third-party to ‘Access’ (i.e. view only) your software but not ‘Use’ it. In fact in this particular case (the one mentioned above) ‘Access’ was ok, but ‘Use’ was not.
Just a few thoughts when drafting your saas contract or software EULA, as you should figure this out before your customer has to (or does). Take a read of your software EULAR or SAAS agreement and see what is says about this!
Legal Disclaimer: This is for informational and educational purposes only, and does not constitute legal advice. Contact your attorney for legal advice, which should be provided after review of the facts and applicable law.
What Does a Software/SAAS Company Need to Know About the Creative Commons License Program?
Any software or SAAS executive should learn about this, even if this does not affect their software EULA or SAAS contract. This is just one of those things to be aware of, because it is a big deal in the licensing of copyrighted material. So what do you need to know about this?
- What is the Creative Commons License Program. It is a new way to license copyrighted material, as essentially there is so much confusion out there regarding what people can and cannot do with content, images, music, etc (especially on the Internet). The fundamental idea is to try to find a more efficient way (trying to take out the intermediaries) to allow people to use copyrighted material through the use of icons/badges, a legal license and embedded code, and to move away from the concept of 'All Rights Reserved' to 'Some Rights Reserved.' More info here.
- How Does it Work? The creative commons is a non-profit organization that promotes the use of their free tools to allow people to license their copyrighted material in a much easier way (but it does not work for everything and every scenario).
- What Do I Need to Know About This?
- First, the Creative Commons License Program should NOT be used to license software (they actually say this, so don't take my word for it (see about 1/3 down this page)).
- Second, I also suggest you do not use it for your documentation, even though they suggest it. I think documentation should be kept proprietary and licensed just like the software.
- Third, so what can you use it for? Maybe your blog or marketing material (maybe viral type marketing material).
There is a lot more to learn about this program (remember this is just a blog) and its relation to copyright law, but I really do think it is a great program. Talk to your copyright attorney first though!
Resource: Here is one of their great short videos to explain the CC program and their reason for existence: Video.
Some more copyright related blog posts.
Everything a Software or SAAS Company Needs to Know About Copyrights.
Disclaimer: This is for informational and educational purposes, and no legal advice is provided. Consult your attorney for legal advice.
Contract or Policy? Which One Does a Software Company Need and When!
While this is a complex issue (like many legal issues), from the perspective of a software and SAAS attorney, I think there are some practical tips to remember when thinking about when to use policies and when to use contracts.
FIRST, THE DEFINITIONS. Policies are generally defined as a set of basic principles and guidelines, formulated and enforced by the governing body of an organization, to direct and limit its actions in pursuit of long term goals (i.e. soft commitments). Contracts are generally defined as a voluntary, deliberate, and legally enforceable (binding) agreement between two or more parties (i.e. hard commitments).
SECOND, 3 TIPS TO REMEMBER!
1) When to Use a Policy. Policies communicate how you plan to operate your business (whether internally or externally), and you can generally change them at any time. However, if you change them you need to think about if you need to notify/inform the groups impacted by the policy change (not necessary their approval for the change, but simply notifying them of the change). Also, remember that courts generally look at written policies as a form of a commitment, and don't like it when a company violates its policies.
Examples: Internal (HR, IT, and Sales Compensation Policies) and External (Support and Privacy Policies). I recommend that you notify all the impacted customers, employees, etc. if possible of material changes to those policies. It is pretty hard to notify everyone that has read your Privacy Policy, but you could notify your customers who bought something online from you if you make a significant change to your Privacy Policy. For example, Facebook and eBay often notify their members when they make significant changes to their Privacy Policy (they are consumer facing companies though, and they both have online ways of notifying you (i.e. not sending you a direct email)).
General Drafting Tips. a) Changes should be prospective, and not retroactive. b) Draft for reality, and not to look good.
2) When to Use a Contract. Contracts are a stronger form of commitment, and one party cannot generally change the contract without the consent of the other party. Use contracts for harder commitments, for protection from claims (if things were to go wrong) and to protect your assets.
Examples: SAAS agreement, EULA, Reseller Agreement, signed Quota Letter with a sales rep.
General Drafting Tips. a) Contracts should be clear and concise, and written in plain English. b) Make sure you fully understand them, as your company is making a legal commitment that cannot be changed (except with the other party's permission). c) Shorter is better than longer.
3) When Policies and Contracts are Interlinked. While this can get very messy, the rules above stay the same unless you say otherwise in the contract. In other words, you can still change the policy without the other side's permission, but you will need their permission to change the contract.
Examples:
a) You may want to link your Support Policies to your EULA template--which I recommend by the way. The way this should work is the EULA cannot be changed without the permission of the other party, but the Support Policies could. I think this has become a best practice for SAAS, Software and IT companies, and is a great way of using hard commitments (contracts) and soft commitments (policies).
b) You may want to link your Sales Compensation Policy to your written Quota Letter–which is another structure I generally recommend. The way this should work is the Quota Letter cannot be changed without the permission of the sales rep (i.e. the commission percentage) but the Sales Compensation Policies could. I also think this has become a best practice, but remember that it is generally a good idea to notify your sales reps of any significant changes to your Sales Compensation Policy in advance, and try not to make changes retroactively (there are legal and morale issues at play here). This is an area you should definitely talk to an attorney about, before making any changes.
General Drafting Tips: a) Describe in your contract that the policy may change from time-to-time. b) You may want to state–in your contract– that your policies will not materially degrade (example, your Support Policy may be changed but it will not materially degrade).
This may have been a little more detail than you thought you would be getting into, but hopefully you have gotten a taste of the issues from a the perspective of a software, SAAS or IT company.Think through this list when deciding if you need a contract or a policy.
Legal Disclaimer. This is for information and educational purposes only, and does not constitute legal advice. Talk to an attorney regarding these issues.
Can You Change Your Software Contracts Unilaterally?
As a software copyright attorney, I was wondering if you read all the electronic contracts you enter into (yea right). But just in case you had, you may have noticed one sentence in certain contracts that states that one party (always the party that wrote the electronic contract) can change the software contract “…at any time, in its discretion….”
- You probably have heard about this particular case, as Blockbuster was supposedly transferring movie rental information to Facebook accounts, without the express advance permission of the Blockbuster account holder (in essence people had automatically opted into this program, called “Beacon”). This program was widely reported and Blockbuster was subsequently sued.
- Blockbuster claimed that the case could not be brought in court as it had to be resolved through arbitration as provided in the Blockbuster ‘Terms and Conditions.’ However, the court ruled that as Blockbuster included language in the contract stating that any contractual term could be changed–at any time, in its discretion–the arbitration clause was therefore not enforceable.
- If you really think about it, a contract is supposed to be a fixed agreement between two parties, and neither party can change it without the permission/consent of the other party.
Just a suggestion for any Software or SAAS based company, which of course is relying on its end user/customer contracts to be enforceable.
By the way, keep in mind that policies can generally be changed without permission, but this case was about contracts not policies.
Disclaimer: This is for informational and education purposes only, and is not legal advice.
CONNECT WITH ME
