Open Source Software Licensing Trends

This is a guest post from Jim Farmer, Chairman of Instructional Media + Magic Inc. Jim has also written a series of feature articles on open source for Informa’s London-based Intellectual Property Magazine.

Higher education has traditionally been a knowledge “sharing” environment. Early software was exchanged without license and, in practice, without restrictions. As the monetization of intellectual property, including software, becomes pervasive more restrictive software licenses have been introduced and enforced. These licenses impose legal duties of the user of “open source software” that could be unexpected and have undesirable consequences.

The first license restrictions were a series of “copyleft” licenses that imposed a duty of a user who makes modifications of open source software to share these modifications with others. In addition, the terms and conditions of licenses of the modified software is required for all subsequent users as well. Richard Stallman is credited with launching the free software movement. He used software licensing to enforce this desired behaviour. In practice the open source community was already sharing software so the “copyleft” licenses were not a substantial burden. Disputes were avoided by an email or telephone request, almost always honoured.

Some open source software from higher education because commercial software products with proprietary licenses. Examples include North Carolina State University’s statistical package that led to SAS, and the University of Chicago’s package that led to SPSS. Their contribution was documentation and standardized stable versions of the software. Subsequently this strategy was used by Red Hat to introduce Red Hat Linux.

Extending Stallman’s practice of imposing duty, the recent and rarely used Affero license has imposed additional and potentially burdensome restrictions on distribution of modifications made to software used as a service over a network.

Higher education is becoming more sensitive to these license restrictions. There are three recent licensing choices that illustrate the trade-off decisions that were made.

edX Seeks More Software Users

Harvard University and MIT had adopted the Affero software license for their edX learning technology platform. In September, Ned Batchelder, edX Sofrtware Architect wrote “…one license does not fit all purposes, which is why we’ve decided to relicense one part, our XBlock API, under Apache 2.0.”

As part of its license compliance software and services, Black Duck compiles use of the various licenses. Using this data the edX shift from restrictive to permissive licensing is illustrated in Figure 1. The data suggests edX’s action was consistent with trends in open source licensing.

Graph showing license usage in open source software; Affero is less than 1% and rank ed 16th most popular; Apache 2.0 is ranked 3rd most popular, after GPL 2.0 and MIT.

Figure 1 – Use of Open Source Software Licenses

Batchelder describes the motivation for the change:

The XBlock API will only succeed to the extent that it is widely adopted, and we are committed to encouraging broad adoption by anyone interested in using it. For that reason, we’re changing the license on the XBlock API from AGPL to Apache 2.0.


The Apache license is permissive: it lets adopters and extenders do what they want with their changes. They can release them under a copyleft license like AGPL, or a permissive license like Apache, or even keep them closed-source.

Using Black Duck data for 2009 and 2015, the licensing trends in Figure 2 show the sharp increases in use of the MIT and Apache permissive licenses.

Figure 2.Trends in license use from 2009-2015, showing increases for MIT and ASL, decrease in GPL and LGPL

Figure 2 – Change in Use 2009 to 2015

According to Black Duck’s data on the use of software licenses, Apache 2.0 – used by 19% – has moved from its 7th ranking to 3rd most used software license. The GNU General Public License is still the most frequently used at 25%. However the GPL license has lost 21.4% of user share since 2009 and Apache has gained 12.4%. The least restrictive MIT license grew from 3.3% to 19.0% during the same period to become the second most frequently used open source software license.

The least restrictive MIT license has few restrictions: You can not sue MIT that the software didn’t do what you thought it should—“fitness of purpose.” Also it mandates attribution via reproduction of the copyright statement.

There is also a difference based on the purpose of the license. Figure 3 shows the differences in use by software developers of open source software, on downloads of the software selected for use, and what companies are using. For enterprise use the Apache license is most used.

Figure 3. License usage by purpose. Figure 3 – License Use by Purpose

Donnie Berkholz at RedMonk quantified the shift toward permissive licensing using data from July 2012. He summarized his results using the ratio of permissive to copyleft licenses. The results are shown in Figure 4. Licenses for both Java and JavaScript—two of the most frequently used—became more frequently used than copyleft licenses in 2008. Cumulatively in 2010 the majority of open source software licenses were permissive licenses.

