The truth of the matter is that the GPLv3 is a very restrictive license, in as much as it’s also a harbinger of freedom.  The GPL was written in a way to specifically retain the freedoms it grants through successive iterations of a particular product, or its add-ons.  This means that if you like a GPL product, develop a derivative work, a modification, a plug-in or any other type of add-on, the resulting work is also going to be covered by the GPL (you do not have a choice in this).

“You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License.” – Section 10 of the GPL

This means that unless the WordPress GPL (yes, they’re specific by product… you can ADD restrictions if you want… so no 2 GPL’d products are necessarily identically licensed – we’ll talk about this in a minute) allowed for a theme developer to restrict the distribution of a theme, a theme developer isn’t allowed to add that restriction on their own.  Your development on a GPL product inherits the license of the original product.

Inheritance is a powerful concept because it creates license congruity, ad infinitum, for all downstream works of the original code.  It would be extremely difficult to manage license compliance if WordPress had one license, but a plug-in had a different one.

But there’s apparently a wonderful new theme available for WordPress called Thesis.  Its developer sells two several different versions of the theme (selling under the GPL is fine).  The problem comes to light when you look at the options:

1. Personal:  one site only; footer link must remain intact; can’t re-sell theme or modifications
2. Developer:  can create multiple sites and must pay Thesis developer for each site deployed; can remove footer link; can’t re-sell theme or modifications

And these options are problematic because they violate the GPL v2 under which WordPress is licensed.  Specifically, Section 2, which states, in part:

“You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.”

and Section 6:

“Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients’ exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.”

(Note that v2 and v3 of the GPL are vastly different animals… and v2 was actually more in the realm of “free as in free beer” than v3, which touts freedom as “free as in free speech, not free beer”.)

So, in fact, the Thesis theme, as a WordPress derivative work, is bound to the GPLv2 license that WordPress is licensed under.  As such, even the sale of the theme is a problem, as are the one-site-only restrictions and the “can’t re-sell” restrictions.  Note: the footer link restriction is probably fine, as it could qualify as the attribution allowed under the GPL.  Additionally, it could be argued that the fee charged is for the “physical act of transferring a copy” as allowed by Section 1 of GPLv2, but even then, the remainder of the unauthorized restrictions are still problematic.

But who is going to do anything about this violation?  Who has the right to enforce the license?  WordPress?  The folks at b2 (WordPress’ predecessor)?  Any particular end user?  Technically, it’s the folks at WordPress who have the right to enforce their license upon theme and plug-in developers.  They have the ability to potentially even sue to prevent a rogue developer from violating their license with WordPress [though I'm guessing that a theme developer is going to try to argue that a theme isn't a derivative work or a modification].  But this is inherently difficult.  So instead, WordPress is taking a slightly different tack.  They’re going to create a Theme Page on the main WordPress website which only lists themes that follow the GPL (by the way, all derivatives have to be GPLv2 licensed, as the WordPress license doesn’t allow for newer versions of the GPL to apply).  I’m guessing that Thesis won’t be listed.

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.  Follow me on Twitter if you want up-to-the-minute information on contracting, licensing, negotiation and the law.

In his post, he blatently advocates buying “lesser” versions of Microsoft products to take advantages of the discounts available to certain classes of users, regardless of whether you actually fall into that user class.  His cavalier attitude towards the vendor (telling his readers that Microsoft probably doesn’t check up on usage) and the user (suggesting that users who pay the appropriate price for their user class are “suckers”) is abhorent and I’m frankly disappointed that the editors at Cnet allowed this garbage to see daylight.

I’ve responded twice in the comments (as “negot8or” if you care to read them… once on page 1 and again on page 2).  The general gist of my response is that if you don’t like the pricing for a particular product, don’t buy it.  Vote with your pocketbook.  Vendors who don’t sell enough software will either drop their price or drop out of the market.  But buying something you’re not licensed to use and using it anyways is a form of theft (“software piracy” if you will).  Software has historically been sold on the basis of end-user value.  It’s the right of the vendor to charge whatever they want.  Stealing, in any form, isn’t justified because there exists a cheaper price somewhere else – or for someone other than you.

As much as I advocate for better software licensing terms and more transparency from vendors, I do not believe in taking what isn’t yours.  I hope you agree.

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.  Follow me on Twitter if you want up-to-the-minute information on contracting, licensing, negotiation and the law.

When you buy a book, you’re actually completing two transactions.  You’re purchasing the paper – the tangible product.  But you’re also buying a copy of the story itself – the intellectual property.  Each of these has distinct legal implications and over the years, laws have been developed to help protect not only the customer/consumer, but also the author and publisher.  The physical aspect protecting the consumer is that you have the ability to change your mind about your purchase (ie: you can return the book assuming you don’t damage it and that the transaction wasn’t noted as “all sales final” (though this isn’t an absolute bar to return)).  Retailers are likewise allowed to return what is returned to them – they have even more flexible return policies with their distributors.  And, as we’ve seen in the prior articles, folks are in an uproar about the idea that a retailer would come to your house to automatically take-back things you’ve purchased simply because their distributors wanted them to do so.

The other transaction – the one for the intellectual property – is much more interesting (IMHO).

