postponed on #547068: D7UX: use Seven for installation / updates getting in in the first place.

http://drupal.org/node/547068#comment-1938778:

Under no circumstances whatsoever can we include the new wordmark in Drupal itself.
One of the main design goals for the new wordmark was to have a new official logo and branding that was not under the GPL. See: http://www.garfieldtech.com/blog/drupal-org-logo-trademark

and

http://drupal.org/node/547068#comment-1940264:

afaik LICENSE.txt isn't in CVS either, but is added by the packaging script - so why not only include it if installing Drupal from a Drupal.org tarball, if you install via CVS you get good old Druplicon instead (which serves as a default for all profiles which don't specify an image) - that gets the logo into the tarball, but not into CVS (it'd have to live on the server somewhere else of course).

The latter got a lot of support. Can we do it like this?

To be clear, what we'd like to do here is this:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

seutje’s picture

subscribe

alexanderpas’s picture

first of all, LICENSE.txt is actually in CVS (http://cvs.drupal.org/viewvc.py/drupal/drupal/LICENSE.txt)
what we're doing with the license is keeping one centralized version of it, and adding it during the packaging to contrib module to ensure GPL compliance.

webchick’s picture

Yes, here's what needs to happen to ensure license compliance, from what I understand (Crell please jump in here to advise if this is correct):

1. The wordmark.png file (which is currently in http://drupal.org/files/issues/install-update-images.zip) needs to be put somewhere that is not anywhere on cvs.drupal.org. A private *.drupal.org SVN repo, somewhere in Drupal.org's files directory, in some shell user's home directory, whatever, but it can't be checked in to cvs.drupal.org because if it is, then it must be GPLed and we can't protect the branding of a GPLed wordmark. (Or something like this.)

2. The packaging scripts (and I don't know where those are) that are currently doing things like adding version info and LICENSE.txt to contrib modules need to be adjusted so that when a tarball of the "Drupal" project is generated, it replaces themes/seven/logo.png with wordmark.png (basically, cp /wherever/the/path/is/to/wordmark.png /themes/seven/logo.png). This way, anyone who downloads a tarball from http://drupal.org/project/drupal (which is most of our users) gets the branding effect during the installer, and anyone else who gets it from CVS (which is most of our developers) gets the old fashioned Druplicon (or probably nothing at all since they're using Drush ;)).

Once we confirm/adjust this plan of action, this issue needs to be moved to the Drupal.org infrastructure queue for implementation.

JohnAlbin’s picture

but it can't be checked in to cvs.drupal.org because if it is, then it must be GPLed and we can't protect the branding of a GPLed wordmark. Or something like this.

So that we don't have that debate again… :-p

  1. Only GPL items can go in cvs.drupal.org because our CVS policy says so.
  2. We could change our CVS policy and our LICENSE file to say that everything but the wordmark is GPL.
  3. But some people (and linux distros) won't use/include/whatever drupal if there is a non-GPL part of it.
  4. Therefore the easiest way to get around these issues to include the wordmark using the tarball packaging scripts. People needing a GPL-only distro of Drupal can get it directly from CVS. And normal tarball downloads will include the Drupal branding.

That said, it seems to me we would still need to edit the LICENSE file included with the drupal tarball, so that it notes the wordmark license exception. The wordmark is (or will be) included in the tarball, after all.

But we desperately need this in D7. I want to see a shiny Drupal wordmark in our installer! And possibly in the Seven theme, too.

mcrittenden’s picture

Subscribe.

yhager’s picture

Does that mean the downloaded tarball will not be GPL?
IANAL, but I would go back and inquire why a GPL'd image brand cannot be protected (GPL does not mean there are no copyrights, it is just a usage license).

What do other open source projects do to protect their brand?

alexanderpas’s picture

remember Firefox, Debian and Iceweasel?

Damien Tournoud’s picture

I don't believe you can reliably protect a logo that is so close to just text. Why not publishing this logo in GPL and getting done with it? While the trademark is important, the logo we picked (a simple text) has no real value.

chx’s picture

Damien, this is a wordmark which, at least in the EU and the USA can be registered so yes it can be protected. Think of FedEx, their special wordmark where the whitespace in the E and the x forms an arrow you think they are not protecting that trick like lions?

Damien Tournoud’s picture

@chx: a "wordmark" (in the common sense of the trademark law) is the usage of a word. It's not the protection of the logo per se, but of the usage of the word. The current "Drupal Trademark" is actually a wordmark. It's independent of the fact that you cannot reliably protect a logo that has nothing special.

yhager’s picture

> where the whitespace in the E and the x forms an arrow

Gee.. never saw that before :) thanks!

chx’s picture

Damien,

A wordmark, also sometimes word mark, subset of the term logotype, is a standardized graphic representation of the name of a company, institution, or product name used for purposes of identification and branding

.

David_Rothstein’s picture

Any decision to make Drupal less than 100% GPL seems like it might be too big to occur in the issue queue, no?...

In any case, I think what Damien says here makes a lot of sense. Protecting the typeface used in this logo really doesn't seem worth it compared to the simplicity of just making the logo GPL.

Also, if going ahead with this change to the installer, did anyone think about the potential for confusion? We'd be showing them one Drupal icon during installation, then a different Drupal icon in the Garland theme once the installation is done.... They'll figure it out and all, but it's a bit odd.

JohnAlbin’s picture

Let's not argue whether or not our wordmark is "unique enough" to be protected; that's just silly. The "Drupal" in the wordmark above is not using an unmodified font and any designer can easily point out the unique properties of it.

This is not the issue to argue about we should or should not protect the wordmark. This issue assumes the wordmark needs protecting and is about how we protect it while still including it in a downloadable tarball.

So back to the issue at hand…

what we're doing with the license is keeping one centralized version of it, and adding it during the packaging to contrib module to ensure GPL compliance.

Since we are already doing this for contrib tarballs, it seems we already have some code in our packaging script that can checkout a file from an alternate source and place it into the tarball. I haven't seen the packaging scripts, but it should be easy to do the following for Drupal 7:

  1. Checkout project into temp directory.
  2. Checkout wordmark.png from a special repository for non-GPL materials.
  3. Take the wordmark.png and copy it over the existing themes/seven/logo.png file in the temp directory.
  4. Ensure that the LICENSE.txt in the temp directory has language noting the GPL exception for the Drupal wordmark file.*
  5. Package up the temp directory into a tarball.

* LICENSE.txt exception text: Its nice that we have a single source for our current LICENSE.txt; we should keep that exactly as is. So we either need to have a modified version of LICENSE.txt describing the wordmark exception (also stored in the non-GPL materials repository) or we need to have a separate LICENSE-WORDMARK.txt that is to be placed next to the LICENSE.txt in the tarball.

JohnAlbin’s picture

BTW, this is what the updater would look like with the wordmark. MUCH better then the Druplicon, IMO.

David_Rothstein’s picture

I think the discussion at http://www.garfieldtech.com/blog/drupal-org-logo-trademark makes clear that the wordmark was never originally intended to be included in the downloadable Drupal software. So if we are talking about changing that here, I don't see why we can't talk about proposing a change in its licensing as well. And the alternative of making Drupal less than 100% GPL (or rather, trying to distribute two versions of Drupal, only one of which is 100% GPL) really seems like it might be too big to decide in some random issue in the "base system" component of the issue queue - at least not without a lot more people participating here :)

Given that both Garland and Bartik already use the Druplicon all over the place, I'm still not sure I understand the rationale behind using a different logo in this one place anyway? And the screenshot in #15 shows that the word "Drupal" already appears in big letters at the top of this page, so adding a logo that also has the word "Drupal" in big letters doesn't seem to add much. I think we'd at least want to retitle "Drupal database update" to "Database update" if doing this.

chx’s picture

Version: 7.x-dev » 8.x-dev

We have much better and urging things to fix than jeopardizing the GPL status of Drupal. See you in Drupal 8! (I had an urge to won't fix this altogether but I know people are obsessed to ruin stuff in the name of 'community expansion', be it damned, so it will be reopened anyways so I won't bother.)

Gábor Hojtsy’s picture

FileSize
466.3 KB

@koleary posted a whole set of mockups in #1260716: Improve language onboarding user experience that use a derviative of the Drupal wordmark (combined with a derviative of the Druplicon to form an 8), to be used in the Drupal 8 (installer) branding. I'm just posting it here for further discussion to untangle that question from that issue:

Drupal8Wordmark.png

The whole set of mockups can be found at http://drupal.org/node/1260716#comment-5069806

Gábor Hojtsy’s picture

BTW I've opened a separate issue for the overall installer theme thing at #1337554: Develop and use separate branding for the installer.

sphism’s picture

This might be a silly question:

If you can't add the Drupal wordmark into the tarball why not just pull that image in from a remote server? ie if you install drupal AND you are online, then the drupal wordmark is pulled in... if you are offline, then the druplicon is used.

This could also be used to get a better idea of the number of installations of drupal.

Just my 2 cents

tkoleary’s picture

Quoting myself from issue# 1337554

"The Drupal logotype is made from custom vectors and is not a specific font, however, it just occurred to me that if we are making an icon font in the issue on supporting retina displays we could simply add the glyphs from the Drupal logo to that font and specify it for that text. Then at least for languages with Latin Scripts we would have the properly branded logotype."

I believe this neatly sidesteps the license issue. The mark is a trademark but the glyphs are not (and cannot be under copyright law, which is why fonts are licensed as software not as images). If we simply include the glyphs in the and GPL the font there is no license issue.

tkoleary’s picture

Also linking to retina diaplay issue #1963886

LewisNyman’s picture

@tkoleary

There is no technical way to sidestep the trademark issue. Courts apply a lot of common sense in these cases. If it looks like the logo, no matter how the visuals are put together technically, it's able to influence the perception of the brand.

To reiterate, it's ok for Drupal core to influence that brand, it's not ok for others to do so, and GPLing the assets might affect Dries' ability to protect the trademark from others.

starko’s picture

This UI is perfect for D8!

tim.plunkett’s picture

That use of the wordmark is illegal.

Please read https://drupal.org/drupal-media-kit#usage-guidelines before proposing any more designs breaking the exclusion zone.

LewisNyman’s picture

Dries in #2035489: Replace imitated "Drupal" wordmark:

Why don't we use the proper Drupal logo? The Drupal trademark that I own is for the word Drupal, not for the Drupal logo. From my point of view, there is no trademark violation here. There might be a license issue though, but I don't believe so either.

I don't think we can get a stronger authority than the trademark holder himself. I think we can push forward and implement the wordmark in the installer inline with comment #27 in #1337554: Develop and use separate branding for the installer. We already include the word Drupal under the GPL license, so adding the logo would not affect Dries' IP rights.

Pancho’s picture

Re #26:
Even Dries can err... :)
And seriously this could be the case here. We really need an expert on media law here.
But even if not, meaning the Drupal wordmark is not explicitely registered, then this should probably be done.