Figure 4: Upwards trend for permissive licensing (source: redmonk)

Figure 4 – Shift of Open Source Software to Permissive Licensing.

In December 2014 ZDNet’s Steven J Vaughan-Nicholas summarized::

“The three primary permissive license choices (Apache/BSD/MIT) … collectively are employed by 42 percent. They represent, in fact, three of the five most popular licenses in use today.” These permissive licenses have been gaining ground at GPL’s expense. The two biggest gainers, the Apache and MIT licenses, were up 27 percent, while the GPLv2, Linux’s license, has declined by 24 percent.

He also reported that in July 2013 Aaron Williamson, senior staff counsel at the Software Freedom Law Center, documented that 85.1 percent of GitHub programs had no license. He commented:

Yes, without any license, your code defaults to falling under copyright law. In that case, legally speaking no one can reproduce, distribute, or create derivative works from your work. You may or may not want that. In any case, that’s only the theory. In practice you’d find defending your rights to be difficult.

The primary edX learning system continues to use the Affero license. Apereo Foundation’s Sakai learning system is licensed under Apache; Moodle uses the GPL license.

edX’s move to a less restrictive license will likely increase use. To gain additional users, perhaps the Apache license should be used for the edX learning system as well.

Kuali Foundation Seeks to Protect Cloud User Market

Administrative software being developed by the participants in the Kuali Foundation was licensed under the Educational Community License (ECL)—an OSI (Open Source Initiative) approved special purpose license for higher education software based o the Apache license. In August the Kuali Foundation Chair Brad Wheeler announced “… the Kuali Foundation is creating a Professional Open Source commercial entity.” He also said “Kuali software now and in the future will remain open source and available for download and local implementations.” The same day the Kuali Foundation posted Brad Wheeler’s blog Kuali 2.0 FAQs. He wrote “The current plan is for the Kuali codebase to be forked and re-licensed under Affero General public License (AGPL). AGPL allows customers to download and use the code at will, but requires partners trying to monetize the software to contribute code changes back to Kuali. This is intended to discourage partners/Kuali Commercial Affiliates (KCAs) from receiving revenue from hosting Kuali software, but does not prohibit them.”

The Foundation asked its participants to transfer their software development to Kuali Inc.and use their proposed cloud-based systems. The Kuali Foundation continues to make available the current version of its software under ECL. The cloud versions also include software proprietary to Kuali Inc.

On September 8, 2014, Chuck Severance wrote :

… the successful use of AGPL3 to found and fund “open source” companies that can protect their intellectual property and force vendor lock-in *is* the “change” that has happened in [Kuali’s] past decade that underlies both of these announcements and the makes a pivot away from open source and to professional open source an investment with the potential for high returns to its shareholders.

Severance suggested how to achieve “high returns:”

First take VC [venture capitalists] money and develop some new piece of software. Divide the software into two parts – (a) the part that looks nice but is missing major functionality and (b) the super-awesome add-ons to that software that really rock. You license (a) using the AGPL3 and license (b) as all rights reserved and never release that source code.


You then stand up a cloud instance of the software that combines (a) and (b) and not allow any self-hosted versions of the software which might entail handing your (b) source code to your customers.

On October 2 at Educause, reporting for e-Literate on the Kuali session, Phil Hill identified “(b):”

The back-and-forth involved trying to get a clear answer, and the answer is that the multi-tenant framework to be developed / owned by KualiCo will not be open source – it will be proprietary code. I asked Joel Dehlin for additional context after the session, and he explained that all Kuali functionality will be open source, but the infrastructure to allow cloud hosting is not open source.

Referring to multi-tenancy, Inside Higher Ed’s Carl Straumsheim described the purpose of “(b)” confirming Chuck Severance’s scenario:

“I’ll be very blunt here,” [Kuali’s Barry] Walsh said. “It’s a commercial protection — that’s all it is.”

In a 10 September blog post Locked into Free Software? Unpicking Kuali’s AGPL Strategy OSS Watch’s Scott Wilson considered the implications of AGPL. He pointed out “The GPL license requires any modifications of code it covers to also be GPL if distributed [emphasis added]. The use of a cloud-based service is not considered distribution of code. So a user could offer a cloud service without making modifications available to the community. Wilson wrote:

The AGPL license, on the other hand, treats deployment of websites and services as “distribution”, and compels [his emphasis] anyone using the software to run a service to also distribute the modified source code.

Wilson also reported Bradley Kuhn, one of the original authors of AGPL, in a talk at Open World Forum in 2012 said “… at that time, some of the most popular uses of AGPL were effectively “shakedown practices” (in his words). This unfortunate characterization may rarely be true.

The AGPL license does meet the Open Source Initiative’s criteria of an open source license. But the pressures of monetization causes its terms to be used inconsistent with the connotation of “open source.”

Oracle Builds a Community?

On September 29th at Oracle World, Oracle announced their Oracle Student Cloud and their investment in the Oracle Customer Strategic Design Program. Embry-Riddle Aeronautical University, University of Texas System and the University of Wisconsin-Madison will participate “to provide guidance and domain expertise that will help shape the design and development of Oracle Student Cloud. A press release described the initiative:

  • Each university will work with Oracle through significant milestones and releases, providing guidance and expertise to develop an industry-leading product. The growth of non-traditional programs is an important trend for these customers, and the first release of Oracle Student Cloud is expected to include flexible core structures and an extensible architecture to manage a variety of traditional and non-traditional educational offerings.
  • Oracle Student Cloud will feature a compelling mobile user interface that enables customers to extend, brand, and differentiate the student experience for each institution.
  • The first phase of Oracle Student Cloud is designed to support the core capabilities of enrolment, payment, and assessment. Oracle Student Cloud will embed CRM-based functionality throughout the solution to promote engagement and collaboration, along with a business intelligence foundation to provide customers with actionable insight into their student operations.

The Design Program could be interpreted as combining the contributions of a community as found in open source development, and a proprietary model that would use the standard Oracle license. If successful this innovation could benefit both Oracle and colleges and universities.

In an October 7 blog Cole Clark, Global Vice President Education and Research industry, reflected on Oracle World. He included Stanford University as a participant. He also said a fifth partner in Europe would be named the following week at the Utrecht NL Higher Education User Group meeting.

He wrote:

We believe this [Oracle Customer Strategic Design Program] gives us a broad spectrum of the higher ed panoply from which to draw a great deal of insight and council [counsel] as we build the next generation student system in the cloud with mobile and social attributes at the core of the development initiative.

He also described the role of open source software:

Don’t get me wrong; there are definitely areas where Kuali (and other open source initiatives) fill gaps that the private sector will likely never pursue – Coeus [research administration] and the open library environment are excellent examples.  Parts of Unizen may be another.  But in the broader areas … where ample (and growing) competition exists to drive innovation up and costs down, there is no justification for investing shrinking resources in higher education on software development and support.

The description of contribution expected of the participants—guidance and domain expertise—and their diverse needs and competencies suggest functional requirements and designs of student services that improve the Oracle software. The reference to the growth of non-traditional programs demonstrated sensitivity to unfilled needs of current student systems. If these are incorporated into the Oracle product, it would benefit their college and university customers. And perhaps be available earlier than other alternatives.

Incorporating customer feedback on products is becoming a standard industry practice for consumer goods. If broadly implemented Clark’s innovation could change the relationship between higher education and software suppliers.

There is one concern. Oracle declined to answer the question whether the participants would be required to sign non-disclosure agreements. It they are, many of the benefits of the broad open communications found in open source development projects may be lost.


  1. The data on the shift from restrictive to permissive licensing suggests, but does not confirm, broader participation and use of software using permissive licenses. edX may want to consider relicensing the learning platform itself using an Apache license to attract more users of its software
  2. Kuali Inc.’s experience introducing the Aferro license demonstrates how restrictions can be perceived based, in part, on the intent of the copyright holder. The many yet-undefined terms that could be a “cause of action” enabling a copyright holder to bring a legal action against a user presents risks that advice of a licensing specialist or an intellectual property attorney may be needed to fully understand.
  3. Oracle Higher Education may benefit colleges and universities by introducing broad collaboration similar to open source communities. That should be encouraged. But implementation may be fragile in the sense participants, users, and prospects are likely sceptical of success. Complete transparency and open communication about the work of the Strategic Design Program may make the true purpose better known and results more widely used.

