Matthew Garrett: How-To Drive Developers From OS X To Linux

[johnc]

Apple is a fourth-rate laptop vendor. Why should we be following their lead exactly? Because they're magical?

[Del_]

We're using "Widely Adopted" different, you only care about the microcosm of Linux, I'm speaking of the macrocosm of OSes in general which makes all the difference in the world.

I beg to differ. I simply point out that being adopted across linux distros *is* wide adoption. You seem to believe that adoption by BSD or Unix somehow supports being wide. Those two together accounts for about one medium sized distro in terms of adoption.

Yes GPL projects are fine using Apache or BSD code, but BSD or Apache projects cannot take GPL code even of fixes to their own project without tainting their codebase. While this isn't a particularly common occurrence it does happen (which speaks in favour of permissive licensing), the biggest example being the LibreOffice vs Apache Open Office split.

So, to find one example of your non-existent problem you turn to Oracle's disgraceful handling of OpenOffice. Good luck with that.

Given ~20% of their listed userspace changes are just ripping out GNU software and replacing them with BSD licensed software... they do have clear preferences.

Glad to see they are having fun with their priorities. If I used FreeBSD, I would have preferred spending the limited resources a bit differently.

[bridgman]

Just to be clear, the original question was why a permissive license was adopted in the first place... and to answer that you need to go back to the time when the license decision was made.

Back then Linux did not exist, GPL did not exist, Windows was at version 1 (basically a demo), and the majority of the target systems ran various versions of proprietary Unix. The fact that things are different today does not affect the rationale for the original decision, unless you're saying that the people working on X in the 1980s should have seen Linus coming

[bridgman]

If the question was "does X still need a permissive license ?" you could probably make a good case that it does not.

If, however, the question was "would putting X under a copyleft license, even in the past, have made anything different/better ?", the answer is probably "no".

[Luke_Wolf]

I beg to differ. I simply point out that being adopted across linux distros *is* wide adoption. You seem to believe that adoption by BSD or Unix somehow supports being wide. Those two together accounts for about one medium sized distro in terms of adoption.

Wide != # of Users of a system; Wide = # of OSes that utilize a system.

In other words how Cross-OS/Platform/Context it is, is how I'm defining wide.

So, to find one example of your non-existent problem you turn to Oracle's disgraceful handling of OpenOffice. Good luck with that.

Like I said It's uncommon but it happens.

That said I hope you realize that this speaks against the need to copy-left code, not for it. As the sheer lack of hostilely licensed forks means that individuals who willingly contribute don't need that gun to their head. Proprietary developers aren't going to touch anything more restrictive than the LGPL if they don't have to because no proprietary developer wants to risk their code becoming a derivative work. This means you're not going to get any code that way either and if you do it's just going to be a one time dump of code. As a result the only thing you do is prevent people from using it in proprietary code, which some people would argue is the whole point. Other people would argue that the inclusion of proprietary developers using open source code resulting in more developers using it has a higher chance of fixes for the open source code being written and submitted upstream (or at the very least more bugs being reported) that then helps everyone, on top of the benefit of greater standardization on open source code meaning better overall code quality.

Glad to see they are having fun with their priorities. If I used FreeBSD, I would have preferred spending the limited resources a bit differently.

Well given one of their top goals is to be a completely permissively licensed OS it's fine that they have a priority in doing such things, however I would agree their time would be better spent in doing things like finishing their port of the Radeon KMS driver, implementing their own version of cgroups, etc..

[zanny]

If, however, the question was "would putting X under a copyleft license, even in the past, have made anything different/better ?", the answer is probably "no".

Problem is we don't and can't know who has taken code from X, or any permissive project, and reused it in their own software. It would require binary analysis to deduce if someone just recompiled some copyleft code under a different name.

Like someone else has mentioned, if X were GPL it would bleed through xlib and xcb into any project linking against it. I'm not sure personally of how that would impact general desktop apps, because they have layers of misdirection between themselves and X.

But you also have a personal view on what would be better. For GPL supporters like myself, preventing or discouraging the use of proprietary software is inherently an improvement, even if it means losing market share. The GPL isn't about what is the most efficient way to get contributions or users, it is about ethics and morality and also preventing the exploitation of your labors by others who would profit off it without attribution.

[chrisb]

Proprietary developers aren't going to touch anything more restrictive than the LGPL if they don't have to because no proprietary developer wants to risk their code becoming a derivative work. This means you're not going to get any code that way either and if you do it's just going to be a one time dump of code. As a result the only thing you do is prevent people from using it in proprietary code, which some people would argue is the whole point. Other people would argue that the inclusion of proprietary developers using open source code resulting in more developers using it has a higher chance of fixes for the open source code being written and submitted upstream (or at the very least more bugs being reported) that then helps everyone, on top of the benefit of greater standardization on open source code meaning better overall code quality.

The problem with that argument (inclusion in proprietary products mean more fixes) is that it does not seem to work out in reality, because in the real world there is very little incentive for corporations to feed back any fixes. Instead companies see fixes as a potential competitive advantage, and hence denying fixes to their competitors makes complete sense.

The GPL has created a 'safe' zone of cooperation among companies, without anyone having to sign complicated legal documents. A company can't feel safe contributing code to the BSDs, because its competitors might simply copy the code without reciprocating. There's much more corporate cooperation in the GPL'ed kernel code than with the BSD'd kernel code. Which means that in practice, it's actually been the GPL that's most 'business-friendly'. So while the BSDs have lost energy every time a company gets involved, the GPL'ed programs gain every time a company gets involved. And that explains it all.

