|
|
Subscribe / Log in / New account

Funding Qubes OS

By Jonathan Corbet
November 30, 2016
Qubes OS describes itself as "a reasonably secure operating system". At its core, it uses the Xen hypervisor to separate applications into isolated "qubes" that cannot interfere with each other. While Qubes OS has pushed the boundaries in desktop security, the company behind it, Invisible Things Lab (ITL), has not been as successful in achieving financial security. As a result, Qubes OS is taking a new direction that, its developers hope, will prove to be more lucrative.

As described in this news posting, the original funding model — beyond what ITL brought in with consulting — was a variant of the open-core approach. While Qubes OS is free software, the company tried to sell support for running Windows applications under AppVM as a proprietary product. Doing so required selling binary-only versions of GPLv2-licensed code. Companies wanting to sell proprietary licenses to free code often require either copyright assignment or the right to relicense the code from their contributors. ITL chose the latter option as can be seen on the Qubes OS License page, which says:

That’s why we ask every developer who contributes code to Qubes project to grant ITL permission to reuse the code under a different license, and to express this consent by including the standard signed-off line in the commit.

Contributors who didn't look closely might have been surprised to learn about the redefinition of Signed-off-by, especially since the page in question links to the kernel's SubmittingPatches document, which has no such provision. In any case, outside contributions do not appear to be a significant source of code for Qubes OS; a quick look at the Qubes core-admin repository shows that at least 90% of the commits there come from ITL employees. Qubes OS is, thus far, a single-company development project.

The AppVM-based business evidently failed to bring in enough revenue to justify it existence, though, so ITL de-emphasized it a little while back. The company credits the Open Technology Fund for supporting Qubes OS work for the last two years; there is no word on whether that funding is continuing into the future or not. Even if it does continue, it seems clear that this funding, while welcome, is not enough to sustain or grow Qubes OS at the level its creators would like.

Thus the new model: a "commercial edition" of Qubes OS that will meet corporate needs in ways that, it would appear, are still being worked out:

Commercial editions of Qubes OS will be customized to meet special corporate requirements. For example, two features that might be particularly attractive to corporate customers are (1) “locking down” dom0 in order to separate the user and administrator roles and (2) integrating our local management stack with a corporation’s remote management infrastructure. These are both examples of features that our developers are capable of implementing now, on Qubes 3.2.

ITL insists that Qubes OS itself will remain an open-source project; it will just be adding some proprietary bits around the edges. Much of this, the posting says, may take the form of "custom Salt configurations" and, perhaps, some additional applications. So users of Qubes OS (of which there are evidently about 20,000), need not worry about it going away, especially if the commercialization effort is successful.

What the company will not do, despite requests from some users, is offer complete systems with Qubes OS installed. That is a hard business and, in any case, there does not appear to be any available hardware out there that meets the company's standards for trustworthiness. It might be interesting to see whether there is a market out there for a complete system that has a higher-than-usual probability of staying under the owner's control, but that would almost certainly require a larger organization and budget than is available at this time.

The Linux distribution market is a hard place to play. Qubes OS does not emphasize its Linux roots, but that is the market it is operating in anyway. Many companies have tried to make a go at it, but few of them are still in business now. Like the Linux kernel itself, a distribution tends to be infrastructure that successful companies use to build some other sort of offering on, rather than a product in its own right.

ITL is now trying to create such an offering in the form of its corporate integration modules. With luck, the company will find success in that area without needing to let the free version of Qubes OS languish. ITL may also want to consider trying harder to build a community of contributors to the project, rather than trying to carry the entire burden on its own. There is certainly space for more secure operating systems; with stable funding and enough developers, perhaps ITL can continue working on one.


to post comments

Why not ARM64?

Posted Dec 1, 2016 5:48 UTC (Thu) by alison (subscriber, #63752) [Link] (1 responses)

Watching Joanna Rutkowska's talk videos from various conferences, we learn that she is unhappy with the state of security on x86 due to problems with the SMI and asssociated BIOS code. In her talks, she mentions that she cannot base her work on an architecture that doesn't support an IOMMU. AFAIK, ARM64 arches support IOMMU. Why doesn't ITL move its basis of development to ARM64? Or perhaps work with Andrew 'bunnie' Huang, creator of the Novena i.MX6 laptop, to create a truly secure QubesOS ARM64 one? I'd sign up for the crowdfunding campaign right now.

Why not ARM64?

Posted Dec 1, 2016 9:00 UTC (Thu) by linuxrocks123 (subscriber, #34648) [Link]

If you're ready to shell out a LOT of money -- for a LOT of computer, though -- this may work for you: https://www.raptorengineering.com/TALOS/prerelease.php

Funding Qubes OS

Posted Dec 2, 2016 14:34 UTC (Fri) by gasche (subscriber, #74946) [Link] (1 responses)

The blog post encourages the community to donate (promising that the money will be used to fund the development of the open-source edition) but, besides Bitcoin, they support donation through Open Collective, a crowdfunding platform. I didn't know about Open Collective before, and I like their insistence on transparency, but the website takes 10% in fees (see their FAQ) in addition to the money transfer fees. That seems excessive to me: I don't trust Open Collective enough to give them 10% of the money I would feel comfortable giving to Qubes OS -- I would be interested in donating a few dollars a month. Are there not crowd-funding platforms that have no fees beside money transfer fees, typically in the 2% + a third of dollar, or at least fees similar to the money transfer fees?

Funding Qubes OS

Posted Dec 7, 2016 21:29 UTC (Wed) by swilmet (subscriber, #98424) [Link]

There is Liberapay and Snowdrift for recurrent donations. On the Snowdrift wiki, there is a long list that compares crowdfunding platforms.

Funding Qubes OS

Posted Dec 5, 2016 1:42 UTC (Mon) by paulj (subscriber, #341) [Link]

Signed-off-by... It needs to die. At best it's just a meaningless bit of noise on commit messages, adding bureaucracy and friction. In some cases though, this inexplicit "many things to different people" pseudo-legalism, actively harms by muddying the waters of what people think is understood between them.

SOB was invented by Linus purely to solve a *social* problem. Namely, that there were people clamouring for all kinds of complicated legal bureaucracy in the earlier days of the SCO lawsuit, and Linus wanted to put a sock in them, and end that debate. It was a sop, a minimal bit of bureaucracy, very indirectly (and not at all generally obviously) referring to a bit of text stating anyone using it was attesting that "they were the author, or maybe not but thought they knew the author (though need not say who), or maybe not but they thought it was all kosher anyway". It was legalesey enough to stop those advocating for contributor agreements and background checks from arguing much more.

The damn thing unfortunately has been cargo-culted to lots of other projects, despite being even less meaningful than the "CE" conformity mark, AFAICT from how actual lawyers view it. Worse, whatever meaning it could have is often undermined. I have seen:

- Integrators knock back patches for lack of a SOB, and request the patch be resent with a SOB line - without any further explanation to the submitters (who likely must be unaware of its significance) that doing so is expected to indicate the submitter is asserting something.

- Integrators add SOB lines for _other_ contributors, on patches where the contributor did not give a SOB.

- Members of projects advocating for the need for SOB lines, but not actually being aware that there was a separate "Developer Certificate of Origin" text elsewhere that /some/ might view the SOB as attesting to.

- The documentation in 'git' (e.g. 'man git commit') for the SOB flag, did not even mention the DCO for a _long_ time. It was updated the other year I think, after I raised this problem.

This wart isn't just useless, it's harmful. Let it die...


Copyright © 2016, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds