Should an Open Source Licence Ever Be Patent-Agnostic?
Sharing lies at the heart of free software, and drives much of its incredible efficiency as a development methodology. It means that coders do not have to re-invent the wheel, but can borrow from pre-existing programs. Software patents, despite their name, are about locking down knowledge so that it cannot be shared without permission (and usually payment). But are there ever circumstances when software patents that require payment might be permitted by an open source licence? That's the question posed by a new licence that is being submitted to the Open Source Inititative (OSI) for review.
It arises out of work to create a reference implementation of the MPEG eXtensible Middleware (MXM) standard. This aims
to promote the extended use of digital media content through increased interoperability and accelerated development of components, solutions and applications. This is achieved by specifying
1.The MXM architecture
2.The MXM components (by reference)
3.The MXM components APIs
4.The MXM applications API
5.The inter-MXM communication protocols
More details can be found here.
The proposed licence is closely modelled on the Mozilla Public Licence (MPL). In his submission to the OSI, the well-known free software activist Carlo Piana explains the key difference:
As you will notice, we have removed some of the patent conditions that existed in the MPL. This is because none of the contributors would have accepted to encapsulate their patents in a FOSS license without the ability to ask for a license separately from the copyright. This is a basic tenet that is enshrined in the so-called ISO/IEC Directives for the development of International Standards. Some of you might know about my public stance against software patents and my approval to some of the licenses which impose implied licensing to or patent retaliation against all who distribute FOSS software while relying on patent protection. However, the sad truth is that if we did not offer a patent-agnostic license we would have made all efforts to have an open source reference implementation moot.
He adds:
I have insisted and obtained, however, that an explicit patent covenant be inserted, to the effect to exclude from any patent concern all who don't distribute the compiled version of the software and to those who compile it only for internal purposes without direct commercial exploitation. This covenant being irrevocable, unconditioned and detached from the copyright licensing conditions. I have asked myself if this could work and if it complied with the OSI definition. My final conclusion is that if the BSD family is considered compliant, so shall be the MXM, as it does not condition the copyright grant to the obtaining of the patents, just as the BSD licenses don't deal with them. And insofar an implementer is confident that the part of the code it uses if free from the patented area, or it decided to later challenge the patent in case an infringement litigation is threatened, the license works just fine.
Beyond the question of whether the proposed MXM licence complies with the OSI definition from a legal point of view, there is a much larger issue of whether it is true to its spirit – and whether we want open source licences to accommodate software patents.
As I wrote above, software patents are fundamentally antithetical to the free sharing of information, and so allowing their presence in an open source licence seems to be tantamount to blessing their negation of that ideal. More generally, explicitly permitting them in an OSI-approved licence is bound to be exploited by those that support software patents, especially in places like Europe where they are not currently permitted.
The argument will go that the MXM licence shows clearly that software patents and open source are not incompatible, and that the former can be accommodated provided a suitable licence is chosen. This would therefore undermine efforts to use open source as one argument against allowing software patents in national and international standards, for example. It would allow those endorsing software patents to claim to be open source, while other licences – notably the GNU GPL – would be excluded. This would lead to a complete dilution of what the open source definition is meant to stand for.
The main argument in favour of permitting software patents in an open source licence seems to be the pragmatic one that if they are not allowed, then the MXM reference implementation will not be released under an open source licence. But this is sheer brinkmanship on the part of the media industries, who are effectively making a threat to the open source community, saying that unless software patents are allowed, they will not permit open source implementations.
But as history has shown, the best way to deal with bullies is to stand up to them. The reason that an open source licence is even being considered by organisations that in the past would never have contemplated such a move is that they fully recognise the power and utility of open source; in short, they *want* this code to be open source, because it is the most efficient way of driving uptake. They need us more than we need them.
So, in my view, the OSI should not give in to this blackmail, but should stand firm on the fundamental principle that software patents are an unmitigated harm for free software. It should reject the current proposed licence, and insist that if the MPEG Working Group wishes to benefit from open source, it should play by open source's rules.
Follow me on Twitter @glynmoody
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Designing Electronics with Linux | May 22, 2013 |
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
- Linux Systems Administrator
- New Products
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Web & UI Developer (JavaScript & j Query)
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Favorite (and easily brute-forced) pw's
1 hour 30 min ago - Have you tried Boxen? It's a
7 hours 22 min ago - seo services in india
11 hours 53 min ago - For KDE install kio-mtp
11 hours 54 min ago - Evernote is much more...
13 hours 54 min ago - Reply to comment | Linux Journal
22 hours 39 min ago - Dynamic DNS
23 hours 13 min ago - Reply to comment | Linux Journal
1 day 12 min ago - Reply to comment | Linux Journal
1 day 1 hour ago - Not free anymore
1 day 5 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi

It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Featured Jobs
| Linux Systems Administrator | Houston and Austin, Texas | Host Gator |
| Senior Perl Developer | Austin, Texas | Host Gator |
| Technical Support Rep | Houston and Austin, Texas | Host Gator |
| UX Designer | Austin, Texas | Host Gator |
| Web & UI Developer (JavaScript & j Query) | Austin, Texas | Host Gator |
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?



