Adopt the 2020 (evergreen) Drupal logo in Drupal core

If I understand correctly, the new logo is only for branding. It replaces the Drupal 8 and other version-specific logos, but not the Druplicon (which is used in the Drupal core).

And, AFAIK, there are only theme-specific favicons and logos in the core repository. So I don't think they should change. Though Claro and Olivero themes might incorporate it in some way (as they do not have stable versions at the moment).

The Druplicon is a GPL mascot of Drupal. The Drupal logo (for Drupal 8 and onwards) and the Drupal wordmark are not GPL. Therefore including them in a GPL package is tricky. We could not figure this out either 5 years ago for the wordmark. So I don't know if this is legally possible to do.

I see #605710: Decide on if and if so, how to implement the Drupal wordmark in core which is already linked.

Adding the background that I'm aware of that would be relevant to this conversation. And of course, I am not a lawyer, so this should be taken with a grain of salt:

The GPL v2 - Section 2 - has this to say about 'aggregation [... of works] not based on the Program':

In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.

We can see some discussion of how various Open Source licenses affect Trademark usage, here in the Open Source Casebook project.

• Note that the GPL v3 explicitly includes a provision allowing for additional terms to prevent misuse of a trademark.
• This could be interpreted a two ways:
  • GPL v2 *did* cover trademarks, and so this explicit clause was added to prevent the problem in v3
  • GPL v2 *did not* cover trademarks, but because of the worry and confusion, the explicit clause was added in v3 to make it crystal clear

We can also see some examples of other projects' trademark enforcement policies.

From Drupal.org itself, we have the following policy statements and interpretations:

From Drupal.org's Policy on Third Party Assets on Drupal.org

Non-code assets

Drupal also permits 3rd party GPL-incompatible non-code assets (e.g. fonts, icons, etc.) in the repo if it can be distributed “in aggregate” with GPL code under a “GPL-friendly” license.

This links to the table of licenses from Drupal.org's Distribution Packaging requirements (where 3rd party assets are a common question):

Drupal also permits GPL-incompatible non-code assets (e.g. fonts, icons, images, etc.) to be packaged and/or distributed as long as the maintainer has the right to distribute them (i.e. they must have a free/libre license that permits them to be distributed “in aggregate” with GPL code). Such licenses are whitelisted as “GPLv-friendly”.

[...]

Informal name	SPDX identifier	Is allowed
CC BY 2.5	CC-BY-2.5
CC BY 3.0	CC-BY-3.0
CC BY	CC-BY-4.0
CC BY-SA 2.5	CC-BY-SA-2.5
CC BY-SA 3.0	CC-BY-SA-3.0
CC BY-SA	CC-BY-SA-4.0
SIL Open font License 1.0	OFL-1.0
SIL Open font License 1.1	OFL-1.1
GPL+FE	GPL-2.0-with-font-exception

And finally from Drupal.org's Licensing FAQ:

3. Can Drupal projects include GPL-incompatible non-code assets? (e.g. fonts, icons, etc)

Yes, so long as the maintainer has the right to distribute the non-code assets, they may be packaged and/or distributed "in aggregate" with GPL code. Only works that are derivative of the original work are subject to the GPL license.

Interpretation

This suggests to me that Drupal.org's standing interpretation of the GPL v2 is that it is safe to distributed third-party works that are not derivative of the Program code without causing them to become subject to the same license. However, I have to reiterate that I am not lawyer.

Next step

My suggested next step would be seeking legal counsel on the following:

• Is our interpretation of the usage of 3rd party assets valid?
• Can that interpretation be validly applied to logos/graphics/font/trademarks?

Note: When we sought legal counsel five years ago, the answer was (approximately): "this particular question hasn't been well-tested by the courts, so we can't rely on precedent - the safest thing to do is follow the practice in 'common usage' by others in the same situation." I am not sure if that advice will have changed.

Disclaimer: I am a programmer, not a lawyer. However, I have worked extensively with free software and free cultural works for several decades, I have served, and still serve, as board member of multiple companies that distribute free software and free cultural works and has in that capacity had to deal with trademark issues multiple times during my career. I have also been the chapter lead of Creative Commons Norway for more than a decade (I have now stepped down), but I am still Norway's representative to the Creative Commons Global Network Council.

First: What does the GPL tell us? There is no doubt in my mind that the GPL (both version 2 and 3) say that you can distribute trademarks in aggregate with GPL software without putting trademark protection in jeopardy. Legally, the term "aggregate" is the antonym of "derivative". The intent, as well of the letter, of the GPL is to make "copyleft" extend to all derivative works originating from any work under GPL. AFAIK, it has never been the intent of the FSF to require that distributing two things that is capable of working independent of each other in the same tarball (or whatever) magically make them legally derived from each other.

