gpl-violations.org

gpl-violations.org Source Code Release FAQ

gpl-violations.org Source Code Release FAQ

This FAQ contains some more detailed information on the requirements and best current practise of providing corresponding source code for GPL licensed executable code. It was compiled as a result of the numerous shortcomings and mistakes of more than sixty successful GPL enforcements.

Before releasing source code as required by the GPL, we therefore recommend reading through this FAQ in order to ensure completeness and mutual satisfaction with what you actually release.

What kind of source code do I have to publish under the GNU GPL?

The GNU GPL demands that as soon as you distribute GPL licensed software in executable format you make available the "complete corresponding source code". The GNU GPL also contains a definition of this term:

The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.

This is a quite precise definition. For a typical C program, this translates into all the source code (.c files) plus header files (.h files) plus the scripts used to control compilation and installation.

Always keep in mind that it is the purpose of the GPL to enable the users to exercise his freedoms. Specifically, the freedom to make modified versions of the program, and to run such modified versions of the program.

What are "scripts used to control compilation"?

Generally, any sophisticated program is split into many different source code files. During the process of compilation, each of them are compiled into executable code, after which they are linked. This process of compiling and linking individual source code files is generally controlled by scripts. Most often the "make" program is used, whose scripts are generally referred to as "Makefiles".

Also, some programs such as the Linux kernel tend to have compile-time configuration (in case of the Linux kernel the .config file). Since this compile-time configuration undoubtedly controls the process of compilation, you need to include any such compile-time configuration files, too.

What are "scripts used to control installation"?

After having translated software from its source code form into executable format, the program quite often needs to be installed into the system. The process of installation is often automatized by installation scripts. Exactly those scripts are referred to by the GPL.

Please note that this is of special practical importance in the case of embedded devices, since the executable program(s) need to be somehow installed onto the device. If the user is not given a way to install his own (modified) versions of the program, he has no way of exercising his freedom to run modified versions of the program.

Sometimes, the process of installation is not facilitated by scripts, but by some other means (such as executable programs). The GPL text only mentions the word "scripts". But when reading and interpreting the license, it is clearly understood that the license doesn't specifically only mean "scripts", but any kind of software programs that are required to install a (modified) version of the compiled program.

What about the compiler, the toolchain?

The GPL explicitly states:

However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

Clearly, this paragraph is written for userspace programs running on existing general purpose operating systems. So if you have only distributed such programs, then you do not need to include compiler, kernel, linker, and so on.

Particularly in the case of cross-compilation for embedded platforms, the cross compiler for your specific hardware is very likely not something that is "normally distributed with ... the operating system".

Therefore, in such cases, you have to provide the the exact version of your compiler toolchain that was used to create the executables that you have distributed. Please note that in most cases this will be GNU GCC, which is itself GPL licensed, so the GPL obligations will in turn apply to the toolchain, and you must release the complete corresponding source code to it as well.

What version of the source code do I have to release?

For each and every version of the executable program, you have to release the precisely corresponding version of the complete corresponding source code.

So if you have distributed ten different versions of firmware for an embedded product, and this firmware contains GPL licensed software, then you need to release ten different source code packages, each one corresponding for each executable version.

Please note that if you chose GPL Option 3b (rather than 3a), then the obligation only lasts for three years. This means that you do not have to provide source code for any executable code that was last distributed more than three years ago.

Please also keep in mind that both distribution on physical storage medium and distribution via data networks such as the Internet count as distribution.

How can I verify that my source code release is complete?

This is quite easy. If you only use source code provided in that release, and you can use this source code to produce a working form of the executable code, then the source code release seems complete.

If the build process fails, or you end up with a non-working executable, or you have no way to install the resulting executable, then clearly something is missing.


Copyright © 2004-2013 The gpl-violations.org webmaster . Harald Welte
Validate XHTML