Skip to content, sitemap or skip to search.

Personal tools
Join now
You are here: Home Licensing GPL Software Certification Program

The certification program provides corporations with the assurances they require when building products upon a Free Software infrastructure. When you purchase certification, FSF undertakes a comprehensive engineering and legal review of your software release to ensure that your work has been done in compliance with GPL and related Free Software licenses. In addition, the FSF can delimit the ways in which your customers may use the software so as to comply with the GPL. Certification is a complex activity and consultation is required to provide an adequate cost estimate. We do offer substantial discounts if a product is 100 percent Free Software and includes no proprietary software components whatsoever.

Submission Requirements

This chapter details the materials that the Certificate Requester must submit to the FSF to begin the compliance certification process. Certification is done for a particular release of a particular Product. A Product includes some set of Free Software, and usually some set of proprietary software which are distributed together as a complete System. A System is a distribution of a collection of software that is distributed on some medium, or installed on some distributed electronic device.

To begin the Certification process, the Certificate Requester will deliver the following documents to the FSF, in electronic form (readable by Free Software) when possible, or in print form when not possible. Note that for 100% Free Software Products, the submission requirements are much simpler. A 100% Free Software Product is a Product which contains no proprietary software, includes Product's entire source code somewhere on the System, and all such source code is licensed under a Free Software license. (A full list of known Free Software licenses is available here) Submission requirements that are not applicable and/or not required for 100% Free Software Products are marked as such in this chapter.

  • 1. The full license texts of all licenses that will be issued with the System. This includes all Free Software licenses, as well as all proprietary software licenses. This information allows us to check for the following issues:
    • a. compliance with the Lesser GPL, (particularly but not exclusively Section 6 of the LGPL).
    • b. proper GPL-compatibility, when needed, of non-GPL Free Software licenses.
  • 2. Full functional specification for the product (Not required for 100% Free Software products). This functional specification should include the name and the purpose of each binary component (executable, DLL, and run-time loadable module) in the System.
  • 3. Details of Free Software components used. For each Free Software component in the System which is to remain Free Software (either by choice of the Certificate Requester, or by requirement under copyleft), the following should be submitted:
    • a. The name, version number, and distribution location of the root version.
    • b. A set of patches that were applied against that root version, suitable for input to the GNU patch program or similar application method. The copyright holder of the patches against the root version may be the Certificate Requester, or any entity that has licensed such patches to the Certificate Requester under a Free Software license.
    • c. A complete description of the build process, including options to any "configure" script, versions of complier and operating system used, and any other pertinent build information.
  • 4. A clear manifest of all object files in the System (Not required for 100% Free Software products.) This manifest should include the following:
    • a. the license that covers each object file.
    • b. the copyright holders of each object file (and/or a list of which files copyright holders are unknown for)
    • c. for each larger binary component (e.g., DLL or executable), a list of object files that combine at link time and/or compile time to make that larger binary component. This information should be in format that is both a human-readable and machine-readable format, such as XML, tab-delimited, field: value or anything else that can be easily converted to the listed formats. The FSF is currently developing a software tool to assist in preparing this manifest.
  • 5. Full object-file-level link, call, and interface map (not required for 100% Free Software products). This link and call map should include:
    • a. all dynamic links in the system that cannot be determined with the ldd command(e.g., links done with dlopen()).
    • b. for each object file, a list of functions defined in that object file, and a list of functions that are called from that object file.
    • c. a work-flow description between any GPL-compatible and GPL-incompatible bi-nary components that communicate in ways other than static or dynamic linking. (Examples of such communication are IPC, network protocols, named pipes, and shared data files.)
  • 6. A list of all patents effecting the System. Section 7 of the GPL (and section 11 of the LGPL) require that distributors of(L)GPL'd software who hold software patents which cover that software license them for everyone's Free use. We do not expect the Certificate Requester to perform a costly patent search, but we do expect to be informed of all patents the Certificate Requester holds on the technology, or those for which Certificate Requester holds patent licenses.
  • 7. A list of where copyright notices are displayed on the System (not required for 100% Free Software products). Since FSF won't be a user of the system, it will be difficult for us to determine where copyright notices are displayed. The Certificate Requester should include a list of all locations in the running program where copyright notices are displayed. In addition, the Lesser GPL requires that "works that use the library" give "prominent notice" that the library is used. Included in this list should be a description of how such "prominent notice" is given. 8. Full Disclosure of any prior violations of Free Software licenses.

