UC Releases Guidance on Open Source Licensing

University of California recently issued guidance on open source licensing, and provided resources on understanding open source licenses, particularly with a view to informing professors and other UC personnel about the process of releasing open source code developed at the university or using university resources.

Kudos to UC for doing this (go, Bears) — more university offices of technology licensing need to understand the open source paradigm and how it benefits their professors, students and staff.  Historically, universities have been laser focused on patents, and so there is a spectrum of sophistication among universities on software copyright alone, not to mention open source licensing.

These materials should be helpful to professors who — during or after their time in academia — want to start companies leveraging software and other technology developed at the university.  That can be a bit of a puzzle, as the rights of the university, the individual professor, and a newly formed company need to be sorted into buckets, and sometimes licensed from the university.  (If you want to know more about university technology transfer generally, see this article.)

The UC system promulgates some policies system-wide, and there are also policies for each campus.

(Thanks to Angus MacDonald, Senior Counsel, Intellectual Property at University of California for the heads-up on this information.)

The guidance below also provides information on common open source licenses and various UC IP policies.


More GPL Cure Period Commitments

Fourteen more companies, including Amazon, ARM, Intel, MariaDB, Pivotal and VMware — have joined in the Red Hat-led GPL Cooperation Commitment, a cure period pledge for violations of GPL and LGPL version 2 licenses, bringing the total number of pledging companies to 24.  The pledges now represent 39 percent of corporate contributions to the Linux kernel and six of the top 10 corporate contributors.  Red Hat has also invited individual Linux contributors to join.

There is a GitHub page with more information about the GPL Cooperation Commitment and instructions on how to join.

See my prior posts here and here.

Revisiting the Open Source Business Model

In the past few years, many companies have come to me asking for help drafting a “new open source license.”  As a rule, drafting a new open source software license is not a good idea, so I always hear this request with skepticism.  But lately, what is behind these requests is something new — frustration with, or perhaps misunderstanding of, existing open source business models. Inevitably, what these companies really want is some kind of proprietary license that makes source code available.  Not open source, but open in a different, and more limited, sense.

For a few years now, companies have tried alternative approaches that make source code available, but with license scope limitations that will prevent massive free riding on their development work.  For example, a few years ago, I helped with a model called theFair Source License.  That was one approach to limited, source-available licensing that allowed free use below a certain threshold.  But this trend is far from done, as companies continue to struggle with how to balance collaborative development and sharing of source code with making money for their own efforts, or their investors.

To understand why companies have come to this difficult choice, it’s necessary to understand the business models that companies use to make money with open source software.  Without making money, they can’t survive. But making money with open source is not intuitive, and not easy.

What is an Open Source Business Model?

Open source business models are almost always either service models or “razor blades” models — the later coming from the (possibly apocryphal) pronouncement of King Gillette,Give ’em the razor; sell ’em the blades.   The razor blades model works — just not for software companies selling only software.   Companies can sell hardware or other complementary products and give away open source software, and still fill the revenue coffers.  In fact, arguably, that’s what has made Linux such a darling of the entire industry. The companies contributing to Linux are, almost to a one, not selling Linux.  They are all selling something else: computers, other devices, or services. But the open source software they make does not give them a competitive edge.

A variation on this theme is that some companies have made money offering professional services, like development, system management, or maintenance services, for open source software.  But as everyone in the Valley knows, professional service models do not scale. Overhead allocation aside, the first hour of professional services costs a business just as much as the 10,000th hour.  With that model, you don’t get the multiples that investors expect and you are basically selling your personal time. All you can do in that model is work harder or work smarter, but there is a limit to how much you can do and how much you can know.  (As any lawyer can tell you.)

Some companies have done quite well selling other kinds of services — such as e-commerce or other web based services — that make heavy use of open source software.  But of course they are not selling software either; they are, like the razor blades companies, investing in their own infrastructure but selling something else.

Dual Licensing

Over time, companies who wanted to make a business selling open source software — the razors rather than the blades — have had to be more creative.  In the 2000s, a business model emerged that is usually called “dual licensing.” It was pioneered by MySQL AB, later acquired by Oracle. Dual licensing works like this:  the company releases software under a copyleft license like GPL. However, anyone integrating that software in a proprietary product would have to violate GPL to distribute its product.  Therefore, the company offers alternative, proprietary licenses, for those wishing to distribute the software as part of a proprietary product.

