This is related to #2137985: Include font-awesome into whitelist?. I know there are dozens of ways to add fonts remotely. CSS and JS can also be added remotely. Let's just assume that a developer doesn't want to build a dependency on a remote requirement and jump right to the question of allowing fonts to be included in a distribution with licenses that are not GPLv2 compatible.
Neither OFL or GPLv2+FE are strictly GPL compatible. OFL 1.1 covers the packaging of fonts with GPL code the way it would happen for distributions. I believe GPLv2+FE is designed to limit the reach of the GPL so documents created with fonts in a GPL word processor don't require a GPL license for every document using the font. There are a lot of links are references about font licensing in https://github.com/FortAwesome/Font-Awesome/issues/1124
It's also worth looking at what WordPress allows http://make.wordpress.org/themes/guidelines/guidelines-resources/
#1449452: Give installation profiles/distributions GPLv3+ license as option for packaged downloads will not solve the font license issue.
Comments
Comment #1
btopro commentedMeta comment
The more complex these issues get I feel the more likely people will setup a distro page, simply place a .make file there for people to checkout, then package everything and throw it on github and add a link. I understand the issues involved in terms of why things are / are not compatible but I think common sense is quickly being lost in all these licensing issues when the intent is free.
Comment #2
hswong3i commentedThanks for WordPress which may give us some hints for solving font licensing issue (http://make.wordpress.org/themes/guidelines/guidelines-resources/):
Which highlight GNU Foundation link as reference (http://www.gnu.org/licenses/license-list.html#Fonts):
And also highlight Fedora Project link as reference (http://fedoraproject.org/wiki/Legal_considerations_for_fonts#Approved_fo...):
Long story short, I would like to recommend approve following font licenses to be included into drupal.org as reference as that of WordPress:
Any idea?
Comment #3
kreynen commentedOFL IS the preferred font license, but it is NOT GPL compatible. We've already confirmed with the FSF in https://github.com/FortAwesome/Font-Awesome/issues/1124. You're unlikely to get a clearer, more authoritative "No" than that to the GPL compatibility question.
WordPress is wrong if they are using this definition of "compatible" http://www.gnu.org/licenses/gpl-faq.html#WhatIsCompatible.
OFL is specifically listed in http://www.gnu.org/licenses/license-list.html#Fonts, not http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses
WordPress allows things Drupal doesn't and that's their right. Github also allows mixing licenses that Drupal doesn't allow.
OFL and GPL+FE are the most popular and most commonly recommended "GPL friendly" font licenses meaning which is why I requested an exception for only those licenses.
Unless the OFL is specifically allowed, it won't be whitelisted.
I wouldn't encourage this, but other projects have just committed the non-GPL code they want to use. Even when that's reported to the Webmaster queue, there is no responce to the issues tagged as Licensing https://drupal.org/project/issues/webmasters?component=Licensing
There are at least 2 cases when Font Awesome was just committed including:
#2153271: Font Awesome is not GPL compatible and must be removed from git and #2153121: Font Awesome is not GPL compatible and must be removed from git
Comment #4
kreynen commentedComment #5
kreynen commentedComment #6
kreynen commentedComment #7
kreynen commentedComment #8
kreynen commentedComment #9
kreynen commentedQuoting Dries from https://www.drupal.org/node/1986082#comment-7827309
Comment #10
gisleMy opinion is that a change policy should allow not only "GPL Friendly Font Licenses", but allow all assets (i.e. data that is used in "mere aggregation" and do not interact with the code) to be in the Drupal Git repository.
In other words, I don't think adding SIL OFL, etc. to the whitelist is a workable solution. Whitelisting should be for code only, and only for code under permissive licenses that can be legally re-licensed to a permitted license.
What we need for assets (data) is a policy change that simply allows assets to be included in the Drupal git repository, but only if strict documentation requirements are met (exact requirements need to be worked out, but I imagine that a file named ASSETS.md/.txt listing origin, credit, rights, and terms of use would suffice).
There already a good, workable definition of what separates assets (data) from code in the Licensing FAQ:
However, the FAQ also explains that you are currently only allowed to include non-GPL assets (data) "when distributing your own Drupal-based work". This policy does not apply to the Drupal Git repository.
I think this restriction should be lifted, and as a matter of policy, assets (i.e. "data" as defined in the FAQ #7), should be allowed in the Drupal Git repository.
I understand that the "everything in the repo must be licensed under GPLv2+" has a certain attraction (e.g. that downside recipients do not have to read the documentation to figure out the terms of use for assets). But this policy also has downsides (see, for example, #605710: Decide on if and if so, how to implement the Drupal wordmark in core, #1986082: Add a webfont version of Source Sans Pro font, #2345675: Distributing protected logo images with Drupal projects, #2314301: Logos in Creative Commons project is not under a GPL friendly license). In balance, I think that these downsides has much more severe consquences than making life a little bit more complicated for downside recipients.
Comment #11
kreynen commented@gisle I think we have always been on the same page about the change to Drupal.org policy regrading non-code assets, but I believe there are legitimate reasons why someone would want to use a whitelist entry vs. committing the asset to a single project. Hopefully after reviewing this, you'll agree.
Font Awesome is a great example of something I think would benefit from both an exception to commit a 3rd party asset to a project hosted on Drupal.org as well a whitelist entry. A whitelist entry for that asset has been requested by several projects as well as found already committed to several more. In my ideal world, an exception would be granted for https://www.drupal.org/project/fontawesome to commit the asset directly to the project. Ideally the project would still allow the now included asset to be overriden with a newer/older/customized version in sites/all/libraries. Most other projects could then simply declare the fontawesome module as a dependency, but they would still have the option of including a different version of Font Awesome to the libraries directory using .make.
This makes it easier to install a module that functions immediately without depending on a CDN for the asset, while still allowing customizations without having to hack/patch the module.
While this is a less likely use case for CC-SA licensed images or text, it is generally more efficient and less likely to cause conflicts if assets like fonts can be loaded from sites/all/libraries.
In general, I think the LWG should maintain a list of licenses we've confirmed are either GPLv2 compatible or GPLv2 friendly (non-code assets that can be freely distributed with GPLv2 code where the license allows the asset to be modified and redistributed with freedoms similar to GPLv2 code). Any project (containing code and/or assets) that meets all of the other whitelist criteria can be whitelisted and used by any packaged into a project on Drupal.org using a .make. Currently we only package .makes for distributions, but that isn't a technical requirement. I know @greggles has floated the idea of processing the .makes included in module and theme projects before, but I haven't been able to find an issue specifically about that. This use of .make files is basically a work around for the lack of git submodule support in packaging. Instead of pinning a git submodule to a SHA1 of a commit in another repo, we use .make files to bundle projects into a single download.
Projects that want to directly include/commit any 3rd party code or asset in Drupal.org's git repository would still need to request an exception (with a process that is yet to be determined). Personally, I would like to see these additional licenses shown on the project page and added to the packaged version of the project similar to how the packaging script adds the GPLv2 license, but that will require changes at the infrastructure level.
Hopefully you can see why we should allow both exceptions for 3rd party assets to be committed directly as well as whitelisted.
Comment #12
gisleThe current whitelist only lists licenses than are lax enough to allow the materials to be technically and legally re-licensed under GPL.
My main objection to whitelisting GPL Friendly Font Licenses is that I fear that it will increase the confusion about licenses if we also whitelisted GPL-incompatible licenses (such as SIL OFL). Yes, it is "GPL Friendly", but unfortunately it is not a license that allows the materials it licenses to be legally re-licensed under GPL.
And what we technically do now (with the permissive licenses that are whitelisted) is to re-license the materials under GPLv2+ when they are placed in the Drupal Git Repo and add LICENSE.txt to the packaging.
Unfortunately, re-licensing is not an option with SIL OFL, as correctly pointed out by the FSF:
But that "harmless" clause is a the blocker that stops us from re-licensing FontAwesome to be under GPLv2+.
This means that putting it on a whitelist serves no purpose. It is still not legal to distribute anything that is under SIL OFL in a package where the documentation (i.e. LICENSE.txt) implies that everything included in that package is made available to downstream recipients under GPL.
Dries is on record that having distros with mixed licenses "is going to get messy":
However, there is no way around this. Just whitelisting "GPL Friendly Font Licenses" will not make it legal to distribute them until the "no mixing licenses" policy is repealed and we've worked out how to deal with this by means of the licensing documentation included in the distribution.
Comment #13
kreynen commentedI think we may still be agreeing, but now I'm less sure.
First... the whitelist isn't a whitelist of licenses, but a whitelist of URLs. I created the current list of licenses to address #1901130: Clarify GPL V2 and later-compatible licenses: make a simple table, update terms, consistency-in-docs.
At one point (before my time as a whitelist maintainer) anything that was compatible with GPLv2 or GPLv3 was being being whitelisted. That's what led to this thread #2307465: Update Whitelist License Taxonomy to Match Allowed Licenses and my attempts to clarify which licenses where allowed and clean up the current whitelist.
The situation isn't going to get messy. It already is. Copies of FontAwesome and other SIL OFL licensed fonts already exist in dozens of projects.
The implementation of the whitelist was half baked at best and the groups that funded the sprint to get this functionality available on Drupal.org have long since checked out. The whitelist lacked a policy for removing an entry if the project's license changes. Unfortunately the whitelist has to work in the real world. We can't just revoke a whitelist entry without causing problems for the projects using it. If I had simply removed CKEditor's entry when we found Apache2 code in that repository, it would have caused problems for dozens of projects used by tens of thousands of sites.
But as I've pointed out repeatedly, the whitelist is just one of many places code and assets become available for download from Drupal.org that have always made the simple "everything downloaded is GPLv2" statement untrue. It isn't even true for code.
There is a larger discussion that needs to happen within the LWG about trying to actual enforce a policy that has been openly violated for > 8 years or draft new policies that are more inline with what other GPLv2 or later/PHP projects are doing.
Are we really going to try to get to the point where "everything downloaded from is GPLv2 from Drupal"?
If we are update the git and licensing policies to allow maintainers to commit non-code assets like fonts to git, then I fail to see what is accomplished by not allowing the URLs to add these same assets via a .make to be whitelisted.
Comment #14
gisleAs you say, we may be mis-communicating. When I say "whitelist", I am referring to the list of whitelist-licenses. My main concern is how this communicated to the public and putting OFL SIL there would simply be misleading, so I don't want it to appear there.
I am not talking about the packaging whitelist, which is is used by .make and is something most members of public never sees. It now occurs to me that you say "whitelist", you refer to the packaging whitelist only.
To make it clear: I am not opposed to putting OFL SIL (or almost any other asset license that allow distributon) on the packaging whitelist as soon as the "all files must be GPL" policy has been amended and we've figured out how to document that there are mixed licenses in a distro.
Comment #15
kreynen commentedGreat. I'm glad we were just talking past each vs. finding a fundamental disagreement in our views on open source licenses. I think following @tvn's suggestion in #2426213: [DOCUMENTATION] Move Whitelisting Documentation under LWG? would help clear up some of the confusion. We should move the just the list of licenses under the LWG and start referring to as that list as the "simplified list of GPLv2 compatible licenses" or something like that so it is no longer tied to the whitelist, but referenced from the whitelist project's documentation.
I completely agree that saying that a SIL OTF font is GPL compatible is misleading. See the long conversation I had with the Font Awesome team and FSF about the use of GPL Friendly vs. GPL Compatible at https://github.com/FortAwesome/Font-Awesome/issues/1124.
@gisle So do we agree on both of the following statements ?
If Drupal.org's strict GPLv2 policy regarding non-code assets is relaxed, regular expressions for font projects could be added to the packaging whitelist.
If Drupal.org's strict GPLv2 policy regarding non-code assets is relaxed, all documentation the LWG is responsible for should be clear that while some non-code asset licenses would now be allowed, it is not because the license is GPLv2 compatible.
Comment #16
gisleYup, I fully agree with the last two paragraphs. I am sorry for any confusion I may have caused.
I also support this:
Its fragment identifier (
#whitelist-licenses) should be changed as well. I think it was this fragment identifier that got me confused about what this list was. (I am a web designer, I read URLs :-)Comment #17
tkoleary commentedCan someone clarify what exactly is blocking this issue?
Comment #18
gisleThank you for asking. Here is a status update on the Git repo policy revamp process.
So far, this has happened:
It is not up to me to decide what happens next, but I presume it would be some variation of this:
Unfortunately, no dates have yet been set for getting the new policy officially announced, discussed and approved - and therefore I cannot give you an expected TOA.
Comment #19
kreynen commentedComment #20
kreynen commented