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.
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.
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
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide