Google can invalidate Black Duck OSS licensing patent

Interesting news today regarding the recently announced Black Duck patent on tracking and analysing open source licenses applicable to software components.  Many have expressed concern about the risk that Black Duck would use the patent to drive out other OSS license checkers such as HP’s Open Source Fossology, Palamida and many more. Aggressive use of the patent would have meant companies using an open source risk management process would have needed to either use Black Duck or to ensure they are otherwise properly licensed.

It seems that Google could come to open source users’ rescue in this case. Google’s Chris De Bona confirmed on the Open Source Initiative’s public mailing list that “Google has prior art” that can invalidate the patent. Good news for those worried about the new Black Duck software patent, although I would not be surprised if others such as HP would also be in possession of prior art.

How Nokia became a bully – The next steps in the Nokia-Apple saga

Christmas was a busy time for Nokia’s external counsel who filed i) a complaint against Apple at the ITC, and ii) another lawsuit claiming most if not all of Apple’s products infringe on Nokia’s patents. The new claims extend the scope of the earlier wireless patents to cover for example various aspects of Apple products’ user interfaces.

In other words, its all out war on the patent front and attorneys are getting excited. One cannot help to wonder, however, whether Nokia’s helping its image as a struggling mobile giant by attempting to use, often obscure, patent law to stop its competitor from taking more market share. Many already believe that patent law has outlived its welcome and is unsuited to the task of both encouraging and protecting innovation. In fact, on the face of it, the case looks like an example of _stifling_ innovation in that a struggling company is trying to stop an innovative competitor.

I cannot comment on the new complaints, as I have not seen them. However, I think the way Nokia is handling the case is hurting its image and makes it look like a grumpy bully resorting to all means possible to prevent it from losing. I think this is likely to be far from the truth, but unless Nokia comes out in the open to explain to the community at large what its intentions are and the reasoning behind its case (instead of giving PR department produced quotes to the media) the amount of money they receive from Apple in an eventual settlement might not be worth as much as the harm done to their image.

Come on Nokia. Don’t forget you are not only fighting in court, but you are also fighting for your customers. In the end, its what the latter group thinks that matters.

Why Nokia should be worried about the Apple litigation

The tech world gasped when the Finnish mobile giant Nokia announced it was suing Apple for patent infringement. According to Nokia,

The ten patents in suit relate to technologies fundamental to making devices which are compatible with one or more of the GSM, UMTS (3G WCDMA) and wireless LAN standards. The patents cover wireless data, speech coding, security and encryption and are infringed by all Apple iPhone models shipped since the iPhone was introduced in 2007.

In other words, Nokia considers it likely that every single iPhone ever sold infringes on Nokia’s patents and entitles the company to damages from Apple. 

There are two key points of note here.

First, these patents relate to various international standards and have been declared essential to those standards by Nokia.

Second, given their status, Nokia has been obliged to give a written commitment to the relevant standard setting organisations to license those patents on a fair, reasonable, and non-discriminatory (FRAND) basis.

Apple’s response

Apple has now responded (and counter-sued Nokia for patent infringement as well), and a review of their response shows where the core of its defence lies. It is in Nokia’s failure to comply with the written FRAND-licensing commitments it has made, and which are binding on it. According to Apple, Nokia tried to force Apple to agree to cross-license Apple’s own iPhone-related patents to Nokia as a condition of Nokia granting a license to Apple.

If this is true, Nokia’s case is far from clear cut, despite what many lawyers thought originally. Having worked before on FRAND-licensing cases (but not being involved in this one in any capacity), the only thing I can testify for is that there are no clear guidelines on what constitutes FRAND. However, there are some indications on what is not FRAND, and an attempt to use essential patents to obtain cross-licenses to other patents not relevant to the standard is falling close to the line. Obviously cross-licenses can be FRAND in some cases (assuming they are coupled with a zero or a lower royalty), but if those demands are directed towards one player with important innovations, we are close to violating the ND-part of the equation, i.e., discriminating between licensees.

I think the whole community is watching with great interest how things develop. Both sides have big-hitting lawyers involved, but it will be interesting to see how the parties will battle over the FRAND issue. If this is not settled, it might become one of the first cases in the world to give good guidance on what amounts to FRAND in the mobile world.

