Funding Qubes OS
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:
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:
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.
Posted Dec 1, 2016 5:48 UTC (Thu)
by alison (subscriber, #63752)
[Link] (1 responses)
Posted Dec 1, 2016 9:00 UTC (Thu)
by linuxrocks123 (subscriber, #34648)
[Link]
Posted Dec 2, 2016 14:34 UTC (Fri)
by gasche (subscriber, #74946)
[Link] (1 responses)
Posted Dec 5, 2016 1:42 UTC (Mon)
by paulj (subscriber, #341)
[Link]
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...
Why not ARM64?
Why not ARM64?
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
Funding Qubes OS