Copyright is the protection most books are afforded.  When you buy a book, you have the right to read the story, burn/destroy the book, talk about the story with anyone, and heck, you can even resell the book (this is all part of what is known as the “first sale doctrine”.  What you can’t do is make copies of the book.  If you sell it to someone else, you can’t keep a copy for yourself, too (this is the issue with software, music, movies, etc being “shared” online).  But short of sale, the ownership in the copy is yours.  Therefore, it’s my argument that Amazon.com’s behavior amounts to theft – both of the tangible item AND the intellectual property.

The usual problem with pursuing this claim is that a service provider is smart enough to make device owners agree to some form of Terms of Service.  I would’ve thought that the Kindle ToS would have even been so bold as to allow Amazon an unrestricted right to do what they did.  But it doesn’t (Amazon Kindle ToS as of 2/9/2009):

Use of Digital Content. Upon your payment of the applicable fees set by Amazon, Amazon grants you the non-exclusive right to keep a permanent copy of the applicable Digital Content and to view, use, and display such Digital Content an unlimited number of times, solely on the Device or as authorized by Amazon as part of the Service and solely for your personal, non-commercial use. Digital Content will be deemed licensed to you by Amazon under this Agreement unless otherwise expressly provided by Amazon. [Emphasis added.]

I have other problems with this document, of course (such as the restrictions on resale).  But on its surface, Amazon grants a perpetual license to the purchased content.  So through their behavior, following their own Terms of Service, they’re in breach.  But we won’t hear about any suits as the ToS restricts claims to confidential arbitration and limits damages to the price of the device.

For its part, Amazon says that “We are changing our systems so that in the future we will not remove books from customers’ devices in these circumstances.”

[Update:  Amazon's Herdener (the source of the above quote) actually said more:

These books were added to our catalog using our self-service platform by a third-party who did not have the rights to the books. When we were notified of this by the rights holder, we removed the illegal copies from our systems and from customers' devices, and refunded customers. We are changing our systems so that in the future we will not remove books from customers' devices in these circumstances.

This doesn't really change anything.  Even if an unauthorized party sells you something they don't own, so long as you don't know that the item wasn't theirs to sell, you retain ownership as a "bonafide purchaser."  I'm glad to see that Amazon won't remove books in the future, seeing that they weren't supposed to do it in the first place.]

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.  Follow me on Twitter if you want up-to-the-minute information on contracting, licensing, negotiation and the law.

And, even if you could, your organization probably doesn’t have tracking enough to make it possible – just remember that if you overuse your permitted license count, chances are there’s another provision in your license that allows the vendor to charge you (perhaps at non-discounted pricing) for the overage.

What I DO like about Ray’s suggestion is that idea that you should try to negotiate for a recapture of maintenance fees on unused licenses.  If you can’t resell them, the least you can do is take an annual count and only pay maintenance on the ones you’re using.  There is, of course, trouble with this thought, too – as there are some vendors that used to allow this (the last one I remember was Autodesk).  But the trouble is that you can get into a situation where you only upgrade SOME of your licenses to the current version because not all of them are currently covered by maintenance and the upgrades provided under such program.

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

Several services have popped up recently that are allowing content to move from one format to another – especially on Amazon-related products and platforms (ie: the Kindle).  More specifically, Amazon is now allowing blog authors to license content for packaging and distribution on the Kindle, with the blog author receiving about 30% of the revenue generated from the license price.  So, if I were to want this blog to be available as a Kindle subscription for say, $1.99, I would get $.31 for every subscription.  But there’s a problem, Amazon has a license agreement that I would have to accept in order to make this happen.  And this license agreement also gives Amazon the right to bundle and resell my content in other forms, too, without paying me for it at all.  [For a full conversation on this, see this great post by Edward Champion.]

Additionally, Amazon’s current system doesn’t actually even check to see if I’m the owner of the blog I’m submitting into the Kindle Blog service!  So I could create an account, submit any of your blogs as my own, and in just a few clicks, create Amazon entries for your blog’s content – even competing with the “real” listing (if you so happened to have agreed to the terms as well and started using the service).

So, for the record, while I love Amazon for a bunch of reasons, this blog is NOT being made available as a Kindle subscription.  It is, however, being posted ON Amazon as part of Amazon’s author services… so you can read the individual postings if you go to the Software Licensing Handbook page at Amazon.  But if you happen to see it on your Kindle device, you’re paying someone else for stolen content.

The current economic situation is encouraging many organizations to reconsider their current contractual relationships.  Contact me before your opponent does to find out how to make the most of your renegotiations.  The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

Of course, the original question wasn’t this simple.  The person asking the question had some interesting constraints.  Specifically, they were licensing software on an exclusive basis, with exclusivity carved out by geographic region.  So a prospective customer wanted to review the vendor’s contracts to make sure that they weren’t getting into an overlap situation.  My answer was still No!

First, contracts are, even at a fundamental level, based on trust and honesty, and not based on a lack thereof.  If you don’t trust the person you’re contracting with, the contract isn’t going to help you too much.  In other words, you can’t contract trust.  It just doesn’t work that way.  So if the vendor in this situation was going to be dishonest in overlapping exclusivities, what would make the customer think that they would allow the customer to actually audit all of the agreements?  A dishonest vendor would simply hide a portion of the contracts that they didn’t want discovered.

Second, with minor exception (such as during due diligence in a M&A transaction), I would never allow anyone to review my contract files.  There’s too much confidential information – and general poking around to see what’s in them isn’t a narrow enough reason to go looking.  In fact, even if the looking was just at license grant language, I still think you’re potentially revealing too much information (exclusivities for geographic regions aren’t the only way to restrict licenses and perhaps you also license based on user counts – allowing others to see the full license grant can give them a sense of pricing, perhaps).

Third, there’s a better way to handle the situation:  provide a warranty and a specific remedy for breach of this particular warranty.  Warrant that you are providing an exclusive license in exchange for specific consideration (probably money, but perhaps something else).  If you (vendor) breach this warranty, the sole and exclusive remedy could be the repayment of the specific amount of consideration provided for the exclusivity.  So, imagine a situation where you license exclusively by country (perhaps your product handles some sort of sales-related transactions).  In exchange for an exclusive license, the customer pays you an extra $1,000,000 in license fees and that this also adds into the annual maintenance costs.  If you later decide to break a previously-licensed country into smaller bits, you simply would have to pay back the $1M plus the accrued/paid maintenance fees for the breach.

Now, this sounds like it may provide you with license to later break the agreement – no, I’m not suggesting that, I am however suggesting that you promise not to and a specific penalty for doing so.

The current economic situation is encouraging many organizations to reconsider their current contractual relationships.  Contact me before your opponent does to find out how to make the most of your renegotiations.  The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

“For ten years, we’ve been driven by a simple vision: The End of Software.  Now it’s time to take on a new challenge: The End of Maintenance.

Let me tell you about a customer that I met on our Cloudforce tour. This customer currently uses Siebel software to run her call center.  She pays more than $15 million a year for the privilege of having to implement the updates that Siebel sends her.  That does not include backup. Or disaster recovery. And of course, it does not guarantee that she will be using the latest technology.  The maintenance agreement only assures her that her outdated software will continue to work.  She is paying tolls on a road to nowhere.

We can help her, and many other customers, and deliver much more for a fraction of what they currently pay in maintenance. It’s time to open up a new front in “The End of Software”– one that is long overdue.

It’s time for The End of Maintenance.

Every year, companies spend billions on maintenance fees and get relatively little in return. Maintenance fees cover updates that are mostly  patches and fixes, but they stop far short of the kind of innovation every that enterprise needs to survive.  Companies pay to keep the past working and they end up doubling down on technology that can never keep up with their needs.  The fees that companies pay have actually been rising, from something like 17% a few years ago to numbers more like 22% today. Every four or five years, companies are paying for their software all over again.

It’s time to set these businesses free and make them successful in the Sales Cloud,  Service Cloud and on our Force.com platform.

Our new mission begins at a critical time in the economy, when companies are questioning conventional wisdom as they never have before.  That, of course, extends to their IT budgets as well. The CIO is in a tough spot right now.  Corporate budgets are tightening.  And our rivals in the legacy client-server world are using this opportunities to extract more money from their customers by raising maintenance fees.  I call this phenomenon “the compression of IT” and it resonates with just about every CIO I speak with these days.

We have a better vision. We sell our customers a service and every customer is able to use the latest. Innovations are included. Upgrades are automatic and invisible. Customers’ intellectual property of customizations and extensions is rigorously preserved, and carried forward without disruption.

The service gets better, not just less buggy. That’s not what people are getting for all those fees that supposedly buy them “maintenance.”

It’s time to set these business people free: to give them the experience of being wildly successful in the Sales Cloud, the Service Cloud, and in their own unique applications that they can build on our Force.com platform. This is the time to do it, because this is when people need it: their IT budgets are tight, their business situations are critical, and their old-world software vendors are taking care of themselves instead of meeting the needs of their customers.

We’ve raised people’s expectations for better alignment of business value with IT cost. We’ve earned our leadership position in enterprise cloud computing. It’s time for us to set people free from paying more and more to get less and less. It’s time for The End of Maintenance.

Aloha,

Marc”

The current economic situation is encouraging many organizations to reconsider their current contractual relationships.  Contact me before your opponent does to find out how to make the most of your renegotiations.  The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

Of course, it’s never that simple.  Because your IT department usually also wants a development server for each database instance.  This makes sense – development should be done separately from production (you wouldn’t want some experiment in design to bring down your production server).  Oh, and what about testing?  This is the middle-of-the-road between development and production… where something that your developers believe is ready for production goes to receive significant QA attention.  That’s yet another set of databases.

So, now we’re talking about 15 licenses: 5 production + 5 QA/test + 5 development.  If 5 were expensive, imagine what 15 could become.

Database software developers understand this dilemma.  They know that if you’re really making use of their products, whatever you have in production has to be supported by nearly as many dev/test environments.  Back in the day, this was usually a pretty simple situation – you asked for, and usually received, “free” dev/test licenses.  I say “free” because they were never really free, they just didn’t separately price them.  You paid for them then, just as you pay for them now.  The difference is that the cost was built into the production licenses back then because the hardware wasn’t strong enough to support some of the tricks that can now be used to run multiple databases within a single hardware environment.  Once the hardware was strong enough (about 8 years ago), savvy licensees didn’t actually need 5+5+5 … they could find ways to do 5 + 3 + 2 or some other combination in something other than a 1:1 relationship.

The net result is that these same savvy licensees started asking for discounts on the initial 5 production licenses because they knew they were no longer needing the triple-play effort of that single license.  Instead, they argued, they only needed a few “extra” licenses (now really for free) because it was understood that to make use of the product, you needed these extra environments.  They just didn’t need them in the same quantities as before, so it had the appearance of being less of a freebie than before.

Software vendors reacted in the best way they could – through changes in language.  The phrase “internal busines purposes” became the expected response.  “Yes”, the vendors said, “you can have a few extra licenses – but only for internal business purposes.”  The meaning wasn’t always clear, of course, but the intent was to say that the licenses you purchased were the ones that could see the light of day (be used by regular users, etc), but that the extra licenses were only for back-room development and testing.  You were signing a license agreement confirming that you wouldn’t take these fully-functional licenses and put them into production.

No problem.

Until ASP/SaaS offerings came along.  Now you have databases that are serving data to the world 24/7/365.  Licensees still need dev/test environments… but these are now potentially available online, too.  And, in rare cases, serve as the backup production environment in the event that the usual production environment goes down.

Has this really created a problem?  No.  The case remains that licensees should have frank and honest conversations with their vendors about how they intend to use the products rather than try to sneak some form of unintended or unexplained use by the vendor.  If licensees want “free” licenses for dev/test, they should expect to see (and respect) “internal business purposes” language.  And they should discuss the possibility of needing to put a dev/test server into production in the event of a disaster.

Lastly, licensees should also remember that such licenses are never free.  Whether you have a line-item cost that shows you paying full-price, partial-price or no-price, the cost is still baked into the deal in some way.  However, one key advantage to calling out the pricing specifically for dev/test environments is the ability to get them excluded from maintenance costs – as there should be no need to pay for maintenance on a dev/test box needed to provide support for a production server.

The current economic situation is encouraging many organizations to reconsider their current contractual relationships.  Contact me before your opponent does to find out how to make the most of your renegotiations.  The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

Sunset Seedless grape package

and I’ve been thinking about the implications…  is it really possible to add this type of condition?  I think I agree with Madisonian’s evaluation of the situation, assuming that the grapes are patented.  But what if they’re not patented?  Can you restrict usage of a purchased good?  Thoughts would be appreciated. 

From boingboing.

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

Google apparently didn’t learn that they need to not necessarily borrow from themselves, either, for the EULA related to Google’s new browser, Chrome.

But the bigger issue in this new EULA from Google were the terms itself.  Specifically, the license for Google’s new browser states/d, in part, that Google will have “a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive license to reproduce, adapt, modify, translate, publish, publicly perform, publicly display and distribute” anything displayed through the browser.

Woah!

At least they’ve changed it.  But the fact that it got in there at all is problematic.

Google, for their part, blames it on a copy/paste error… that it was erroneously inserted to make it similar to their usual language, to “keep things simple for their users”.

Um… sure. 

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

In this case, and as supported by most of the commenters, I think Ken’s admitted lack of knowledge in the subject matter of licensing is hurting his assessment.  Software licensing folks don’t like wordy contracts any more than anyone else.  We’d love to get rid of unnecessary phrases or redundancies.

But I’ve actually seen a license terminated at the will of the vendor as a result of a lack of the word “irrevocable”.  And I’ve seen one restricted because of the lack of the word “world-wide”.  So for me, simple language gives way to extra descriptiveness in the license grant just from a risk management perspective.

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

Folks – just as I was talking about in the discussion on Invoicing, please watch your pocketbooks on this one.  The current cost of Microsoft Office Home & Student 2007 is $147.00 per Circuit City’s website (which is how you will be able to buy Equipt).  Microsoft releases a new version of Office approximately every 4 years.

Four years of Equipt = $69.99*4 = $279.96.

Oh, not to mention that Internet activation will be required.  Which means that they’re going to be keeping a much tighter grip on the leash this time.

Hmmm… 

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

I also believe that we’re going to eventually need an overhaul of our intellectual property system on a global scale.

Why, you ask? Simple.

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

My knee-jerk reaction is that this isn’t going to be good for the average (any) user – business or consumer.  But let’s play it out and see what happens:

In the current, perpetual model, the average cost of Microsoft Office 2007 is $119 (per Amazon.com).  This is a one-time expense and allows you to install Office on two machines (desktop and laptop) so long as you only use it on one machine at any given moment in time.  The average person never buys any kind of support for this product unless it’s a pay-per-incident issue that is SO complex that they can’t get help with it from friends or strangers via the internet.  But you do get all of the updates to the current version of the product (ie: if you’re on version 2004, you’d get all updates to 2004, but not get version 2007).

Because it’s a perpetual license, you can use this product FOR EVER, without ever having to pay another fee to Microsoft unless you want to upgrade to their latest version (which, at the time I’m writing this, happens about every 3 years per platform, alternating between PC and Macintosh).  From a depreciation perspective, if you were going to buy the latest and greatest version of the product every three years, you would divide the purchase price by 3 to find out your annual cost of ownership:  $39.67, which works out to $0.108/day.  Not too bad for the product that supports all of your e-mail, writing, spreadsheet and presentation tasks.

We don’t yet have pricing available for Microsoft’s new online offering, called Albany, but we do know that they’re going to bundle in a few already-available-for-free services.

We also know that Google already offers something quite similar (GoogleDocs) for free.  If you’re already a GoogleDocs user versus a Microsoft Office user, you have made a choice to go with one or the other for a reason (most would say that they choose Microsoft for “guaranteed compatibility” and “support if needed” … and Google users say that they want “openness”, “freedom” and “collaboration ability”).  I highly doubt that Microsoft is going to offer their product/service for free… but I’ve been wrong before.

However, this really isn’t about Microsoft versus Google – it’s about a bigger issue of whether a conversion from Perpetual Licensing to SaaS is really a benefit to either the vendor or the consumer.  Perpetual software users like not having to upgrade every time the vendor releases a “fix.”  They like knowing that they don’t have to keep paying for maintenance when the product hasn’t really changed much over time.  They like having a one-time depreciable expense (if they’re business users).  Oh, and they like knowing that if the vendor ever goes out of business, it doesn’t matter too much, since the software is installed locally.

SaaS offers a level of convenience not found with perpetual products.  You are always on the latest version, always covered by support and you have less of an administrative headache since the product isn’t installed locally.  Sure, you have to have greater bandwidth (I’m guessing Microsoft will actually have you download a full version of the product which will simply “phone home” every time you double-click on the product to use it).  But you give up the ability to sever your ties with the vendor yet continue using the product.

I like the SaaS model for some situations – I use one for my contract management system, for example.  But for everyday, standard use products?  Especially those in millions of homes world-wide?  I’m not sure we’re there yet.  I’m REALLY concerned about the quality of service – and the constant communication connection (from a privacy perspective) of all of these phone-home events.

What do you think?

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

http://techknowledgyblog.squarespace.com/techknowledgy-blog/2008/2/22/software-licensing-trends.html

It’s rare that an attorney in this space actually knows what he’s talking about – but Steve seems to know his stuff (ie: I agree with his position).

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering a licensing topic every week, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

“CUPERTINO, Calif., Sept. 24 /PRNewswire-FirstCall/ — Apple has discovered that many of the unauthorized iPhone unlocking programs available on the Internet cause irreparable damage to the iPhone’s software, which will likely result in the modified iPhone becoming permanently inoperable when a future Apple-supplied iPhone software update is installed. Apple plans to release the next iPhone software update, containing many new features including the iTunes Wi-Fi Music Store (www.itunes.com), later this week. Apple strongly discourages users from installing unauthorized unlocking programs on their iPhones. Users who make unauthorized modifications to the software on their iPhone violate their iPhone software license agreement and void their warranty. The permanent inability to use an iPhone due to installing unlocking software is not covered under the iPhone’s warranty.”

This was the perfect opportunity to go read Apple’s iPhone license. At seven pages in 7-point font, it was a treat. Apple has taken the license to a state of one-sided nirvana (though I must admit that Apple isn’t the only vendor to have found Valhalla on this).

First the good news. There is no specific license prohibition on unlocking software. If a third-party application can unlock the iPhone without violating the terms of what most competent folks would consider a standard one-sided agreement, you’re still in the clear.

Now the bad news. As with almost any license, there are specific restrictions about reverse engineering, decompiling or otherwise taking things apart to figure out how they work. Based on the various announcements from places like Gizmodo and Engadget, it appears that the people developing these cracks are having to do at least SOME deconstruction. They, then, are violating the terms of the agreement. But if the unlocking software itself doesn’t decompile the iPhone software (and the end-user doesn’t have reason to suspect that the creator of the unlocking tool violated the terms of the license – which, unfortunately, most of them do as a result of the heavy-duty detailed articles in Giz and Engadget, among others), use of the tool by an unknowing end-user would not necessarily be a violation of the agreement.

There is also nothing in the agreement that will prevent Apple from releasing a product update that will “brick” (kill) an iPhone with unlock software on it.

But, if there is an unlocking tool that is 100% software, was created and runs like any other third-party application, Apple’s iPhone updates could still brick the iPhone, but use of the software wouldn’t be a violation of the agreement… and restoring the iPhone to its original state would be a simple fix – one which Apple should do under warranty.

As usual, though, there is another wrinkle. The DMCA (Digital Millennium Copyright Act) prevents circumvention of any copy-protection devices implemented (for an extreme situation, consider the Zune – which, even for music that you created from scratch still wraps with a copy restrictive time-bomb that you can’t disable, and is thus illegal to remove for your own self-created music). If the iPhone uses such device(s), avoiding them is a violation of the DMCA in addition to any pure copyright issues that would already exist. And each USE of the tool to do so would be another violation.

Overall, I make no recommendation here, but merely suggest, as with all licenses, that you understand the licenses you’re under so that you know what you can and cannot do.

Woah. Wait a minute. Don’t you already HAVE the rights to turn your music that you’ve purchased into ringtones? Let’s break down copyright just a little bit and find out.

There are six exclusive rights granted to the creator of a work. These six (reproduction, creation of derivative works, distribution, public performance, public display and the right to perform via digital audio transmission) can be granted to a “buyer” independently of any other rights and in fact, can be parceled even within one specific right.

This is why, when you “buy” a CD, you can listen to the song anywhere you can take the CD – and you can rip the songs from the CD to your computer/MP3 player. But it’s also the reason why you have to remove the songs from you computer/MP3 player if you ever sell the CD. You have a license to the songs – you didn’t actually buy the songs themselves (hence why this is important to us in the software realm).

But the deeper meaning of what Jobs said, without elaborating, is that the license you get from a downloaded song on iTunes is actually a more limited license than was originally considered by most consumers. Namely, that there is NOT included in the license the ability to make a ringtone. I disagree.

The only way this would be possible is if one of two things were happening. First, if you actually received notice when you were downloading the song that there was a more restrictive license in place; or second, if the ringtone is somehow going to be considered as a derivative work. As I’ve downloaded a few songs from iTunes, and actually read all of the license language that came with iTunes, I haven’t yet seen anything that would restrict my usage of a downloaded song. In fact, iTunes itself has a restrictor built right in – knowing full well that people won’t remember differences in licenses for each song – so it limits your ability to create a CD with a certain playlist more than a specific number of times.

That leaves derivative works. And I’m just not sure that a 30 second clip from a song – which hasn’t otherwise been altered, really constitutes a derivative work. I’ve never heard of someone playing a ringtone (mine happens to be a-ha’s “Take on Me”) that’s anything other than a clip from the song. If the 30-second clip WAS a derivative work (ie: was altered by the consumer in a way that made it a derivative), it would be problematic regardless of whether it was a ringtone or not. But taking a chunk of a song and playing it on your phone isn’t a derivative work – you are not required to play an entire song every time you hit the play button, and you can play your existing CD, for example, in your house, car, boat or portable player. Thus, Steve’s comments the other day don’t reflect the derivative work option.

In all, that means that you CAN create a ringtone from any song that you’ve already lawfully purchased/licensed. Apple and iTunes are making the recoding industry happy to charge extra for something that isn’t required to pay extra for (at the moment). This also lead to two possible ends to this story, both of which affect us in the software world:

1. Apple is just getting away with what the consumer population will let them charge. The average consumer doesn’t know the law – nor do they realize that they don’t actually have to pay to make a ringtone. They’re paying for the feature in iTunes to make one more easily. In the software world, this happens all the time, with vendors selling products based on “value” to the customer. Fuzzy math at best.

2. Apple is introducing a new licensing model for music – more restrictive than anything you’ve been exposed to in the past – licensed per consumer’s use (as opposed to commercial use, which is already restricted in this way). As consumers, we will either have to manually manage these different licenses, or technology will come up to “help” – but “help” is a misnomer, as I don’t want help with losing rights I already had.

As before, the software world feels this already and it’s just getting worse. License metrics are getting more and more restrictive – it’s now quite common to find double, triple and sometimes even quadruple license metric restrictions. Be careful what you agree to – as you’re setting precedent for what the industry will do to everyone else.

Recently, I was engaged in the beginning of a deal that would end with the purchase of a large technology system. The evaluation was done via an almost picture-perfect RFx process, spearheaded by a business owner who knows the value of a corporate contracts group and for whom I hold great respect. As the selection process neared conclusion, the business got anxious. They “needed” to start work immediately to meet their internal deadlines and thus wanted to do a…

… wait for it …

… bu, bum, baaaah…

Letter of Intent!

I wanted to cry. Here we were, humming along beautifully, and they wanted to derail it with a Letter of Intent (LoI).

Now, if you’ve never heard of a LoI, it is to a contract what a golf cart is to a car. In other words, it might eventually get you to your destination, but without the protection afforded by an enclosed vehicle. LoI’s are one of the banes of a contract negotiator’s existence – a poor excuse for a contract and they are sometimes seen as the easy way out to get a deal done quickly.

In the particular example above, the business wanted to use it as a bridge to get work started while we negotiated the full agreement. Since LoIs take at least some time, there’s a choice to devote some effort to the LoI rather than review the full agreement. Granted, the full contract will require MORE time, but I don’t think it outweighs the risks of the average LoI.

When confronted with a request to review a LoI (and when you can’t negotiate with the business to just forge ahead with the full agreement), then remember to at least lock down the following things:

1. Term. Place a limit on how long this interim agreement is going to last. The shorter the term, the less the risk.

2. Fee/Rate. Clearly state the rate/fees and how they will be calculated. A fixed fee is always best (and even better if that fee is $0.00). If you really want to protect yourself, include a cap on the total amount of money that can be expensed under the LoI. Remember always that a one-week engagement isn’t equal to only 40 hours – 2 resources = 80 hours, 3 resources = 120 hours. Multiply against your listed hourly rate and you can see “small” agreement add up quickly. Oh, and don’t forget about capping expenses, too.

3. License. If you’re getting access to software without a full license – WATCH OUT. All of the standard license issues still apply (IP indemnification and virii for example). Also remember that if for any reason the full agreement doesn’t get signed, it’s most likely that your license will terminate.

4. Services. Clarify ownership for anything created as a result of services performed. What happens if the full agreement isn’t completed? Do you lose ownership? How about work that includes your confidential information?

5. Warranty. Depending on how long the LoI lasts, or how any deliverables are created and delivered, you may need/desire a warranty for those deliverables.

6. Indemnification. As mentioned above, and for deliverables/services, too, you will want to be indemnified in the event that the vendor uses something they don’t have the right to use in performing the work. You will also want a general indemnification if the vendor is going to be onsite at your facilities in the interim term.

7. Confidentiality. Hopefully you’ve already completed a Non-Disclosure or Confidentiality Agreement with any vendor that you’re willing to use a LoI with – but if not, include your standard confidentiality language.

8. Termination. As with any other license or services agreement, include standard termination for breach language. Make sure you also retain the ability to terminate the LoI at any time, for any reason. It’s probably reasonable that you will have to pay for services performed up to the moment of termination, but don’t forget to tie it to ownership over work completed and paid for.

9. Governing Law. Fairly self-explanatory, but don’t forget to cover governing law. And remove jurisdictional statements, just like always.

Oh, and to make matters even worse, each of the terms you negotiate in the LoI may change in the full agreement, as the risk you (or the vendor) are willing to tolerate in a short-term agreement may be drastically different than the risk you (or they) are willing to take in the long run. The usual saving grace in all of this is that the vendor probably doesn’t want the LoI either – work together to make it palatable.

Have you (or your sales team) ever gotten this call?

“Hi! I’m Jeff from the contract management group at yournextcustomer. I’m calling about the End User License Agreement (EULA) that your distributor would like us to agree to before purchasing your product. I just have a few issues with it and want to know where to send a redline.”

Do you know what is happening or about to happen? The call above is not fabricated, as it is a conversation I have personally started hundreds of times with a variety of software vendors over the last several years. The companies I’ve worked for believe they are large enough to not have to agree to a one-sided contract and I was hired for the express purpose of negotiating a more favorable license agreement with each of our vendors. Invariably, I start with the sales contact, get passed to management, and I usually end up with a contract more favorable to my company than it is to yours.

When I initiate the call, I am usually confident about two key things. The first is that you want our business. As a large buyer in a particular industry, you may want to leverage experience in that industry into more lucrative deals. I count on the fact that you realize that an initial purchase is almost never the final purchase, and that getting your foot in the door with a negotiated agreement is better than no deal at all. Secondly, and perhaps more importantly, I know that I can use that “want” of business to leverage you into using my template license agreement. Truthfully, neither of these two facts will probably change. You will still want your customer’s business and will still be willing to make concessions in order to reach that goal. The important next detail, then, is an awareness of the various options available when a customer refuses to agree to your EULA.

Initially, you have three possible options, depending on your comfort level and pre-planning: a) Offer the customer a negotiable Software License Agreement, b) Negotiate the terms of the EULA itself, or c) Use the customer’s template Software License Agreement. Obviously, if possible, you would want to use option (a) first. It’s probably longer than your EULA, but it also has probably been written in a way that would allow for some concessions to various terms and conditions.