This model works because GPL does not allow distribution of GPL code within a proprietary product, and because vendors of proprietary products were not willing to lay open their proprietary code under a compatible license.  Therefore, the vendor of a dual licensed product places its developer community between a rock and hard place, with an option to buy their way out.

Many people find dual licensing models confusing, and they often ask, how can anyone license GPL code under a proprietary license?  The answer is that not just anyone can do that, only the author of the software (or a subsequent copyright owner via assignment). The author of software, as owner of the copyright, has the right to choose multiple outbound licenses.  In other words, the software is not GPL unless and until the author says so. Only the author can make that unfettered choice — everyone downstream must make the dual licensing choice.

But that model only works, in an economic sense, for cases like MySQL where two conditions are met: the software is not an entire program, and the software is mainly used in distributed products.  If the software is an entire program, then anyone can use and distribute the software under GPL. The pain point comes when the GPL code must be integrated with proprietary code to make it work. In this sense, dual licensing is like an intentional “license bug” that has to be solved with a proprietary license.

And there are complications.  Dual licensed products are rarely truly community projects, because, to make the model work, contributors have to grant the vendor broad enough rights to allow the vendor to use contributions under either GPL or proprietary terms — in other words to use a contribution license agreement or CLA.  Contributors tend to balk at this requirement, resulting in demands for license in = license out

Historically, dual licensing models were almost always implemented with GPL2 as the open source choice; most other licenses lack the conditions to drive private businesses to the proprietary licensing choice.  Once GPL3 and AGPL3 were released, those licenses took their place as part of the dual licensing model, because they imposed more conditions on the exercise of the license than GPL2.

But that is not the only limitation of the dual licensing model.  If the software is intended for uses (such as supporting SaaS, monitoring or development tools, or software intended for end use) that would not normally require distribution, then GPL would not drive anyone to take a proprietary license.   So, the dual licensing model waned in popularity over time. AGPL was potentially more effective in such cases, but again, only for pieces of programs, not whole ones. Today, pure dual licensing models are not so common, and have given ground to the “upsell” model described below.


In one variation on the dual licensing model, which is sometimes referred to as an upsell model, the company releases a basic “community” version of its software, saving the “enterprise” features for proprietary licensing.   This approach makes more sense in some cases than others. Enterprise editions can include features that are legitimately unique to commercial enterprise deployment — such as the ability to spin up and coordinate many simultaneous instances, servers or users.  But often they simply include attractive features that the developer wants to sell rather than give away. Even worse, some dual licensing models do not make clear the distinction between their community and enterprise editions, leaving customers unclear on which they need. 

Dual licensing and the free software movement have always been uneasy bedfellows. Dual licensors have been instrumental in establishing the enforceability of licenses like GPL; after all, they have the incentive and money to bring enforcement claims.  But free software advocates have often denigrated the pure dual licensing model or called the upsell model by pejorative terms like “crippleware.” 

Infrastructure and Free Goods

The moral rightness — or for that matter the commercial effectiveness — of dual licensing models is in the eye of the beholder.  But there is a subtler reason for this diversity of views that has nothing to do with philosophy. It is because the free software model is primarily focused on infrastructure, and the proprietary model primarily on higher level applications.

Free software for infrastructure is like banning toll roads.  If we have free roads, we can all share them, and get from place to place.  It makes sense for infrastructure to be a public good. There are lots of economic participants willing to contribute to infrastructure and the cost can be spread across many parties.  Collecting tolls is time consuming and expensive, and thwarts commerce. So we expect the government to build roads, fund the building collectively through taxes, and defray the expense through the increased commerce the roads create.

But collaborative economics don’t work so well for bicycles.  For bicycles to be useful, you definitely need roads. But you don’t need the government to build bicycles.  Private companies will build those, and in fact, will offer a dizzying array of models, prices, quality, and specialization.  The price for bicycles will be borne by those riding them, and the transactions costs are more efficient — it’s easier to charge once for a bicycle than every day for a road.

