Ubuntu 14.04 Codename Revealed, Mir Haters Attacked

[dee.]

I really don't understand all of the complaints about Mir not being a protocol. So what? It's an implementation of a display server with a client side API implemented as a shared library. It like screaming "GTK sucks! It isn't a protocol!" again and again.. no, it isn't a protocol, but who cares? You write your code and link to a shared library. The only time "it isn't a protocol" would matter is if you wanted to create a competing implementation.

No, it matters to DE developers. Canonical wants DE's to support Mir, but at the same time, they're making it difficult if not impossible for them to do so. In this case the client side API doesn't matter as much as the server side, and there's no stable API or protocol on the server side: Mir is designed, on the server side, to only talk with Unity, it's integrated tightly with Unity 8, and there's no protocol there for another DE to support it.

So of course, other DE's wont want to support Mir, especially since there's already Wayland which is much easier to support, as it provides a guaranteed stable protocol both client- and server side.

Exactly. It's like the Wright brothers inventing a three axis control system for their airplane, which then went to on be used by everyone else in every future airplane design.

Hm, I don't think you do analogies very well.

When the Wright brothers invented the control system for their airplane, there was no competing control system for airplanes because the Wright brothers were pioneers in their field. Also, the Wright brothers' control system was fairly primitive: it used a wing-warping technology, instead of the control flaps (ailerons) that most modern aircraft use, and it did not have a tailplane like most modern aircraft, instead relying on a canard design which has been less popular since (although still used in some designs).

[chrisb]

Yet, they can do their own Wayland compositor and sell it to OEMs, and IIRC libwayland is MIT, so again, they can sell it to OEMs. Of course, then, they would be more like selling their brand than the actual software, since the OEMs could get the software for free.

If you believe the claims about the huge demand from phone manufacturers for a non-GPL3 Linux display server, then it would be more than just "selling a brand", they could have their own open source GPL3 compositor and libwayland, and then licence it under another licence to these GPL3 fearing OEMS. The OEMs could only get it for free under GPLv3, anything else and they have to pay.

[chrisb]

Wayland is a protocol. You cannot sell a protocol to anybody and Weston is a test/reference implementation and OEM's don't want a proprietary license for a reference implementation designed to flush out bugs.

http://mjg59.dreamwidth.org/25376.html

Canonical could have released the Unity desktop and its compositor (based on Wayland) as GPLv3 and dual licensed it to OEMs.

[mrugiero]

If you believe the claims about the huge demand from phone manufacturers for a non-GPL3 Linux display server, then it would be more than just "selling a brand", they could have their own open source GPL3 compositor and libwayland, and then licence it under another licence to these GPL3 fearing OEMS. The OEMs could only get it for free under GPLv3, anything else and they have to pay.

I'm talking about selling a custom libwayland. They could get libwayland without GPLv3 for free, because the original implementation is already MIT. In *that* case they would be selling just their brand.

[mether]

Canonical could have released the Unity desktop and its compositor (based on Wayland) as GPLv3 and dual licensed it to OEMs.

It appears you didn't bother to read the link I gave you. OEM's are interested in a proprietary Mir due to their interest in keeping their drivers proprietary. A proprietary Unity would not be of the same interest.

[chrisb]

It appears you didn't bother to read the link I gave you. OEM's are interested in a proprietary Mir due to their interest in keeping their drivers proprietary. A proprietary Unity would not be of the same interest.

If an OEM intends to ship Ubuntu/Unity on a device, but wants to avoid any GPLv3 software, then it is going to have to have a non-GPLv3 version of Unity. If it doesn't, then the OEM has to give the user the freedom to replace Unity (and any other GPLv3 components), and hence can't lock the device down.

I've read the link you refer to before and its analysis is flawed. If an OEM can release their existing drivers for Android (which they do), and their lawyers are confident that the drivers are not a derived work of the GPL Linux kernel, then I see no reason why they would change this opinion because the display server is GPL. Whether it is GPLv2 or GPLv3 does not matter - if the lawyers are of the opinion that the drivers are not a derivative work, then neither applies. Conversely, if the lawyers are of the opinion that the presence of GPLv3 software would be a problem for their drivers, then that means that they believe the drivers are already a derivative work of that software, and hence they should already be releasing the source as required by the existing license.

[bridgman]

Android drivers generally have open source kernel components even if the user-space bits are proprietary and binary-only.

[mether]

If an OEM intends to ship Ubuntu/Unity on a device, but wants to avoid any GPLv3 software, then it is going to have to have a non-GPLv3 version of Unity. If it doesn't, then the OEM has to give the user the freedom to replace Unity (and any other GPLv3 components), and hence can't lock the device down.

I've read the link you refer to before and its analysis is flawed. If an OEM can release their existing drivers for Android (which they do), and their lawyers are confident that the drivers are not a derived work of the GPL Linux kernel, then I see no reason why they would change this opinion because the display server is GPL. Whether it is GPLv2 or GPLv3 does not matter - if the lawyers are of the opinion that the drivers are not a derivative work, then neither applies. Conversely, if the lawyers are of the opinion that the presence of GPLv3 software would be a problem for their drivers, then that means that they believe the drivers are already a derivative work of that software, and hence they should already be releasing the source as required by the existing license.

OEM's don't have to avoid all GPLv3 software. Just ones that interface with their drivers. You have missed this fundamental point. Matthew Garett understands this and is part of the team that enforces the license. Read the analysis carefully and you will have a better understanding.

[chrisb]

OEM's don't have to avoid all GPLv3 software. Just ones that interface with their drivers. You have missed this fundamental point. Matthew Garett understands this and is part of the team that enforces the license. Read the analysis carefully and you will have a better understanding.

And you miss the point that licensing isn't about "interfacing" - it is about whether the driver is a derivative work. Do you believe that an OEM using the Nvidia or AMD closed source drivers (which both have closed source kernel modules) is a violation of the GPL license of the Linux kernel? If not, then why would introducing a GPL display server suddenly create a GPL violation?

[mether]

And you miss the point that licensing isn't about "interfacing" - it is about whether the driver is a derivative work. Do you believe that an OEM using the Nvidia or AMD closed source drivers (which both have closed source kernel modules) is a violation of the GPL license of the Linux kernel? If not, then why would introducing a GPL display server suddenly create a GPL violation?

Oh, I see your confusion. You don't understand the ARM architecture and how the drivers there are different from what you know about in desktop systems. Learn about it and you will know why the analysis makes sense.