Asking for exception so that Source Sans Pro font can be added to core

I have no idea who would hand out such an exception...

Personally I think it's ok from a legal POV. But that's just me, and I am not even a lawyer.

If we allow this for core, do we need to allow this for contrib too? Won't we end up with hundreds of themes including the same font(s)?

If it's allowed via the packaging whitelist process then maybe that would be the right way to get approval?

It's not quite the same since
1. the font would be committed directly to core instead of packaged
2. it's a font, not code

Note that to date we've made exceptions only for code that is GPL compatible. jQuery, Symfony, etc. are all under permissive licenses that are GPL inbound compatible. (Vis, you can bundle them straight into GPL code.)

This font is not GPL compatible, so would be the first time we've ever done that AFAIK. In the past we've generally said no, because we want everything coming out of our repos to be GPL-friendly.

Currently, any code you download from Drupal.org is legal to copy-paste into some other GPL file. There may be documentation requirements (maintaining copyright headers and the like), but that's true of Drupal code, Symfony code, jQuery code, Zend code if we merge that, etc. That's to protect our users downstream from legal complications. This font would be the first exception to that, and for that reason I'm very reluctant to grant it an exception. That opens up a slithery can of worms.

Source Sans Pro is a a free, libre and open source made available under the SIL Open Font License (OFL). You may want to read the section about "FLOSS-friendliness".

Since it is a font, and not code, it makes no sense to "copy-paste [it] into some other GPL file". It is not designed for this purpose. It is designed to be included is a project archive along with other digital assets.

In legal terms, such an collection of stand-alone assets is known as "a compilation". A compilation is not a derivative (for the precise. legal definition of these terms, please refer to Compilations and Derivative Works).

When a computer program is transformed or altered (for instance a bug is fixed or it is extended with more features), the result is a derivative. We want users to be able to fix bugs and extend features when they use free software. The GPL was created to license derivatives (which would otherwise be the exclusive right of the first author). I fully support the GPL and Drupal.org's decision to only allow code under a GPL compatible license in its repositories. Only having GPL-compatible code in the repo is essential to preserve the four freedoms embodied in the GPL.

However: Digital assets (such as fonts) are not code. When they are bundled with something (a video game, a computer program, an ebook) the users don't expect to be able to transform, alter or otherwise build upon the font. The users is just happy that the asset came bundled, so they didn't have to hunt for it on the web and install as an appendage.

To make sure there is not misunderstanding, the creators of the SIL OFL have a FAQ that makes it clear that it perfectly legal to bundle a SIL OFL licensed font with any Free/Libre and Open Source Software collection (compilation). I quote:

Question: 1.2 Can the fonts be included with Free/Libre and Open Source Software collections such as GNU/Linux and BSD distributions and repositories?

Answer: Yes! Fonts licensed under the OFL can be freely included alongside other software under FLOSS (Free/Libre and Open Source Software) licenses. Since fonts are typically aggregated with, not merged into, existing software, there is little need to be concerned about incompatibility with existing software licenses. You may also repackage the fonts and the accompanying components in a .rpm or .deb package (or other similar packaging formats or installers) and include them in distribution CD/DVDs and online repositories. (Source: SIL OFL FAQ.)

Crell writes:

That's to protect our users downstream from legal complications. This font would be the first exception to that, and for that reason I'm very reluctant to grant it an exception. That opens up a slithery can of worms.

As long as one is talking about code, this is absolutely right. So Drupal.org should never allow non-GPL code in its repos.

However, a finished font is not code, and the package containing both the code and a font is a not a derivative (but a compilation).

This means:

1. Bundling the Source Sans Pro with Drupal 8 is perfectly legal.
2. This will not create any legal (or other) complications for the users of Drupal 8.

For instance, if the users of Drupal 8 extract the font from the package, and re-use it for their own projects (FLOSS or proprietary), that's fine! I cannot imagine a single use case where a font licensed under SIL OFL in a compilation that also contains GPL code that will create "legal complications" for the recipient of the compilation.

There is not much point in protecting our users against a non-existing problem, is there?

I say: Go for it!

I say: Go for it!

Please don't.

1. Bundling the Source Sans Pro with Drupal 8 is perfectly legal.

Hopefully we are beyond having to explain that this is Drupal git policy issue and not a legal issue. As it stands the policy is that "all FILES checked into the repository (code and ASSETS) must be licensed under GNU/GPL version 2 and later." You can legally commit a copy of Drupal to GitHub and say your version is now licensed as GPLv3 and bundle it with code that uses licenses that are only compatible with version 3 of the GPL like AGPLv3 and Apache 2... as well as including artwork that is licensed with a Creative Commons ShareAlike license and OFL licensed fonts.