Similarly, free software is a great model for infrastructure, but much more difficult for applications.  While many companies will collaborate to build operating systems and web servers, they will not be so keen to collaborate to build applications.  This is not a new idea — it was behind Linus Torvalds’ position that user space programs could run on the Linux operating system, regardless of their licensing. 

New Licenses, New Models, Old Models

All this is preface to explain that today, more and more companies have decided that even dual licensing does not work as a business model for applications.  Dual licensing is about as far as an open source licensing model could be pushed without foregoing licensing revenue entirely. So now, software developers have begun to insist: I need my software to be free only for non-commercial purposes.  Or, I need my software to be free only for small users, or for some kinds of uses. And most common: I don’t want anyone to use my software to provide paid services without paying me. That is the genesis of the “new open source license” people ask me to write.  What they are saying, by implication, is that open source licensing does not work for them as a business model.

Wanting to prevent free-riding is understandable, but it is not open source.  In fact, any license restriction is not open source. For example, the Open Source Definition (planks 5, 6, 8 and 10) prohibit limitations on fields of endeavor, types of users, or types of products.  In fact, open source licensing, by definition does not limit the scope of a license — it only applies conditions to exercising the license. This distinction is subtle but important. In open source licensing, no one can stop you from doing whatever you want with the software — whether that use is commercial or non-commercial, or famously, good or evil.  Limited, or proprietary, licensing does not let you do everything you want, but only what the licensor allows. Perhaps you can use but not distribute. Perhaps you can distribute but not modify. Perhaps you can distribute only in free products. The variations are infinite.

Proprietary licensing has been around for a long time, of course, and it is not going away any time soon.  It was invented to allow software developers to make money. So it is not surprising that some developers, despite that they love the collaborative aspects of open source, want to move to proprietary models.  The question is not whether they will do that — they will. The only question is how much of the open source model they can preserve in a proprietary paradigm.


One of the things people love about open source licensing is that it is (mostly) standardized.  Although there are over 100 OSI-approved open source licenses, people only use a handful of them with any frequency: BSD, MIT, Apache 2, MPL, EPL, LGPL, GPL, AGPL.  One of the boons of open source licensing is that a few letters can identify a licensing model, and those tasked with license compliance don’t have to read hundreds of licenses to know how to do their job.

But proprietary licensing is, at this point, mostly still the wild west.  If you count Creative Commons licenses — which are not really software licenses — there is a small amount of standardization.  But for the most part, the end user license for one proprietary product bears little resemblance to that for another product, other than overarching substantive terms.  Lawyers who practice in this area all have their own favorite forms, and many of them are similar in substance, but you still need to read the fine print every time.

What the technology business is seeming to cry out for is standardized and easy to understand proprietary licenses.  They don’t want to pay lawyers thousands of dollars to write non-standardized licenses that licensees find hard to understand.  What they want is something more like a “smart contract” — a set of terms with minimal variations that can be quickly and easily understood but have a reasonable force of law.

Technology transactions lawyers need to understand that non-standardized and elaborate software licenses are going to become a thing of the past.  For proprietary licensing, we are at the point of “evolve or die.” But there is nothing preventing us from evolving; all we need is a pen.

For open source advocates, the choice is now.  Copyright holders have the right to set their terms, and open source terms don’t always work for businesses with commitments to the bottom line. Too much criticism of alternative models will probably result in vendors backing into proprietary licensing models that don’t preserve any of the benefits of open source.  In other words, halfway is better than none.

Microsoft Buys GITHUB

This transaction is big news this week, and some have been tempted to call it the end of an era.  But a few years ago, Microsoft joined the Linux Foundation, and if we needed a symbolic act to to mark it, that was the end of the era of Windows vs. Linux — a red versus blue dynamic that as already outdated by that time.  So in a way, the acquisition of GITHUB by Microsoft is a bit of a coda.

Some open source advocates are still anti-Microsoft, and the announcement apparently caused many developers to move to competing services like GITLAB, which has reported a leap in subscribers this week.  The philosophical divergence between GITHUB and GITLAB may not be obvious to the uninitiated.  GIT was developed as a decentralized tool, in the spirit of the loose control of open source, and ironically, GITHUB used that to create a centralized hosting platform.  In broad terms, this is kind of like creating a private Internet funneled through a single company.

