Non-FOSS Requirements

Some projects can have non-FOSS requirements for them to be used. In some scenarios this is very much intentional; For example, video game modifications may be provided as FOSS but they rely upon the original (usually propriety) game to be used. Such scenarios are rarely problematic since the value being advertised & provided would be in the modification itself, and it would generally be clear to users that it’s built to be used with such an external propriety requirement.

There are other cases however which may be considered more problematic. Examples include:

• Source code needing to be built using non-FOSS libraries or tooling.
• Projects needing to use external non-FOSS platforms or services to function.
• Projects which rely on non-FOSS assets (images, sounds, fonts etc…).

This may not always be done to specifically be nefarious, sometimes FOSS might just not be a core value, or the licensing of required elements is not well understood, or the project has used an external non-FOSS service to speed-up development, but such non-FOSS requirements can impact what value is provided as FOSS, the control retained by the authors, and what value could be forked if needed.

Ultimately the impact will depend on the specific scenario, including how the project is marketed relative to FOSS and the intent behind the decisions. For example, if a project relies on a non-FOSS extra service for most of its value, and that service is provided by the same authors, then that may indicate that the FOSS project is practically being treated as a marketing tool for their non-FOSS services.