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

[Del_]

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".

I have a hard time seeing why you reach that conclusion. There are numerous occasions when the license could have been reconsidered. Actually, this may be a case where the typical culture of respecting the choice of permissive licensing was counter productive. I would turn it around and say that during the last two decades I have seen no indication that the permissive license was a good choice. There is a large number of projects indicating that copy-left spurs large involvement when it comes to important plumbing on linux.

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

Then start counting, here is a hundred OS'es for you: http://distrowatch.com/ It seems your definition of wide is "being used by distributions only available with a BSD kernel".

the sheer lack of hostilely licensed forks means that individuals who willingly contribute don't need that gun to their head.

I have no idea how you can conclude like that. Your rhetorics makes no sense to me. Permissively licensed code gets proprietary forks all the time. Are you really oblivious to realities? Yes, it happens that copy-left projects gets abused, but that is the exception. For permissively licensed code it is simply intended usage, and happens all over the place. A very common approach is open core, like Apple does with Clang. Open the compiler, but keep the IDE closed. Xcode is a proprietary fork of LLVM/Clang. Hostile? Hardly, it is the intended usage. The license is specifically designed to allow proprietary forks. The only gun to the developers head is from the employer refusing him/her to release code. From a developers point of view a GPL project is far more attractive. You are basically guaranteed that you can take all your code with you if you choose to change employer. Many would call this freedom, the total opposite of your gun analogy.

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..

I do see what you mean here, but I believe you are misguided. You should distinguish software companies where the copy-left code is part of their product from other companies that are in the user or customer category. For companies where the GPL code helps push their core products there is rather strong incentives to contribute. For companies whose business model is to sell licenses to proprietary code, then using GPL'ed code for the core product can be a bad idea. However, numerous companies have demonstrated that even then, GPL code can help them win the market (ref. Android).

The idea that companies contribute to permissively licensed code more than they would on copy-left does not seem to have any root in reality. There are two companies, namely Microsoft and Apple, that fights copy-left with all means, and they have deep pockets. For the rest of the industry, copy-left can be quite attractive.

[Luke_Wolf]

Then start counting, here is a hundred OS'es for you: http://distrowatch.com/ It seems your definition of wide is "being used by distributions only available with a BSD kernel".

I'm not counting distributions I'm counting OSes which are completely separate things. You can have a distribution of an OS but Distributions != OSes. Linux is an OS however Debian, Fedora, Ubuntu and OpenSUSE are not. FreeBSD, NetBSD,OpenBSD, and DragonFly BSD are OSes, however PC-BSD is not. Solaris is an OS. AIX and friends are an OS. NT is an OS, Windows is not. etc...

I have no idea how you can conclude like that. Your rhetorics makes no sense to me. Permissively licensed code gets proprietary forks all the time. Are you really oblivious to realities? Yes, it happens that copy-left projects gets abused, but that is the exception. For permissively licensed code it is simply intended usage, and happens all over the place. A very common approach is open core, like Apple does with Clang. Open the compiler, but keep the IDE closed. Xcode is a proprietary fork of LLVM/Clang. Hostile? Hardly, it is the intended usage.

Are you really proposing that an IDE is a proprietary fork of a compiler? Really? That's like saying that systemd is a fork of the linux kernel. It relies upon and is built on top of LLVM/CLang however that makes it a derivative work not a fork. The idea that you own the license on someone elses code no matter how complex it is just because they decided to share a common core with other people by utilizing open source libraries sounds exceedingly pretentious and antagonistic to me.

Further getting right down to it Apple is highly involved in the development of LLVM and not that long ago they upstreamed their ARM64 backend, and AMD, Google, and Intel have all been involved in it's development proving the idea quite false that you need to put a legal gun to someone's head in order to get them to open source code or work on a project.

Getting more to the point however the entire point of permissive licensing is to increase the userbase of an application or library by allowing more people to participate with no strings attached. Now please provide proof that attempting to force people to contribute as opposed to letting people choose to contribute results in more and better work upstream.

The license is specifically designed to allow proprietary forks. The only gun to the developers head is from the employer refusing him/her to release code. From a developers point of view a GPL project is far more attractive. You are basically guaranteed that you can take all your code with you if you choose to change employer. Many would call this freedom, the total opposite of your gun analogy.

You do realize that for proprietary developers, their companies basically forbid even touching GPL code right? Which means you can cut them entirely out of the picture. For a commercial Open Source developer (say Red Hat or SUSE) then my goal is to get my software as widely supported as possible so that I can have more support contracts. Permissive licensing allows you to get support contracts from not just open source developers but proprietary ones as well, which is more advantageous to me.

Further copyleft has no advantages over permissive licensing in terms of taking it with you (Which only applies to proprietary developers anyway, as Open Source development is well... Open Source), and it only brings an advantage in cases where you need to point a gun at someone's head.

I do see what you mean here, but I believe you are misguided. You should distinguish software companies where the copy-left code is part of their product from other companies that are in the user or customer category. For companies where the GPL code helps push their core products there is rather strong incentives to contribute. For companies whose business model is to sell licenses to proprietary code, then using GPL'ed code for the core product can be a bad idea. However, numerous companies have demonstrated that even then, GPL code can help them win the market (ref. Android).

So inotherwords this is a long roundabout way of saying: "Individuals who have a deep interest in an open source project, are far more likely to contribute to it, however individuals who can't take advantage of it aren't going to use it (and thus won't contribute)".

Further Android beating Apple can't actually be attributed to the GPL, but that open source is an inherently superior development flow than closed source, and open hardware beats closed hardware. Or to put it another way: Free Markets always win.

The idea that companies contribute to permissively licensed code more than they would on copy-left does not seem to have any root in reality. There are two companies, namely Microsoft and Apple, that fights copy-left with all means, and they have deep pockets. For the rest of the industry, copy-left can be quite attractive.

You have presented no evidence of this whatsoever.

Also here's a few of the reasons why permissive licensed code is more likely to have more meaningful contributors than copyleft in a few points:

1). Proprietary Developers can actually use your code resulting in an increase in the number of developers using your code over copy-left competitors which has a positive correlation to the number of patches and useful bug reports.
2). Permissive licensing does not have the religion of the FSF trailing it around everywhere demanding that forcing everything to be open source is better than proper engineering, amount of contributors, or usage. As a result of said fanatics software comes into existing that is intentionally designed to not allow proprietary developers to do anything with it at the cost of good design (See the GCC). The side effect being that you can't really reuse the software written by said fanatics for anything else even if you're an open source developer.
3). Permissive licensing is indicative of a desire for wider adoption meaning that the individual is more likely to put in the effort to design it to be reusable, and that things are done right.

[drSeehas]

... Linux is an OS ...

Linux is NOT an OS! It is just a kernel.
For the rest I fully agree with you.

[Luke_Wolf]

Linux is NOT an OS! It is just a kernel.

Well.... That's kind of a matter of opinion, if Linux was a microkernel then yes it would be "just a kernel" however linux is a macrokernel which means that most of the bits that sit between the hardware and the applications is there in the kernel and as a result the kernel is most of what defines an OS. Yes you need to add in the userland drivers like Mesa and Bluez, an IPC method like dbus, an init system, and some sort of userland like GNU or BSD, but it's a bit of a hard claim to say you're using a different OS by using zsh instead of bash, or systemd instead of SysV.

[emblemparade]

Linux is NOT an OS! It is just a kernel.

It depends on what you consider to be the scope of the term "operating system." Linux contains much of the functionality required to "operate" a computer. Whether or not a userland (that includes a desktop environment or not?) is necessary for that definition is a matter of opinion.

The argument between Linus and RMS about whether "Linux" should be called "GNU/Linux" (for those distributions that include much of the GNU userland) is thus quite silly, considering that both of these people should know better. Most Linux-based desktop operating systems (Ubuntu Desktop, Fedora, etc.) include a very large amount of software packages, many of them with many, many more lines of code than either Linux or GNU. The question of which packages should be considered essential is entirely relative: the whole point of a "general purpose" operating system is that it can be put to all kinds of uses. For many uses the kernel doesn't matter much. For example, you can run LibreOffice on a Linux OS or on a FreeBSD OS, and if that's your core use, "Linux" is simply not that significant. On the other hand, if you're creating a router based on Linux, it's very reasonable to call your operating system "Linux."

Calling Linux "just" a kernel also isn't saying much: it a simple reference to the parts of the OS that run in the CPU's kernel-mode. It's technically important for some use-cases, but that says more about the technical architecture than the use case. (For example, micro-kernel OSes have very little code running in kernel-mode.)

Case closed, let's move on.

[chrisb]

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 .

X11 is not a good example of permissive licensing encouraging upstream contributions. X11 was forked by HP, DEC, Apple, Exceed, X-Win32, Attachmate... at one point, pretty much every Unix vendor shipped their own version of the X Server.

BSD Is not a good example either, there have been multiple forks, how many patch sets get shared between those forks?

As a counter-example: what about AOSP? Practically every Android OEM forked AOSP and only released their changes to the GPL Linux kernel (because they had to), whilst keeping all their other changes closed. Why would they do that? Is it just random chance that they happen to release the source for the GPL component of AOSP, but keep all of the non-GPL closed?

The fact is companies don't contribute because of the license

That is not a fact, that is an opinion. I once read a quote from a senior manager at IBM during the SCO case, and he said that IBM contribute to the Linux kernel because of the GPL. I can not find the quote online right now, but it was something like, "The GPL is the only reason that multiple companies can cooperate and contribute to the Linux kernel without having to get lawyers to write thousands of licensing agreements and NDAs".

Absolutely. The fact is most of those companies aren't forced to do so because they do not distribute linux.

Just because they are not traditional Linux distributions, does not mean that they do not distribute Linux in some form. A lot of companies, especially in the embedded space, distribute test kits, SDKs, etc. that include binary images with the Linux kernel. A lot of companies distribute hardware that has the Linux kernel built in. Even a prototype board with Linux on the flash counts as redistribution.

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.

This is not a great argument. Broadcom has some closed source drivers. AMD has some closed source drivers. Linaro has closed source drivers and their own fork of the kernel. Samsung has closed source drivers, so does Qualcomm, so does Texas Instruments, so does Nvidia, so does Freescale...

A better explanation is that these companies are strategically choosing which patches to open source and upstream. If they think they can argue that the GPL does not apply (binary driver module), then they do not open source or upstream. If they think that the GPL does not apply (internal use only, no redistribution), then they do not release or upstream. If they are a small company and think that upstreaming helps them sell chips, then they upstream. If they do not believe that there is any commercial advantage to the code, and they do not want to pay their own programmers to maintain it, then they upstream. If they sell chips and provide their own hardware kits with their own kernel and commercial support package, then they selectively upstream some bits, but try to ensure that their commercial developers are locked into using their SDK by not upstreaming some bits, not providing commercial support for upstream kernel, etc.

Oracle, SuSE, Redhat, Google, and Samsung could have maintained their own trees outside of Linus's control

They do. What the GPL ensures is that developers who get products containing a kernel from, say, Samsung, can get the source of that product, and can take patches from that source, clean them up, and forward them to Linus. This changes the dynamic, since core changes can no longer be kept secret, and companies know this, and so they might change their behaviour. But the world is still full of companies, particularly in the embedded and mobile space, who do maintain their own kernels, and do a single dump of source only when a customer demands.

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

Sure, those companies can fork the kernel and maintain their own fork. The GPL does not prevent that. What it does it reduce the incentive to do so; since they have to release the source, there can be no "secret changes", and whatever they do release can be copied back into the mainline kernel by anybody. This is the bit of the process that is missing with permissive licenses.

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.

A third party can not be held liable for any contractual dispute between Microsoft and Samsung, and besides, as far as I know nobody has presented any evidence that Samsung did violate Microsoft's license by opensourcing the Samsung implementation of exFAT. However, exFAT is patented, so to use it you would need to secure a license to use the patent from Microsoft, or go to court and argue that the patent is invalid.

[Del_]

Are you really proposing that an IDE is a proprietary fork of a compiler? Really?.

Yes really. Just as webkit is part of safari and cups has had proprietary extensions on OSX for quite some time. Moreover, I believe the only reason Apple keeps LLVM/Clang development sort of open (they did keep the ARM64 stuff rather closed for quite some time, didn't you notice?), is because of their stated goal of out-competing gcc. I only hope they fail, and that both compiler stacks prosper in the time to come. It is going to be very interesting to see how other companies involvement in LLVM/Clang works out long term. It certainly didn't take google long to figure out that webkit collaboration was rather tedious. But yes, the model can succeed. Let's discuss it again in ten years.

Getting more to the point however the entire point of permissive licensing is to increase the userbase of an application or library by allowing more people to participate with no strings attached. Now please provide proof that attempting to force people to contribute as opposed to letting people choose to contribute results in more and better work upstream.

Nothing prevents anybody from using GPL code. Everybody uses linux today. What you are trying to say is that you are losing those developers that would like to include the code in their employers software, and you believe this to be a very important group of developers. In some cases this may be true, typically if you have one major company throwing the code over the fence for free for all. If you on the other hand conclude that their is no such rich uncle, then the empirical evidence telling you that you are wrong is right in front of your nose. In the case of openstack, that rich uncle was Rackspace, and they have had a tremendous success with their bet so far. I am very interested in seeing how this plays out though. I am afraid proprietary extensions and management software will be abundant some years down the road. That is, unless Red Hat decides to be the second rich uncle for the project. If they do, I do hope they choose GPL for licensing regardless.

You do realize that for proprietary developers, their companies basically forbid even touching GPL code right?.

As developers yes, as users no. You really need to raise your precision level. They can still report bugs, and even provide patches, as users. And they do in large numbers. For me this is very pragmatic. When it comes to support contracts, it is not given that you will get more of them on a permissively licensed code base.

I should note that copyright transfer agreements like Ubuntu's CLA are very problematic. For this discussion I am thinking of copy-left projects with distributed copyright.

and stop with the gun already. It is even worse than all the car analogies that plague the internet.

Further Android beating Apple can't actually be attributed to the GPL, but that open source is an inherently superior development flow than closed source, and open hardware beats closed hardware..

On this we agree, but I am afraid humans are not that idealistic in general. I do believe we need GPL to keep the suits in check. As I am sure you know, a lot of people only care about the own short term profit.

1). Proprietary Developers can actually use your code resulting in an increase in the number of developers using your code over copy-left competitors which has a positive correlation to the number of patches and useful bug reports.
2). Permissive licensing does not have the religion of the FSF trailing it around everywhere demanding that forcing everything to be open source is better than proper engineering, amount of contributors, or usage. As a result of said fanatics software comes into existing that is intentionally designed to not allow proprietary developers to do anything with it at the cost of good design (See the GCC). The side effect being that you can't really reuse the software written by said fanatics for anything else even if you're an open source developer.
3). Permissive licensing is indicative of a desire for wider adoption meaning that the individual is more likely to put in the effort to design it to be reusable, and that things are done right.