The Creative Commons organization, whose CC BY-SA license has been approved as mutually compatible with the GPL by the boards of both the FSF and the Creative Commons, has this FAQ about trademarks:

Can I offer material under a CC license that has my trademark on it without also licensing or affecting rights in the trademark?

Yes, you may offer material under a Creative Commons license that includes a trademark indicating the source of the work without affecting rights in the trademark, because trademark rights are not licensed by the CC licenses. However, applying the CC license may create an implied license to use the trademark in connection with the licensed material, although not in ways that require permission under trademark law. To avoid any uncertainty, Creative Commons recommends that licensors who wish to mark material with trademarks or other branding materials give notice to licensors expressly disclaiming application of the license to those elements. This can be done in the copyright notice, but could also be noted on the website where the work is published.

Source: https://creativecommons.org/faq/#can-i-offer-material-under-a-cc-license...

So, legally (ie. as regulated by the GPL, copyright law, and trademark law), distributing the Drupal brand in Drupal core does not put its trademark protection in jeopardy.

However, the advice from Creative Commons to take explicit steps to "avoid any uncertanity" about the trademark's protected status should be taken seriously.

Second: The Drupal core will be put in our Git repo, so it also need to comply with our Git repo policy. It says:

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

Please notice the total lack of references to “GPL-friendly” licenses from that official document. The "license" that accompany the third party asset can be anything, including a pretty detailed spelled out policy, such as the Wordpress trademark policy. AFAIK, the WordPress trademark has been distributed in mere aggregate with the WordPress code (which is licensed under GPL) for years, without anyone challenging the trademark's protected status.

Our community documentation about this says:

Non-code assets that cannot be distributed under a “GPL-friendly” license (e.g. trademarked logos) cannot be included in the repo and distributed unless they are granted an exception by the Licensing Working Group (LWG).

Community documentation is not official, so I don't think that requiring more to be done to include such assets than what is spelled out in the Git Repo Policy has much merit. But I also imagine that the LWG would supportive if such an exception was requested for having the Drupal trademarks, etc. in the Drupal core.

To conclude:

• Your interpretation of the usage of 3rd party assets is valid.
• That interpretation can be validly applied to logos/graphics/font/trademarks.

@gisle thanks for that great feedback. I think the intent of protection is to (a) keep Druplicon as GPL and remixable by people (b) make the wordmark and the software logo NOT remixable and only possible to use within their guidelines / intended use. Is that what you meant in protection of the trademark? I believe the previously understood limitation was that once we include the wordmark or the software logo in the GPL package it becomes remixable (potential for derivative works) and that is explicitly not what a brand would be.

My understanding was that Firefox historically got into this trouble with Debian where they could not use the Firefox name and logo due to similar reasons in their "true" open source package. So a derivative browser called Iceweasel was made available.

Thank you for the supporting arguments, @gisle. Those are helpful.

My understanding was that Firefox historically got into this trouble with
Debian where they could not use the Firefox name and logo due to similar
reasons in their "true" open source package.

^^ If anyone finds a good write up of what happened there I would love to see it. (I'll be looking for one as well).

And actually - if this wikipedia summary is accurate - it looks like the rebrand was done out of desire not to be constrained by the trademark - not because of a legal issue with including the trademark - and apparently they have reverted back to the trademarked branding as of 2016: https://en.wikipedia.org/wiki/Mozilla_software_rebranded_by_Debian

Yay then! Sorry for leading you on the wrong path there :) also exciting that this would be possible then. Woot!

In comment #8, Gábor Hojtsy wrote:

I think the intent of protection is to (a) keep Druplicon as GPL and remixable by people (b) make the wordmark and the software logo NOT remixable and only possible to use within their guidelines / intended use. Is that what you meant in protection of the trademark?

Yes. IIRC, the Druplicon mascot was deliberately made remixable under GPL, so that organizers of events, etc. can create their own variations.

However, Dries and the Drupal Association clearly does not want anything like that happening to the new branding, so concerns has been raised about putting it in core would make it remixable just like Druplicon. And my answer is "no" - that will not happen if you take the steps suggested by Creative Commons to avoid any uncertainty about their status.

I believe the previously understood limitation was that once we include the wordmark or the software logo in the GPL package it becomes remixable (potential for derivative works) and that is explicitly not what a brand would be.