This type of mixed license packaging is legal and done by thousands of project... but that's not the issue.

2. This will not create any legal (or other) complications for the users of Drupal 8.

That's not really true. The current policy allows people to make the statement that EVERYTHING downloaded from Drupal.org is licensed as GPLv2 and later or a GPLv2 and later compatible license. Allowing OFL, Creative Commons, GPLv3, etc would make that statement untrue... but so does failing to address the projects violating the policy.

Despite the policy, it isn't safe to assume that what you download from Drupal.org today is GPLv2 and later. There have been a number of open issues about project maintainers who are knowing violating the git policy by committing files (both assets and code) that haven't been addressed in years, but rather than ignoring the policy it would be more productive to fix the policy or enforce the policy. Ignoring the policy just creates more problems.

There is a lot more information about OFL as it relates to GPL in #2139273: Allow GPL Friendly Font Licenses. I'd really like to see this resolved at the whitelist level first before getting into whether assets with "GPL friendly" licenses can also be committed to Drupal's git repo.

kreynen wrote:

Hopefully we are beyond having to explain that this is Drupal git policy issue and not a legal issue.

I know full well it is a Drupal git policy issue, and not a legal one. But from crells comments about "legal complications" and from looking at dozens if past threads here about licensing. I wasn't sure that this has been established. If this is moot, great!

Despite the policy, it isn't safe to assume that what you download from Drupal.org today is GPLv2 and later. There have been a number of open issues about project maintainers who are knowing violating the git policy by committing files (both assets and code) that haven't been addressed in years, but rather than ignoring the policy it would be more productive to fix the policy or enforce the policy. Ignoring the policy just creates more problems.

I agree that the policy need to be amended, but I think that is not something that will happen overnight.

In the meantime, there is a policy in place that exceptions can be made, and I think that the case for adding an exception for the Source Sans Pro font is good.

However, I've also created an issue were I request that the policy is fixed: #2298275: Proposal to amend Drupal Git Repository Usage policy to allow content licensed under Creative Commons . Please participate in that discussion as well.

Despite the policy, it isn't safe to assume that what you download from Drupal.org today is GPLv2 and later.