Options (b) and (c), however, pose more difficult challenges. EULA’s are now distributed to the customer by one of two main conduits, either as a click-through agreement or as a PDF, sent prior to the sale or attached to the ordering document. As a negotiator, I prefer to use an electronic form of the agreement, so having a word-processing document format would be advisable. Using e-mail to send the document to your customer subtly tells the customer that you have a document from which you want to start and it opens the door for negotiation without agreeing to use the customer’s template.

Regardless of which document you end up negotiating, there are key license and other terms that you need to consider with respects to margin, liability and feasibility issues. In essence, you need to evaluate the language with an eye to profitability, exposure and whether you can actually live up to the agreement. Your answers to these issues, of course, are unique to your business, but the following sections are usually considered the most crucial to any software license and should be paid special attention.

License Grant
While the nature of software licensing versus sales is beyond the scope of this article, suffice it to say that you will be granting your customer a set of rights to your software. These rights can be as simple as the ability to use the product, and as complex as the ability to create and/or own derivative works from your product. Additional considerations such as backup copies, location-based restrictions and other options results in your need to clearly understand what you want to allow your customers to do with your product and what rights they will need to accomplish their purpose for licensing.

Warranty
In days of yore it was once common to see a one-year warranty. More common now, however, is a short-term warranty of anywhere from 30 to 90 days. The reduction in length is a function of the real purpose of a warranty, namely, to show to the customer that your product works as advertised. The complex nature of customer environments discourages software vendors from offering a longer term warranty, as the risk of issues increases the longer the product is installed. On the other hand, most customers believe a warranty to act in the form of an insurance plan – a way to guaranty that the product continues to work over a longer period.

