Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Oh I didn't even know that. That's a great reason to prefer Wayland over Mir or Mir over Wayland. I'm a bit torn now..


Indeed, also X.Org is X11 Licensed (MIT license variant).

Wayland and Mir driver support is pretty much a mystery, and Canonical has been trying to engage hardware designers (Nvidia, Intel, AMD) for support. This recent spate between Canonical and Intel may be indicative that the process isn't going well.

Ubuntu's next LTS release is 14.04 so it's 8 months away, and if there's any surefire way to piss Canonical off then Intel us definitely getting that job done. I'm not trying to defend Canonical but it's hard to ignore the reality of the situation.

I wouldn't be surprised if BSD licensing is on the table front-and-center during negotiations, considering the legal barriers surrounding GPLv3.

Also, it makes me wonder where this leaves Valve. I get the distinct impression that they've been getting cozy with Canonical and they might be getting nervous about the situation.


Hmm, I would say the oppposite. The recent spate between Canonical and Intel might indicate that Canonical's engagement with competitors NVidia and AMD are going well. Canonical doesn't really need to cooperate with Intel, because Intel already makes excellent open source drivers for their graphics cards.

I think Valve is the reason that Canonical can work together with NVidia and AMD, and that they're probably not nervous about this at all.


Not really. I much prefer the GPL, since I think copyleft is (at least partly) what has made Linux the massive success it is, and I think a copyleft licence for a display server would similarly be better. But in this situation, I have to support Wayland over Mir. The reason largely being that Wayland vs. Mir actually gives credence to the argument that Linux can't succeed on the desktop because of fragmentation. Normally in response to that argument, I'd say it's not that big of a deal, and that things like different package managers and desktop environments keep a healthy level of competition, while still having a great amount of cooperation. But when it comes to display servers, we're talking about something that requires driver support, which is already one of (if not the) top problems on GNU/Linux. Forcing the small teams that deal with Linux graphics driver development to choose between using their already limited time to support the general standard or what the most popular distro uses is a horrible decision.


Not really. GPLv3 will prevent hardware manufacturers from locking down their devices if they intend to ship Ubuntu Mobile. This is a good thing for users of those devices. I can't defend Canonical's support of proprietary drivers, especially on these devices that are known to be used for such pervasive spying, but at least a non-hardware-locked device allows for workarounds (i.e. deployment of your own free drivers).


GPLv3 will prevent hardware manufacturers from locking down their devices if they intend to ship Ubuntu Mobile.

Actually the opposite; Canonical will sell phone vendors a non-GPL version of Mir so that they can lock down their phones.


Hence the copyright assignment required for any contribution to Canonical's projects, to ease the double licensing.

But for now, it's only speculation. Time will tell.


It's not copyright assignment, it's just a broader license grant than what the GPL allows.


I'm sorry, but must be missing something. How does a GPLv3 display server prevent locking down the hardware? Afaik, the anti-TiVoization stuff only applies to the software that's GPLv3, not the stack it's running on.


Some argue that if it makes calls to a GPL application, it's a derivative work, which means it must also be GPL.

This means that if one part of the stack is GPL, everything higher must also be GPL.


Can you point me towards some people arguing this? It's patently false. If it were true, every single application on your typical GNU/Linux box would also be GPL.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: