Anniversaries

[This post was pre-recorded.]

Today, March 31st, is the logical anniversary of three significant beginnings, all of which are wonderful.

Firstly, it’s the logical anniversary of the start of Mozilla. There are several significant dates here – the organization itself was created on February 23rd – but historically we have always remembered the day at the end of Code Rush, the day when the source code became available to the public – March 31st 1998, 15 years ago today. Because that’s the primary way we do what we do – we make great open source software and give it to people. And while the software that was released that day may not have been great in many ways (we threw a lot of it out some time later), it had the seeds of greatness within it. We’ve come a long way from there to Firefox OS, and we should pause and recognise our achievement.

Secondly, it’s the logical anniversary of my engagement to Ruth – a seed which has flowered into a happy marriage and two lovely sons. We got engaged on Easter Sunday 2010 (which, that year, was 4th April) and so we like to celebrate at Easter each year.

And no post about today would be complete without recognising that Easter Day is, of course, the logical anniversary of the day Jesus rose from the dead. The Easter story is how he does what he does – he provides salvation, hope and joy for all who come to him, by dying in their place and rising from the dead, conquering death. In doing so he also planted a seed, which has now grown into a worldwide church, hundreds of millions strong.

So all in all, a great day, and hopefully one which will be marked by peace and harmony. Happy Easter!

Mozilla is now a member of OASIS

Mozilla recently joined OASIS, in order to take part in some work on the PKCS#11 cryptography standard which is being hosted there. So if any Mozillian has an interest in anything else OASIS are doing, we now have the capability to get you involved.

So if we roll with it, and take our time, then we’ll live forever. After all, it’s our wonderwall.

Why The Smart People Leave A Forum

There will be no explosion when forums reach [a] breaking point. There is just a quiet negative feedback effect: people unsubscribe from the lists, or leave the IRC channel, or at any rate stop bothering to ask questions, because they can see they won’t be heard in all the noise. As more and more people make this highly rational choice, the forum’s activity will seem to stay at a manageable level. But it is staying manageable precisely because the rational (or at least experienced) people have started looking elsewhere for information—while the inexperienced people stay behind and continue posting. In other words, one side effect of continuing to use unscalable communications models as the project grows is that the average quality of both questions and answers tends to go down, which makes it look like new users are dumber than they used to be, when in fact they’re probably not. It’s just that the benefit/cost ratio of using those high-population forums goes down, so naturally those with the experience to do so start to look elsewhere for answers first. Adjusting communications mechanisms to cope with project growth therefore involves two related strategies:

  • Recognizing when particular parts of a forum are not suffering unbounded growth, even if the forum as a whole is, and separating those parts off into new, more specialized forums (i.e., don’t let the good be dragged down by the bad).
  • Making sure there are many automated sources of information available, and that they are kept organized, up-to-date, and easy to find.

– Karl Fogel, Producing Open Source Software

“Understanding Mozilla: Communications” v0.1

On February 27th, I blogged my intention to produce a 5-minute Popcorn short on communications in Mozilla. I got most of it done before other exciting events intervened (3 days early :-) so there has been a small delay but now I have a version 0.1 to share with you. Please comment with improvements.

It has a number of known issues:

  • The voice-over is a bit pedestrian in tone
  • Needs a better video to demonstrate IRC (ideally of Mozilla IRC)
  • Needs a better video to demonstrate Vidyo (currently using a section of a weekly meeting, which isn’t really Vidyo)
  • Some screenshots contain mouse pointers

Feel free to remix it and fix any or all of these things; that’s the beauty of Popcorn Maker!

While making it, I found several bugs/made several suggestions for enhancement in Popcorn, which were gratefully accepted by the developers.

Yay for open source :-)

John Phinehas Markham

I am pleased to announce the birth of John Phinehas Markham at 10.55pm on the evening of 10th March 2013, Mother’s Day, weighing 8lb 3.5oz. Mother, father, baby and older brother are all well :-)

He is called John after:

  • John the Apostle, who wrote the Gospel of John, the Epistles of John and the Book of Revelation, all of which provide invaluable divinely-inspired guidance to the church;
  • John Calvin, whose Biblical scholarship and preaching underpinned much of the Reformation, that glorious time when half the world rediscovered the truth of salvation by faith;
  • John Wycliffe, one of the forerunners of that Reformation, who created and directed the first translation of the Bible into vernacular English;
  • G. C. John Rotter, Ruth’s grandfather, a godly man who served as an engineer in World War II and brought Ruth’s father up in the faith;
  • Admiral John Markham, second son of Archbishop William Markham (after whom his brother is named), who served his country in the navy and then became MP for Portsmouth.

He is called Phinehas after the priest whose rather striking story (pun intended) is told in the Biblical book of Numbers, chapter 25. God’s and our approval of that Phinehas may surprise or shock some; I’ve written a little more elsewhere about why we think he is a wonderful person to be named after.

To my eyes, John looks nothing like his brother (and so not much like me either), so we’ll have to see if he is as different in personality also!

Bugzilla API 1.3 Released

