To my non-US readers…

In the course of my career, I’ve only really done a handfull of deals where the vendor was based outside the US. In those situations, the vendor was generally willing to use language that I was offering. But I know that this isn’t always the case.

I have been watching my analytics pretty closely over the last few months and have noticed a significant increase in my non-US readership. So, this off-Tuesday post is a request to anyone and everyone who lives anywhere other than the US to let me know about licensing and contract issues that are happening in your corner of the world that may be unique to your area.

I would really like to start an international conversation on these topics, as I’m not sure anyone is covering these issues from that perspective (whether you have specific intra-country issues or if you have trouble when doing licensing between companies in different countries). All you have to do is talk to me (each other) and we’ll all be better off! It’s as easy as clicking the comment button below.

Two-Top Tuesday

Thanks to Apple’s press release yesterday regarding iPhone unlocking tools and the iPhone’s warranty and license agreements, you get a special second-post (I’m also still feeling guilty about last week).

“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.

May the Force be with you

While sometimes found in a license agreement, force majeure language is usually only appropriate for the provision of services or maintenance, as a force majeure event is considered to be delay caused as a result of something outside the control of either party. This would not usually impact a license itself, as delay of use of the license cannot normally be the fault of the provider, except where there is a problem with delivery or installation services.

Force majeure events should be listed items that are also known as “Acts of God” but should not include delay as a result of preventable problems or events that have no true impact on the provision of the Services. For example, many force majeure clauses contain “earthquakes” (and now in 2007, “wars, riots and terrorism”) as listed events. This is only appropriate if the event is happening in the same geographic location as either the provider or the licensee and is where services are being performed or received. Otherwise, a war in a far-off country could be used to claim force majeure.

Some providers are also now attempting to list events that fall cleanly outside of the traditional view of force majeure. My favorite, perhaps, is “labor disputes and strikes.” Again, remember that force majeure is an event outside the control of the provider. While a provider doesn’t usually go on strike themselves, their ability to manage their workforce is within their control.

Additionally, the delay should only exist as long as the force majeure event predicating the delay. Some providers like to remain vague on when work will resume after a force majeure event. A general rule of thumb is that normal activity should resume when the event is over, as further delay will only be a detriment to the customer.

Lastly, some providers prefer to exclude customer’s payment obligations from receiving the benefit of force majure events. Customers should generally push back to keep the benefit of these events mutual, so long as the event is actually causing an impact upon both parties.

Are there items in a force majeure clause that strike you as interesting, funny or odd? Let us know in the comments!

About last night

Oops. A week slipped by and I hardly noticed. I’ve been totally engrossed with installing a new contract management system. I forgot the billions of decisions that have to be made… and forgot how hard it was to make changes after you started entering data.

But the benefits significantly outweigh the negatives. I simply can hardly wait for the first “event” to get e-mailed to one of my business owners telling them that a contract is up for renewal. They’ll ignore it, of course, but my first line of defense was at least present.

In the event that you’re in the market for a system, though, make sure you find one that’s appropriate for your size… and budget… and contract load. There are dozens of them out there – ranging in price from a few thousand to a few hundred thousand dollars. It’s easy, especially if you’re a contracts geek like me to get all googly about the various choices available. And Ken Adams has even gone so far as to start interviewing contract management system vendor employees to get a feel for the differences.

As the Knight Templar said to Indiana Jones “Choose wisely.” Granted, it won’t save your father, but it might save your sanity.

Copyright, the iPhone and You

The new iPods were released on Wednesday, along with a drop in the price of the iPhone – and Steve Jobs then announced a little tweak to allow an individual to “buy” a song solely for the creation of a custom ringtone. He was excited that you’d pay $.99 for the song and then $.99 to allow it to become a ringtone – still less expensive than most “premium ringtone” services. But during his presentation, he let loose a little slip that I haven’t heard mentioned on anyone else’s blog or on any news outlet. He said that the extra $.99 was for the rights to make the song into a ringtone.

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.

Source Code Escrow Demystified

When purchasing a million dollar software product with a quarter-million dollar implementation and 18% annual maintenance fee, it’s probably reasonable to guess that the buyer expects to keep the product around for a little while. The fear is that the vendor, however well intentioned, won’t be able to survive in this interesting world of mergers, acquisitions and bankruptcies. So the buyer asks for a little insurance policy known as “source code escrow.”

For those of you who don’t already know, software is developed in a 2-step method. What you install on your computer (the executable) is actually the result of the second step, the object code. It’s machine readable only. The developers code in a human-readable version known as “source code” and go through a process called “compiling” to convert the source into object.

In the event that a future developer would want to modify an application, then, they need the source code to do so. There are some specialized tools (known as decompiliers) to help in the event that you don’t have the source code, but generally speaking, having access to all of the original source files is the easier way to go. And in fact, most license agreements expressly prohibit reverse engineering or decompiling.

