Intel and XMir

Posted Sep 12, 2013 17:00 UTC (Thu) by kiko (subscriber, #69905)
In reply to: Intel and XMir by hunger
Parent article: Intel and XMir

Matthew Garrett's comment mirrors yours about this "not being valuable to Intel customers". But I think that completely fails to recognize that Ubuntu (which will default to using Mir RSN) is the third most widely used OS running on x86 today (behind MacOS and Windows), and that it ships preinstalled on a pretty sizeable number of Intel-based laptops and desktops by the world's largest consumer OEMs, Lenovo, Dell and HP. Canonical helps move a lot of Intel silicon.

It's a bit irksome to see Intel benefit directly from the work that goes into making Ubuntu a real product but then deny it when it comes the time to.. err.. accept a 300-liner? Come to think of it, it's not irksome. It just boggles the mind at how anything that would consider itself wise enough to be deemed "management" would make a decision like this.

Intel and XMir

Posted Sep 12, 2013 17:09 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (4 responses)

Isn't that the point? It'll ship regardless of whether Intel put any effort into it. Intel still gets their cut of the sale.

The things it makes sense to focus on are the things that the distributions can't provide - support for the features that differentiate Intel and the other options. They don't benefit in any way from the Xmir code.

Intel and XMir

Posted Sep 12, 2013 17:23 UTC (Thu) by kiko (subscriber, #69905) [Link] (3 responses)

I'd understand that position if we were talking about anything but maintenance of an open source project.

To carry code is some investment, I agree, but it's not like Canonical engineers aren't willing to help maintain it, and as I was trying to point out, carrying the code will benefit Intel customers directly.

Intel and XMir

Posted Sep 12, 2013 20:46 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

While Ubuntu is the only distribution shipping Mir, the customers gain the same benefit regardless of whether or not Intel ship it. Open Source project management doesn't require you to ship anything a downstream wants you to - an obvious analogy is the difficulty involved in getting the Android code into the upstream kernel.

Intel and XMir

Posted Sep 13, 2013 0:18 UTC (Fri) by daniels (subscriber, #16193) [Link] (1 responses)

The 'but it's all open source' thing is a bit of a red herring, when Mir is developed under a CLA which allows Canonical — and only Canonical — to relicense code under proprietary terms for its own profit, to the exclusion of all others, including any external contributors.

Intel and XMir

Posted Sep 26, 2013 15:52 UTC (Thu) by kiko (subscriber, #69905) [Link]

I don't think that's a fair comment; what we are discussing here is open source, non-CLA'd code in the open source Intel driver -- it's definitely odd to see for political reasons a patch like that backed out, and it's weird that you don't think the same.

Any copyright owner has the right to selfishly relicense code they wrote; the CLA is definitely controversial in its expansiveness (and overall myself I don't like it) but it's not like we are doing something that unusual. Companies with different business models care about different types of freedom and openness. Canonical gives away its main product, with updates, at no cost to the end-user. Redhat and SUSE charge end-users for theirs.

But let me put this controversy a different way, using a contrived analogy (that is contrived only because Intel doesn't license its GPU IP, but I feel is still useful). Let's say there was code in this GPU driver that would only be useful on ARM-based systems -- say, to work with the ARM memory controller and memory architecture. Would it be reasonable for an Intel maintainer to back out patches on the basis that ARM isn't interesting to them?