Well, this has never been my understanding of how a "GPL package" that contains aggregate assets that are explicitly separately licensed is supposed to work. Nor am I aware of any case law that is contrary to my understanding of this. As for Debian's dropping of the Firefox name, this was due to them distributing a derivative of Firefox under the Firefox brand. And of course they could not do this, even if the branding materials was included in the GPL package they received from Mozilla. Debian soon realized their mistake, and acknowledged that the Firefox branding was not licensed to them under GPL, unlike the GPL code in the package they received. I think this incident supports my interpretation of these things, rather than the opposite.

I think what Debian tried to do here was rather outrageous. It would just be like the Backdrop project distributing their code (a derivative work of Drupal) with Drupal branding (unlike Debian, they never tried to pull such a stunt, I must add).

@gisle: makes sense, thanks for clarifying. It is exciting that this is possible to do :)

I suppose an important next question is which license we should specify as the GPL-Friendly license for the new brand materials. The table of CC licenses quoted above is not totally up to date with all of the latest CC 4.0 license options.

My suggestion is that we should take one of two paths:

1. Use a license like CC-BY-ND

OR

2. We should draft a statement like the Wordpress Foundation trademark policy that they use for their logo inclusion.

Thoughts?

I think CC-BY-ND would be a well understood license scheme instead of making our own up. But I am not a lawyer :D also the distribution packaging requirements above do not mention that as a potential option (although it does not rule it out either). If we are to use it, it should be explicitly included IMHO.

In comment #15, hestenet wrote:

I suppose an important next question is which license we should specify as the GPL-Friendly license for the new brand materials. The table of CC licenses quoted above is not totally up to date with all of the latest CC 4.0 license options.

For the record: CC BY-ND is not a "GPL-Friendly license". "A GPL-Friendly license" is a license that provides the downstream recipient with what the FSF calls the "four essential freedoms". CC BY-ND does not offer the "The freedom to distribute copies of your modified versions to others (freedom 3)", so that excludes it from being classified as "GPL-Friendly". The list quoted in #6 is curated by the LWG, and it is up to date. The exclusion of CC BY-ND is deliberate.

IMHO, you should not consider CC BY-ND as a license for the trademark or any other brand materials. It is indeed a well understood license scheme, and here is what it does (my "good"/"bad" rating is given for suitability for licensing protected materials for the purpose of branding):

1. It does not allow derivative works of the brand (good).
2. It does not allow any use of the brand to suggest an affiliation with or endorsement by the Drupal Association or the Drupal free software project (bad).
3. It allows use of the brand to promote other products and services than Drupal (bad).
4. It allows use of the brand to promote non-free software (bad).

Assuming that the Drupal Association wants to regulate the use of the brand beyond preventing derivative works and endorsement, I do not think there is an alternative to create a brand policy (similar to the Wordpress Foundation trademark policy) that spells out under what condition the brand can be used. How strictly the DA wants to regulate use of the brand is of course up to the DA, but I think the DA, as a minimum, needs to explicitly regulate all four uses in the list above, and in more detail than this license does.

As for implied affiliation and endorsement, you probably want to disallow this in general, but you may also want to allow this in specific cases (DrupalCon, official sprints, etc.), so the blanket ban on this as mandated by CC BY-ND does not fit the use case of branding.

The Wordpress Foundation trademark policy has got this covered by:

Permission from the WordPress Foundation is required to use the WordPress or WordCamp name or logo as part of any project, product, service, domain name, or company name.

I.e. use of the branding by third parties is not allowed, unless explicit permission is given by the WordPress Foundation.

I don't think it has been mentioned in this issue, but Drupal already has a "Drupal trademark and logo policy": https://www.drupal.com/trademark - dating from 2009. It is pretty permissive compared to the Wordpress Foundation trademark policy, and the DA might want to reconsider the idea of an "automatic license". Such a procedure automatically grants sites such as https://ilovedrupal.com/ permission to use the brand.

There are also guidance about brand usage in the media kit: https://www.drupal.org/about/media-kit/logos and https://www.drupal.org/about/media-kit/logo-wordmark-guidelines and from pages linked from those. I think this could do with some updating and consolidating (but that is unrelated to having the brand in core).

Thanks @gisle - that guidance is really helpful. Appreciate your expertise here.

Okay - we'll begin work drafting a custom policy per that example.

Core already has the official D8 logo on the status report -- see #3137414: Remove D8 branding from D9 status report.

The issue pointed out by @xjm at #3137414: Remove D8 branding from D9 status report would be the most urgent to add the evergreen logo ASAP indeed. :) I believe people did remix the Drupal 8-drop as well, so we should have a policy crafted for the evergreen logo then.

Also made the issue title easier to google and identify. (There were new brandings before as well).

Assigning to myself - hoping to have a draft of the usage policy tomorrow.

Per the recommendations we've arrived at above, we now have a draft Trademark & Copyright policy to be posted on Drupal.org and included in the git repo for Drupal:

