Failure of the GPL
David Chisnall takes a critical look at the GNU GPL and asks if it does more harm than good for the Free Software movement.
In 1985, the Free Software Foundation (FSF) was formed to promote software freedom, as defined by these four freedoms:
One of the tools used to accomplish this is the GPL license. Looking back, was the GPL help or hindrance? And will it continue to be help or hindrance in the future?
The FSF website points to a specific instance of the GPL in order to force a company to open its source code. The company in this example is NeXT (now Apple), and the source code is Objective-C front-end for GCC. But what really happened?
When NeXT bought rights to Objective-C, it inherited two pieces of technology. One was a preprocessor — a fairly simple program that turned Objective-C into pure C. The other was a runtime library that processed all dynamic requests, module loading, and other elements required for a complete Objective-C environment. The preprocessing approach had some limitations, not the least of which was difficulty in debugging, so NeXT decided to move the preprocessor to the compiler.
At the same time, the C compiler used was GCC, which was released under the GPL. To avoid the limitations of this code, NeXT has provided its front-end as a library that end users link to GCC, thus avoiding the GPL (which only applies to software distribution, without regard to how you use it). This small legal maneuver did not work, however, NeXT was forced to release the code.
Remember that an Objective-C implementation consists of two parts: a compiler and a library. NeXT was required to release its compiler code, excluding the runtime library. As one who worked on the Objective-C compiler and two Objective-C runtime libraries, I can say with some certainty that NeXT could not count on a better outcome in this situation: for Objective-C dialects of that era, the library is much more complex than compiler.
Instead of acknowledging that it was a worthless piece of code, the GNU Project wrote its own library for Objective-C - and this is when the most interesting things started. The GNU library was not a real replacement for the NeXT library, and GNU needed to change the compiler to support the new library. The modification involved a lot of operators #ifdef Objective-C support file. Of course, NeXT had no interest in supporting the GNU library, and therefore did not bother to import these changes.
Periodically, NeXT would release a new version of its fork GCC, and the main developers would try to backport their changes to the mainline. When Apple took over NeXT, Apple continued to work on GCC, adding enhancements such as improved SIMD support to take advantage of AltiVec modules on PowerPC processors that Apple supplied. Developers also continued to add features to Objective-C. Since the Apple branch supported a single runtime library, there was no clear separation between runtime-specific and runtime-independent parts, and thus the GNU branch quickly fell behind.
However, the story does not end there. Later, Apple wanted to more closely integrate the compiler with its IDE. One of the good things about Visual Studio is that it uses the same parser and semantic analyzer to highlight syntax and error messages as for code generation, allowing you to get much better feedback than from completely separate two editors. Unfortunately for Apple, the GPL required either to open source code for Xcode or rewrite GCC. Apple chose the latter.
Fortunately, Apple didn't have to start from scratch, but instead it was able to hire the lead developer of the LLVM Compiler Infrastructure Project, a compiler infrastructure with a BSD license, and get him to work. The result was the creation of a new project, clang, to create a new front-end for LLVM, which supported C, Objective-C, and C ++. This front-end currently supports the GNU library and two Apple libraries, and supports several features — such as fast enumeration and partial support for declared properties — that GCC does not even use the GNU library.
Clang is not the only Objective-C front end for LLVM, although the only one based on GCC. Unfortunately for people using non-Apple platforms, it is based on the Apple GCC branch, and therefore supports only Objective-C on Darwin. This front-end is covered by the GPL, while the one that has the best support of the GNU library comes under the BSD license.
What lesson should we learn from this story?
First, we learn that you do not necessarily get good results due to the fact that you are forcing people to do something. NeXT's Objective-C code was introduced to GCC grudgingly, and never really supported. In contrast, Apple’s code introduced in clang was written with a clear level of abstraction and makes it easy to maintain new runtime libraries. This was not required by Apple, which launched the project and therefore she could do whatever she wanted with it. Since Apple eagerly attracted the community, the result was the best for everyone.
The second thing to remember is that sometimes having someone else’s code is actually not a good thing. Objective-C code in GCC is a creepy, unreadable mess. Objective-C is a small language, and the GCC team could possibly combine it with its own front end at the most in a few weeks. If the team did this, they would probably design it so as to support multiple libraries from the start, and end up with something much more comfortable to maintain.
For some time, Google has been a model representative of the free software community. The entire Google infrastructure is built around free software, and Google returns a lot to Linux. This can be considered a success for the GPL.
The elephant in this china shop is Google's file system, a highly scalable distributed file system used in Linux. Has Google published it? Not. But does the GPL require it? After all, wasn't that the goal — to get people who benefit from and improve free software, to share their improvements with the community?
In fact, no. As I mentioned earlier, the GPL is a distribution license, not a use license. It comes into effect when you distribute the code. If you use it only for yourself, you should not share your changes for anyone.
However, Google has made a fair contribution of the code to Linux. Why? Because it’s cheaper for guys from Google to keep this code up to date than to keep a constantly growing local patch set for things that are not key to their business. Every company that uses free software should do this calculation. The content of changes in the secret entails an increase in costs (such as additional maintenance work, when someone makes some changes that break your patches) and benefits (the commercial advantage you get from being the only one with such a key feature) . If the costs outweigh the benefits, then any competently managed company will release its code, regardless of whether the license requires it or not.
This explains why Yahoo! hired people full-time to work on FreeBSD and made most of the changes. Yahoo! used FreeBSD internally, and needed to add certain features and fix bugs. Like the GPL, the BSD license only applies to distribution, but even if people from Yahoo! distributed the code, they would not need to release their changes. Only they did it because they had a good business sense.
Let's think about it for a moment. The latest estimates that I saw showed that approximately 10% of developers were employed to write bulk software, while the remaining 90% were used to develop software for internal use. None of these people are required to release GPL code changes, which they modify and use for themselves. The community does not necessarily benefit from any of their work, but can the GPL cause any actual damage?
Several people in various companies recently told me something that makes me believe that the GPL is actually detrimental: These people said that they would use projects with BSD or a similar license to base their internal systems, but would avoid the GPL, because their legal department decided that compliance with the license is too difficult. If they use the code under the BSD license, they will make improvements, but keep their internal code closed. (In most cases, nobody would care if the code was released or not, as it is highly specialized.)
The FSF makes two sets of free software licenses — one that is GPL-compatible and the other is GPL-incompatible. This is an interesting position, because most of the “GPL-incompatible” licenses are single-file, allowing you to combine them with code under any other license. The GPL places additional restrictions on the code, and therefore is incompatible. You can easily combine the code under the APSL, MPL, CDDL, Apache, and BSD licenses in one project, but you can combine only one of them with the GPLv2 code.
Even the FSF does not manage to solve all this correctly. Version 3 of the LGPL, for example, is incompatible with version 2 of the GPL. This recently caused a problem for several GNU library projects that wanted to switch to the LGPLv3, but were used by other projects that were GPLv2-only.
The official position is that projects should not be v2-only, they should always be v2-or-later. I will let you try to convince Linux to switch. Oh, and good luck, also, with PDF readers; The only open source PDF readers are currently based on xpdf, which is GPLv2-only. FSF is desperately trying to write a new PDF library to work around this limitation, and licenses it as GPLv3-or-later.
This attitude is understandable. Richard Stallman believes that writing proprietary software is antisocial. Unfortunately, this way of thinking leads to a loss of opportunity. The GPL does not give you a choice in writing some proprietary software and promoting its free software. If you want to use some code under the GPL, you must have your entire project under the GPL (which is sometimes impossible due to third-party requirements).
This is where the FSF and I have a fundamental philosophical disagreement. I believe the community benefits when the amount of free software grows. The Free Software Foundation believes that the community is harmed when the number of proprietary programs grows, and that facilitating the writing of proprietary software is a bad thing, even when, as a result of a side effect, developers improve some free software.
The GPL is a few pages of legal jargon. I have read it several times, and still need to clarify certain things, and I probably have better knowledge of copyright law than the average developer. One of the main reasons for using free software is that there is no cost to maintain licenses. Any part of free software comes with the freedoms of FSF 0 and 2, meaning that you can use it and copy it as much as you like. This procedure dramatically simplifies auditing, and is a huge gain for large companies.
Since the GPL is a free software license, the same principle applies here, right? Yes, while you distribute with source codes. There is an easy way to break version 2 of the GPL, which, I believe, is at least half the readers of this article guilty of. Take the source code of your favorite GPLv2 project, compile it, and give a friend a binary file. Oops - you just committed copyright infringement. GPLv2 requires that you either provide the source or written proposal (valid for three years) upon their submission (see clause 3).
It is generally useful to take into account when compiling software for your friends who are not particularly versed in computers. They have no interest in the source code, but the GPL requires you to give them the source code (they will thank you for it when they download the combined package for a mobile pay-per-call connection), or give them a written proposal for the source code. If you choose the second option, you must have a copy of the source available for three years - and do not forget that this should be exactly the version used to build the binary.
This is just an individual problem, right? Well, not quite. Imagine this conversation taking place between two employees of different companies:
Sounds reasonable? Variations of the same conversation are widespread when the software in question is proprietary, and its copying is illegal, and for free software such a conversation is likely to be even more peculiar.
This helpful employee has now brought his company under legal responsibility. Notice that in this example no one changes the source text at all, they both only use and exchange. These two conditions, defined by the free software foundation as being vital, but still exercising these freedoms, they violated the license.
Of course, no reasonable developer would have sued for this kind of GPL violation. Unfortunately, there is no easy way to check whether the developers of a particular program are reasonable.
The GPL inflates the issue of binding. If you want to avoid having to comply with the GPL requirements, you need your code to work as a completely separate program. You can connect two programs through channels or sockets if you do this through a fairly universal interface, without sharing the results of your work. Or, as NVIDIA discovered, you can provide a GPL version of a GPL program that provides a universal interface, and then force end users to associate it with some proprietary code.
If you are creative enough, it’s quite easy to bypass the restrictions imposed by the GPL. With web services and web applications becoming more common, you don’t even have to strain too much. You can embed as many GPL codes as you want in your proprietary web application or service, and nobody can get the code because you don’t distribute the binary — you just allow people to use it.
The GPL Affero is trying to address this issue by requiring you to leave in place any existing “download source” links. Of course, this requirement made Affero GPL incompatible with GPLv2 (v3, has a special exception). Since this requirement limits the modifications you can make in the code, it violates four freedoms (although this does not prevent the FSF from recommending it).
If the GPL is easy to get around, why is this a problem? Anyone who needs to set additional restrictions on the code can do it - that is, anyone with enough money to spend on additional developer effort or legal advice, and therein lies the problem. The GPL is not able to achieve its original goals, and it also prevents people who do not want to hire a lawyer to read several pages of legal jargon and find out whether their intended use can really be allowed. It is easy to break by accident; but if you really want to break the spirit of the license, it is still possible to comply with the letter of the license. Realizing this situation, it becomes easy to understand why licensed-licensed alternatives to GPL programs have recently begun to see much more commercial developers.
In 1985, the Free Software Foundation (FSF) was formed to promote software freedom, as defined by these four freedoms:
0. Freedom to execute the program, for any purpose.
1. Freedom to learn how the program works, and adapt to your needs.
')
2. Freedom to distribute copies to help your neighbor.
3. Freedom to improve the program, and release its improvements (and modified versions in general) for everyone, so as to benefit the whole community.
One of the tools used to accomplish this is the GPL license. Looking back, was the GPL help or hindrance? And will it continue to be help or hindrance in the future?
GPL Success Story
The FSF website points to a specific instance of the GPL in order to force a company to open its source code. The company in this example is NeXT (now Apple), and the source code is Objective-C front-end for GCC. But what really happened?
When NeXT bought rights to Objective-C, it inherited two pieces of technology. One was a preprocessor — a fairly simple program that turned Objective-C into pure C. The other was a runtime library that processed all dynamic requests, module loading, and other elements required for a complete Objective-C environment. The preprocessing approach had some limitations, not the least of which was difficulty in debugging, so NeXT decided to move the preprocessor to the compiler.
At the same time, the C compiler used was GCC, which was released under the GPL. To avoid the limitations of this code, NeXT has provided its front-end as a library that end users link to GCC, thus avoiding the GPL (which only applies to software distribution, without regard to how you use it). This small legal maneuver did not work, however, NeXT was forced to release the code.
The note
In fact, this trick would probably work if NeXT could show that its front-end did not use the results of GCC (problematic because it used), or if NeXT did not distribute GCC (which it distributed).
Remember that an Objective-C implementation consists of two parts: a compiler and a library. NeXT was required to release its compiler code, excluding the runtime library. As one who worked on the Objective-C compiler and two Objective-C runtime libraries, I can say with some certainty that NeXT could not count on a better outcome in this situation: for Objective-C dialects of that era, the library is much more complex than compiler.
Instead of acknowledging that it was a worthless piece of code, the GNU Project wrote its own library for Objective-C - and this is when the most interesting things started. The GNU library was not a real replacement for the NeXT library, and GNU needed to change the compiler to support the new library. The modification involved a lot of operators #ifdef Objective-C support file. Of course, NeXT had no interest in supporting the GNU library, and therefore did not bother to import these changes.
Periodically, NeXT would release a new version of its fork GCC, and the main developers would try to backport their changes to the mainline. When Apple took over NeXT, Apple continued to work on GCC, adding enhancements such as improved SIMD support to take advantage of AltiVec modules on PowerPC processors that Apple supplied. Developers also continued to add features to Objective-C. Since the Apple branch supported a single runtime library, there was no clear separation between runtime-specific and runtime-independent parts, and thus the GNU branch quickly fell behind.
However, the story does not end there. Later, Apple wanted to more closely integrate the compiler with its IDE. One of the good things about Visual Studio is that it uses the same parser and semantic analyzer to highlight syntax and error messages as for code generation, allowing you to get much better feedback than from completely separate two editors. Unfortunately for Apple, the GPL required either to open source code for Xcode or rewrite GCC. Apple chose the latter.
Fortunately, Apple didn't have to start from scratch, but instead it was able to hire the lead developer of the LLVM Compiler Infrastructure Project, a compiler infrastructure with a BSD license, and get him to work. The result was the creation of a new project, clang, to create a new front-end for LLVM, which supported C, Objective-C, and C ++. This front-end currently supports the GNU library and two Apple libraries, and supports several features — such as fast enumeration and partial support for declared properties — that GCC does not even use the GNU library.
Clang is not the only Objective-C front end for LLVM, although the only one based on GCC. Unfortunately for people using non-Apple platforms, it is based on the Apple GCC branch, and therefore supports only Objective-C on Darwin. This front-end is covered by the GPL, while the one that has the best support of the GNU library comes under the BSD license.
What lesson should we learn from this story?
First, we learn that you do not necessarily get good results due to the fact that you are forcing people to do something. NeXT's Objective-C code was introduced to GCC grudgingly, and never really supported. In contrast, Apple’s code introduced in clang was written with a clear level of abstraction and makes it easy to maintain new runtime libraries. This was not required by Apple, which launched the project and therefore she could do whatever she wanted with it. Since Apple eagerly attracted the community, the result was the best for everyone.
The second thing to remember is that sometimes having someone else’s code is actually not a good thing. Objective-C code in GCC is a creepy, unreadable mess. Objective-C is a small language, and the GCC team could possibly combine it with its own front end at the most in a few weeks. If the team did this, they would probably design it so as to support multiple libraries from the start, and end up with something much more comfortable to maintain.
Google for linux
For some time, Google has been a model representative of the free software community. The entire Google infrastructure is built around free software, and Google returns a lot to Linux. This can be considered a success for the GPL.
The elephant in this china shop is Google's file system, a highly scalable distributed file system used in Linux. Has Google published it? Not. But does the GPL require it? After all, wasn't that the goal — to get people who benefit from and improve free software, to share their improvements with the community?
In fact, no. As I mentioned earlier, the GPL is a distribution license, not a use license. It comes into effect when you distribute the code. If you use it only for yourself, you should not share your changes for anyone.
However, Google has made a fair contribution of the code to Linux. Why? Because it’s cheaper for guys from Google to keep this code up to date than to keep a constantly growing local patch set for things that are not key to their business. Every company that uses free software should do this calculation. The content of changes in the secret entails an increase in costs (such as additional maintenance work, when someone makes some changes that break your patches) and benefits (the commercial advantage you get from being the only one with such a key feature) . If the costs outweigh the benefits, then any competently managed company will release its code, regardless of whether the license requires it or not.
This explains why Yahoo! hired people full-time to work on FreeBSD and made most of the changes. Yahoo! used FreeBSD internally, and needed to add certain features and fix bugs. Like the GPL, the BSD license only applies to distribution, but even if people from Yahoo! distributed the code, they would not need to release their changes. Only they did it because they had a good business sense.
Let's think about it for a moment. The latest estimates that I saw showed that approximately 10% of developers were employed to write bulk software, while the remaining 90% were used to develop software for internal use. None of these people are required to release GPL code changes, which they modify and use for themselves. The community does not necessarily benefit from any of their work, but can the GPL cause any actual damage?
Several people in various companies recently told me something that makes me believe that the GPL is actually detrimental: These people said that they would use projects with BSD or a similar license to base their internal systems, but would avoid the GPL, because their legal department decided that compliance with the license is too difficult. If they use the code under the BSD license, they will make improvements, but keep their internal code closed. (In most cases, nobody would care if the code was released or not, as it is highly specialized.)
Who is not with us is against us
The FSF makes two sets of free software licenses — one that is GPL-compatible and the other is GPL-incompatible. This is an interesting position, because most of the “GPL-incompatible” licenses are single-file, allowing you to combine them with code under any other license. The GPL places additional restrictions on the code, and therefore is incompatible. You can easily combine the code under the APSL, MPL, CDDL, Apache, and BSD licenses in one project, but you can combine only one of them with the GPLv2 code.
Even the FSF does not manage to solve all this correctly. Version 3 of the LGPL, for example, is incompatible with version 2 of the GPL. This recently caused a problem for several GNU library projects that wanted to switch to the LGPLv3, but were used by other projects that were GPLv2-only.
The official position is that projects should not be v2-only, they should always be v2-or-later. I will let you try to convince Linux to switch. Oh, and good luck, also, with PDF readers; The only open source PDF readers are currently based on xpdf, which is GPLv2-only. FSF is desperately trying to write a new PDF library to work around this limitation, and licenses it as GPLv3-or-later.
This attitude is understandable. Richard Stallman believes that writing proprietary software is antisocial. Unfortunately, this way of thinking leads to a loss of opportunity. The GPL does not give you a choice in writing some proprietary software and promoting its free software. If you want to use some code under the GPL, you must have your entire project under the GPL (which is sometimes impossible due to third-party requirements).
This is where the FSF and I have a fundamental philosophical disagreement. I believe the community benefits when the amount of free software grows. The Free Software Foundation believes that the community is harmed when the number of proprietary programs grows, and that facilitating the writing of proprietary software is a bad thing, even when, as a result of a side effect, developers improve some free software.
I feel disturbed!
The GPL is a few pages of legal jargon. I have read it several times, and still need to clarify certain things, and I probably have better knowledge of copyright law than the average developer. One of the main reasons for using free software is that there is no cost to maintain licenses. Any part of free software comes with the freedoms of FSF 0 and 2, meaning that you can use it and copy it as much as you like. This procedure dramatically simplifies auditing, and is a huge gain for large companies.
Since the GPL is a free software license, the same principle applies here, right? Yes, while you distribute with source codes. There is an easy way to break version 2 of the GPL, which, I believe, is at least half the readers of this article guilty of. Take the source code of your favorite GPLv2 project, compile it, and give a friend a binary file. Oops - you just committed copyright infringement. GPLv2 requires that you either provide the source or written proposal (valid for three years) upon their submission (see clause 3).
It is generally useful to take into account when compiling software for your friends who are not particularly versed in computers. They have no interest in the source code, but the GPL requires you to give them the source code (they will thank you for it when they download the combined package for a mobile pay-per-call connection), or give them a written proposal for the source code. If you choose the second option, you must have a copy of the source available for three years - and do not forget that this should be exactly the version used to build the binary.
This is just an individual problem, right? Well, not quite. Imagine this conversation taking place between two employees of different companies:
“I can't open the file you sent me.”
“Oh, sorry. I will send you the program that I used to create the file — it is free. ”
"Excellent thank you."
Sounds reasonable? Variations of the same conversation are widespread when the software in question is proprietary, and its copying is illegal, and for free software such a conversation is likely to be even more peculiar.
This helpful employee has now brought his company under legal responsibility. Notice that in this example no one changes the source text at all, they both only use and exchange. These two conditions, defined by the free software foundation as being vital, but still exercising these freedoms, they violated the license.
Of course, no reasonable developer would have sued for this kind of GPL violation. Unfortunately, there is no easy way to check whether the developers of a particular program are reasonable.
Links, Channels, Tricks
The GPL inflates the issue of binding. If you want to avoid having to comply with the GPL requirements, you need your code to work as a completely separate program. You can connect two programs through channels or sockets if you do this through a fairly universal interface, without sharing the results of your work. Or, as NVIDIA discovered, you can provide a GPL version of a GPL program that provides a universal interface, and then force end users to associate it with some proprietary code.
If you are creative enough, it’s quite easy to bypass the restrictions imposed by the GPL. With web services and web applications becoming more common, you don’t even have to strain too much. You can embed as many GPL codes as you want in your proprietary web application or service, and nobody can get the code because you don’t distribute the binary — you just allow people to use it.
The GPL Affero is trying to address this issue by requiring you to leave in place any existing “download source” links. Of course, this requirement made Affero GPL incompatible with GPLv2 (v3, has a special exception). Since this requirement limits the modifications you can make in the code, it violates four freedoms (although this does not prevent the FSF from recommending it).
If the GPL is easy to get around, why is this a problem? Anyone who needs to set additional restrictions on the code can do it - that is, anyone with enough money to spend on additional developer effort or legal advice, and therein lies the problem. The GPL is not able to achieve its original goals, and it also prevents people who do not want to hire a lawyer to read several pages of legal jargon and find out whether their intended use can really be allowed. It is easy to break by accident; but if you really want to break the spirit of the license, it is still possible to comply with the letter of the license. Realizing this situation, it becomes easy to understand why licensed-licensed alternatives to GPL programs have recently begun to see much more commercial developers.
Source: https://habr.com/ru/post/70097/
All Articles