3. Forks and variants¶
As already cited before, a fork may have two different forms based on the final aim. As such, in order to make it clear how to handle the publiccode.yml in both cases, below we define two different semantics: technical forks and software variants.
3.1. Technical forks (i.e. to publish patches)¶
A technical fork is a fork made by a developer for the purpose of working on the original code base or sending improvements to the original authors, without any explicit goal of creating and publishing an alternative variant of the original software.
In the context of distributed control systems and collaborative code hosting platforms like GitHub, forking is almost always used by developers as a step to work on a contribution on an existing codebase, by sending “pull requests”.
Because of the way forking works on GitHub and other platforms,
developers publish their forks as perfect copies of the original
software, thus including also
publiccode.yml. However, parsers need
to be able to distinguish such technical forks from the original
Parsers SHOULD identify a technical fork by noticing that the
url key does not point to the repository in which the
publiccode.yml is found.
Parsers MIGHT identify a technical fork also through metadata that might be exposed by the code hosting platform (eg: GitHub marks forks explicitly as forks)
3.2. Software variants¶
A software variant is a fork that is offered as an alternative to the original upstream software.
It contains modifications that are still not part of the upstream version, like more features, different dependencies, optimizations, etc.
By marking a fork as a variant, the author indicates that they believe that the variant includes a complete and working set of modifications that might be useful to other people.
Marking a fork as a variant does not relate to the willingness of contributing upstream; the author might still plan to contribute the modifications upstream, or even being in the process of doing so. Thus, even if the fork will eventually be merged upstream, it might make sense to mark it as a variant during the process, so that others might discover it and benefit from it.
Parsers SHOULD identify a variant by noticing that the top-level
url key matches to the repository in which the
found, AND a top-level
isBasedOn exists and points to a
Parsers should expect and analyze other differences in
publiccode.yml between variants of the software. Specifically
description/features is designed to be compared across variants to
identify and show user-visible differences.