I am proud to announce the release of version 1.3 of the Bugzilla REST API. This maintenance release has a bug fix or two, and fully supports the version of Bugzilla 4.2 which has just been deployed on bugzilla.mozilla.org. For smooth interaction with BMO, you should be using this version.

The installation of BzAPI 1.1 on api-dev.bugzilla.mozilla.org will go away in 4 weeks, on 4th April. There is a limit to the number of old versions we can support on the server, particularly as the older ones can put a larger load on Bugzilla and may not work correctly. Please use either the /1.3 or the /latest endpoints. Now that BzAPI has been stable for some time, tools which earlier rejected using the /latest endpoint may want to reconsider.

File bugs | Feedback and discussion

mozregression

Kudos to k0s and sinemetu1, the current maintainers of mozregression, an idiot-proof script for helping you find the regression range for a bug. Give it two dates, and it automatically downloads and runs a nightly and, when you exit, asks you whether the bug is present or not and downloads another build accordingly, until you have a 24 hour window identified. And then it says “do you want to compile some code to narrow it down even more?”. Awesome.

(More regression-hunting tools.)

Web Standards Project Shuts; Not Paying Attention?

The WaSP has closed its doors, with a post titled “Our Work Here Is Done“:

Tim Berners-Lee’s vision of the web as an open, accessible, and universal community is largely the reality.

If by the web you mean “the desktop web”, then things are undeniably much better than they used to be. But what about the mobile web? Opera just shifted to WebKit precisely because the vision of Tim and the Web Standards Project is not a reality. Did they notice that happening?

They later go on to almost say the opposite:

The job’s not over, but instead of being the work of a small activist group, it’s a job for tens of thousands of developers who care about ensuring that the web remains a free, open, interoperable, and accessible competitor to native apps and closed eco-systems.

When was it not, in the end, up to developers? It’s always been up to the developers, and it was the case that the WaSP helped them. Seemingly no more.

I also saw this news on the same day that Lawrence Mandel posted a call for help with the numerous problems we are having due to people coding mobile websites which assume “Android”. That needs to change, and you can help. Is Mozilla now the flag bearer for web standards? Former WaSPers, join us and help out :-)

First Boot2Gecko White Label

This, I would suggest, is a sign of success. Firstly, it’s more people (to add to the 22 major companies on stage at MWC) who think our OS is good enough to compete and ship. Secondly, they are doing it without abusing our trademarks. Third, this is what open source is all about. We hope they’ll come and join our community and help make the code better. (And we need to work to make sure that’s easy for them to do.)

I note their screenshots are pretty hacked together, though; has no-one told them Boot2Gecko doesn’t use a hardware Back button or Search button? :-)

(Thanks to nukeador for the link.)

Understanding Mozilla: Communications

I’m running with my “Understanding Mozilla” idea – 5-minute shorts to explain things about the Mozilla project to new or existing participants.

Things at Mozilla change a lot; therefore, altering the presentation to fix bugs or incorporate new material should be easy. Therefore, it makes a lot more sense to use a “voiceover plus” approach, and to build it using Popcorn rather than as a compiled video that has to be re-edited in heavy duty video-editing software each time.

So, each short will be:

  • 5 minutes max
  • Scripted voiceover combined with stills, video and/or overlaid text
  • Script written collaboratively in wiki
  • Constructed using popcorn.js and Popcorn Maker
  • Easily remixable and rebuildable if things change

Here’s a draft script for the first one, on the subject of “Communications”. I expect that as I go through this process I’ll also be able to provide good feedback to the Popcorn team, which is all to the good.

Comments welcome, as are suggestions for future topics.

An Introduction to Modern Open Source Licence Patent Clauses

I bet that title sent shivers of pure pleasure up and down your spine, didn’t it? :-) This post explains why all modern open source licences have patent clauses, what they do (and don’t do), and why you should use and recommend licences which contain them. This question is relevant to discussions of licence choice.

I am not a lawyer, although I do sometimes play one in real life. If in doubt, consult the real deal.

This analysis will focus on the 3 most popular modern licences with patent clauses – the Apache License 2.0 (“APL”), the Mozilla Public License 2.0 (“MPL”), and the GNU General Public License 3.0 (“GPL”).

What Do They Do?

The APL (section 3) and the MPL (section 2.1, 1.11, 1.2, 1.3) say that if you make a contribution to the code, you have to grant all users a licence to any patent you hold which is infringed by your contribution, or by the whole thing as a result of adding your contribution. In the case of the GPL (Section 11, para 2), you have to grant a licence to any patent you hold which is infringed by any part of the modified work, at the time you contributed to it, whether you wrote or changed that part or not. So the GPL’s grant is wider in scope than the other two.

The above affects contributors. There are also clauses which relate to users. In the case of the MPL (section 5.2) and the GPL (section 10, para 3), you lose your right to use the software at all if you launch a patent suit against someone else regarding that software. In the case of the APL (section 3), you lose any patent licences you might have got to the code (which may be none), but you don’t lose your copyright rights.

What Don’t They Do?

In the case of the APL and MPL, they don’t make a contributor grant a licence to patents which the code already implemented before they came along, or which someone else made the code implement while they were contributing. In all cases, if the code is changed in the future by someone else to implement a patent, the licences don’t make the contributor grant a licence to that patent. (I.e. if BigCorp has a patent on the Bar algorithm, and they contribute some non-Bar-related code to project Foo, you can’t get a free license to the Bar patent by changing Foo to implement it.) And they don’t protect you at all from the patents of people who are neither contributors nor users, including patent trolls.

Why Are They Good?

  • They provide some protection to stop one member of the community suing another one. This particularly applies to the MPL and GPL, which rescind all rights (including copyright rights) to the code when a suit is filed, thereby giving the small, patentless guy some power when this happens.
  • Relatedly, they make big companies much more comfortable about collaborating on a codebase together. Without a patent licence, the first big company you recruit to work on your code will scare off any additional ones, because they are concerned about the first company’s patents.
  • If your code is widely-enough used, it provides some protection from third parties who would not want to lose their rights to use it.

Patent clauses do not solve the software patent problem. But they do mitigate it and, in the presence of the problem, they do help build collaborating communities. That is why all modern open source licences have a patent clause, and why you should only use and promote licences which have them, and encourage others to do the same.

Relicensing: When Do You Have To Ask?

When an open source project or codebase is considering a move from one licence to another, one question which may affect whether they go ahead or not is whether they have to track down and ask permission of all the contributors. (Another question is how many people will be upset by the change; that is out of scope here. This post is about what is possible, not about what is wise.)

By “relicensing”, I mean “make it so that the code can only be used by following the terms of the new licence”. This is distinct from dual-licensing, where the code can be used under either set of terms. For example, jQuery is dual-licensed MIT/GPL, and so it can be used and redistributed under MIT, or GPL, or both.

When you relicense, you may have to continue following the terms of the old license as well, or you may not – it depends on the exact licences concerned. If a project moves from the MIT licence to the GPL licence, users would need to obey both sets of terms – although the MIT requirements are a tiny subset of the GPL ones; the only relevant term in the MIT licence is “preserve this notice”. By contrast, if a project moves from LGPL 2.1 to GPL, as permitted by LGPL section 3, then you delete the LGPL boilerplate and replace it with the GPL one, and only GPL terms apply from then on.

So when do you have to ask in order to relicense? You don’t have to ask if:

  • The project has formally aggregated copyright (e.g. each contributor has signed a CLA), and the aggregate copyright holder agrees; or
  • The move is to a later version of the same licence, and either the license allows that (e.g. the MPL), or the license boilerplate on the files permits it (e.g. the standard GPL boilerplate); or
  • The move is to a “compatible” license.

The last bullet is a tricky one; what makes two licenses, A and B, compatible? “Compatible” is a word used with regard to licences in a number of senses. Here, I mean that it’s possible to migrate from users/distributors being required to obey License A to users/distributors being required to obey License B (and possibly A as well; see above). The first thing to note is that compatibility of this sort is not symmetric – A → B does not imply B → A. To be certain in any case requires an analysis of the two texts, but in general:

  • Two permissive licenses are compatible if the terms of A are a subset of, or can be complied with at the same time as, the terms of B.
  • Permissive licenses are usually compatible with copyleft licenses, with the notable exception (according to the FSF) of Apache Public License 2.0 → GNU General Public License 2.0.
  • Two copyleft licenses are not compatible unless A has a specific provision which allows relicensing under B.
  • Copyleft licenses are never compatible with permissive licenses (that would destroy the copyleft).

Being specific, the following compatibility diagram, while incomplete, may help with the most common open source licenses. “+” means “or later” where such a clause is optional.

MIT/BSD → Apache 2.0 → MPL 2.0 → LGPL 2.1+ → GPL 2.0+
                                      ↓         ↓
                                 LGPL 3.0+ → GPL 3.0+ → AGPL 3.0+

This diagram is meant as a guide only, and does not cover some particular twists; for example, it does not reflect the Apache 2.0/GPL 2.0 incompatibility, and you can only relicense from the MPL to a GPL license if you combine with existing GPLed code and dual-license the MPLed part. But it gives the general idea.

A separate question is: what boilerplate headers do I put on the relicensed files? A big part of that question is whether you end up having to obey both licences or just the new one, and that depends on the two licences concerned. So this question is complicated enough that it’s best to ask for advice for any specific case. (But implementing the answer is probably a lot easier than chasing down hundreds of contributors!)

Join the Organ Donor Register

A friend who will soon need a double lung transplant (due to a genetic illness) tells me:

96% of people believe donating organs is the right thing to do but only 30% have joined the NHS Organ Donor Register. 1 in 2 people die on the double-lung waiting list.

Please take a few minutes to sign up. If you are in the UK, see here. If not, do a web search for the register in your country. (Sadly, they won’t take my organs, but they will probably take yours.)

No One Considered…

Micire’s talk was an excellent example of what can happen when a device maker doesn’t lock down its device. It seems likely that no one at Google or Samsung considered the possibility of the Nexus S being used to control space robots when they built that phone. But because they didn’t lock it down, someone else did consider it—and then went out and actually made it happen.

LWN (an awesome publication; do subscribe)