But the source code is really the crown jewel of the software company. Giving it to everyone and anyone who asks isn’t a good idea. Recognizing the fear discussed earlier, though, the vendors are sometimes willing to place their code into escrow. Source Code Escrow is a service offered by a variety of organizations (such as GuardIT, Iron Mountain and others), called escrow agents. The vendor can “deposit” copies of the source code and then have an agreement with the Escrow Agent to only release the Source Code to specific recipients in the event of a “Release Condition.”

In theory, if the vendor were to suffer a Release Condition (usually something catastrophic to the vendor’s health, such as bankruptcy), the buyer could send a notice to the Escrow Agent that such a Release Condition has happened. The Escrow Agent, through a contractually-detailed process, confirms the condition and then would release the source code to the buyer.

Through contractual restrictions between the buyer and the vendor, the buyer is normally then allowed to use the source code to maintain their copy of the software. This doesn’t allow the buyer to sell or otherwise divest themselves of the source code – it merely offers the buyer a way to continue to help themselves in the event of a problem with the executable. In some rare cases, the buyer might also have the ability to create derivatives of the source code – new versions of the product, so to speak, but again, this is almost always limited to the buyer’s own use and not for resale to others.

Practically, though, source code escrow is a bit more tricky. First is the source code escrow agreement and the various things that have to be properly defined, such as the Release Conditions and the process by which the Escrow Agent would release the code in the event of one of these conditions. Buyers always want to play a bit more fast and loose than the vendor (for obvious reasons). But for the most part, these issues are resolved in favor of the vendor.

Second, the Escrow Agent doesn’t provide escrow services for free. Some vendors will offer to pay for the service, but most require the buyer to pay the annual costs involved. These are usually relatively nominal – $1500/year or so. But some Escrow Agents charge a small fortune. This cost may be easily forgotten when budgeting – or may be overlooked in later years and the service then lapses.

Third, the quality of the code placed into escrow is important. Most good escrow agreements have stated periods upon which the vendor is supposed to update the code or re-deposit new code. This could be on an annual basis (which is usually fine for software that’s not updated frequently or is less expensive) – but the buyer’s perspective says that they always want the source code equivalent of the most recent released commercially-available product. So there are times where the vendor will have to pay for multiple deposits and will want the buyer to share in that cost. Remember, though, that HUNDREDS (or thousands) of buyers may be beneficiaries of an Escrow Agreement – so buyers generally shouldn’t have to pay for deposits (as one deposit can satisfy all buyers).

Perhaps most important in the escrow discussion, however, is the ability of the buyer to actually make use of what they’ve received in the event of a release. Unless you, as a buyer, have an IT staff that’s educated on the programming language used to write the code in the first place – and have the tools to debug and then compile any changes you were to make, source code access might not do you any good.

In the age of ASPs and SaaS vendors, having source code escrow is seen as a remedy for the problem of not having the executable running at your physical location. But, consider whether you have all of the other back-office requirements needed to effect a product’s use. Having the source code to their product might get you that product – but if that product also requires, for example, a SQL or Oracle backend database, do you also get THOSE products as well? Probably not. So source code won’t help you as much as you would hope.

Overall, then, when considering source code escrow, make sure that:

1. it will actually provide you what you need to stay operational;
2. cost a reasonable sum in relation to the value (just like any other purchase);
3. that the terms of an Escrow Agreement are reasonable and that Release Conditions are clearly defined and not unduly burdensome to prove or meet;
4. your in-house IT staff has the ability to make use of the code.

If the answer to any of those questions is NO, look for other solutions to the possible problem of the vendor shuttering its doors. By way of example, one creative idea I’ve seen is to have the vendor (in an SaaS model), actually host the physical server within the buyer’s IT facilities. The vendor would remotely access the box for maintenance and service, just like they probably would if the box sat in a hosted data center. The only difference is that in the event of trouble with the vendor, the box was sitting in the buyer’s IT shop – readily accessible by the buyer without having to negotiate with an Escrow Agent that a release condition was met.

Anyone have other creative solutions to this problem?

Thanks for your Votes!

I just received notice that I’ve been selected to be one of five finalists in the “Software Idol” competition at the Business of Software Conference next month in San Jose!

I didn’t realize that the competition was anything more than getting to speak at the conference, but thanks to your votes, I’m among the five finalists. We’ll each have 11 minutes to speak on our specific topic – then instantaneously, we’ll find out the results.

So, if you’re in the San Jose area and have some time October 29th/30th, I would highly recommend coming down… if for no other reason than to hear Guy Kawasaki, Joel Spolsky, Eric Sink, Bill Buxton and Rick Chapman (among others). These folks are all at the forefront of the software business – and are shaping its future form. Oh, and yeah, you can hear my 11 minute talk on the Five Fundamental Skills for Effective Negotiation, too.

Thank you all again!