In any case, relicensing the Drupal wordmark under the terms of the GPL would even go beyond that. Regarding the partly questionable Drupal trademark and logo policy, GPL would waive the license grant requirement in the trademark policy in many situations.

It's not without reason why the GPL-only Debian project completely rebranded Firefox, after Mozilla understandably insisted on name and logo being exempt from the terms of the GPL.

Given that, I'd love having the Drupal wordmark in the installer, but again: we (or Dries) need legal advice by a lawyer specialized on licensing here.

Gábor Hojtsy’s picture

TL;DR: brand protection; licensing

One of the points of separating the wordmark from Druplicon was to have a Drupal logo that is not freely adapted and modified as people feel like. Druplicon is supposed to be free to tinker with but the wordmark was not supposed to allow for that. As soon as its distributed with GPL software, we explicitly allow tinkering with it. I believe that is what not including it in Drupal desired to achieve.

If we want to make an exception for the wordmark in our license, I believe we have been concerned with that open source repositories (eg. Debian packages, if such things still exist for Drupal) would not include the distro as-is anymore, since they would not allow for non-free components. So they would need to fork Drupal core for the exclusion of the wordmark. So I believe we considered this would be an issue for free redistribution of core in general.

Pancho’s picture

#28:
Technically, the Debian case shouldn't be a major problem, not even a special case.
Anyway we wouldn't want any distribution ship with the Drupal trademark in that prominent place, so the Debian distribution would be just another slightly modified standard distribution.

The central problem remains to see if there is a legally acceptable way at all to include our wordmark in the installer, without the wordmark becoming subject to the terms of GPL.

As I said in #2035489-5: Replace imitated "Drupal" wordmark, GPL3 has a "Section 7: Additional Terms" covering this aspect, while GPL2 doesn't.
Still, the Additional Terms section is highly problematic, because the rebranded distribution (with the wordmark being replaced or removed) wouldn't be license-compatible to the Drupal project anymore. Meaning that we couldn't include code, that was developped on basis of a rebranded Drupal distribution, back into the Drupal project, without explicit permission of all code owners.

Again, this is highly complex and highly sensible.
Besides an Free Software Foundation lawyer, the Debian people could possibly help us with some advice.

sphism’s picture

Interesting, I've been fiddling with the look of the installer and I added the Drupal wordmark, but remembered there was some legal reason not to use it.

I've never actually liked it so i'm happy to make a different one for drupal 8.

Would be good if someone could answer my question from earlier:

This might be a silly question:

If you can't add the Drupal wordmark into the tarball why not just pull that image in from a remote server? ie if you install drupal AND you are online, then the drupal wordmark is pulled in... if you are offline, then the druplicon [edit: or other font] is used.

This could also be used to get a better idea of the number of installations of drupal.