But most observe that the truth is more nuanced, as Microsoft has been gradually joining the rest of the industry in the open source revolution for quite some time.  We will leave aside, for the sake of politeness, their patent claims accusing Linux.

Setting aside the red versus blue dynamic, there are a few interesting aspects to this deal.  The first is the valuation applied to GITHUB — a huge $7.5 billion in an all-stock deal.  GIT, of course, is an open source product (the history here is a great read, particularly the explanation of the name), and that might lead some to conclude that open source can be big business after all.  That’s a bout half true; open source business strategies always have to include an upsell element other than the code.  Microsoft did not buy GIT, the open source software product, it bought GITHUB, a developer platform with a massive user base of 28 million developers — which happens to run on GIT.

Second, in recent years, Microsoft has made a strategic move squarely into the cloud services and SAAS space, with emphasis on products like Office 365 and Azure.  Azure, provides, for example, cloud services for application development, and so perhaps the acquisition of a popular online development tool by Microsoft should be no surprise.

Finally, it will be interesting to see how the acquisitions may change the licensing landscape for GITHUB code.  GITHUB has historically taken a hands-off approach to licensing: Unlike some other code repositories, it does not require an open source license to be applied to every project.  Some time ago it started recommending the practice of using license terms, but stopped short of requiring it.  It’s an open question whether this policy will survive acquisition by one of the world’s biggest proprietary licensors.



First GPL Case in China — or Is It?

The Beijing Intellectual Property Court recently handed down a decision relating to GPL.

See WYSIWYG note below on the facts.

The plaintiff Digital Heaven Internet Technology CO., LTD. (数字天堂网络技术) made publicly available its product HBuilder. One of the modules in HBuilder (“Aptana” released by Appcelerator, Inc., a third party) was licensed under GPL 3.0, and three modules developed by the plaintiff, “CIM plugin”, “ACR plugin”, and “HTML code drawing in real time plugin”, also included in HBuilder, had no other specific licensing terms.  Plaintiff alleged that defendant Pomelo Technology CO., LTD.(柚子科技有限公司) used some of its source code in a project called APICloud without permission.

The judges opined that the GPL license is enforceable in China, but that interpreting the copyleft conditions should be done on a case-by-case basis.  Asked to distinguish between mere “aggregation” and “derivative” works in GPL-3.0, the judges ruled that the relationship between the modules developed by the plaintiff to the GPL licensed Aptana is aggregation only, and thus the plaintiff’s modules need not be licensed under GPL 3.0. (Here, it is not clear whether the plaintiff or defendant alleged that plaintiff’s modules were under GPL 3.0, by inference.)

The judges ruled for the plaintiff and ordered damages of  “one million and 250 thousand” RMB, or approximately 165 thousand EU dollars, not including lawyers fees and court costs.  (See the decision for more information about the latter; the Google Translate feature does a decent job on this part of the decision.)  The judgement is appealable.

WYSIWYG: The decision is in Chinese, and the above is based on a description from secondary sources, which I will update if and when I receive a translation or learn to read Chinese, whichever comes sooner.  Actually, the facts are not clear to me at this time — particularly, it is not clear why the judges would rule that the Digital Heaven modules need not be under GPL, but state that the GPL is enforceable, because in that case the issue of enforceability does not seem ripe for decision.   The court awarded damages, but it is unclear to me whether these damages were for breach of GPL or simply copyright infringement.

Update: The defendant argued that the plaintiff’s software was under GPL. Note this may be a generally useful strategy to defend against copyright claims for proprietary software, though asking a court to interpret GPL as a matter of first impression may be an expensive defense to prosecute.  The damages were for copyright infringement, not violation of GPL.

Update: An English translation appears here.

More Companies Join the L/GPL Cure Pledge

Six more companies have joined Red Hat, Facebook, Google and IBM (after the lead of Linux Foundation) to provide a cure period for GPL2 and LGPL2.1 violations.  This initiative was originally announced in November 2017.  See the press release from Red Hat.

It’s great to see momentum for this effort, which enables licensors and licensees to work out GPL and LGPL violations amicably.

My post on the initial announcement is here.