Category Archives: source code

FOSS licenses upheld!

After a five-year struggle in US Federal District Court, Robert Jacobson recently prevailed in his copyright infringement claim against Matthew Katzer as a result of Katzer’s alleged misappropriation of open source code from Jacobson’s Java Model Railroad Interface project.

You can read all of the story in more detail at ConsortiumInfo.org.  The end result is a huge win for open source developers as a result of three key findings by the District Court:

  1. Violation of an open source software license constitutes copyright infringement, not just breach of contract (this was first upheld by the Federal Appeals Court in 2008 in this case).
  2. Use of open source code without attribution is a violation of the Digital Millennium Copyright Act.
  3. These violations entitle the Plaintiff (Jacobson) to monetary damages – which, as they’re based on violations of copyright law, are potentially much more substantial than those which may have been limited by contract law.

There are some mitigating circumstances in that the results in this case are not yet dispositive of all future violations, as the ruling of a US District Court is limited to absolute applicability only in its geographic district.  The concern is that a Federal Appellate Court (including the US Supreme Court) could overrule or otherwise reverse this decision.  Worse yet would be another US District Court coming to a different conclusion with a similar set of facts.

But for now, FOSS developers can rest a little easier knowing that their creations are protected by copyright law.

Advertisements

GPL, WordPress and Themes

I saw an intriguing post the other day by Jennifer Schiffer on WordPress, themes and the GPL.  She linked to a video of Matt Mullenweg (one of WordPress’ lead developers) who was talking about why WordPress was a GPL product (short answer: they didn’t really have a choice because WP is based on b2, which was GPL) and, more specifically, was talking about why themes and plugins are also then GPL.

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.

Business Continuity

A lot of conversations have been going on recently regarding source code escrow and business continuity: here, here and here.

Wow.  Regardless of whether you’re talking about on-premise applications or SaaS “hosted” apps, business continuity is a pretty important issue.  Many organizational leaders are extremely worried about making sure that their infrastructure is stable enough to allow them to sleep well at night.  So they sink a lot of cash into various potential solutions in hopes that they’ll create a safety net.  Right now, for most customers and vendors, this safety net is built out of four potential components (some solutions aren’t conducive to all options):

  1. source code escrow (vendor out of business)
  2. insurance (vendor causes damage)
  3. warranties (solution doesn’t work as advertised)
  4. IP indemnification (solution infringes on rights of others)

Like any net, though, it has a lot of holes – gaps in the netting where stuff can slip through.  Even if you try to cinch the net tighter, it’s not a solid material – there are ALWAYS going to be gaps.  This is a hard lesson to learn, especially in the game of risk management and mitigation.  You’re not going to protect it all.  [It’s an imperfect analogy, but look at the Secret Service detail for the President of the US – he doesn’t walk around all day completely enclosed in bullet-proof material.  Rather, he’s protected by agents all around.  Once and awhile, something slips through, even after extensive diligence and effort.]  At the end of the day, therefore, you protect against what you can with the understanding that the only way to obtain 100% protection is to restrict operations by 100% as well.

The goal, therefore, is to find a way to mitigate the biggest risks, not just the low-hanging fruit and those that are most obvious – but those that can cause the most damage.  Which brings us back to losing access to software used to run a business.  This could be your desktop operating systems… it could be your word processing applications… it could be your CRM (customer/relationship management) application.  The key is to determine which applications are mission critical and then figuring out strategies to make sure that you have options available in the event you lose access.

This does not mean you need source code escrow for every application.  Microsoft Word, as pervasive as it is, isn’t the only word processing application available in the world.  It’s also not using a file format that is wholly unreadable by any other word processing application.  So if Microsoft Word becomes suddenly unavailable tomorrow, even if it was a hosted application (which it currently is not), having spent money on source code escrow will have been wasted.  You could probably more cheaply (and with greater efficiency) simply buy a new word processing application.  And guess what?  This is true for almost ALL of the applications that your business uses!  As Apple has been saying for their iPhones, “there’s an app for that.”  In fact, there are usually a dozen.  What you move to might not be your favorite, but it will get the job done in a cost effective manner.

So where did you need escrow?  In the past, it was for customized applications or those that required substantial and pervasive integration and implementation – something so ingrained in your environment that its failure would immediately and irreparably cripple your business.  Many CRM tools used to be of this nature.  They were so customized… so specialized… so deeply modified for your particular use that it wouldn’t be as simple as just grabbing a new one off the shelf and porting the data over.  But that’s not really how it is these days.  Data is no longer held in proprietary databases, it’s held in more generically available database architectures (like Oracle or SQLServer).  Competitors now are even building their apps using similar data structures to encourage customer poaching.  You can thus port your data efficiently and quickly if necessary.  Thus escrow has become an almost non-starter.  Eventually, you’ll have to move to a new app regardless – but with an on-premise solution, you can keep using the software until you migrate.  Source code isn’t going to get your data moved to a new application any quicker.

For hosted apps, however, the added risk is that you no longer have control of your data.  Even a daily backup doesn’t get you the application.  Source code escrow in this scenario was hopefully going to give you access to the code to bring up at your own site if the hosted vendor went away.  But wait!  It’s not OBJECT code escrow, it’s SOURCE code escrow.  Additionally, you’re not getting the support applications, either.  We need another option.  A way to provide a SaaS customer continuity in software use.

It’s brainstorming time.  I put out my suggestion in the comments of Frank Scavo’s post.  Now it’s your turn.  Speak loudly – get creative – no idea is too outlandish.  The comment area awaits your input!

This Week on The Web 2009-08-23

The things that happened around the web this week – maybe you already read about them, maybe you need to again:

Delivering Perfection

In thousands of meetings over the years, I’ve been privvy to a very common conversation.  It’s a discussion of deliverables – what is needed, what is wanted, how much money is available to pay for the needs/wants, who can create the best solution, etcetera.  Regardless of the actual nature of the deliverable, the basics are always the same:  We want what we want, when we want it, at the least total cost.  The end result, however, varies widely on a huge number of factors.  One of them is the quality of the “spec” – the document describing what’s being created; and another is the quality of the group performing the work.

The deliverable is never perfect.  At some point in the process, either the vendor makes errors or the buyer doesn’t adequately describe what they want (or consider all of the various contingencies).  The net result is payment for something that doesn’t do what you hoped it would do – or going over budget for the fix.  So how do you deliver perfection?

Well, the folks who write the software that runs NASA’s Space Shuttle have it about right.  It’s a four-part process that keeps their code running virtually bug free for the last 20 years, and like the Five Fundamental Skills for Effective Negotiation, it’s not (pardon the pun) rocket science:

  1. The product is only as good as the plan for the product.
  2. The best teamwork is a healthy rivalry.
  3. The database is the software base.
  4. Don’t just fix mistakes – fix whatever permitted the mistake in the first place.

This is a fascinating story about a group of 260 people working normal hours and achieving extraordinary results (the last 11 versions of the software have only had a total of 17 errors).  Equaly important from a stats perspective are the specs.  For the current application (420,000 lines of code – for comparison’s sake: WindowsXP has 40,000,000 and MacOSX has 86,000,000), the current spec is 40,000 pages long.

Now, granted, many of the projects your teams are working on aren’t operating systems.  But how many of you have seen a spec document that’s even more than 100 pages?  How about 50?  Very few.  In fact, I am used to seeing spec documents of less than 5 pages – 10 at most.  It’s no wonder that there are errors.

I also don’t believe that many of us will be effective in getting our development teams to change, either.  But if they only got a little better, the cost savings would be immense.  So share the article with them from a human interest perspective (ie: don’t push an agenda).  The worst that happens is you start a dialog.

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?

Open Wha?

[OK… my bad… things got a bit busy yesterday.]

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)!