How to make money from your open source project

It often amazes me to see the amount of effort and dedication developers put in the open source projects they are participating in. Often this is done without more consideration than building the developers’ reputation, and of course contributing useful code for others to use. The truth, however, is that reputation and goodwill do not pay the bills. I’m sure we all know that.

Given this unfortunate fact, it is surprising that not more projects try to generate revenue from the work they do.  As charging license fees for open source software is very difficult at best, and more often than not impossible, the traditional software licensing business model is obviously out of the question for most projects. However, there is nothing in open source licenses that prevent projects offering support and maintenance services for users and distributors of the software. Many projects have realised this, but most have not. This is a shame, as I dare to say that open source projects that have achieved even moderate enterprise adoption have huge opportunities in this area, which well surpass those of traditional software providers due to for example following reasons

• Support and maintenance is a well-accepted concept in the enterprise and there is clear demand for it. Many clients I have worked for would be happy to pay for bug-fixing.
• Open source projects do not need to (but obviously can) sell their software in the same way as traditional software houses.  Customers can download the software for free, and the community plays a big part in the sales process.
• Open source has global reach. Unlike enterprise software houses who need to have local sales reps, open source is available everywhere via the Internet.

There are obviously a few legal issues that you need to address before you can start making money from your project, but despite what your attorney might tell you, it is not difficult. You will need to have a company that acts as the service provider. In most cases, you need just one agreement template (with a few appendices). The support and maintenance agreement will set out the service you are providing, under which conditions, and the payment you will receive. A key appendix is the Service Level Agreement (SLA) which sets out the level of service you promise to provide, and the consequences of what happens if you do not meet the agreed service levels. If you agree on levels that you know you can meet and consequences that are limited to price reductions in case of failures to meet the levels, you are essentially paid by users to fix bugs in the software you would fix anyway (albeit not as fast as without the SLA). The best of all, given that the support & maintenance arrangement is optional, companies that need the support will be happy to pay you for it.

It goes without saying, that you should obviously consult a lawyer when preparing the agreements to make sure the agreements reflect i) what you want to provide, and ii) the risk you are willing to take. But do keep in mind that for simple agreement templates, if you are asked to pay more than a few hundred dollars/euros, you are being ripped off.

Licensing 101 for open source projects – Pick a license, part II

Part I dealt with the impact your licensing choice can have on the use of the code you write. This part II focuses on how your choice of license impacts your ability to incorporate third party code (whether from third party programs or third party contributions). Like in in Part I, the analysis below is slightly simplified and addresses license categories instead of individual licenses (although individual licenses are used as examples in some places).

What’s the problem?

When you write your code from scratch, you get the added benefit of being the so-called “owner” of the code. In legalese, it means that you own the copyright over the code, and can restrict others from using it, or to grant them limited rights (via licensing). More importantly, you are free to decide yourself on what terms you want to license the code, e.g., whether to for example license your code for a fee (i.e., via proprietary licensing) or under an open source license (where a fee is sometimes possible, but not necessarily always a viable business model given the characteristics of open source licenses).

The flip-side of the above is that when you are the one receiving code, you do not usually get full rights to do what you want with the code. You are limited by the license terms covering the code in question. It makes no difference in theory whether the license is open source or not, as open source licenses are based on exactly the same legal principles as proprietary licenses.  Thus, when you incorporate third party open source code into your project’s codebase, you need to always comply with the license terms for the code in question. If you do not, you could at worst create a licensing incompatibility that makes it a copyright infringement to distribute your code, and at the very least make it very difficult for a licensee to know how to comply with all the licenses applicable to your code.

As an example, if your project is licensed under the BSD and you wish to integrate into it a nifty third party open source database connector licensed under the GPL, you run into difficulties. Whereas your BSD license gives free rights to the licensee to use _your software_ however they wish (subject to certain notice/attribution requirements), the license for the connector requires it (and probably also your work) to be licensed under the GPL. Thus, if you attempt to license your work under the BSD, you are infringing the copyright in the connector as you are attempting to distribute it against the terms of its license.

In order to avoid this, here are some guidelines on what to consider when planning to integrate third party open source code into your project. Do note that the guidelines below are general rules, and there are numerous license specific exceptions that should obviously be taken into account.