The emergence of “intellectual property”—software licenses in these cases—has created monetary incentives for copyright holders. Assessment of licensing restrictions and risks should now be incorporated into all information technology decisions.

This guest post is (c) Jim Farmer, and is licensed under the Creative Commons Attribution 4.0 International license. The graphic in Figure 4 is by Donnie Berkholz of RedMonk, and licensed under the Creative Commons Attribution ShareAlike 3.0 license.

Open or Fauxpen? Use the OSS Watch Openness Rating tool to find out

Open  sign with "Sorry We're Closed" sign beneath it

Is your software open or fauxpen?

This is the question that OSS Watch, in partnership with Pia Waugh, developed the Openness Rating to help you find out.

Using a series of questions covering legal issues, governance, standards, knowledge sharing and market access, the tool helps you to identify potential problem areas for users, contributors and partners.

Unlike earlier models designed to evaluate open source projects, this model can also be applied to both open and closed source software products.

We’ve used the Openness Rating internally at OSS Watch for several years as a key part of our consultancy work, but this is the first time we’ve made the app itself open for anyone to use. It requires a fair bit of knowledge to get the most out of it, but even at a basic level its useful for highlighting questions that a project needs to be able to answer.

Get started with the Openness Rating tool.

Photo by Alan Levine used under CC-BY-SA.

New open source organisation launches in China

This week saw the launch of KAIYUANSHE (开源社), an association comprising both companies and universities with the aim of providing developers in China with education, tools and services to foster a healthy and robust open source ecosystem.

KAIYUANSHE from the outset is working through two core programs. The first, Open Source Star, helps software developers apply an open source license to their projects, and specifically recognize those that use one of the several available OSI-approved licenses.

The second program is called Open Source Ambassadors. Through this program, the alliance aims to recognize individuals and organizations who are actively engaged in community efforts, for their work to champion best practices and collaboration.

At OSS Watch here at the University of Oxford we’ve also been collaborating with the new initiative, providing access to our content and tools so that they can be localised and translated. You can find Chinese versions of some of our briefing notes on the KAIYUANSHE website already, and I’m sure more will soon follow.

Initial members of the association include Ubuntu Kylin, Microsoft Open Technologies, GitCafe, CSDN and Mozilla. For more information visit the KAIYUANSHE website.

You can also check out the press coverage of the launch (in Chinese) at EvolifeZOL and ChinaByte.

Locked into Free Software? Unpicking Kuali’s AGPL Strategy

Chuck Severance recently published a post entitled How to Achieve Vendor Lock-in with a Legit Open Source License – Affero GPL where he criticises the use of AGPL licenses, particularly its use – or at least, intended use – by Kuali. Chuck’s post is well worth reading – especially if you have an interest in the Kuali education ERP system. What I’m going to discuss here are some of the details and implications of AGPL, in particular where there are differences between my take on things and the views that Chuck expresses in his post.


image by subcircle CC-BY

Copyleft licenses such as GPL and AGPL are more restrictive than the so-called permissive licenses such as the Apache Software License and MIT-style licenses. The intent behind the additional restrictions is, from the point of view of the Free Software movement, to ensure the continuation of Free Software. The GPL license requires any modifications of code it covers to also be GPL if distributed.

With the advent of the web and cloud services, the nature of software distribution has changed; GPL software can – and is – used to run web services. However, using a web service is not considered distributing the software, and so companies and organisations using GPL-licensed code to run their site are not required to distribute any modified source code.

Today, most cloud services operate what might be described as the “secret source” model. This uses a combination of Open Source, Free Software and proprietary code to deliver services. Sometimes the service provider will contribute back to the software projects they make use of, as this helps improve the quality of the software and helps build a sustainable community – but they are under no obligation to do so unless they actually choose to distribute code rather than use it to run a service.

