Why I Care About Licensing

Both on the blog and on Twitter, I have ranted at length at projects missing licensing information altogether, or not providing licensing information on specific files, or providing conflicting licensing information. As you can imagine, this is a topic that I’m very attached to, which is why I have been following REUSE guidelines to make sure that all my (currently active) projects follow the specification.

Unfortunately this care is not shared with many developers, even those who consider themselves part of the Free Software movement, and this causes friction, poisons the well in both directions, and overall is detrimental to the community and the movement. Even more so than when people care deeply and disagree on the “correct” licensing terms.

While I am most definitely not a lawyer, and I speak most definitely only for myself and not my employer, let me try to give you a run down of what’s going on here.

First of all, we need to start with a simplification, and handwavey accept that without an explicit license allowing it, the distribution, modification, and integration of source code is not allowed, or at least that’s the way we perceive it in the wider world. And Free Software licenses, more or less permissive, spell out the terms with which distribution and usage are allowed.

It Is But An Example

As far as I can tell, there’s no provision anywhere that source code used in documentation is exempt from these limitations, except insofar as the license on the documentation itself would apply if not otherwise overridden. And that’s how I started engaging with Adafruit: the documentation for most of their CircuitPython libraries provide a lot of useful examples — and as it turns out they were already released with an open-source license (MIT), but that was not obvious when looking at the docs sites themselves. So I convinced them to add SPDX headers to all their source code, including the examples — and now you can read the example and see immediately which license it’s released under. Isn’t that cool?

Unfortunately, sometimes developers are stubborn and find adding two lines to their documentation examples a distraction, and argue against it, making it annoying for others to use their example source code without either infringing the copyright or going the long way to find the right answers.

Websites, PDFs, Books, they are all equal

But this goes to the double for code that is explicitly written only as example material! Let me take a bit of a detour — my wife went through the awesome Python Crash Course a few months ago. While it suffers from a few of the issues I already complained about when it comes to splitting names, the book is fairly well written and has hands-on exercise that provide enough of a stretch to “my first Python project”. In the later parts of the book, one of the long-building exercise is writing a clone of Space Invaders with PyGame, which turned out to be interesting not just for her writing it, but for myself reviewing it as well, as game programming is definitely not a skill I ever spent time acquiring.

Now, remember I said there’s space to stretch? While the book guides you through building the very basic framework for “Alien Invasion” with full code to go with it, it leaves a lot of holes to be filled. Not just the assets (that it pretty much suggests you Google for and find somewhere online, without any discussion on what you can and cannot use — shout out to the Noun Project which I use for my own projects nowadays), but also some of the more advanced gameplay, and a lot of the refactoring — the way you write the game following the book is definitely more aimed at teaching than at maintaining. So when my wife finished with the book, I started showing her examples of how to refactor the code and introduce new features. So while the basic skeleton is the same as the original from the book, the version she ended up with was nearly fully rewritten. And it’s all in a Git repository!

But she has nothing to show for it. The source code in the book does not provide any licensing information. When I reached out to Eric Matthes (the book’s author) on Twitter asking him if he’d consider applying an opensource license to the code, so that she could publish it on her GitHub account to show off to some of her friends – and with an explicit mention that I’d have liked to use it as a base to test out BeeWare projects and see to contribute to some – he said he’d think about it, but that he wouldn’t feel right to release it under a permissive license that would allow someone to take it and sell it on AppStore and similar. So her options are to ignore licensing and publish the code anyway (after all, nobody cares, and I’m sure I can find plenty of people who did exactly that), or to comply with the (lack of) license and keep it for herself, and only show her friends a video of it working. She went for the latter, as we already had a long discussion of copyright when J Salmeron brought up the topic (and dang, we missed the opportunity to shake his hand as we were standing right behind him at the Beast in Black concert in Amsterdam last year!)

Provide It And They Will Build

There is one case that, personally, drained my will to contribute to an ecosystem even more than the example above. After all, Python Crash Course is a great book, and the only really good reason to publish the code is for “bragging rights” — which is not to say it’s not something, but it’s not the end of the world either.

When a commercial vendor is providing you with an extensible ecosystem for you to build upon, but doesn’t play by the same rules, it’s just… disappointing. In this case the issue is with Saleae, the manufacturer of the Logic Pro 16 analyzer I use for a bunch of different things. You may have noticed me providing screenshots off it when talking about fake candles and infrared. As a vendor, Saleae has very good user support: when I complained on Twitter that I wasted two hours chasing ghosts because I didn’t realise I forgot to connect the USB cable to the analyzer, and the software didn’t make it clear enough it was showing me demo garbage, they engaged, asked me what I would have done differently, and delivered the fix in less than a month. That was awesome support.

So where does it go wrong? Well, in June they updated their software to support Python-based extensions for analysis of specific protocols. I was actually interested in adding support for IR decoding to make my life easier in my TV controlling project, and so when they posted that one of their employees built a duty cycle measure tool and posted it on GitHub I was thrilled!

Except… the repository is there, the source code is there, but there is no license. The extension is pretty much a tutorial by itself on how to build what I needed, but it’s coming with no license attached, and as such I can’t use its code as a base for my own extension. And while I could possibly learn from it, it’s also a poison pill… there’s no license, if I copy it too literally, am I infringing copyright? Maybe, who knows? The author says I should «feel free to look, copy and use [his] Logic 2 extensions in any way [I] would like», but that’s not exactly a very comforting statement when you’re contributing while part of a company.

Final Thoughts

Just be yourself (this is pre-recorded). If you do care about Free Software, please take licensing seriously. If you don’t care about Free Software, because you don’t believe in the ideals behind, or you’re just not part of the ecosystem, then I can’t really blame you for disrespecting licenses, but then again if you rely on proprietary software license, you probably should respect all of them. It’s the same problem with software piracy.

I do believe that the folks at REUSE are doing a great service for all of us by making it possible to spell out licenses clearly and openly, and making it easy for others to modify and copy the code that we want to be out there in the world. It doesn’t take so much time to use the tool to add a few lines to a text file, or an additional text file for binary files. Please take the chance to sort this out!