Yes, you can get extra contributors from proprietary software houses, those may or may not outweigh potentially lost developers or sponsors. No, GCC is not hampered by politics, basically all issues have been addressed (transition to C++, plugin interface, modular code base, facilitating JIT). Actually you are very hard pressed to find a project more willing to adapt to those who wish better design than GCC. We all know where RMS comes from, but I get very provoked by your unfounded bashing of the GCC developers here. Desire for wider adoption? I beg to differ. My involvement in GPL projects is certainly fuelled my belief that those projects will get wider adoption than permissively licensed alternatives. I cannot speak for other of course, but neither should you.

[chrisb]

You do realize that for proprietary developers, their companies basically forbid even touching GPL code right?.

As developers yes, as users no. You really need to raise your precision level. They can still report bugs, and even provide patches, as users. And they do in large numbers. For me this is very pragmatic. When it comes to support contracts, it is not given that you will get more of them on a permissively licensed code base.

The companies that I have worked for have had no problem with using or shipping GPL software in their products. The only place the developers couldn't add GPL code was into the source code of the company's own proprietary software. But using it everywhere else, modifying it when needed etc. was absolutely fine. One company had a contractual obligation to report the licenses of any sub-software they used in their product (our customer required it for reporting to regulatory authorities). Again, no problem - one of our developers wrote a simple script that extracted all of the package dependencies of our software, then looked up the LICENSE variable of each package from a Gentoo ebuild and copied the license from /usr/portage/licenses/. The customer got a big list of every package and every license on the system. Nobody cared that many packages were GPL - not our company, or the customer, or the regulator. The GPL is only a problem if you want to take that code and use for your own proprietary product, or use a GPL library (of which there aren't actually that many). Having your own proprietary process running on an otherwise GPL system is completely legal.

[Del_]

The companies that I have worked for have had no problem with using or shipping GPL software in their products. The only place the developers couldn't add GPL code was into the source code of the company's own proprietary software..

Exactly.

Nobody cared that many packages were GPL - not our company, or the customer, or the regulator.

Actually, as a customer I do care (in the positive sense). Projects with proprietary dependencies is not attractive. When depending on open projects it is also very important that the project is healthy, which tends to more often be the case with GPL.

[Luke_Wolf]

X11 is not a good example of permissive licensing encouraging upstream contributions. X11 was forked by HP, DEC, Apple, Exceed, X-Win32, Attachmate... at one point, pretty much every Unix vendor shipped their own version of the X Server.

The Question isn't whether those vendors forked, the question is rather whether those vendors contributed back upstream.

BSD Is not a good example either, there have been multiple forks, how many patch sets get shared between those forks?

While I don't follow the BSDs that closely I do know that the Radeon KMS work was shared between the BSDs, and the changelog for FreeBSD 10 implies a lot of sharing of patchsets. I do know that Sony contributed AVX support back to upstream FreeBSD.

As a counter-example: what about AOSP? Practically every Android OEM forked AOSP and only released their changes to the GPL Linux kernel (because they had to), whilst keeping all their other changes closed. Why would they do that? Is it just random chance that they happen to release the source for the GPL component of AOSP, but keep all of the non-GPL closed?

Not true, a quick scan of AOSP's commit history and Ohloh tells us a different story. https://android-review.googlesource.com/#/q/statuspen http://www.ohloh.net/p/android If it was as you claimed, Intel and Sony wouldn't have submitted patches and the contributor base would be a lot smaller and completely made up of Google and independent contributions.

That is not a fact, that is an opinion. I once read a quote from a senior manager at IBM during the SCO case, and he said that IBM contribute to the Linux kernel because of the GPL. I can not find the quote online right now, but it was something like, "The GPL is the only reason that multiple companies can cooperate and contribute to the Linux kernel without having to get lawyers to write thousands of licensing agreements and NDAs".

Given that IBM is one of the largest backers of the Apache Foundation I don't buy that even if some senior manager did say that. The kernel is not unique among software, and there are plenty of large permissively licensed projects where those games aren't being played.

Just because they are not traditional Linux distributions, does not mean that they do not distribute Linux in some form. A lot of companies, especially in the embedded space, distribute test kits, SDKs, etc. that include binary images with the Linux kernel. A lot of companies distribute hardware that has the Linux kernel built in. Even a prototype board with Linux on the flash counts as redistribution.

That presumes that they're carrying a patchset on those kits vs vanilla linux, also please do point me towards the images/hardware that AMD or Intel distribute in this fashion.

This is not a great argument. Broadcom has some closed source drivers. AMD has some closed source drivers. Linaro has closed source drivers and their own fork of the kernel. Samsung has closed source drivers, so does Qualcomm, so does Texas Instruments, so does Nvidia, so does Freescale...

Actually it's a perfect validation of my argument because guess what all these companies distributing closed source drivers mean? The GPL is being no more effective at forcing companies to contribute that don't want to contribute than a permissive license would be. However companies interested in providing open source drivers (Intel and AMD) will do so.

A better explanation is that these companies are strategically choosing which patches to open source and upstream. If they think they can argue that the GPL does not apply (binary driver module), then they do not open source or upstream. If they think that the GPL does not apply (internal use only, no redistribution), then they do not release or upstream. If they are a small company and think that upstreaming helps them sell chips, then they upstream. If they do not believe that there is any commercial advantage to the code, and they do not want to pay their own programmers to maintain it, then they upstream. If they sell chips and provide their own hardware kits with their own kernel and commercial support package, then they selectively upstream some bits, but try to ensure that their commercial developers are locked into using their SDK by not upstreaming some bits, not providing commercial support for upstream kernel, etc.

For the ARM Manufacturers and anyone else who don't want anything to do with open source code but are forced into it because Android is based on linux, sure. For everyone else no. Intel and AMD again as an example aren't writing Mesa drivers because they have to, they're doing it to achieve better OOTB support and to take advantage of the benefits of open source development.

They do. What the GPL ensures is that developers who get products containing a kernel from, say, Samsung, can get the source of that product, and can take patches from that source, clean them up, and forward them to Linus. This changes the dynamic, since core changes can no longer be kept secret, and companies know this, and so they might change their behaviour. But the world is still full of companies, particularly in the embedded and mobile space, who do maintain their own kernels, and do a single dump of source only when a customer demands.

That again assumes distribution of the kernel, Google for instance has a lot of bits locked up meaning core bits are still kept secret, and sure someone can attempt to upstream a blob patch but blob patches are an excessive pain with a huge barrier to entry which means that pointing a gun to a companies head and demanding they turn over source is usually not something that sets up having more meaningful contributors.

Sure, those companies can fork the kernel and maintain their own fork. The GPL does not prevent that. What it does it reduce the incentive to do so; since they have to release the source, there can be no "secret changes", and whatever they do release can be copied back into the mainline kernel by anybody. This is the bit of the process that is missing with permissive licenses.

You cut out secret sauce if the company distributes the source, yes, but the question is does that actually positively effect people who don't want to open source their code into becoming open source friendly and contributing... the answer as seen by the ARM situation is no, they just find a way to hack around the GPL with shims.

A third party can not be held liable for any contractual dispute between Microsoft and Samsung, and besides, as far as I know nobody has presented any evidence that Samsung did violate Microsoft's license by opensourcing the Samsung implementation of exFAT. However, exFAT is patented, so to use it you would need to secure a license to use the patent from Microsoft, or go to court and argue that the patent is invalid.

Okay you have a point that nobody knows what Samsung's actual terms for exFAT were, however that's kind of what I'm getting at. As an individual user you can willfully infringe in the comfort of your own home and you're not a big enough target for anybody to care about assuming they even know, but any large company would be under immediate threat by Microsoft unless they licensed the patent.