Linux Kernel Contributors 2013. Do you believe that all of those companies would be willingly contributing code without the GPL forcing them to? If it were not for the GPL, most of those companies would immediately fork Linux and start producing their own proprietary versions. We would have Samsung Operating System, Oracle OS, Cisco OS, ARM OS,.. There would be no reason for any of those companies to feed their changes back upstream, since every change that they paid for would be something their competitors could use against them. Samsung released their exFAT driver as closed source, until someone leaked the code and it was found to be a derivative of a GPL driver, and they ended up releasing it as GPL. Would Samsung have done that if the original code were not GPL?

"Making Linux GPL'd was definitely the best thing I ever did." - Linus Torvalds

[zanny]

Valve and SteamOS are the droids you're looking for here :P While the OEMs don't care two whits about Joe Schmo Linux Distribution, 4 or 5 years from now the idea of riding the wave of Valve's success by selling AlienWare Laptops running SteamOS is going to occur to Dell (and for the other Gaming brands), which will be the foot in the door from which things can trickle down. Also it has to be at least a half-rolling release distribution because the average individual isn't going to be willing to go through a complex upgrade process.

Have you actually tried using SteamOS on a desktop? It doesn't have printer drivers, or a whole suite of standard working software (no sane, no samba, dunno about avahi, or file system drivers, etc). The Valve repositories are bare bones and contain almost nothing, so you have to manually add Debian. It uses its own compositor and mix of Debian Stable + Up to Date packages, and has no way to install alternative desktops without using the Debian repos. Also, stock images hard boot to Steam Big Picture, so you have to mod that too. How in the universe does it make sense to try to get that to a working desktop than shipping Debian with Steam installed?

[Luke_Wolf]

The problem with that argument (inclusion in proprietary products mean more fixes) is that it does not seem to work out in reality, because in the real world there is very little incentive for corporations to feed back any fixes. Instead companies see fixes as a potential competitive advantage, and hence denying fixes to their competitors makes complete sense.

Actually that argument is quite vacuous, as we can see from plenty of permissively licensed projects like Mesa, LLVM, CLang, X11, any of the Apache Foundation projects, and even the BSDs . The fact is companies don't contribute because of the license, they contribute because having patches maintained downstream is a pain, or they are interested in it's active development, and the same goes for GPL software because by and large because companies are generally paranoid about using GPLed software, and thus don't avoid using it in their products and any internal patches they have against linux they do not have to make public. Unless things have changed Google for instance is sitting on a significantly changed version of the Linux kernel that it uses internally.

Linux Kernel Contributors 2013. Do you believe that all of those companies would be willingly contributing code without the GPL forcing them to?

Absolutely. The fact is most of those companies aren't forced to do so because they do not distribute linux. Broadcom, Intel and AMD for instance could have chosen to keep the status quo and go proprietary only, after all it's what AMD was doing before. Yet both of them decided to do open source drivers. Why? Because it makes their product more attractive. Oracle, SuSE, Redhat, Google, and Samsung could have maintained their own trees outside of Linus's control or even just dropped glob patches to satisfy the GPL (since it says nothing about pushing the patches upstream). Why go through the process of pushing patches upstream? Because it's a pain to host them downstream, and some of the patches are still being held downstream in spite of the GPL.

If it were not for the GPL, most of those companies would immediately fork Linux and start producing their own proprietary versions. We would have Samsung Operating System, Oracle OS, Cisco OS, ARM OS,..

You mean...: Samsung's take on Android, Oracle Linux, NX-OS, and Linaro? Also hows that Tivo working out for you?

There would be no reason for any of those companies to feed their changes back upstream, since every change that they paid for would be something their competitors could use against them.

There's plenty of reasons: Hardware companies want the best experience OOTB, OS Vendors and companies that use linux internally don't want to carry patches downstream, and those who don't want to contribute don't have to unless they choose to distribute Linux and even if they do they only have to make the changes public not upstream.

Samsung released their exFAT driver as closed source, until someone leaked the code and it was found to be a derivative of a GPL driver, and they ended up releasing it as GPL. Would Samsung have done that if the original code were not GPL?

exFAT is an interesting case as technically they are in violation of Microsoft's License by opensourcing it, however they were in violation of the GPL by it's existence. So Samsung was forced to open source it in order to keep using Android, and as a user you're in the clear to use it however any significantly sized corporate entity who tries to use it without getting a license from Microsoft is in extreme danger of being sued over it.

[Luke_Wolf]

Have you actually tried using SteamOS on a desktop? It doesn't have printer drivers, or a whole suite of standard working software (no sane, no samba, dunno about avahi, or file system drivers, etc). The Valve repositories are bare bones and contain almost nothing, so you have to manually add Debian. It uses its own compositor and mix of Debian Stable + Up to Date packages, and has no way to install alternative desktops without using the Debian repos. Also, stock images hard boot to Steam Big Picture, so you have to mod that too. How in the universe does it make sense to try to get that to a working desktop than shipping Debian with Steam installed?

Technically yes, using Debian with Steam installed would be significantly better, however my point is that for the initial foot in the door targeted at gamers it really doesn't matter that much. A hardcore gamer buying an alienware laptop is going to do mostly gaming, some media, some internet, and light word processing which means that 90% of their usecase can be solved by running in big picture mode. Which will allow Linux to get it's foot in the door and from there the various linux distribution companies and the OEMs can buddy up to find what works best for the rest of the ecosystem.