Scenario 1: If your project uses a permissive license (e.g., BSD, MIT, Apache license)

As noted above, one of the most common examples of licensing problems is trying to combine GPL code into a project licensed under the BSD license. This usually not possible, given that the permissive BSD license is, ironically enough, more free than the GPL in that it does not impose similar compliance obligations as the GPL regarding re-licensing and source code disclosures. Attempting to incorporate GPL code into software licensed under such a license will result in a high risk of copyright infringement.

As a rule of thumb, if your project is licensed under a permissive license, you are not able to incorporate any third party code licensed under any of the strong or weak copyleft licenses. This is because the concept of copyleft is in many ways orthogonal to the other type of freedom provided by the permissive licenses. There are obviously exceptions to this basic rule (e.g., LGPL, which allows certain types of linking without the copyleft effect being triggered), but strictly speaking even these create licensing issues, as they impose to your recipient licenses obligations additional to those contained in your project’s main license. Unless you clearly flag these additional obligations, you could i) infringe the LGPL, and/or ii) make it very difficult for your licensee to legally redistribute your software.

Scenario 2: If your project uses a weak copyleft license (e.g., Mozilla Public License)

My definition of a weak copyleft license is one whose copyleft effect attaches to i) modifications to the licensed code, ii) additions to the code, but not other components merely linking to the original licensed code.

If your project uses a weak copyleft license, you are able to incorporate third party open source code licensed under i) a permissive license, or ii) the same weak copyleft license as your code. These are compatible with the main license, in that they impose no additional obligations to those imposed by your project’s license. In other words, in terms of compliance, In most cases compliance with your primary license is sufficient to comply with the licenses applicable to the third party code incorporated in your codebase. However, you are not able to incorporate strong copyleft code (mainly GPL) into your project, as its copyleft effect contradicts your main license’s terms.

Scenario 3: If your project uses a strong copyleft license

I define a strong copyleft license as one whose copyleft attaches not only to code additions and modifications, but additional components linked to the original component.  The GPL is the paradigm example.

If you use a strong copyleft license for your project, you can incorporate code from projects licensed under a permissive license, or the same strong copyleft license under which you license your software. In other words, the rules are similar to those applicable to projects using weak copyleft licenses. What it means in practice is that if you need to incorporate GPL code into your project, you have no other choice but to license your own work under the GPL. Otherwise you are taking a significant legal risk.

Licensing 101 for open source projects – Choosing an open source license, part I

The most important thing for your open source project’s success is obviously good and useful code. Licensing, however, can make or break  your project as well. Choosing the right open source license for your software is crucial for your project’s success as it determines, amongst other things,

i) who will use your program
ii) whose code you can integrate into your program

There are in essence three key open source license types, and deciding on the type will ultimately also decide the faith of your project. These are the strong copyleft license, the weak copyleft license and the permissive license. The next section will summarise their key characteristics and how they impact enterprise use of your software. The issue of how the license type impacts your ability to incorporate third party code in your program will be discussed in a later blog post.

How the license type affects your project

1. Strong copyleft

Choosing a strong copyleft licensee (e.g., GPL) ensures that the source code of all modifications, additions, or derivatives of your work will be disclosed (eventually). In case of the GPL, derivatives are likely to include also other components licensees link your program to and distribute your program with.

If your project uses a strong copyleft license, most enterprises relying on licensing revenue for their business are unlikely to use your software as their own software linking to your code could be subject to GPL obligations. In fact, many companies have prohibited the use of GPL interally for this very reason. Your code is more likely to be used by companies requiring the software for internal use, or companies that do not rely on license fees for their business but instead make their money out for example the provision of IT services.

2. Weak copyleft

A weak copyleft license (e.g., MPL and arguably LGPL) is in many ways similar to its strong cousin, with one significant difference. Weak copyleft licenses generally do not affect independently created programs that merely link to your software. They exclude copyleft’s effect from such scenarios via various means (depending on the license), including by limiting the license’ scope to specific files or by expressly allowing linking.

If you choose a weak copyleft license, you are more likely to see your program adopted by enterprises as the license allows them to use your software together with theirs without sacrifing their own business model. However, it also means that they can make licensing revenue from value add they develop to a codebase which you give away for free

3. Permissive

All permissive licenses (e.g., BSD, MIT, Apache) generally allow for use for whatever purpose without an obligation to disclose source code, subject only to some obligations regarding the retainment of copyright notices and warranty disclaimers. Although flexible, they can be difficult to comply with in some cases.

If you choose a permissive license for your proejct , your code is likely to spread around like wildfire if it is good enough. Companies of all kinds are interested in it, as they can integrate it into their software as they see fit. You get recognition and your software could become standard, but the companies all money.

Part II will focus on how the license type affects your ability to incorporate third party code.

Why the MIT and the BSD are the most often violated licenses

When preparing corporate open source compliance programs and teaching about compliance, a great deal of time is often spent on the GPL, LGPL, and similar copyleft licenses that also require source code disclosures. They are seen as the paradigm open source licenses, and others, such as the MIT and BSD (the permissive licenses) are only mentioned in passing as you can’t really infringe them. How wrong most people (including me) are or have been.

In my view, probably the most difficult license obligations to comply with are the following:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software. (MIT)

Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. (BSD)

Now you probably think I must be a very lousy lawyer if I do not understand what those clauses mean and how to comply with them. Well, leaving aside my skills, let’s just consider what those clauses mean in practice for a company wishing to distribute only the binary version of an open source program.

Let’s take the hypothetical example (and believe me, I see concrete ones every week) of the Widget Framework. The Widget Framework is licensed under the BSD license, which thus should allow for free use subject to the limited conditions pertaining to the retainment of copyright notices. Compliance with a single BSD license is pretty simple, but this is not enough.

The Widget Framework (like over 95% of all real open source projects) consists of

1. code created by the people running the project,
2. code taken from other projects by the people running the project, and
3. code contributed by third parties to the project.

If the project has the policy that they only accept code licensed under the BSD or MIT licenses, this means that there are probably 10s, 100s or in some cases even 1000s of files with third party copyright holders each of which have licensed their code under the BSD or MIT. In order to distribute the Widget Framework, you need to comply with every single one of those BSD/MIT licenses (note that this is an issue that applies to all licenses, but the focus of this post is on the practical difficulties it poses for BSD/MIT distributions).

This creates two problems for the binary distributor:

• How do I identify all those licenses?
• How do I extract all the copyright notices so that I can include them in the program’s documentation or perhaps an about-page in the program itself?

I do not have good answers to those questions. The best advice I can give at the moment is to use a search tool that identifies the licenses automatically from the source code. There are many such tools available, but none of them are perfect. More importantly, none of them seem to be capable of extracting all the relevant notices and listing them in a form that could be included with the distribution. What distributors are thus now stuck with, is a manual process by which they go through every source code file and copy paste the copyright notices into a text document which is then distributed together with the code. This can sometimes take days.

Due to the process being so difficult, many fail to follow it alltogether. Many BSD/MIT components are likely to be incorporated into binary distributions without any regard to the copyright notice obligations. This is a shame, but partly caused by the poor license management of many open source projects. It should be for the projects to make sure that they maintain a list of all third party code contributions so that those can be easily given credit by companies wishing to distribute binary versions of the project’s software. Many professional projects handle it well, but unfortunately the majority of projects out there really do not even understand the issue.

Copyleft is all right

A cliché is nothing more than the reality front-runners have left behind. I hear and read about the mainstream adoption of open source software on a daily basis, and am often myself also fooled into believing that the software world has truly changed forever. Not so.

Many of us working for more traditional ICT companies encounter the reality everyday day at the office. Open Source is a term we see in powerpoints every now and then and open source licenses are those radical inventions that “take away your IPRs and give them to all the world.” Although many would probably want that to happen, in reality the licensing is not that radical and not that conceptually different from what all companies in the business are used to when dealing with their suppliers and their customers. Granted there are differences, but with a little bit of education and a great deal of business planning open source and its “exotic” licensing model can provide a real boost to any software company’s bottom line.

All it takes is a little bit of education and a willingness to embrace it. Oh, and lawyers of course. The kinds that do not insist on their own carefully drafted license templates.