That is true as well. I recently tried to block this project from being hosted on drupal.org on grounds that it contains an asset (icons) with a license (CC BY-SA) that is not GPL-compatible. My block was overruled, and the project is now hosted on Drupal.org despite its rather obvious violation of the Drupal git policy (and the icon author's copyright).

Another example that apparently violates the Drupal git policy is the project Creative Commons. The directory http://cgit.drupalcode.org/creativecommons/tree/images and its sub-directory "buttons" contain a lot of images that comes from http://creativecommons.org/about/downloads. The license for these images can be found here: http://creativecommons.org/policies - and the license terms is not even similar to GPL. Since you (kreynen) is the owner of this project, I would be interested in hearing your views about about the assets bundled with this project and their relation to the Drupal git policy.

I think the fundamental problem of the Drupal git policy is that it currently echos the politics of FSF. The FSF refuses to acknowledge as forward compatible with GPL a number of licenses that are legally forward compatible with GPL, for reasons that are not (IMHO) valid.

The WordPress and Fedra projects have realised this, and instead of treating the FSF-list as authoritative, they've created their own list of font licenses that are forward-compatible with GPL: http://make.wordpress.org/themes/guidelines/guidelines-resources/ and http://fedoraproject.org/wiki/Legal_considerations_for_fonts#Approved_fo...

I believe it is a mistake to listen to the FSF is matters concerning license compatibility. The FSF, and in particular its president, has a political agenda regarding IPR that is, IMHO, not always aligned with the interests of the FLOSS and Free Culture movement.

@gisle, it looks like we agree on the need to update Drupal's licensing policies... and possibly even about fixing it vs. violating it. @klausi was wrong to promote a sandbox project with a known violation of the policy. @killes was also wrong when he said...

If somebody files complaints we'll deal with them on a case by case basis.

That is simply not true. No one deals with these which is why I opened #2175005: [META] Changes are required before it will be safe to assume code from Drupal.org's git repo is really GPLv2+ or GPLv2 compatible. I'm not sure who the "we" @killes is referring to, but from what I've experienced nothing happens when issues are opened about violations if the maintainer isn't willing to address the issue within the project. Creative commons licensed images, fonts, Apache2 licensed code, etc now litter Drupal's git repo making the statement that "any code you download from Drupal.org is legal to copy-paste into some other GPL file" untrue as well.

As for the Creative Commons module, I took that project over while co-mentoring a Google Summer of Code project that was managed by the Creative Commons. Not that it is a good excuse, but the icons were already part of the project when I got involved. I didn't understand as much about GPLv2+ compatibility at the time. It never occurred to me at the time that images with no license would be preferred for Drupal projects over images with a CC license with a GPL-like clause that forced anyone making improvements or derivates to share those. I didn't realize that there was an issue until the CC 3.0 license discussions when someone brought up the topic of GPLv3 compatibility, but by that time the Creative Commons had licensed added the CC0 license. So while the original commit was probably a violation, it is my understanding that the Creative Commons icons are now licensed as CC0.

While I've made mistakes in both what I've committed as well as what I've requested be whitelisted, I've also tried to understand Drupal's policies as well as the motivation for those policies. I've tried to make it clearer what is and isn't acceptable based on the current GPLv2+ policies including updating the licensing portion of the Drupal.org Whitelist Documentation. I think there is hope to find some common ground by updating the license policies around packaging while retaining the git policy and improving the way licensing issues are handled. @crell could say with much more confidence that "anything you download from Drupal.org's git repo is legal to copy-paste into some other GPL file". That's why I've been pushing #1449452: Give installation profiles/distributions GPLv3+ license as option for packaged downloads

The way Creative Commons licensing is handled on Drupal.org is also a mess. Despite the FSF's recommending please don't use [Attribution-ShareAlike 2.0] for software or documentation, since it is incompatible with the GNU GPL, all documentation posted to Drupal.org is licensed at CC BY-SA 2.0... including code snippets. It makes my head hurt to think that copy and pasting information from a documentation node on Drupal.org into a README or creating a variation of a code snippet as a module would be a violation of Drupal's Git Policy.

Wikimedia moved to a CC-BY-SA/GFDL dual license system on all of their project’s content in 2009 after users who had made 25 edits prior to March 15, 2009 on any Wikimedia project voted to approve the change, but changing the licensing on Drupal.org's documentation is really OT and deserves its own issue.

I can't see the downside of #2139273: Allow GPL Friendly Font Licenses to be whitelisted. It puts Drupal more inline with the licensing policies of the other PHP based, GPLv2+ licensed CMS projects and it looks like it would solve this issue as well as several issues with copies of Font Awesome already git.

So while the original commit was probably a violation, it is my understanding that the Creative Commons icons are now licensed as CC0.

They're not. They're licensed under something called the Creative Commons Trademark Policy which is designed to protect the trademarks from abuse and dilution. However, your project neither abuses nor dilutes the trademarks.

I am a CC affiliate with a direct line of communication to their legal staff, so I have taken the matter up with Creative Commons. Here is their reply:

Gisle.
You are right that our existing trademark policy is a little unclear on this point, and we are currently finishing up an overhaul of that policy that has been quite a few months in the making. Among other clarifications, the revised policy will make it clear that use of our trademarks by platforms and projects that enable their users to CC-license works is permitted.

We will be vetting the revised policy with affiliates once a few last details are ironed out. Look for an email on this list with the revisions.

Thanks for raising the issue.
best,
Sarah

Sarah Hinchliff Pearson
Senior Counsel, Creative Commons

So it looks like the Creatice Commons has no objections to the images being included in your project's distribution.

Btw: We are in complete agreement about the need to fix Drupal's git policy instead of continuing to ignore violations of it.

Obsolete.

Obsolete.

@kreynen

it would solve this issue as well as several issues with copies of Font Awesome already git.

Where are the font awesome icons in GIT and are they used in core?

If so they should be replaced with icons from the Libricons set created for D8 by ry5n, If there are no libricon replacements for the icons we are getting from font awesome then I can create new ones and add them to libricons.

Postponed, pending decision about future policy regarding third party non-code assets.

The Drupal.org Git Repository Usage Policy was changed in December 2017.

As a result of this change, the LWG is now able to grant an exception that allows the Source Sans Pro font that is available under the SIL OFL as a mere aggregate to the Drupal core.

Reminder The Git Repo policy now says this about including third party assets (such as fonts):

Any third party assets you include must have their provenance, license and source documented in a file included in the project.

By setting status to "Fixed", the issue will automatically close in two weeks. If anyone think this step is premature please set status back to "Needs work" - and tell us exactly what is required before the LWG is able to grant an exception.