Is a CQ required?

The Contribution Questionnaire (CQ) is the entry point into the Eclipse intellectual property (IP) due diligence process (the full process is defined in the Due Diligence Process poster).

The term CQ has expanded from it’s original meaning. Originally, CQs were literally a questionnaire filled out by a project committer to provide important information for the Eclipse IP Team to use during their scan of a piece of IP (generally software, configuration, or documentation). The term is used today to refer to the persistent record in our IP database (IPZilla) that documents communication that occurred during the due diligence process, maintains various bits of state information, and ultimately represents the approval or rejection of the artefact it represents. A CQ tracks the association between an Eclipse project and a piece of IP.

CQs track contributions. This takes the form of an Initial Contribution for new projects, or simply a “contribution” of new features or functionality for an established project. Whether or not a CQ is required for a contribution is covered quite well by the Due Diligence Process poster.

CQs are also used to track third-party libraries used by a project. An Eclipse project needs a CQ if project code makes direct use of a library. An import statement in Java source, or a bundle reference or package reference in a manifest file are examples of a direct reference. Using metadata tricks to avoid import statements (e.g. using Class.forName() or an equivalent), abstract references to services, or clever uses of extensions still generally constitutes a direct reference that requires a CQ (in some cases, the reference may be considered a “Works with” dependency). Similarly, if project code makes direct reference or is directly influenced by a property or configuration file, then a CQ is required.

Indirect references through another project’s code do not require a CQ. If an Eclipse project leverages (or distributes) CDO, for example, that hypothetical Eclipse project does not need to create CQs for the third party libraries that CDO makes use of, unless those libraries are accessed directly.

If a project needs to directly use a third-party library for which a CQ already exists, that project can create a “piggyback” CQ. Piggyback CQs let projects “hitch a ride” on the due diligence work that has already been done on behalf of another project. They are relatively easy to make and get processed very quickly as the hard work has (typically) already been done.

A CQ is (almost) never required to leverage/distribute code created by another Eclipse project. It’s only when you’re forking the code and making changes that a CQ is necessary.

When in doubt, ask your PMC or (for incubating projects) your project mentors.