Are recipes considered GPL?

When distributing recipes, are they GPL?

Yes. All contributed files that are derivative works of Drupal hosted on Drupal.org, are licensed under the GNU version 2 or later. This includes files that makes use of an API that is in the Drupal core.

See also the Licensing FAQ #1: https://www.drupal.org/about/licensing#drupal-license →

Is it possible to sell recipes?

Yes. However, you must distribute it under the GPL version 2 or later, so those you sell it to must be allowed to modify and redistribute it as well.

This is not as simple as modules, themes or even install profiles/distributions.

Is it possible to sell recipes?

Regardless of whether they are required to be distributed as GPL, you can sell Recipes the same way you could sell a install profile/distribution.

Before we dig into the details, I will say that IANAL and the LWG does NOT dictate DA/Drupal.org policy. This group exists to advise the DA and help explain and implement policies... and we're always looking for more members!

Back when Drupal started figuring out how to manage the licensing requirements of the project, we were often the first and largest project to define these policies. If you look at https://wordpress.org/about/license/, it STILL references Drupal's interpretation of modules/plugins as derivative work.

Today, the FOSS landscape is much bigger than PHP CMS projects.

When discussing Resipes, we have well-established projects we can look at. Ansible is a GPL-3.0 licensed project with a feature that is similar to Recipes they call Playbooks (https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_intro.html). Playbooks are YML files are distributed with a variety of licesense

MIT
https://github.com/Azure-Samples/ansible-playbooks/blob/master/LICENSE.md
https://github.com/ansible/ansible-examples/blob/master/tomcat-memcached...

CC-BY-3.0
https://github.com/ansible/ansible-examples/blob/master/wordpress-nginx/...

Apache-2.0
https://github.com/opensearch-project/ansible-playbook/blob/main/LICENSE...
https://github.com/confluentinc/cp-ansible/blob/7.6.1-post/LICENSE.md

This was discussed when the Distribution Modernization Initiative was just getting started, but the stars didn't align as well as we'd hoped with...

1. the shift to using more GitLab features
2. shift away from only adding the GPL-2.0 license text in projects when packaging the .zip
3. use of General Projects for Drupal adjacent code that is not a module/theme/derivative work

When we updated what is essentially the Drupal project's CLA at https://www.drupal.org/docs/develop/git/setting-up-git-for-drupal/drupal... → , back in 2020? to finally clarify what was considered derivative work and acknowledge that a "GPL only" approach wasn't compatible with the variety of FOSS licenses now being used "off the island", the changes to...

All code that is a derivative work of Drupal (typically PHP code, including but not limited to: core patches, modules, themes, etc) committed to Drupal.org's git repository is licensed as GPL version 2.0 and later (official short identifier: “GPL-2.0-or-later”).

...and...

In general, all code downloaded from Drupal.org is distributed as GPL-2.0-or-later and includes this license. In some cases, code that is not a derivative work of Drupal may be distributed "in-aggregate" with Drupal code. Any permissively licensed 3rd party code that allows relicensing is automatically relicensed and distributed as GPL-2.0-or-later.

... were intended to address that and add more clarity to was legal under the GPL and what was allowed by DA/Drupal.org policy.

A Recipe is essentially install instructions in YML. Whether this is considered a derivative work isn't clearly stated anywhere. When discussing javascript dependencies back in the D6, D7 era, the decision to require javascript to be licensed as GPL-2.0 or a permissive license like MIT wasn't based on all javascript being a derivative... but simplicity and resource limitations. Hopefully everyone agrees that a module project could include javascript that is in no way derivative of Drupal. Trying to figure out which .js files were derivative and which weren't FAR exceeded the resources of the LWG volunteers.

With General Projects, the topic of the GPL requirements came up again. The case was made that the javascript ecosystem simply wouldn't accept a GPL-2.0 requirement. Because these projects weren't necessarily packaged and distributed through Composer, many included their own license text in GitLab and then referenced that license in the related packaging manifest. If you review the ~150 General Projects now in https://www.drupal.org/project/project_general → , you'll find a variety of licenses. You'll also find projects with no license that don't contain any PHP or javascript that could be considered a derivative work. While the project node links to GPL-2.0, it is possible (even likely) that someone would download or clone one of those projects without ever seeing the project page on Drupal.org.

ISC
https://git.drupalcode.org/project/react_menu_component/-/blob/1.0.x/pac...

GPL-3.0
https://git.drupalcode.org/project/drupal_extend_phpstorm_plugin/-/blob/...
https://git.drupalcode.org/project/drupal_svelte_component_menu/-/blob/1...
https://git.drupalcode.org/project/open_project/-/blob/9.2.x/LICENSE?ref...

NO LICENSE
https://git.drupalcode.org/project/core_logs
https://git.drupalcode.org/project/growmark
https://git.drupalcode.org/project/gitlab_templates
https://git.drupalcode.org/project/next_webform
https://git.drupalcode.org/project/phpstorm_code_style
https://git.drupalcode.org/project/openculturas_project
https://git.drupalcode.org/project/cacheable_types
https://git.drupalcode.org/project/ui_suite_bootstrap_demo
https://git.drupalcode.org/project/formgeneratetrait
https://git.drupalcode.org/project/drush_sqlsrv
https://git.drupalcode.org/project/wisski_docker_image
https://git.drupalcode.org/project/drupal_contrib_docksal

General Projects are still a bit of a secret, insider-only option on Drupal.org. They aren't linked under the Download menu, but the DA is going to need clarify the licensing requirements for these projects and whether the view that we've based our policies on about all modules and themes being derivative works also applies to Recipes.

There is a lot to clarify here, but this isn't as easy to define as a PHP module.