REUSE: Simplifying Code Licensing

I have recently written how licensing is one of the important things to make it easy to contribute code. While I was preparing that blog post, I was also asking Matija if he knew of anything that would validate the presence of license and copyright information in new files. This is because in the past I might have forgotten it myself, and I have definitely merged a pull request or two in which a new contributor forgot to add the headers to the new files — I’m not blaming them, I’m not even blaming myself, I blame the fact that nothing stopped either us!

And indeed, Matija pointed at REUSE, which is a project by FSFE (which I still support, because they are positive!), and in particular at the reuse-tool, which includes a linter, which will ensure that every file in a repository is properly tagged with a license, either inline or (if not possible) through an explicit .license file. I love the idea.

The tool is still a bit rough around the edges, and for instance (because of the spec) it does not have any provision to ignore 0-sized files (or symlinks, as it turns out). Hopefully that can be fixed in the spec and the tool soon. When I started using it, it also didn’t know how to deal with any file that is there to support Autotools, which was clearly something I needed to fix, but that’s a minor issue — clearly the tool has focused on the stuff people care the most about, and Autotools projects are definitely going out of fashion, for good or bad.

I’ve now used reuse-tool to add proper licensing to all the files in most of the repositories that I’ve been actively working on. I say most — I have not touched usbmon-tools yet, because for that one I need to pay more attention, as the copyright not not fully mine. Which means that most likely even the silly configuration files that are unlikely to be copyrightable will have to be licensed under Apache 2.0.

Speaking of the configuration files — the FAQ I linked above suggests using CC0-1.0 license for them. I originally followed that and it took me a moment to remember that I should not do that. The reason is once again found in the previous post: CC0-1.0 is not an OSI-approved license, and that makes it impossible for some people (starting with my ex-colleagues at Google and other Alphabet companies) to contribute to the software, even if it’s just fixing my Travis CI configuration. Instead I selected MIT — which is pretty much equivalent in practice, even though not in theory. Update 2020-05-14: there’s some discussion of alternative recommendations going on right now. Considering that, I have changed my mind and will use Unlicense for configuration files, for the foreseeable future. As I said in the other post, Fedora prefers CC0-1.0, but it does not seem to be outright banned by any organization or project.

I did that for a number of my projects, including those under the python-scsi organization, and included it into a pending pull request I had already open for cachecontrol. Not all of them pass the linter clean yet, because of the 0-sized file issue I noted above. I also didn’t set them up to use pre-commit (despite Carmen adding support for it very quickly), because of that. But at least it’s a step in the right direction, for sure.

Speaking of pre-commit — one of the reasons why I wanted to have this is to make sure that the .license files are not left uncommitted. With the pre-commit check in place, the lint needs to pass for the staged changes rather than for the checked out tree. Once again, yay for automation.

I have to say that this push from FSFE — particularly because I have found myself unable to contribute to one of their projects before, because of missing licensing information on the repository. I also like the fact that they do care about getting people to use this, rather than making a purity tool for the sake of purity, which I’ve seen happening in other organisations. Again, score one for FSFE.

So if you have an open source project, and you want to make sure it’s easy for everyone, including those who may be working for big corporations, to contribute back, give a try to just setting this up with the tool. It should reduce significantly the cost of contribution, and even that of adoption.

Making it easy to contribute (code)

Now that I left one bubble, and before I join the next one, I thought it would be a good time to discuss one thing that would otherwise be perceived as a shill by many (I’m sure it still will, but at least I gave it a shot): how to make it easier for employers of big corporations (case in point, Google as I just left that) to make code contributions to your project.

I’ve heard complains, and in some cases complained myself, about big companies not contributing back improvements, or deciding to “do their own thing” rather than contribution to an already existing project. But after spending seven years working for them, I have a clearer idea that there’s a few things that the projects can do, to make it easier to take contributions. And because I don’t want to be thought as I’m talking of secret information, I’ll be talking about it while referencing the Google Open Source Docs site, which is a (nearly complete) mirror of the documentation available to Googlers.

First of all, as the landing page states, there is some content missing on that site, so that’s not secret either. I no longer have access to the internal version, so I can’t even compare it right now, but the times I have consulted it, the missing content is really not relevant to external discussion. No secret cabals hidden there.

So the first obvious thing is that you need a license. This is something that effectively everybody has been saying forever. No license in a repository means there’s no legal way to use, distribute, or contribute to the code. And pretty much every company out there will forbid its employees from contributing to such projects. Google is quite explicit on this, and includes a (strangely non-comprehensive) list of forbidden licenses — it goes into further details with the list of banned software licenses, that include non-open source licenses too.

There’s a funny tidbit here — Google bans both WTFPL and CC-0 licenses — but explicitly allows Unlicense without review (assuming a bunch of other requirements are met). This is in contrast to the Fedora Project, that goes the other direction, recommending CC-0 over Unlicense. Personally, with the objective of this post, I would suggest the MIT license — it provides pretty much the same widely permissive license, and is accepted by effectively everybody that I know of. It definitely covers both Google and Fedora Project at the same time.

Update (2020-06-09): it was brought to my attention that a week or two after this post was published, Google’s Open Source documentation was amended to include Unlicense together with CC-0 and most other public domain dedications, except for US Government works and BSD0. I’ll keep my advice for using MIT for those files, if at all possible.

When it comes to licensing repositories, remember to license the repository with websites, too. Some time ago I wanted to send a correction for pdfreaders.org, but I couldn’t because the repository for the site didn’t have a license. Oops! (I believe this was fixed.)

At this point, with the right license, most open source projects are “patchable” — as in, you can provide a patch to the right reviewers and they can give you a green light (or tell you why you can’t do it). This is not particularly difficult work, but it is a bit toily, and it assumes that you’re able to write a patch and get it reviewed quickly — it makes the difference between sending a patch being around ten minutes at once, to be about half an hour to prepare, and then wait a day or two.

In particular for me the problem with this workflow had been transferring the patch from my Linux development workstation into my corp machine to be able to fill in the form. You can’t use GitHub private repositories either, or email it to yourself — what I used to do was to use Google Drive to share it with my corporate account, but that’s also a bit painful. I have given up a few times on some patches because of this reason, until…

Eventually, in the seven years I worked at Google, the policy relaxed a bit, and in particular, there is no review necessary for patching a subset of public GitHub repositories. You still need to make sure the patch is to a project with an accepted license (actually, a subset of licenses), and not be one of the banned projects, or one of the projects that need SVP approval (you really don’t want to wait on an SVP, from what I have been told), but then you can patch most GitHub repositories easily.

What this means in practice is that while I was working on usbmon-tools, I could keep patching python-pcapng — but I would have had to ask for review to patch hexdump: the latter has an acceptable license (Unlicense), but it’s not hosted on GitHub, but rather on BitBucket. The same is true for GitLab.

I’m not quite clear why this difference, but there you go. My recommendation here is to have at least a GitHub mirror — it doesn’t really cost much to set up mirroring, and it makes it easier for Googlers (and I’m sure other corporate employees as well), and for newcomers who might only have seen GitHub up to then.

There is one more thing that I would suggest you to do. There’s an additional bit of documentation around having an AUTHORS file. I have followed this advice for most of my projects, whether released under Google’s open sourcing policy or not. It makes it much easier to make sure that everybody is credited, while not having to keep adding more and more copyright lines into the files. It also matches well with the advice given by Matija, when it comes to include SPDX metadata to the files themselves.

With all these (small) things considered, I would say that a project is in the best state possible to accept code contributions from “corporate actors” — or at least Googlers. I think this approach, of documenting clearly (or as clear as it’s feasible) how to contribute to open source project, is a great starting point — it makes it possible for projects to not unwittingly put up barriers to contributions. And at the same time it gives the chance for those projects who really don’t want corporate contributions to set up as many barriers as they want. I’m sure it’s a signal that some find positive, I really don’t, but that’s just me.

The GPL is not an EULA

Before I get to the meat of this blog post, let me make sure nobody would misunderstand for a lawyer. What you’re about to read is a half-rant about Free Software projects distributing Windows binaries with pretty much default installer settings. It is in no way legal advice, and it is not being provided by someone with any semblance of legal training.

If you follow Foone or me on Twitter, you probably have noticed one time or another our exchanges of tweets about GPL in Windows installers.

The reason for this annoyance is that, as Foone pointed out many times in the past, licenses such as GPL and MIT are not EULAs: End-User License Agreements. They are, by design, licensing the distribution of the software, rather than its use. Now, in 2020 a lot of people are questioning this choice, but that’s a different topic altogether.

What this means for a consumer is that you are not required to agree to the GPL (or LGPL, or MIT) to install and use a piece of software. You’re required to agree to it if you decide to redistribute it. And as such the install wizards’ license dialogs, with their “I accept the terms” checkboxes are pretty much pointless. And an annoyance because you need to actually figure out where to click instead of keep clicking “Next” — yes I realise that the tiniest violin may be playing at that annoyance, but that’s not the point.

Indeed, the point why I make fun of these installers is because, at least to me, they show the cultural mark of proprietary software on Windows, and the general lack of interest in the politics of Free Software from pretty much everybody involved. The reason why the installers default to saying “EULA” and insisting on you to agree to it, is because non-Free Software on Windows usually does have EULAs. And even the FLOSS installer frameworks ended up implementing the same pattern.

VLC, unsurprisingly, cares about Free Software ideals and its politics, and went out of its way many years ago to make sure that the license is correctly shown in its installer. For a few other projects, I sent patches myself to correct them, whenever I can. For others… well, it’s complicated. The WiX installer toolkit was released years ago by Microsoft as open source, and is used by Calibre and Mono among others, but it seems like the only way to have it show a non-EULA screen is to copy one of its built-in dialogs and edit it.

As I said recently on Twitter, we need a reference website, with instructions on how to correctly display non-EULA Free Software licenses on Windows (and any other operating system). Unfortunately I don’t have time to go through the releasing process as I’m about to leave the company in a few weeks. So either it’ll have to wait another couple of weeks (when I’m free from those obligations), or be started by someone else.

Until then, I guess I’ll provide this blog post as a reference to anyone who asks me why am I even complaining about those licenses.

Why is `git send-email` so awful in 2017?

I set myself out to send my first Linux kernel patch using my new Dell XPS13 as someone contacted me to ask for help supporting a new it87 chip in the gpio-it87 driver I originally contributed.

Writing the (trivial) patch was easy, since they had some access to the datasheet, but then the problem came to figure out how to send it over to the right mailing list. And that took me significantly more time than it should have, and significantly more time than writing the patch, too.

So why is it that git send-email is still so awful, in 2017?

So the first problem is that the only way you can send these email is either through a sendmail-compatible interface, which is literally an interface older than me (by two years), or through SMTP directly (this is even older, as RFC 821 is from 1982 — but being a protocol, that I do expect). The SMTP client has at least support for TLS, provided you have the right Perl modules installed, and authentication, though it does not support more complex forms of authentication such as Gmail’s XOAUTH2 protocol (ignore the fact it says IMAP, it is meant to apply to both IMAP and SMTP).

Instead, the documented (in the man page) approach for users with Gmail and 2FA enabled – which should be anybody who wants to contribute to the Linux kernel! – is to request an app-specific password and saving it through the credential store mechanism. Unfortunately the default credential store just stores it as unencrypted plaintext. Instead there are a number of credential helpers you can use, either using Gnome Keyring or libsecret, and so on.

Microsoft maintains and releases its own Credential Manager which is designed to support multi-factor login to a number of separate services, including GitHub and BitBucket. Thank you, Microsoft, although it appears to only be available for Windows, sigh!

Unfortunately it does not appear there is a good credential helper for either KWallet or LastPass which would have been interesting — to a point of course. I would probably never give LastPass an app-specific password to my Google account, as it would defeat my point of not keeping that particular password in a password manager.

So I start looking around and I find that there is a tool called keyring2 which supposedly has kwallet support, though on Arch Linux it does not appear to be working (the kwallet support, not the tool, which appear to work fine with Gnome Keyring). So I checked out the issues, and the defaulting to gnome-keyring is known, and there is a feature request for a LastPass backend. That sounds promising, right? Except that the author suggests building it as a separate library, which makes sense to a point. Unfortunately the implicit reference to their keyrings.alt (which does not appear to support KDE/Plasma), drove me away from the whole thing. Why?

License is indicated in the project metadata (typically one or more of the Trove classifiers). For more details, see this explanation.

And the explanation then says:

I acknowledge that there might be some subtle legal ramifications with not having the license text with the source code. I’ll happily revisit this issue at such a point that legal disputes become a real issue.

Which effectively reads to me as “I know what the right thing to do is, but it cramps my style and I don’t want to do it.” The fact that there have been already people pointing out the problem, and the fact that multiple issues have been reported and then marked as duplicate of this master issue, should speak clearly enough.

In particular, if I wanted to contribute anything to these repositories I would have no hope to do so but in my free time, if I decide to apply for a personal project request, as these projects are likely considered “No License” by the sheer lack of copyright information or licenses.

Now, I know I have not been the best person for this as well. But at least for glucometerutils I have made sure that each file lists its license clearly, and the license is spelt out in the README file too. And I will be correcting some of my past mistakes at some point soon, together with certain other mistakes.

But okay, so this is not a viable option. What else remains to use? Well, turns out that there is an actual FreeDesktop.org specification, or at least a draft, which appears to have been last touched seven years ago, for a common API to share between GNOME and KWallet, and for which there are a few other implementations already out there… but the current KWallet does not support it, and the replacement (KSecretService) appears to be stalled/gone/deprecated. And that effectively means that you can’t use that either.

Now, on Gentoo I know I can use msmtp integrated with KWallet and the sendmail interface, but I’m not sure if in Arch Linux it would work correctly. After all I even found out that I needed to install a number of Perl modules manually, because they are not listed in the dependencies and I don’t think I want to screw with PKGBUILD files if I can avoid it.

So at the end of the day, why is git send-email so awful? I guess the answer is that in so many years we still don’t have a half-decent, secure replacement for sending email. We need what they would now call “disruptive technology”, akin to how SSH killed Telnet, to bring up a decent way to send email, or at least submit Git patches to the Linux kernel. Sigh.

Update 2020-08-29: if you are reading this to try to make sense on how to use git send-email with Gmail or GSuite, you may want to instead turn to the sendgmail binary released in the gmail-oauth2-tools repository. It’s not great, particularly as the upstream maintainer has been very non-responsive, even when I was a co-worker, and it’s not the easiest thing to setup either (it needs you to have a Google Cloud account and enable the right API key), but it does work. If you feel like forking this, and merging the requisite pull requests, and release it as its own application, please be my guest. I’m not using Gmail anymore myself, so…

Fake “Free” Software hurts us all

Brian Krebs, the famous information security reporter, posted today (well, at the time of writing) an article on security issues with gSOAP library. I found this particularly interesting to me because I remembered seeing the name before. Indeed, Krebs links to the project’s SourceForge page, which is something to see. It has a multi-screen long list of “features”, including a significant number of variant and options for the protocol, which ends in the following:

Licenses: GPLv2, gSOAP public license (for engine and plugins), commercial non-GPL license available upon request (software is 100% in-house developed, no third-party GPL contributions included)

Ah, there we go. “Free” Software.

You may remember my post just a few days ago about the fact that Free Software to actually make a difference in society the way Stallman prophesizes needs a mediating agency, and at least right now that agency is companies and the free market. I argued that making your software usable by companies that provide services or devices is good, as it makes for healthy, usable and used projects, and increase competition and reduce costs of developing new solutions. So is gSOAP the counterexample? I really don’t think so. gSOAP is the perfect example for me that matches my previous rant about startups and fake communities.

The project at first look like the poster child for FSF-compatible software, since it’s licensed under GPL-2, and it clearly has no CLA (Contributor License Agreement), though the company provides a “way out” from GPL-2 obligations by buying a commercial license. This is not, generally speaking, a bad thing. I have seen many examples, including in the open multimedia cliques, of using this trick to foster the development of open solutions while making money to pay salary or build new Free Software companies.

But generally, those projects allow third party contributions with a CLA or similar agreement that allows the “main” copyright holders to still issue proprietary licenses, or enforce their own rights. You can for instance see what Google’s open source projects do about it. Among other things, this contribution method also disallows re-licensing the software, as that requires agreement from all copyright holders. In the case of gSOAP, that is not the case: as they say their software is «100% in-house developed».

They are very well proud of this situation, because it gives them all the power: if you want to use gSOAP without paying, you’re tied to the GPL, which may or may not become a compliance problem. And if you happen to violate the license, they have all the copyright to sue you or just ask you to settle. It’s a perfect situation for copyright trolls.

But, because of this, even though the software is on paper “Free Software” according to FSF, it’s a piece of proprietary software. Sure you can fork the library and build your own GPL-2 instead, as you have the freedom of fork, but that does not make it a community, or a real Free Software project. And it also means you can’t contribute patches to it to make it more secure, safer, or better for society. You could report bugs, including security bugs, but what’s the likeliness that you would actually care to do so, given that one of the first thing they make clear on their “project” page is that they are not interested in your contributions? And we clearly can see that the particular library could have used some care from the community, given its widespread adoption.

What does this mean to me, is that gSOAP is a clear example that just releasing something under GPL-2 is not enough to make it Free Software, and that even “Free” Software released under GPL-2 can be detrimental to society. And it also touches on the other topic I brought up recently, that is that you need to strike a balance between making code usable to companies (because they will use, and thus very likely help you extend or support your project) and keeping it as a real community or a real project. Clearly in this case the balance was totally off. If gSOAP was available with a more liberal license, even LGPL-2, they would probably lose a lot in license fees, as for most companies, just using this as a shared library would be enough. But it would then allow developers, both hobbyists and working for companies, to contribute fixes so that they trickle down on everybody’s device.