The AGPL license, on the other hand, treats deployment of websites and services as “distribution”, and compels anyone using the software to run a service to also distribute the modified source code.

AGPL has been used by projects such as Diaspora, StatusNet (the software originally behind – it now uses, the CKAN public data portal software developed by the Open Knowledge Foundation, and MIT’s EdX software.

[UPDATE 20 September 2014: EdX has since relicensed its AGPL component under the Apache License]

We’ve also discussed before on this blog the proposition – made quite forcefully by Eben Moglen – that the cloud needs more copyleft. Moglen has also spoken in defence of the AGPL as one of the means whereby Free Software works with cloud services.

So where is the problem?

The problem is that the restrictions of AGPL, like GPL before it, can give rise to bad business practice as well as good practice.

In a talk at Open World Forum in 2012, Bradley Kuhn, one of the original authors of AGPL, reflected that, at that time, some of the most popular uses of AGPL were effectively “shakedown practices” (in his words). In a similar manner to how GPL is sometimes used in a “bait and switch” business model, AGPL can be used to discourage use of code by competitors.

For example, as a service provider you can release the code to your service as AGPL, knowing that no-one else can run a competing service without sharing their modifications with you. In this way you can ensure that all services based on the code have effectively the same level of capabilities. This makes sense when thinking about the distributed social networking projects I mentioned earlier, as there is greater benefit in having a consistent distributed social network than having feature differentiation among hosts.

However, in many other applications, differentiation in services is a good thing for users. For an ERP system like Kuali, there is little likelihood of anyone adopting such a system without needing to make modifications – and releasing them back under AGPL. It would certainly be difficult for another SaaS provider to offer something that competes with Kuali  using their software based on extra features, as any improvements they could make would automatically need to be shared back with Kuali anyway. They would need to compete on other areas, such as price or support options.

But back to Chuck’s post – what do we make of the arguments he makes against AGPL?

If we look back at the four principles of open source that I used to start this article, we quickly can see how AGPL3 has allowed clever commercial companies to subvert the goals of Open Source to their own ends:

  • Access to the source of any given work – By encouraging companies to only open source a subset of their overall software, AGPL3 ensures that we will never see the source of the part (b) of their work and that we will only see the part (a) code until the company sells itself or goes public.
  • Free Remix and Redistribution of Any Given Work – This is true unless the remixing includes enhancing the AGPL work with proprietary value-add. But the owner of the AGPL-licensed software is completely free to mix in proprietary goodness – but no other company is allowed to do so.
  • End to Predatory Vendor Lock-In – Properly used, AGPL3 is the perfect tool to enable predatory vendor lock-in. Clueless consumers think they are purchasing an “open source” product with an exit strategy – but they are not.
  • Higher Degree of Cooperation – AGPL3 ensures that the copyright holder has complete and total control of how a cooperative community builds around software that they hold the copyright to. Those that contribute improvements to AGPL3-licensed software line the pockets of commercial company that owns the copyright on the software.

On the first point, access to source code, I don’t think there is anything special about AGPL. Companies like Twitter and Facebook already use this model, opening some parts of their code as Open Source, while keeping other parts proprietary. Making the open parts AGPL makes a difference in that competitors also need to release source code, so I think overall this isn’t a valid point.

On the second point, mixing in other code, Chuck is making the point that the copyright owner has more rights than third parties, which is unarguably true. Its also true of other licenses too. I think its certainly the case that, for a service provider, AGPL offers some competitive advantage.

Chuck’s third point, that AGPL enables predatory lock-in, is an interesting one. There is nothing to prevent anyone from forking an AGPL project – it just has to remain AGPL. However, the copyright owner is the only party that is able to create proprietary extensions to the code without releasing them, which can be used to give an advantage.

However, this is a two-edged sword, as we’ve seen already with MySQL and MariaDB; Oracle adding proprietary components to MySQL is one of the practices that led to the MariaDB fork. Likewise, if Kuali uses its code ownership prerogative to add proprietary components to its SaaS offering, that may precipitate a fork. Such a fork would not have the ability to add improvements without distributing source code, but would instead have to differentiate itself in other ways – such as customer trust.

Finally, Chuck argues that AGPL discourages cooperation. I don’t think AGPL does this any more than GPL already does for Linux or desktop applications; what is new is extending that model to web services. However, it certainly does offer less freedom to its developer community than MIT or ASL – which is the point.

In the end customers do make choices between proprietary, Open Source, and Free Software, and companies have a range of business models they can operate when it comes to using and distributing code as part of their service offerings.

As Chuck writes:

It never bothers me when corporations try to make money – that is their purpose and I am glad they do it. But it bothers me when someone plays a shell game to suppress or eliminate an open source community. But frankly – even with that – corporations will and should take advantage of every trick in the book – and AGPL3 is the “new trick”.

As we’ve seen before, there are models that companies can use that take advantage of the characteristics of copyleft licenses and use them in a very non-open fashion.

There are also other routes to take in managing a project to ensure that this doesn’t happen; for example, adopting a meritocratic governance model and using open development practices mitigates the risk of the copyright owners acting against the interests of the user and developer community. However, as a private company there is nothing holding Kuali to operate in a way that respects Free Software principles other than the terms of the license itself – which of course as copyright owner it is free to change.

In summary, there is nothing inherently anti-open in the AGPL license itself,  but combined with a closed governance model it can support business practices that are antithetical to what we would normally consider “open”.

Choosing the AGPL doesn’t automatically mean that Kuali is about to engage in bad business practices, but it does mean that the governance structure the company chooses needs to be scrutinised carefully.

Kuali governance change may herald end of ‘Community Source’ model

For quite some time now at OSS Watch we’ve struggled with the model of “Community Source” promoted by some projects within the Higher Education sector. Originating with Sakai, and then continuing with Kuali, the term always seemed confusing, given that it simply meant a consortium-governed project that released code under an open-source license.

As a governance model, a consortium differs from both a meritocracy (as practised by the Apache Software Foundation) or a benevolent dictatorship, or a single-company driven model. It prioritises agreement amongst managers rather than developers, for example.

We produced several resources (Community Source vs. Open Source and The Community Source Development Model) to try to disambiguate both the term and the practices that go along with it, although these were never particularly popular, especially with some of the people involved in the projects themselves. If anything I believe we erred on the side of being too generous.

However, all this is about to become, well, academic. Sakai merged with JaSig to form the Apereo Foundation, which is taking a more meritocratic route, and the most high-profile project using the Community Source model – the education ERP project Kuali – has announced a move to a company-based governance model instead.

I think my colleague Wilbert Kraan summed up Community Source quite nicely in a tweet:

‘Community source’ probably reassured nervous suits when OSS was new to HE, but may not have had much purpose since

Michael Feldstein also provides a more in-depth analysis in his post Community Source Is Dead.

There’s good coverage elsewhere of the Kuali decision, so I won’t reiterate it here:

A few months ago we had a conversation with Jisc about its prospect to alumnus challenge, where the topic of Kuali came up. Back then we were concerned that its governance model made it difficult to assess the degree of influence that UK institutions or Jisc might exercise without making a significant financial contribution (rather than, as in a meritocracy, making a commitment to use and develop the software).

Its hard to say right now whether the move to a for-profit will make things easier or more difficult – as Michael points out in his post,

Shifting the main stakeholders in the project from consortium partners to company investors and board members does not require a change in … mindset

We’ll have to see how the changes pan out in Kuali. But for now we can at least stop talking about Community Source. I never liked the term anyway.

Ohloh to be renamed Black Duck Open Hub

Here at OSS Watch we’re big fans – and users – of Ohloh, the site that helps you analyze open source software repositories, for example when evaluating the sustainability of projects.

Since Black Duck bought the site back in 2010 there haven’t been any obvious changes.

Until now that is:

Dear Ohloh user, 


We would like you to be the first to know of an exciting update to This week, Ohloh will be changing its name to the Black Duck Open Hub.

Since 2010, we have supported the Ohloh community, now consisting of over 250,000 users, with a stream of new features and functions – all to remain freely available. The name change to Black Duck Open Hub reflects an increasing commitment on our part to the developer community, as well as anyone who wants to learn about the world of open source.

So, goodbye Ohloh, hello Black Duck Open Hub!

I have to admit it doesn’t exactly roll off the tongue that easily, and I’m not looking forward to correcting all the mentions of it in various OSS Watch publications either, but hey, things move on!

Open Source Phones at MWC

Mobile World Congress is running this week in Barcelona.  While it’s predicable that we’ve seen lots of Android phones, including the big unveiling of the Galaxy S5 from Samsung, I’ve found it interesting to see the coverage of the other devices powered by open source technologies.

Mozilla announced their plans for a smartphone that could retail for as little as $25. It’s based on a new system-on-chip platform that integrates a 1GHz processor, 1GB of RAM and 2GB of flash memory, and will of course be running the open source Firefox OS.  It’s very much an entry level smartphone, but the $25 price point gives real weight to Mozilla’s ambition to target the “next billion” web users in developing countries.

Ubuntu Touch is finally seeing the light of day on 2 phones, one from Chinese manufacturer Meizu and one from Spanish manufacturer Bq.  Both phones are currently sold running Android, but will ship with Ubuntu later this year.  The phones’ internals have high-end performance in mind, with the Meizu sporting an 8-core processor and 2GB of RAM, clearly chosen to deliver Ubuntu’s fabled “convergence story”.

There’s been rumours abound this year that Nokia have been planning to release an Android smartphone, and they confirmed the rumours were true at MWC, sort of.  “Nokia X” will be a fork of Android with its own app store (as well as third-party ones) and a custom interface that borrows elements from Nokia’s Asha platform and Windows Phone.  Questions were raised at the rumour mill over whether Microsoft’s takeover of Nokia’s smartphone business would prevent an Android-based Nokia being possible.  However, Microsoft’s vice-president for operating systems Joe Belfiore said “Whatever they do, we’re very supportive of them,” while Nokia’s Stephen Elop maintains that the Windows-based Lumia range is still their primary smartphone product.

A slightly more left-field offering comes in the shape of Samsung’s Gear 2 “smartwatch” running Tizen, the apparently-not-dead-after-all successor to Maemo, Meego, LiMo, and all those other Linux-based mobile operating systems that never quite made it.  The device is designed to link up to the Samsung Galaxy range of Android phones, but with the dropping of “Galaxy” from the Gear’s branding, perhaps we’ll be seeing a new brand of Tizen powered smartphones from Samsung in the future.

Leveling the playing field for open source in education and public sector

Last week I presented at ALT-C in Nottingham on the topic of open source in education and the public sector.

This was partly to invite people to participate in Open Source Options for Education, and partly to open up discussions around software procurement policies and processes in the sector.

The discussion tended to confirm our survey findings that the practice of procurement including open source options varies a lot within institutions, resulting in different biases (both for and against FOSS). So the degree to which FOSS is considered for procurement in education can be quite different depending on who you’re dealing with. To get a more balanced approach to closed and open source software would therefore require engagement with all of the different groups engaged in software procurement to develop their understanding and practices.

Here’s the slides:

BBC creates HTML5 TV appliance

The BBC R&D labs have recently been busy working on a TV prototyping appliance called the egBox. The idea behind it is to create a minimum viable product of a HTML5-based TV as the base platform for experimenting with new features.

The appliance uses HTML 5, the WebM video codec, runs services using Node.js, and is being used as the basis for various technology experiments at the BBC. The  set of components used by the egBox is one that many developers will be familiar with – node, redis,, backbone.js – on top of which the developers are working on areas such as TV authentication.

What is interesting is that, while the idea is to create a minimum viable TV product as the basis of other prototypes, the nature of the egBox stack suggests lots of interesting ways to extend it. For example, as it uses Node.js, you might make use of the Webinos platform to offer apps.

At the time of writing the egBox code is not open source; however, that is the eventual plan.

The usual sticking point for any foray into TV using open source is actually working with TV services themselves. The “Smart TV” space not only has a whole raft of competing and conflicting standards, but most of the consortia operate on a paid membership basis, some even requiring signing NDAs to read the documentation; this is something I covered in a post a few years ago.

Things have improved since then, but there is still a long way to go. Ironically, a W3C standard for encrypted media content might actually be a good thing – or at least, a less-bad-thing – for open source TV, as W3C standards are royalty-free and publicly available unlike many of the specifications developed within the TV industry.

The upshot is that any open source project looking to work with a good range of TV services is likely to have to pony up some membership fees, and potentially keep some important parts of the codebase closed source to avoid issues with partners and consortia.

Still, its going to be interesting to see whats possible with the egBox.

You can find out more on the egBox over at the BBC’s R&D blog.

How “open source” is the Minnowboard?

This week, Intel announced the Minnowboard, a small embedded development board akin to the RaspberryPi, BeagleBoard and similar devices. The point that grabbed my attention is that it’s being touted as an “open source computer”. The device is shipped running Ångström and is compatible with the Yocto project for building custom embedded Linux systems, but while there are many devices available that run Linux, the term “open source computer” is seldom bandied about. So just how “open source” is the Minnowboard?

The minnowboard viewed from above, with labelled external interfaces

The Minnowboard from above

For a start, the board uses Intel chips, which is usually a good sign that the drivers required will be open source, without requiring any binary blobs in the Linux kernel. Furthermore, the UEFI system is open source. This is the code which executes when the computer first powers up and launches the operating system’s boot loader, and making this open source allows hackers to write their own pre-OS applications and utilities for the Intel platform, an opportunity we don’t often see on consumer devices.

Update: Scott Garman’s comment below clarifies the situation regarding graphics drivers and initialisation code.  A proprietary driver is required for hardware accelerated graphics.

However, moving away from the software, there’s a clear message that the Minnowboard is meant to be “open source hardware”. There are of course competing definitions from groups like OHANDA and OSHWA as to what qualifies as “open hardware” and “open source hardware” – one we heard at Open Source Junction included that all components should be available from multiple sources which is never going to be the case here – but a reasonable metric in this case would be, “is one free to modify the design and make a similar device?”.

The language on the site certainly seems to suggest that this is the intention. The Minnowboard Design Goals page clearly states:

Our goal was to create a customizable developer board that uses Intel® Architecture and can be easily replicated. It is a simple board layout that lends itself to customization. The hardware design is open. We used open source software as much as possible. We used standard (not cutting edge) components that are in stock and affordable, to keep the cost down.

Also, the introductory video explicitly says that the technical documentation will be available under Creative Commons licenses allowing people to modify the designs without signing an NDA.
That said, this documentation isn’t currently on the website, the only reference is a notice saying that “By August 2013 we will post all board documentation, software releases, links to Google Group forums, where to buy, and information of interest to the community.” We’ll just have to be patient.

Update: The schematics, design files and bill of materials are now available on the Technical Features page of the Minnowboard website.

Minnowboard with a type-C lure expansion template attached.

There are 3 formats for “lure” expansion boards – the Type C template here shows the smallest.

Another vector to openness for the Minnowboard is the opportunity to create daughter boards dubbed lures. These are akin to Arudino shields and allow additional components to be plugged in to the main board to expand its capabilities. There’s already several designs taking shape, and there’s certainly the potential for a community to arise around creation of these lures.

What Intel have produced is an open platform with standard components and interfaces for prototyping and developing embedded systems. Unlike the RaspberryPi which is designed as a learning device, the Minnowboard’s design (once released) could represent a starting point for both hobbyist projects and commercial products, without any royalties to be paid to its original designers (except, of course, that you’ll need to buy your chips from Intel). From Intel’s point of view, this is clearly a move to gain traction in the ARM-dominated market of embedded systems. As far as calling it an “open source computer” goes, once the designs are published, I think they’ll have done a pretty good job to justify the term.

Images from Minnowboard Wiki users Jayneil and Prpplague, used under CC-BY-SA.