Customers also have a tendency to believe that warranties are the free version of maintenance or support services. To their credit, this was a functionally accurate description until the late 1980s, when many software vendors started offering maintenance programs designed to provide long-term support and product updates. Once the two types of help (at the time of installation versus in the future) were delineated, customers were often confused by the software vendor’s attempt to separate these concepts in the contract.

Today it is imperative that a warranty describe those things that you guaranty will never happen, and those things that will be fixed at no charge (for some limited period of time). Amongst this list would be warranties that protect the customer against problems resulting from ownership issues, conformance to documentation, processing four-digit years and a warranty protecting the customer from the introduction of malicious code.

Indemnification
When a customer licenses software, one of the last things they want to have to worry about is a situation where the software vendor does not have the right to license or is not the owner of the product licensed. This scenario creates substantial financial liability that the customer believes they are paying the vendor to assume. As a result, the concept of indemnification is used by vendors to promise to customers that they will be receiving an unencumbered license (based on the license grant as discussed above). Indemnification obligations are most often a) limited to only cover the most recent version of a particular product, but b) offer unlimited financial protection to the customer (the cost of the product, attorney’s fees and any damages awarded to a true owner). An EULA may offer little or no indemnification, but the desire by a customer to include an indemnification section should not come as a surprise to a software vendor.