Since I do not know what the proprietary license that the company behind gSOAP requires their customers to agree with, I cannot say whether there is any incentive in said companies to provide fixes back to the project, but I assume if they were to do so, they wouldn’t be contributing them under GPL-2, clearly. What I can say is that for the companies I worked for in the past, actually receiving the library under GPL-2 and being able to contribute the fixes back would have been a better deal. The main reason is that as much as a library like this can be critical to connected devices, it does not by itself contain any of the business logic. And there are ways around linking GPL-2 code into the business logic application, that usually involve some kind of RPC between the logic and the frontend. And being able to contribute the changes back to the open source project would allow them to not have to maintain a long set of patches to sync release after release — I had the unfortunate experience of having to deal with something in that space before.

My advice, is once again, to try figuring out what you want to achieve by releasing a piece of software. Are you trying to make a statement, sticking it to the man, by forcing companies not to use your software? Are you trying to make money by forcing companies interested in using your work to buy a special license from you? Or are you contributing to Free Software because you want to improve society? In the latter case, I would suggest you consider a liberal license, to make sure that your code (that can be better than proprietary, closed-source software!) is actually available for those mediating agencies that transform geeky code into usable gadgets and services.

I know, it would be oh so nicer, if by just releasing something awesome under GPL-2 you’d force every company to release all their firmware as Free Software as well, but that’s not going to happen. Instead, if they feel they have to, they will look for worse alternatives, or build their own (even worse) alternatives, and keep them to themselves, and we’ll all be the poorer for it. So if in doubt, consider MIT or Apache 2 licenses. The latter in particular appears to be gaining more and more traction as both Google and Microsoft appear to be fond of the license, and Facebook’s alternative is tricky.

Some of you may consider me a bit of a hypocrite since I have released a number of projects under more restrictive Free licenses (including AGPL-3!) before I came to the conclusion that’s actually bad for society. Or at least before I came back to that idea, as I was convinced of that back in 2004, when I wrote (In Italian) of why I think MySQL is bad for Free Software (I should probably translate that post, just for reference). But what I decided is that I’ll try now to do my best to re-license the projects for which I own the full copyright under Apache 2 licenses. This may take a little while until I figure out all the right steps, but I feel is the right thing to do.

Technology and society, the cellphone example

After many months without blogging, you can notice I’m blogging a bit more about my own opinions than before. Part of it is because these are things I can write about without risking conflicts of interests with work, so that makes it easier to write, and part of it is because my opinions differing from what I perceive as the majority of Free Software advocates. My hope is that providing my opinions openly may, if not sway the opinion of others, find out that there are other people sharing them. To make it easier to filter out I’ll be tagging them as Opinions so you can just ignore them, if you use anything like NewsBlur and its Intelligence Trainer (I love that feature.)

Note: I had to implement this in Hugo as this was not available when I went to check if the Intelligence Trainer would have worked. Heh.

Okay, back on topic. You know how technologists, particularly around the Free Software movement, complain abut the lack of openness in cellphones and smartphones? Or of the lack of encryption, or trustworthy software? Sometimes together, sometimes one more important than the other? It’s very hard to disagree with the objective: if you care about Free Software you want more open platforms, and everybody should (to a point) care about safety and security. What I disagree with is the execution, for the most part.

The big problem I see with this is the lack of one big attribute for their ideal system: affordability. And that does not strictly mean being cheap, it also means being something people can afford to use — Linux desktops are cheap, if you look only at the bottom line of an invoice, but at least when I last had customers as a -Sysadmin for hire- Managed Services Provider, none of them could afford Linux desktops: they all had to deal with either proprietary software as part of their main enterprise, or with documents that required Microsoft Office or similar.

If you look at the smartphone field, there have been multiple generations of open source or free software projects trying to get something really open out, and yet what most people are using now is either Android (which is partly but not fully open, and clearly not an open source community) or iOS (which is completely closed and good luck with it.) These experiments. were usually bloody expensive high-end devices (mostly with the excuse of being development platforms) or tried to get the blessing of “pure free software” by hiding the binary blobs in non-writeable flash memory so that they could be shipped with the hardware but not with the operating systems.

There is, quite obviously, the argument that of course the early adopters end up paying the higher price for technology: when something is experimental it costs more, and can only become cheaper with enough numbers. But on the other hand, way too many of the choices became such just for the sake of showing off, in my opinion. For instance in cases like Nokia’s N900 and Blackphone.

Nowadays, one of the most common answers when talking about the lack of openness and updates of Android is still CyanogenMod despite some of the political/corporate shenanigans happening in the backstory of that project. Indeed, as an aftermarket solution, CyanogenMod provides a long list of devices with a significantly more up to date (and thus secure) Android version. It’s a great project, and the volunteers (who have been doing the bulk of the reverse engineering and set up for the builds) did a great job all these years. But it comes with a bit of a selection bias. It’s very easy to find builds for a newer flagship Android phone, even in different flavours (I see six separate builds for the Samsung Galaxy S4, since each US provider has different hardware) but it’s very hard to find up to date builds for cheaper phones, like the Huawei Y360 that Three UK offers (or used to offer) for £45 a few months back.

I can hear people saying “Well, of course you check before you buy if you can put a free ROM on it!” Which kind of makes sense if what constraints your choice is the openness, but expecting the majority of people to care about that primarily is significantly naïve. Give me a chance to explain my argument for why we should spend a significant amount of time working on the lower end of the scale rather than the upper.

I have a Huawei Y360 because I needed a 3G-compatible phone to connect my (UK) SIM card while in the UK. This is clearly a first world problem: I travel enough that I have separate SIM cards for different countries, and my UK card is handy for more than a few countries (including the US.) On the other hand, since I really just needed a phone for a few days (and going into why is a separate issue) I literally went to the store and asked them “What’s the cheapest compatible phone you sell?” and the Y360 was the answer.

This device is what many people could define craptastic: it’s slow, it has a bad touchscreen, very little memory for apps and company. It comes with a non-stock Android firmware by Huawei, based on Android 4.4. The only positive sides for the device are that it’s cheap, its battery actually tends to last, and for whatever reason it allows you to select GPS as the timesource, which is something I have not seen any other phone doing in a little while. It’s also not fancy-looking, it’s a quite boring plastic shell, but fairly sturdy if it falls. It’s actually fairly well targeted, if what you have is not a lot of money.

The firmware is clearly a problem in more than one way. This not being just a modified firmware by Huawei, but a custom one for the provider means that the updates are more than just unlikely: any modification would have to be re-applied by Three UK, and given the likely null margin they make on these phones, I doubt they would bother. And that is a security risk. At the same time the modifications made by Huawei to the operating system seem to go very far on the cosmetic side, which makes you wonder how much of the base components were modified. Your trust on Huawei, Chinese companies, or companies of any other country is your own opinion, but the fact that it’s very hard to tell if this behaves like any other phone out there is clearly not up for debate.

This phone model also appears to be very common in South America, for whatever reason, which is why googling for it might find you a few threads on Spanish-language forums where people either wondered if custom ROMs are available, or might have been able to get something to run on it. Unfortunately my Spanish is not functional so I have no idea what the status of it is, at this point. But this factoid is useful to make my point.

Indeed my point is that this phone model is likely very common with groups of people who don’t have so much to spend on “good hardware” for phones, and yet may need a smartphone that does Internet decently enough to be usable for email and similar services. These people are also the people who need their phones to last as long as possible, because they can’t afford to upgrade it every few years, so being able to replace the firmware with something more modern and forward looking, or with a slimmed down version, considering the lack of power of the hardware, is clearly a thing that would be very effective. And yet you can’t find a CyanogenMod build for it.

Before going down a bit of a road about the actual technicalities of why these ROMs may be missing, let me write down some effectively strawman answers to two complaints that I have heard before, and that I may have given myself when I as young and stupid (now I’m just stupid.)

If they need long-lasting phones, why not spend more upfront and get a future-proof device? It is very true that if you can afford a higher upfront investment, lots of devices become cheaper in the long term. This is not just the case for personal electronics like phones (and cameras, etc.) but also for home hardware such as dishwashers and so on. When some eight or so years ago my mother’s dishwasher died, we were mostly strapped on cash (but we were, at the time, still a family of four, so the dishwasher was handy for the time saving), so we ended up buying a €300 dishwasher on heavy discounts when a new hardware store just opened. Over the next four years, we had to have it repaired at least three times, which brought its TCO (without accounting for soap and supplies) to at least €650.

At the fourth time it broke, I was just back from my experience in Los Angeles, and thus I had the cash to buy a good dishwasher, for €700. Four years later the dishwasher is working fine, no repair needed. It needs less soap, too, and it has a significantly higher energy rating than the one we had before. Win! But I was lucky I could afford it at the time.

There are ways around this: paying things by instalments is one of these, but not everybody is eligible to that either. In my case at the time I was freelancing, which means that nobody would really give me a loan for it. The best I could have done would have been using my revolving credit card to pay for it, but let me just tell you that the interests compound much faster on that than with a normal loan. Flexibility costs.

This, by the way, relate to the same toilet paper study I have referenced yesterday.

Why do you need such a special device? There are cheaper smartphones out there, change provider! This is a variation of the the argument above. Three UK, like most of their Three counterparts across Europe, is a bit peculiar, because you cannot use normal GSM phones with them, you need at least UMTS. For this reason you need more expensive phones than your average Nokia SIM-free. So arguing that using a different provider may be warranted if all you care about is calls and text, but nowadays that is not really the case.

I’m now failing to find a source link of it, but I have been reading this not too long ago (likely on the Wall Street Journal or New York Times, as those are the usual newspapers I read when I’m at a hotel) how for migrants the importance of Internet-connected mobile phones is significant. The article listed a number of good reasons, among which I remember being able to access the Internet to figure out what kind of documents/information they need, being able to browse available jobs opening, and of course to be able to stay in touch with their family and friends that may well be in different countries.

Even without going to the full extreme of migrants who just arrived in a country, there are a number of “unskilled” job positions that are effectively “at call” — this is nothing new, the whole are of Dublin where I live now, one of the most expensive in the city, used to be a dormitory for dock workers, who needed to be as close as possible to the docks themselves so that they could get there quickly in the morning to find job. “Thanks” to technology, physical home proximity has been replaced with reachability. While GSM and SMS are actually fairly reliable, having the ability to use WiFi hotspots to receive text and SMS (which a smartphone allows, but a dumbphone doesn’t) is a significant advantage.

An aside on the term “unskilled” — I really hate the term. I have been told that delivering and assembling furniture is an unskilled job, I would challenge my peers to bring so many boxes inside an apartment as quickly as the folks who delivered my sofa and rest of furniture a few months ago without damaging either the content of the boxes or the apartment, except I don’t want to ruin my apartment. It’s all a set of different skills.

Once you factor in this, the “need” for a smartphone clearly outweighs the cheapness of a SIM-free phone. And once you are in for a smartphone, having a provider that does not nickel and dime your allowances is a plus.

Hopefully now this is enough social philosophy for the post — it’s not really my field and I can only trust my experience and my instincts for most of it.

So why are there not more ROMs for these devices? Well the first problem is that it’s a completely different set of skills, for the most part, between the people who would need those ROMs and the people who can make those ROMs. Your average geek that has access to the knowledge and tools to figure out how the device works and either extract or build the drivers needed is very unlikely to do that on a cheap, underpowered phone, because they would not be using one themselves.