The Certificate Requester must submit a full description of any prior violations of Free Software licenses. Under some Free Software licenses (specifically GPL and LGPL), rights under the license are terminated upon activity that violates the copyright license.

If violations have occurred, but the copyright holder of the relevant Free Software has reinstated the Certificate Requester's redistribution rights, a clear, written documentation should be submitted of the reinstatement of rights.

Outline of Compliance Process

Upon receipt of the relevant materials, the FSF performs an evaluation to determine compliance of the product. The primary goal of the FSF in this matter is to bring the product into full compliance with relevant Free Software licenses. The compliance process is an iterative process where the FSF raises any compliance concerns at the earliest possible time, and works with the Certificate Requester to bring the product into compliance.

Determining compliance with Free Software licenses requires issuing a legal opinion which is based heavily on technological analysis of the relevant software. As such, knowing ahead of time the licensing concerns of a particular software combination is an intractable problem.In this chapter, we list the general rules that govern our compliance check. Compliance with Free Software licenses is not a particularly difficult process, but does require care and some analysis to be completed properly.

For each binary component in the system, we consider the following points as we determine compliance. New points of consideration can certainly come up, particularly when software is combined in novel ways. As best we can, we will update this document to include new consideration points.

Each section deals with a class of compliance that we consider.

Compliance with pure GPL

By "pure GPL", we mean a typical GPL license, either "version 2", or "version 2 or later" without any additional exceptions granted by the copyright holder. For each binary component whose ultimate license is GPL-incompatible, we ask one key question: "Is this binary component a derivative work under copyright law of a pure-GPL'ed work?".

Common ways that clearly make such a binary component a derivative work include, but are not necessarily limited to the following: * the static link of the binary component included a GPL'ed component.* *the binary component links dynamically at runtime with a GPL'ed component, through a system such as dlopen(), insmod, or a generally equivalent system.*

Common ways that may make the binary component a derivative work of a pure-GPL'ed component include, but are not necessarily limited to: * communication of the binary component with a pure-GPL'ed component via a rich,non-standard IPC or network interface that gives all the same functionality normally given by static or dynamic linking.*

Distribution of a binary component that is explicitly designed to link with a specific GPL'ed component. (For example, distributing object code for a GCC front-end and telling the user: "To make this work, get GCC yourself" is considered a violation, but distributing a binary component that requires a standardized, commonly implemented POSIX API is not considered a violation.) For each program that is considered to fall under the terms of pure-GPL, we look for"yes" answers to the following questions:

  • Is complete source code provided?
  • Is there a copy of the GPL included?
  • Does the distribution state that the code is under the GPL?
  • Are the appropriate copyright notices in place (per Sections 1 and 2c of GPL)? (Note that Section 2c only applies if the original work had such notices originally, and Section 1 requirements are typically fulfilled by placing the notices in the corresponding source code shipped with a binary).
  • Are all modifications noted in an appropriate way? (Two common and acceptable ways that modifications are noted is via entries in a GNU-standard "ChangeLog" file, or listed in a set of release notes.)
  • Are all the libraries linked with the software GPL-compatible?
  • Are the complete build scripts included and released under the GPL? Do these scripts work to build the system correctly?
  • If rights under GPL have been terminated under Section 4 due to a previous violation,have those rights been properly reinstated?

Compliance with GPL plus exceptions