Just my 2 cents

danillonunes’s picture

I think this pull-online approach seems to add a lot of complexity that might not be worth enough for just this issue. For example, what we should do when a internet connection is available, but the Drupal server is unreachable? What if the connection runs at very low speed? The mark is shown in the first page displayed, so we don't have time or a expected waiting window as we have when we're checking for updates after the end of the installation.

tstoeckler’s picture

Well if the Drupal server is unreachable, we don't do anything regardless of whether internet in general is available or not.
And if we do replace the title via Ajax, it won't slow down the rest of the page.

So that's just to say this could be done in a reasonable amount of code. I would personally actually find it to be a very neat idea.

sphism’s picture

@tstoeckler: Oh, that's good, I thought maybe I was going mad. I'm not really sure how the GPL applies to assets pulled in remotely, I really don't understand the issues at all.

sphism’s picture

I've just been doing a little digging to see how other software deals with this issue.

I downloaded wordpress and it includes the official logo, wordpress-logo.png

I also found this page: Wordpress Trademark Policy

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

So I emailed the wordpress foundation to ask them if they have any information on this issue, how/ if they get around it. I'll post anything I learn here.

Wordpress in under GPLv2 licence, the Drupal licence is GPLv2 or later ??? whatever that means: drupal.org/licensing/faq/

xjm’s picture

Issue summary: View changes
LewisNyman’s picture

Issue tags: -Legal +licensingpolicy
gisle’s picture

Issue tags: -licensingpolicy +licensepolicy

@sphism, legally, what WordPress is doing is fairly trivial.

Here is the relevant language from the GPLv2-licence:

“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.”

The Drupal Wordmark is not code, so including it in the repo/distribution as a "mere aggregation" does not bring it under the scope of the GPLv2-licence. (The viral clause of GPLv2 is only triggered for derivatives.)

This means that you can create a "Drupal Trademark Policy" (similar to the Wordpress Trademark Policy) and legally include it in a distribution that is otherwise under GPLv2+.

gisle’s picture

Issue tags: -licensepolicy +licensingpolicy

Sorry, just noticed that Holly's minutes says "licensingpolicy", not "licensepolicy". Retagging.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

hestenet’s picture

Noting here that this question has raised it's head again with the release of the new Drupal brand materials.

The new issue created is: #3134326: Adopt the 2020 (evergreen) Drupal logo in Drupal core

And I've tried to summarize the current state of our understanding in this comment.

I'm trying (again, 5 years later) to get a strong legal opinion on this one way or another. I'll report back what I find.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Gábor Hojtsy’s picture

#3137414: Remove D8 branding from D9 status report started using the new drop software logo in status report, while #3178135: Change favicon to new Drupal logo continues doing that as a favicon and #2030027: Use the Drupal software logo in the installer would apply it in the installer. I am not sure we want to use both the software logo and wordmark at once. However https://www.drupal.org/about/media-kit/logo-wordmark-guidelines does include that as a guideline. That both the wordmark and the software logo would be used alongside each other in core.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.