But this is just the tip of the iceberg, as that could be fixed by just convincing a handful of people who know their stuff to maintain the ROM for these. The other problem with cheap device, and maybe less so with Huawei than others, for various reasons, is that the manufacturer is hard to reach, in case the drivers could be available but nobody has asked. In Italy there is a “brand” of smartphones that prides itself in advertisement material that they are the only manufacturer in Italy — turns out the firmware, and thus most likely the boards too, are mostly coming from random devshops in mainland China, and can be found in fake Samsung phones in that country. Going through the Italian “manufacturer” would lead to nothing if you need specs or source code. [After all I’ve seen that for myself with a different company before.

A possible answer to this would be to mandate better support for firmware over time, fining the manufacturers that refuse to comply with the policy. I heard this proposed a couple of times, particularly because of the recent wave of IoT-based DDoS that got to the news so easily. I don’t really favour this approach because policies are terrible to enforce, as it should be clear by now to most technologists who dealt with leaks and unhashed passwords. Or with certificate authorities. It also has the negative side effect of possibly increasing the costs as the smaller players might actually have a hard time to comply with these requirements, and thus end up paying the highest price or being kicked out of the market.

What I think we should be doing, is to change our point of view on the Free Software world and really become, as the organization calls itself software in the public interest. And public interest does not mean limiting to what the geeks think should be the public interest (that does, by the way, include me.) Enforcing the strict GPL has become a burden to so many companies by now, that most of the corporate-sponsored open source software nowadays is released under Apache 2 license. While I would love an ideal world in which all of the free software out there is always GPL and everybody just contributes back at every chance, I don’t think that is quite so likely, so let’s accept that and be realistic.

Instead of making it harder for manufacturers to build solutions based on free and open source software, make it easier. That is not just a matter of licensing, though that comes into play, it’s a matter of building communities with the intent of supporting enterprises to build upon them. With all the problems it shows, I think at least the Linux Foundation is trying this road already. But there are things that we can all do. My hopes are that we stop the talks and accusations for and against “purity’ of free software solutions. That we accept when a given proposal (proprietary, or coming out a proprietary shop) is a good idea, rather than ignore it because we think they are just trying to do vendor lock-in. Sometimes they are and sometimes they aren’t, judge ideas, formats, and protocols on their merits, not on who propose them.

Be pragmatic: support partially closed source solutions if they can be supported or supportive of Free Software. Don’t buy into the slippery slope argument. But strive to always build better open-source tool whenever there is a chance.

I’ll try to write down some of my preferences of what we should be doing, in the space of interaction between open- and closed-source environments, to make sure that the users are safe, and the software is as free as possible. For the moment, I’ll leave you with a good talk by Harald Welte from 32C3; in particular at the end of the talk there is an important answer from Harald about using technologies that already exist rather than trying to invent new ones that would not scale easily.

GNU is actually a totalitarian regime

You probably remember that I’m not one to fall in line with the Free Software Foundation — a different story goes for the FSFe which I support and I look forward for the moment when I can come back as a supporter; for the moment I’m afraid that I have to contribute only as a developer.

Well, it seems like more people are joining in the club. After Werner complained about the handling of GNU copyright assignments – not much after my covering of Gentoo’s assignments which should probably make those suggesting a GNUish approach to said copyright assignment think a lot – Nikos of GnuTLS decided to split off the GNU project.

Why did Nikos decide this? Well, it seems like the problem is that both Werner and Nikos are tired of the secrecy in the GNU project and even more of the inability to discuss, even in a private setting, some topics because they are deemed taboo by the FSF, in the person of Richard Stallman.

So, Nikos decided to move the lists, source code and website on its own hosting, and then declared GnuTLS no longer part of the GNU project. Do you think that this would have put the FSF in a “what are we doing wrong?” mood? Hah, naïve are you! Indeed the response from the FSF (in the person of Richard Stallman, see a pattern?) was to tell Nikos (who wrote, contributed to GNU, and maintained the project) that he can’t take his own project and take it out of GNU, and that if he wants he can resign from the maintainer’s post.

Well, now it seems like we might end up with a “libreTLS” package, as Nikos is open to renaming the project… it’s going to be quite a bit of a problem I’d say, if anything because I want to track Nikos’s development more than GNU’s, and thus I would hope for the “reverse fork” from the GNU project to just die off. Considering I also had to sign the assignment paperwork (and in the time that said paperwork was being handled, I lost time/motivation for the contributions I had in mind, lovely isn’t it?).

Well, what this makes very clear to me is that I still don’t like the way the GNU project, and the FSF are managed, and that my respect for Stallman’s behaviour is, once again, zero.

Bloody upstream

Please note, this post is likely to be interpreted as a rant. From one point of view it is. It’s mostly a general rant geared toward those upstreams that is generally impossible to talk into helping us distribution out.

The first one is the IEEE — you might remember that back in April I was troubled by their refusal to apply a permissive license to their OUI database, and actually denied that they allow redistribution of said database. A few weeks ago I had to bite the bullet and added both the OUI and the IAB databases to the hwids package that we’re using in Gentoo, so that we can use them on different software packages, including bluez and udev.

While I’m trying not to bump the package as often as before, simply because the two new files increase the size of the package four times. But I am updating the repository more often so that I can see if something changes and could be useful to bump it sooner. And what I noticed is that the two files are managed very badly by IEEE.

At some point, while adding one entry to the OUI list, the charset of the file was screwed up, replacing the UTF-8 with mojibake then somebody fixed it, then somebody decided that using UTF-8 was too good for them and decided to go back to pure ASCII, doing some near-equivalent replacement – although whoever changed ß to b probably got to learn some German – then somebody decided to fix it up again … then again somebody broke it while adding an entry, another guy tried to go back to ASCII, and someone else fixed it up again.

How much noise is this in the history of the file? Lots. I really wish they actually wrote a decent app to manage those databases so they don’t break them every other time they have to add something to the list.

The other upstream is Blender. You probably remember I was complaining about their multi-level bundling ad the fact that there are missing license information for at least one of the bundled libraries. Well, we’re now having another problem. I was working on the bump to 2.65, but now either I return to bundle Bullet, or I have to patch it because they added new APIs to the library.

So right now we have in tree a package that:

  • we need to patch to be able to build against a modern version of libav;
  • we need to patch to make sure it doesn’t crash;
  • we need to patch to make it use over half a dozen system libraries that it otherwise bundles;
  • we need to patch to avoid it becoming a security nightmare for users by auto-executing scripts in downloaded files;
  • bundles libraries with unclear licensing terms;
  • has two build systems, with different features available, neither of which is really suitable for a distribution.

Honestly, I reached a point where I’m considering p.masking the package for removal and deal with those consequences rather than dealing with Blender. I know it has quite a few users especially in Gentoo, but if upstream is unwilling to work with us to make it fit properly, I’d like users to speak to them to see that they get their act together at this point. Debian is also suffering from issues related to the libav updates and stuff like that. Without even going into the license issues.

So if you have contacts with Blender developers, please ask them to actually start reducing the amount of bundled libraries, decide on which of the two build systems we should be using, and possibly start to clear up the licensing terms of the package as a whole (including the libraries!). Unfortunately, I’d expect them not to listen — until maybe distributions, as a whole, decide to drop Blender because of the same reasons, to make them question the sanity of their development model.

Inside the life of an embedded developer

Now that the new ultrabook is working almost fine (I’m still tweaking the kernel to make sure it works as intended, especially for what concerns the brightness, and tweaking the power usage, for once, to give me some more power), I think it’s time for me to get used to the new keyboard, which is definitely different from the one I’m used to on the Dell, and more similar to the one I’ve used on the Mac instead. To do so, I think I’ll resume writing a lot on different things that are not strictly related to what I’m doing at the moment but talk about random topic I know about. Here’s the first of this series.

So, you probably all know me for a Gentoo Linux developer, some of you will know me for a multimedia-related developer thanks to my work on xine, libav, and a few other projects; a few would know me as a Ruby and Rails developer, but that’s not something I’m usually boasting or happy about. In general, I think that I’m doing my best not to work on Rails if I can. One of the things I’ve done over the years has been working on a few embedded projects, a couple of which has been Linux related. Despite what some people thought of me before, I’m not an electrical engineer, so I’m afraid I haven’t had the hands-on experience that many other people I know had, which I have to say, sometimes bother me a bit.

Anyway, the projects I worked on over time have never been huge project, or very well funded, or managed projects, which meant that despite Greg’s hope as expressed on the gentoo-dev mailing list, I never had a company train me in the legal landscape of Free Software licenses. Actually in most of the cases, I ended up being the one that had to explain to my manager how these licenses interact. And while I take licenses very seriously, and I do my best to make sure that they are respected, even when the task falls on the shoulder of someone else, and that someone might not actually do everything by the book.

So, while I’m not a lawyer and I really don’t want to go near that option, I always take the chance of understand licenses correctly and, when my ass is on the line, I make sure to verify the licenses of what I’m using for my job. One such example is the project I’ve been working since last March, of which I’ve prepared the firmware, based on Gentoo Linux. To make sure that all the licenses were respected properly, I had to come up with the list of packages that the firmware is composed of, and then verify the license of each. Doing this I ended up finding a problem with PulseAudio due to linking in the (GPL-only) GDBM library.

What happens is that if the company you’re working for has no experience with licenses, and/or does not want to pay to involve lawyers to review what is being done, it’s extremely easy for mistake to happen unless you are very careful. And in many cases, if you, as a developer, pay more attention to the licenses than your manager does, it’s also seen as a negative point, as that’s not how they’d like for you to employ your time. Of course you can say that you shouldn’t be working for that company then, but sometimes it’s not like you have tons of options.

But this is by far not the only problem. Sometimes, what happens is a classic 801 — that is that instead of writing custom code for the embedded platform you’re developing for, the company wants you to re-use previous code, which has a high likelihood of being written in a language that is completely unsuitable for the embedded world: C++, Java, COBOL, PHP….

Speaking of which, here’s an anecdote from my previous experiences in the field: at one point I was working on the firmware for an ARM7 device, that had to run an application written in Java. Said application was originally written to use PostgreSQL and Tomcat, with a full-fledged browser, but had to run on a tiny resistive display with SQLite. But since at the time IcedTea was nowhere to be found, and the device wouldn’t have had enough memory for it anyway, the original implementation used a slightly patched GCJ to build the application to ELF, and used JNI hooks to link to SQLite. The time (and money, when my time was involved) spent making sure the system wouldn’t run out of memory would probably have sufficed to rewrite the whole thing in C. And before you ask, the code bases between the Tomcat and the GCJ versions started drifting almost immediately, so code sharing was not a good option anyway.

Now, to finish this mostly pointless, anecdotal post of mine, I’d like to write a few words of commentary about embedded systems, systemd, and openrc. Whenever I head one or the other side saying that embedded people love the other, I think they don’t know how different embedded development can be from one company to the next, and even between good companies there are so big variation, that make them stand lightyears apart from bad companies like some of the ones I described above. Both sides have good points for the embedded world; what you choose depends vastly on what you’re doing.

If memory and timing are your highest constraints, then it’s very likely that you’re looking into systemd. If you don’t have those kind of constraints, but you’re building a re-usable or highly customizable platform, it’s likely you’re not going to choose it. The reason? While if you’re half-decent in your development cross-compilation shouldn’t be a problem, the reality is that in many place, it is. What happen then is that you want to be able to make last-minute changes, especially in the boot process, for debugging purposes, using shell scripts is vastly easier, and for some people, doing it more easily is the target, rather than doing it right (and this is far from saying that I find the whole set of systemd ideas and designs “right”).

But this is a discussion that is more of a flamebait than anything else, and if I want to go into details I should probably spend more time on it than I’m comfortable doing now. In general, the only thing I’m afraid of, is that too many people make assumption on how people do things, or take for granted that companies, big and small, care about doing things “right” — by my experience, that’s not really the case, that often.