From time to time, a copyright holder releases software under the GPL plus some set of exceptions. These exceptions are stated as part of the full copyright license of the software.

If such exceptions exist, they may affect compliance issues.

For such an exception to apply to a given binary component, the exception must be given by a copyright holder of the pertinent original work(s). That copyright holder must state clearly the precise exception in the copyright license of the original work(s). In practice,this usually means that each GPL'ed copyrighted file that combines into a derived work must state the exception along side its copyright notice in the source file.

If it is determined that such an exception is in place, and thus the work as a whole is licensed not under "pure GPL" but "GPL plus some exception", the analysis process for finding compliance with pure GPL will be sufficiently modified to account for the exception.

Specific real world examples of such exceptions, and how the process will be modified tidal with them, will be detailed here as they are encountered. While we currently know of some single source files (e.g., in the GCC distribution) and even some full programs (e.g.,Guile) that grant such exceptions, we actually know of no real-world examples yet that take advantage of such exceptions. 2.3 Compliance with Lesser GPL Some libraries (e.g., the GNU C Library) are released under Lesser GPL (LGPL) rather than pure GPL. GPL-incompatible binary components that do not link against GPL'ed modules, but do link against LGPL'ed modules are held to the compliance criteria in this section.

For those parts of the binary component that are (under LGPL) "works based on the library", we apply the pure-GPL compliance criteria to them (see Compliance with pure GPL).

For those parts of the binary component that are (under LGPL) "works that use the library", we look for "yes" answers to the following questions:

  • Are binary-only components distributed in such a way that it can be relinked to new versions of the library?
  • Is a copy of the LGPL included?*
  • Are copyright notices and a license reference displayed correctly (where applicable)? (Note that per Section 6 of the LGPL, this is only a concern if the combined work as a whole happens to display copyright notices.)
  • Is correct "prominent notice" of the library's use given? (Some common and acceptable ways that "prominent notice" is done is by clearly giving a notice in the user manual that accompanies the software, by stating a notice in an "About" box in a GUI program, or by printing a notice on the screen at System startup. In general, much flexibility is available for giving this "prominent notice".)
  • For each binary component linked to the library, does its license allow relinking and reverse-engineering?
  • Does the distribution state prominently that the library is under the LGPL? (Some common and acceptable ways to give such information is by stating it in the user manual that accompanies the software, by stating it in an "About" box in a GUI program, or by printing it on the screen at startup. Much flexibility is available for ways of handling this matter.)
  • If rights under LGPL have been terminated under Section 8 due to a previous violation,have those rights been properly reinstated?

Legal Assurances Made Upon Certification

Legal assurances given by the Free Software Foundation to the Certificate Requester are typically negotiated on a case-by-case basis between the legal counsel of the two organizations.

FSF Obligations Under its Articles of Organization

The FSF, as a 501(c)(3) non-profit organization incorporated in the Commonwealth of Massachusetts cannot undermine its expressed mission as it carries out the work of this certification program.

We cannot sign a non-disclosure agreement nor agree to a non-Free Software license for any generally useful technical information. This includes all of the material required for submission to the certification process itself. Any generally useful technical information included in the submission materials must be freely redistributable.

We also must reserve the right not to issue an official certification on any product that includes technology that explicitly works against the mission of the Foundation itself. Specifically, Section 2 of the FSF's Articles of Organization, states the following:

The corporation is formed for literary, educational, and charitable purposes with the special purposes of:

  • a. encouraging, fostering, and promoting the free exchange of computer soft-ware and information related to computers and other technology;
  • b. distributing and disseminating software and information related to computers and other technology; and c. increasing the public's access to computers and other high technology devices.

For example, the FSF will not certify Products containing implementations of "digital copy control" (or "Digital Rights Management"), since such controls work directly against "promoting the free exchange of ... information related to computers and other technology".

The FSF is a charity with a worldwide mission to advance software freedom — learn about our history and work. is powered by:


Send your feedback on our translations and new translations of pages to