Confidentiality
Another common, but often overlooked provision is one detailing the confidential information of each party and the obligations the recipient of confidential information will have to the discloser. Confidentiality terms should almost always be mutual. Each side should have an identical obligation to the other side with respects to how they are going to treat information they receive. Software would be included within the definition of confidential information for the vendor, whereas specifications, drawings and other work product might be information special to the customer.

There are five standard exclusions from protection: 1) information already known by the recipient, 2) information later received from someone not under a confidentiality agreement, 3) information put into the public domain, 4) information you’re later told by the discloser is no longer confidential, and 5) information required to be disclosed by a court of law (so long as recipient gives the discloser reasonable notice that they’re being compelled to provide confidential information).

Term and Termination
Software license agreements are usually found to be either perpetual (license the software once and there are no additional license fees) or term-based (license the software for a set period of time and renew the license afterwards if still needed). A third variety, the so-called “subscription model”, is essentially a term-based license for a set number of years and the license includes maintenance, support and upgrades. There is a faction of attorneys and negotiators that are concerned about the perpetual model, and thus resort to a 99-year term license. This is not a subscription, but a way to license the software well beyond its useful life. When negotiating, watch for the conversion of a term-based license to a perpetual license and for the inclusion of maintenance, support and upgrades.

Termination is also a consideration, as most EULAs will have broad termination rights for the vendor. It is not uncommon to have almost identical termination capabilities for both parties and to limit termination for cause to the breach of a party’s obligations. Customers sometimes desire the ability to unilaterally terminate the agreement without cause (you can’t force a customer to use the product). Vendors can usually accept this provision with the caveat that the licensee and/or maintenance fees for the current term still be paid as due under the agreement.

Maintenance
Perpetual and term-based licenses are designed to allow continued use of a product over a long period of time. In the meantime, the software vendor continues to develop their product line as well as provide support for the current products. Customers are usually offered the ability to purchase maintenance as a way to obtain those newly-developed products without paying the entire licensing fee all over again, as well as to enable the vendor to offer help in the event of a problem. Confusion sometimes happens when maintenance and/or support are separated into their component parts or when service capabilities are redefined to mesh with the customer’s needs. Care must be taken to be sure that what is sold is actually able to be provided and that what is provided is going to satisfy the needs of the customer.

Converting an EULA into a fully-negotiated contract is not usually advised, as the level of risk involved in the transaction can increase proportionately to the changes in language. If you do not have a full Software License Agreement and you are selling a product for more than $15,000-$20,000 (either a single product or an average sale), it is advisable that you have one developed, as buyers of that quantity of product expect the ability to negotiate. As starting the negotiation process from your preferred language is one goal of the EULA, maintain that advantage by developing a negotiable license as well.

But vendors don’t just deposit software at even their most favorite customer’s facility without assurance that the software is going to have some sort of contractual fence protecting it from release, abuse or misuse. So the typical pattern for a customer to test software is a one-two contractual punch of a non-disclosure agreement (NDA) in addition to, or part of, an evaluation agreement.

We’ll talk NDA’s in the near future – today is about the eval.

Evaluation agreements (also called Demo Agreements) are used for GA software, not just software still in development or otherwise limited or restricted in some way. So invariably, the contract presented is a repurposed software license… which does, actually, have the right type of terms and conditions necessary to effect the temporary relationship desired.

The problem, however, is that temporary relationships have a tendency to become permanent simply by inattentiveness. And a contract that’s designed to be temporary has probably been given less review attention at the outset of the relationship. Which means that a long-term eval/demo agreement is essentially a possible perpetual license agreement. Combining the lesser review attention with the possibility of perpetuality, and you get a bad deal from the customer perspective.

The fix, of course, is diligence. Remember that each interaction between vendor and customer has the chance to last much longer than originally intended… the chance to apply to things never initially considered. And it is for this reason that many contract professionals have a negative visceral reaction to eval or demo agreements. The business people believe that it’s “just a demo”, and the contracts folks know that it can become so much more.

When reviewing an eval agreement, the most effective solution is to place a termination date in the agreement itself. This will cut short the demo/evaluation process (which the business folks must be aware of), but it will at least prevent the eval from becoming the more permanent software license for the purchased product. Of course, this doesn’t stop someone from amending the agreement to make it last longer, but at least there’s the chance that the someone will also at least ask the question of why there was termination for the eval in the first place.

If you have the time or wherewithal, evals should be reviewed in as much depth as any other normal software license agreement. This allows you the flexibility to slip into a longer term relationship without worry about the terms and conditions of the underlying agreement (and without additional review/negotiation time/expense). But it does require a more extensive up-front investment of time, which is often problematic for organizations that don’t have a lot of contract reviewing staff or are paying outside counsel for time to review agreements that might never lead to a purchase.

Oh, and by the way, NEVER accept any type of eval agreement without the same IP Indemnification clause you would get in any other software license. If you’re going to install the software at your organization, you need the same protections that you’d need from purchased software. Arguments from the vendor that the customer is not paying for the software and is thus not eligible for protection should not be paid any attention.

Whatever the solution that is right for you, just remember that the eval is just as binding as any other agreement… the term “eval” isn’t meant to describe the agreement.