https://www.drupal.org/about/media-kit/copyright-and-trademark

Next steps:

• Review the draft policy for any key considerations we feel might be missing. In particular - is it accomplishing it's primary goal of allowing Core to use the brand materials, without exposing those materials to the risk of alteration, remix, fork, etc?
• If we are satisfied with the policy, create a COPYRIGHT.TXT document to commit to core in the appropriate location in the file tree to represent the protections in place for the included brand materials.

Thanks for the draft, @hestenet!

A) Is the draft policy sufficient to move forward fixing core to start using this?

B) Should that page explicitly grant permission for core (and presumably contrib) to use the (unmodified) logo inside Drupal when referring to Drupal(tm) itself? There's this:

This means that when these brand materials are distributed in aggregate with the Drupal software itself, which is licensed under the GPL v2, the brand materials do not inherit the terms of the GPL v2, but retain their own terms and usage restrictions per this policy.

It says that Drupal software is distributing these brand materials, implying the right to use them, but it doesn't actually say so. Can/should it?

C) Under Legal provisions:

the invalidity or unenforceable of such provision...

s/unenforceable/unenforecability/ ? I guess that's not a word, but the grammar doesn't parse as-is. Maybe:

"the invalidity or unenforceable aspects of such provision..."?

D) Do we want the "hosted on Drupal.org" link to point to https://www.drupal.org/node/3137696 (current) or https://www.drupal.org/about/media-kit/copyright-and-trademark ?

Thanks for working on this! It's good to provide clarity.

I've been working with the GPL for more than 20 years. It's also my understanding that you can license digital assets (such as logo and brand images) differently from code. I believe we should. In other words, I agree with @gisle's statement and support the direction.

I like https://www.drupal.org/about/media-kit/copyright-and-trademark. I would, however:

1) The title "Copyright and trademark" feels too generic. It could be confused with the "Copyright" of the code or the governance of the trademark. I would update the title of the document to mention "Brand materials" or something equivalent to capture the scope.

2) The difference between the "Brand materials" and the Druplicon is something most people are not familiar with. I believe that warrants a bit more explanation. I'd imagine this documents will get reviewed by people/organizations not familiar with the history. I'd consider embedding example logos and adding a bit more context.

To answer @dww:

A) I'm comfortable with the current draft. First, it's a big improvement. Second, because the Drupal Association owns the copyright for the brand materials and the governance of the brand materials policy, it should be easy to refine the policy at any time. "Big improvement + easy to adjust/refine = move forward", in my opinion.

B) I don't believe we must call out Drupal core explicitly. At the same time, it doesn't hurt. So I'd consider that a nice to have.

Great! Do we need to change license files (text) in Drupal core to point to the policy so that there is a reference to it in the GPL package?

Do we need to change license files (text) in Drupal core.

What license files do you refer to?

Just to make clear: You never change somebody else's license file. They are usually copyrighted, with some clause saying that you must distribute verbatim copies with the work it covers. But that changing it is not allowed.

Standard practice when you include assets (including branding materials) in aggregate with free software, is to put the asset collection in a separate subdirectory, and then put a text file inside that directory (e.g. "licence.txt" or "licence.md") where you put text to make clear that the contents of that directory is not under the GPL, but licensed separetely.

I think a short plain language explanatory text with the URL pointing to the web page with full branding materials policy is better than a long file with a verbatim copy of the full legal code. These things may evolve over time, and having the canonical version in just one place simplify the logistics of keeping things up-to-date.

Sounds good. Looks like #3137414: Remove D8 branding from D9 status report is going to be the first implementation issue of this. It would need to include the branding in all the themes to mirror how it was done before, so I think that practice itself would need to change so its only included once and in a subdirectory with a license .txt or license.md.

Addressed some of @Dries's remarks in #25:

• #25-1 - updated the title to: "Copyright and Trademark Policy for Drupal Brand Materials"
• #25-2 - added a bit more explanation of the Druplicon. @TODO - add example logos
• #25-A - per Gábor in comment #28, we are proceeding with current draft, with ability to revise as needed
• #25-B - added an explicit authorization for Drupal itself

I updated the link to the latest new brand kit, where evergreen SVG logos were fixed.

@saschaeggi opened #3178135: Change favicon to new Drupal logo as well.

Also, I repurposed #2030027: Use the Drupal software logo in the installer which was originally the lack of Druplicon in the installer.

The navigation module snuck in the 2020 logo actually, so I think this is somewhat resolved. However, it was just redesigned slightly, so needs a change again :D #3446413: Update the Drupal logo in Drupal core with the 2024 brand evolution.