Individual developers and contributors
The rule
Free and open-source software not supplied in the course of a commercial activity is outside the scope of the Regulation. No obligation falls on the developer, natural or legal person, who makes their work available on that basis.
The whole difficulty lies at the boundary of “commercial”.
What is not enough to make an activity commercial
The recitals expressly rule out several situations:
- contributing to a free software project, even regularly and substantially;
- hosting code on a forge or public repository, including with paid services for the maintainer;
- accepting donations intended to cover development or infrastructure costs;
- charging for ancillary services — technical support, consulting, training — distinct from the supply of the software itself;
- collaborating with companies that use the software, including by integrating their contributions.
What tips it over
The activity becomes commercial when the software itself is supplied within a business relationship. Converging indicators:
- the software is charged for, in any form — licence, subscription, access;
- development is carried out for remuneration within an identified commercial relationship;
- the free software serves as a lead product for a linked paid offering, such as an enterprise edition or reserved features;
- the entity integrates the software into a product it places on the market — but then it is a manufacturer, which is a different status.
Your own contributions
Three situations must be settled by a written internal policy.
1. An employee contributes to an upstream project, on work time, to fix a defect that affects you. This is the most common and healthiest case. It makes you neither a manufacturer of the upstream project nor a steward: you remain a user who contributes. The Regulation in fact expressly encourages sharing security fixes upstream — see Integrating open source.
2. You publish a free software project arising from your work, with no associated commercial offering. Out of scope as long as the supply remains non-commercial. To be re-examined if a paid offering is later attached to it.
3. You durably fund the development of a free software project you do not manufacture, and you ensure its viability. That is the definition of an open-source software steward: see the dedicated page.
What to write down
A short internal open source contribution policy answering:
- In what cases may an employee contribute to an upstream project on work time?
- Under whose identity — personal or corporate?
- Who authorises the publication of a new free software project by the company?
- Who verifies, before publication, that the project does not tip into an unintended commercial qualification?
- How are your upstream security fix submissions documented, given that the Regulation expects them and they constitute evidence of due diligence?
The policy belongs to Legal but is applied by engineering: it must fit on one page.