I live in Raleigh, NC – home to RedHat Software. Most of you have heard of RedHat as a result of their linux offering. But more than that, almost everyone has heard of RedHat because they sell free software. Initially, this was absolutely dumbfounding, confusing even seasoned contract negotiators with the world’s first broad introduction to the concept of free software, also known as open source software.

[Let's clear something up just in case there are still any misunderstandings. "Free" software, is not actually free. The term "free" is meant to refer to access to the source code, not to financial costs. As a result, it's better to use the term "open source" when talking about this access.]

Open source software, then, is based on the idea that the source code would be provided along with the object code at no additional charge. In other words, you still end up BUYING the object code, but you get the source for free and a license to make changes (and distribute the source code per the constraints of the license if you make said changes).

But all of this open distribution leads to an absence of definitive liability. The result is that if you have licensed open source products for use in an enterprise environment, you can have problems with indemnification, warranty, and other “missing” traditional contract terms. So the trick is to understand the scope of the open source usage in your environment in conjunction with the license provided. This obviously can become a large issue.

Additionally, there are currently more then 50 “accepted” open source standard agreements. Each one is unique in some form or fashion – and thus each one provides at least a small difference in terms of the rights and obligations apportioned. The net effect is that each of these licenses has to be read very carefully. Any vendor looking to use open source software (and any customer looking to use a vendor who uses open source software) needs to read, re-read, and triple-re-read the license to understand the specifics of what is provided, what has to remain “open” in the future and what kinds of protections you have in the event of a problem. At the end of the day, then, what you have is a completely custom software license that has to be read with a fine-tooth comb. DO NOT TAKE THE USE OF OPEN SOURCE SOFTWARE IN VENDOR PRODUCTS LIGHTLY!!!

ICN offers a slew of conferences and presentations on a variety of contracting and negotiation topics. In June, the Technology Procurement Conference in Chicago will offer attendees the chance to deep-dive into technology contracting-related topics in a series of 3-hour sessions. It sounds like one of the topics for this conference is going to be on Open Source procurement. Check it out (especially since I’m going to be there as a presenter)!

[Note: the term "assignment" is used with respects to rights and the term "delegate" is used with respects to obligations. I will use the term "assign" or "assignment" through this post for both, but when drafting actual contract language, keep both terms in mind.]

Recall that assignment is the redirection of all or some contractual right(s). Template language in most agreements prevents unilateral assignment, usually requiring the permission of the non-acting party to complete the act. For services-type work, it’s fairly common for subcontractors to do bits and pieces of larger agreements… and prime contractors do have a tendency to disappear sometimes. But when you deal with software assignments, the game changes. A lot.

Assignments with respects to software manifest normally in ASP and SaaS relationships. As discussed in this blog before, a service provider relationship for software works by allowing the service provider to have some sort of right to host the software. In some cases, this is done with assignment language, allowing the licensee to grant a service provider the right to host the software on behalf of the licensee during the ASP relationship. With SaaS vendors, however, this right is part of the license itself, as the vendor is the service provider.

Assignments of all rights, however, get a bit more sticky. Software vendors price and license their products based on the perceived customer value that the software brings to that particular customer. The vendors, however, can’t know this value explicitly, so they guess and create a price they feel is reasonable and one that will be paid by the licensee. Again, as discussed previously, we’ve seen that licensing metrics are used as a way to calculate that value.

A customer who assigns all of their rights to another party can mess up this calculation, especially where site-based or enterprise-type licenses are involved. The problem can most easily be illustrated by imagining a licensee with 1000 employees in a single geographic location obtaining an “enterprise license” to a particular software product. They’re charged a fee, created by the vendor, based on the number of employees at the time of the initial license grant – and based on an estimate of how large the company will grow over time. This wasn’t usually a problem. Until companies began merging like wildfire.

Today, that same 1000 person company could be acquired by a 10,000 person company. If the assignment language isn’t written appropriately with this in mind, the software vendor may have unwittingly granted an enterprise license that is now for 11,000 people rather than 1,000. As a result, language in software licensing is now adjusted by software vendors to remove the ability to assign (and fewer enterprise licensing schemes are used, too).

But customers do sometimes need the relatively-automatic ability to assign a contract as a result of a merger, acquisition or other transfer of ownership of the organization. Most contract boilerplate language allows for this. Software vendors who are granting site or enterprise licenses, however, should continue to remember that this could lead to the example situation above. Therefore, take the time to perhaps create a “carve-out” whereby an assignment due to this type of transfer would convert the license to a set number of users… or to a very specific geographic location. This still allows for the assignment, but doesn’t open the software usage floodgates.

Software vendors decide how to license their products based on the estimated value the product will have to the licensee. For mainframe products specifically, and a few others as well, CPU-based licensing has been an easy way to calculate that value. The speed/type of the processor determines the quantity of processing power, thus the amount of processing cycles that can be utilized by the licensed software. So software vendors licensed the product based on the number of CPUs the licensee would want to use to power the software.

This was actually quite an easy metric to choose, both for the vendor and the customer. Easy to track/count by both groups, CPU-based licensing is not affected by fluctuations in users, helping the customer. On the flip-side, vendors could very easily manage a relatively small number of CPUs (usually monitored by CPU serial number), too.

The problem with CPU-based licensing, however, is that until recently, neither vendors NOR customers anticipated multiple processors or cores on a single chip. So once introduced, vendors predictably argued that each processor/core counted as an individual CPU, and customer obviously argued that a single CHIP was an individual CPU. This fundamental difference is a clear example of how contract definitions can prevent problems, as virtually no software license contained an adequate definition to resolve the definitional dispute.

To compound issues, consider the fact that many of these licenses are perpetual with annual maintenance contracts. If there is a lack of clarity with respects to the definition of a CPU, not only do the parties not have a way to know how many copies of the product are authorized to be used, but it also makes the computation of maintenance dollars unclear, too.

It is now imperative that CPU-based software licenses contain a clear and obvious definition with respects to what constitutes a CPU. Oh, and did I mention virtualization? What do your licenses say?