Comments
This is not OSI compatible
As it discriminates against commercial use:
"I have insisted and obtained, however, that an explicit patent covenant be inserted, to the effect to exclude from any patent concern all who don't distribute the compiled version of the software and to those who compile it only for internal purposes without direct commercial exploitation."
VOID!
It's the same old talk about principles: "I'm against software patents but..."
These people never look themselves at the mirror and call themselves hypocrites.
GPL allows for patents in the most sensible way possible.
GPL allow for patents in the most sensible way possible - if patents interfere with the spirit and intentions under which its copyright holders licensed it for use, then that license cannot be used to distribute it, and a new license must be agreed with the copyright holders in order to use it with patent licensing. Since it is not possible to anticipate the terms and conditions that will be put into the patent licenses, this is the only sensible way forward - ie for each copyright holder to look at the patent license terms and negotiate a new license to go with the patent license.
Standards should belong to humanity
Dear Glyn,
I agree with you that the open source community should stand up to the "sheer brinkmanship on the part of the media industries" as you call it. More and more countries are hardening their stance against software patents and the US remains one of the few countries that continues to grant software patents. Even in the US, the voices for reform are growing. Bessen and Meurer's research (http://www.researchoninnovation.org/) shows that software patents lead to litigation and actually prevent innovation. Even in the US, the recent Bilski case goes against business method patents, which are closely related to software patents.
The larger issue is that standards should belong to humanity and should not be controlled by individuals or companies. We do not pay for standards like weights and measures in the physical world and we should not pay for standards in the digital world either. Governments across the world are mandating open standards because public data should be in public formats and not private formats like MPEG. This will eventually tilt the balance of power in favor of open standards.
The dot com bust proved that the digital world cannot violate the laws of economics. The open standards movement will prove that the digital world cannot violate the norms of civil society.
EULA's are to software, what
EULA's are to software, what GMO's are to the food chain!
laws of economics? what laws?
Stop using this idiotic terminology which gives these mechanism certain qualities they dont have.
These are NOT like laws of science.
This is theoretical BS, schemes and frauds put together.
Laws of economics is an oxymoron.
I dont remember the laws of physics ever beeing totally wrong to the point that we had to bail it out on multiple occassions with billions just so that simple reactions could continue.
The laws of economics have as much credibility as the laws of socialism. Let's not forget that the laws of economics heavily depends on the laws of socialism (for the rich) when it screws up and then it becomes 'a shared burden'.
Keep voodoo, religion and economics out of science and tech.
good points
Thanks.
You Are Richard Stallman...
..and I claim my five pounds.
Well, they're related, at least.
Open Source vs Free Software
The title of you article hints at a discussion of Open Source software and patents but the first sentence of the article starts off talking about free software. I've never seen these two things as the same.
Free as in free speech, not
Free as in free speech, not free beer. Open source software may still need to be purchased but the licensing is such that the source is provided and you can extend or modify the software as long as the copyright, licensing and distribution of source code requirements of the license are followed.
Often the purchase price is for media, a support period and updates rather than the software itself.
I would also distinguish
I would also distinguish between "Open Source" and "Free Software", as Free Software in the sense of the Free Software Foundation does not accept all "Open Source"-licenses as "free".
So in an "Open Source" sense there are possibilities to have patent-poisoned code. As you mentioned the BSD licenses for example allow patented algorithms.
Yet the MPL gives some extra restrictions and thus there are parties that might want to have those restrictions but without the patent enforcement.
That said, for me it boils down to the fundamental difference between "Free" and "Open". Of course I would prefer to see code "Free" and not just "Open", but when it comes to corporate limitations it might be acceptable to make them release code under an "Open" license. As already mentioned there are many countries where the software-patents do not apply, and with the hopes that they might even fall in the USA in the future, we would then have the code under an otherwise acceptable "Open Source"-license.
As bad as patents are, especially how diametrical they are to Free Software, I personally still would encourage corporations to give out the code even if for now it would not be "Free" in some countries.
For what it's worth, most of
For what it's worth, most of my reply is directed at the author of the article rather than you, I just was lazy, and wanted to kill two birds with one stone. :)
The problem with what you
The problem with what you (and to a greater extent the article) are saying is that the BSD license IS considered both open source and free software by any reasonable metric, and it would arbitrary to exclude a license for being patent agnostic.
That said, I don't think it makes sense for a copyleft-style license to be patent agnostic. For what it's worth, the latest version of the non-copyleft apache license I believe deals with patents at a certain level.
So my point is that the article is making an unfair and arbitrary attack on this license, though I too am against software patents.
Most of the dangers of software patents can't be dealt with directly by a license anyway, (if you unintentionally use a patented algorithm without having any knowledge about the patented algorithm, I seriously doubt a license could protect you) and the best way to deal with them is by publishing cutting edge algorithms as soon as they are implemented to make a case for "prior art". Also, it's probably a good idea to stay as far away as possible from any known patented algoriths, and so on.