More Seven Theme issues: #1986434: [meta] New visual style for Seven

Short version: The style guide for the updated default Seven admin theme proposes to use the Source Sanse Pro font. Source Sans Pro is not only free but open source, available under the SIL Open Font License (OFL). We propose to include a webfont version of Source Sans Pro be included with the Seven theme.

  1. Figure out if we can, license-wise
  2. Decide if we will (our rationale below)
  3. If so, do it

Rationale for the use of Source Sanse Pro

This guide proposes all text be set in Source Sans Pro from Adobe. Similar in character to Lucida Sans (the existing typeface specified by Seven), Source Sans is a professionally designed, fully open-source type family that falls into the general category of “humanist sans-serif”. Fonts of this type combine the modern geometric and industrial-age characteristics of sans-serif typefaces with the calligraphic and handwritten qualities of Renaissance letterforms. This balance of the engineered and the human matches well with the Drupal brand.

Seven’s original choice of Lucida was a good one for those same reasons, but also for a very practical one: legibility in UI. Source Sans is arguably even better in this respect, with glyphs such as lowercase L and upper/lower I all easily distinguishable from one another, even at small sizes. This is one of many details to consider when choosing a typeface for UI work, and where some common choices – like Helvetica – fare poorly.

Source sans also provides a versatile set of weights, including a semibold.

Licensing

Source Sans is one of the few professionally-designed typefaces that is not only free but open source, available under the SIL Open Font License (OFL). However, it is unclear whether the OFL would allow it to be included as part of Drupal core. The Wikipedia page on OFL states that it is not GPL-compatible. However, SIL’s own FAQ states, under a question about bundling with GNU/Linux that “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.”

Provided the OFL license is compatible and the community supports it, this guide proposes that a webfont version of Source Sans Pro be included with the Seven theme. To keep file size and HTTP requests down as well as to simplify the design system, not all of the fonts that make up the complete type family would need to be included. This guide uses the Regular, Italic, Semibold and Bold fonts.

So to repeat the main points:

1. Figure out if we can include the font files in the Drupal project, license-wise
2. Decide if we will
3. If so, do it!
4. If not, figure out if we can find a way to download the files from an external server without harming UX.

Files: 
CommentFileSizeAuthor
#43 old1.png81.29 KBandymartha
#43 1986082old2.png56.66 KBandymartha
#43 1986082new1.png43.2 KBandymartha
#43 1986082new2.png66.98 KBandymartha
#43 1986082new3.png63.83 KBandymartha
#8 1986082-source-sans-font-8.patch3.29 KBmcpuddin
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1986082-source-sans-font-8.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#6 1986082-source-sans-font-6.patch0 bytesmcpuddin
FAILED: [[SimpleTest]]: [MySQL] Repository checkout: failed to checkout from [git://git.drupal.org/project/drupal.git].
[ View ]
#4 1986082-source-sans-font.patch3.29 KBsccherry
PASSED: [[SimpleTest]]: [MySQL] 55,716 pass(es).
[ View ]

Comments

Bojhan’s picture

Issue tags:+Usability, +styleguide

Thanks, adding tags.

I also want to add that this font is an integral part of our proposed new styling. Although not including it, is the easy road - we would like to press for this to be included given that it will modernize and elevate our styling

Bojhan’s picture

Issue summary:View changes

Updated issue summary.

LewisNyman’s picture

From the preamble of the OFL web version:

The fonts and derivatives, however, cannot be released under any other type of license.

This is our roadblock, the Drupal.org policy requires that anything checked into git is licensed as GPL. Unless we make an exception for font files, we can't include them.

The license goes on to say that embedding the font into documents does not require the document to be licensed under OFL. This does mean we could download the font from an external server. I won't go into the details of that implementation until we are agreed on the above.

ry5n’s picture

Yes, those are the options as far as I understand them: get an exception, or figure out a separate loading strategy.

ry5n’s picture

Issue summary:View changes

Added clarification

sccherry’s picture

Status:Active» Needs review
StatusFileSize
new3.29 KB
PASSED: [[SimpleTest]]: [MySQL] 55,716 pass(es).
[ View ]

Used Google Webfonts to get Source Sans Pro, so the font files will not be added to Drupal.

I created an additional file with the CSS file that is created by Google, so the file can be aggregated.

mcpuddin’s picture

Status:Needs review» Reviewed & tested by the community

I applied this patch and it worked well. My only possible issue is that the admin website font will have a dependency on being connected to the internet and to google services. If you are all good with that, it will work out, if not, then someone needs to make the ultimate decision regarding this.

mcpuddin’s picture

StatusFileSize
new0 bytes
FAILED: [[SimpleTest]]: [MySQL] Repository checkout: failed to checkout from [git://git.drupal.org/project/drupal.git].
[ View ]

Actually I rerolled the patch because the original one was uploaded via Windows and had some issues being applied.

mcpuddin’s picture

ug ignore that, that is 0kb.. one sec

mcpuddin’s picture

StatusFileSize
new3.29 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1986082-source-sans-font-8.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Actually the original file and my new one are the same.. but I'm going to upload my rerolled one just in case it removed any windows'ness.

Bojhan’s picture

Status:Reviewed & tested by the community» Needs review

@mcpuddin Just explaining some general community guidelines here, we mark this RTBC when a number of contributors agree that this is a good direction and have looked at the code. Its common not to mark your own patches RTBC.

Status:Needs review» Needs work

The last submitted patch, 1986082-source-sans-font-8.patch, failed testing.

mcpuddin’s picture

@Bojhan, this was not my patch but rather someone at the code sprint. I simply re-rolled his patch that seemed to work well except there was a windows newline error. Correct me if I'm wrong, but I was under the impression that someone marks RTBC once someone reviews it and validates it. Or do I just need more clout or to work on issues that seem to be a little more decision-worthy?

Bojhan’s picture

@mcpuddin True, however this is a big change it could benefit from more discussion.

ry5n’s picture

The bigger issue here is whether committers are OK with relying on a third-party service for the typeface used in the default admin UI. I’m the one who proposed the typeface and I am not sure I’m comfortable with it. We simply need an answer from committers if they are willing to include the font files in the source (preferable, but unlikely) or if they are OK with relying on a service.

In the patches, I notice a couple of things:
- The fonts are being pulled from 'themes.googleusercontent.com'. What is this? There is no site there; is it the font store for Google Web Fonts? Is the URL reliable?
- The patch only pulls woff versions. Now that we’ve dropped IE8 support, that covers everything but Android. We should decide if we want to serve webfonts to mobile browsers. Maybe we don’t (for speed). If we do, we should include a TTF version for Android.

ry5n’s picture

At this point I’m going to come out and say that I think we should either bundle the font files with core or stick with Lucida. I don’t like facing that, but at this point we need a decision, and I just don’t want to even go down the road of relying on third parties for a core aspect of Drupal’s appearance.

cweagans’s picture

Issue tags:+Legal

This would be a good point to defer to the DA legal counsel or ask the author for a new license. Crell used to be the legal liaison for the DA, and I know he's knowledgeable about licensing issues, however, I imagine he's pretty busy at the moment preparing for July 1. Is there a process for submitting issues like this to the DA legal counsel?

If we can bundle Source Sans Pro with core, that'd be ideal. If not, I would not be comfortable with using the Google Fonts API by default. Relying on third party services for core seems like a bad path to go down.

If Source Sans Pro isn't an option, are there any other free fonts that we could consider? Is Lucida Sans available on all platforms?

ry5n’s picture

@cweagans I second that. Unfortunately I don’t know what processes exist around legal counsel.

If we can’t use Source Sans, we can stick with Lucida. Windows has Lucida Sans, Macs often have Sans but if not, Lucida Grande. We can do our best picking a fallback on Linux if system fonts have changed since D7.

cweagans’s picture

We could relicense to GPL3 and use Open Sans or Droid Sans, though I suspect that'd be much more work than designing our own font =P

IANAL, but couldn't we just not relicense the font files as GPL2? That seems to sidestep the problem entirely, especially since SIL's FAQ says that it's okay. That is, the problem is that we take the stance that everything that goes into Git is going to be relicensed as GPL2. If we make an exception for the font files, then I *think* we'd be okay. Like I said, though, IANAL.

ry5n’s picture

@cweagans Oh man, if we can simply relicense then we’re fine. I remember reading the SIL FAQ and I did not think it was possible. Sounds like we /really/ just need someone with legal expertise to take a look.

sccherry’s picture

So, I wrote the original patch and I have a few comments (mainly replying to @ry5n, comment #13).

1. I'd actually agree that bundling Source Sans in core would be preferable to using a font provider. But since I can't do anything about licensing I provided a patch for an alternative approach if people decide that's an acceptable solution.

2. The fonts.css file is the CSS generated by using Google Webfonts URL (http://fonts.googleapis.com/css?family=Source+Sans+Pro:400,600,700,400it...). I copied the code to a new file rather than linking to Google's external stylesheet so that the code could be compressed and aggregated with the other CSS files, avoiding an extra HTTP request.

LewisNyman’s picture

We can not release the fonts under any other license, the SIL OFL explicitly forbids it:

5) The Font Software, modified or unmodified, in part or in whole,
must be distributed entirely under this license, and must not be
distributed under any other license.
The requirement for fonts to
remain under this license does not apply to any document created
using the Font Software.

GPL3 may be compatible, but OFL is not.

cweagans’s picture

I understand. The other fonts that I mentioned are released under the Apache 2 license, and are therefore compatible with GPL3.

For Source Sans Pro, we'd either have to get a special license just for use in Drupal, or bundle the font and NOT include it in our blanket GPL2 license that we apply to all files in Git.

jpamental’s picture

If Open Sans has a more compatible license, I think it's a good choice. It's also more complete than Source Sans (more Unicode characters) and also has a 'Condensed' family, making for a really nice combination when using that for headers.

ry5n’s picture

I’ve asked a couple of times in IRC #drupal-contribute who I should talk to to reaolve these licensing issues (whether Source Sans or another font), with no response. Can someone point me to an authority that can help resolve this? We need a clear-cut answer now or this should be postponed to D9.

cweagans’s picture

I talked to Crell about this:

[09:29:43] I was wondering if you could point me toward whoever is the POC for legal questions. They're blocked on https://drupal.org/node/1986082#comment-7492484 solely on licensing issues, and I'd love to get them in touch with the right people.
[09:32:16] Ugh.
[09:32:23] I don't think there is an official point person at the moment.
[09:33:53] Would it be worthwhile to just send an email to the contact address for the DA and see where it gets routed? Or would Holly know?
[09:37:20] hm.
[09:38:41] Well... At the moment the DA isn't Final Word(tm) in this case. Webmasters would be.
[09:38:51] Because it's non-GPL, we can't put it in the repo without an exception.
[09:39:10] Since it's not GPL-compatible (the way Symfony or jQuery are), an exception is extremely unlikely.
[09:39:28] Everything coming out of or repos is GPL or GPL-compatible.
[09:39:39] Right. Most of our legal issues right now are around that blanket relicensing policy.
[09:39:51] In fact, I think all of them are (all three)
[09:40:53] Okay. I'll update that issue and see what we can do.
[09:40:55] Thanks :)
[09:41:23] So, yeah, I don't think we can use that font, for Drupal reasons not lawyer reasons.

So it sounds like we should:

1) Open an issue with webmasters ASAP (done: #2010902: Asking for exception so that Source Sans Pro font can be added to core)
2) Open an issue with webmasters to establish official POC/process for these legal questions (done: #2010906: Establish official process and/or POC for legal questions)
3) Probably come up with a plan B for this issue, since it's unlikely that #2010902: Asking for exception so that Source Sans Pro font can be added to core is going to pan out in our favor

cweagans’s picture

I've sent an email to Paul Hunt (the creator of the font) to see if we can talk to him about how best to bundle his font with Drupal. Hopefully, he will talk to us here, or if I get an email back from him, I'll keep you guys posted.

tkoleary’s picture

Awesome. We did the same with Lato for Ember but unfortunately the designer was unwilling. There's nothing legally wrong with maintaining two versions of the (visually) same font under two different licences (in this case OFL and GPLV2).

tkoleary’s picture

Issue summary:View changes

meta issue added

Gaelan’s picture

Status:Needs work» Needs review
Issue tags:-Usability, -Legal, -styleguide

#8: 1986082-source-sans-font-8.patch queued for re-testing.

Status:Needs review» Needs work
Issue tags:+Usability, +Legal, +styleguide

The last submitted patch, 1986082-source-sans-font-8.patch, failed testing.

tkoleary’s picture

@Gaelan What does this patch do?

Gaelan’s picture

It gets the font from Google Web Fonts. It is not my patch.

cweagans’s picture

I am thinking that a licensing exception is not going to happen in time for feature freeze. In the interest of time, I think we should do one of these two things:

1) Use the web font - I've been thinking about this, and this could possibly be okay if it's either off by default or easily disableable. We could also download the font once from Google and cache it in the files directory at install time.
2) Pick a different font that doesn't conflict with our licensing policy

We might consider doing both of these things, and using the font chosen in #2 as a fallback in the event that the site admin turns off the web font option.

cweagans’s picture

Also, if we're going to use the web font, we need approval from Dries, I think. That sounds like a product decision.

tkoleary’s picture

@cweagans

1) Use the web font - I've been thinking about this, and this could possibly be okay if it's either off by default or easily disableable. We could also download the font once from Google and cache it in the files directory at install time.
2) Pick a different font that doesn't conflict with our licensing policy

The only problem with 1 is that if Google changes anything about the font (file names etc.) the @font-face CSS that references it could become out of sync. Apart from that it sounds like a good idea.

On 2, we did an extensive search for GPL fonts and there is nothing of sufficient quality available. GPL is just not the standard for font licensing. The standard for open fonts is OFL and unless Drupal accepts the font exception fonts that ship with core will continue to be anemic (which is why I really like the approach in 1)

Also, if we're going to use the web font, we need approval from Dries, I think. That sounds like a product decision.

Dries has reviewed the seven style guide and AFAIK voiced no objection to the font.

cweagans’s picture

The only problem with 1 is that if Google changes anything about the font (file names etc.) the @font-face CSS that references it could become out of sync. Apart from that it sounds like a good idea.

Yeah. But the only thing that would affect is the typeface. I realize that's kind of a big deal from a design standpoint, but it wouldn't disable anyones site as long as there was a web-safe fallback. Also, if we download and cache the font files locally in the site's files directory, this becomes not as big of an issue.

On 2, we did an extensive search for GPL fonts and there is nothing of sufficient quality available. GPL is just not the standard for font licensing. The standard for open fonts is OFL and unless Drupal accepts the font exception fonts that ship with core will continue to be anemic (which is why I really like the approach in 1)

I think an exception for including the license directly is not going to happen with the current licensing policy. OFL is not GPL compatible in any sense. In order to do this, we'd need some clear process for adjusting the licensing policy, as well as a review by the DAs legal counsel, and there's simply not enough time to do all of that.

Dries has reviewed the seven style guide and AFAIK voiced no objection to the font.

I'm not talking about the choice of font. I think pretty much everyone can agree it's a good font. I'm talking about pulling the font in from the Google Fonts API. That's kind of a big deal.

LewisNyman’s picture

Yeah. But the only thing that would affect is the typeface. I realize that's kind of a big deal from a design standpoint, but it wouldn't disable anyones site as long as there was a web-safe fallback. Also, if we download and cache the font files locally in the site's files directory, this becomes not as big of an issue.

Agreed, if the font fails to load it should not be noticeable to the user. If Google does change their API, we can always update our implementation in a minor version.

cweagans’s picture

Can somebody please assign this to Dries for feedback? Specifically looking for advisory on whether or not we can pull the font in through Google Web Fonts.

Crell’s picture

Assigned:Unassigned» Dries

Dries, I believe your options are:

1) "It's OK to have a font in the core repo that is not GPL-compatible."

2) "It's OK to have a default font that gets pulled from a 3rd party server (Google)".

3) "Neither of those are OK, let's try something else."

Dries’s picture

I'm going to rule out option (2).

At first glance, I'm not all that thrilled about shipping a font with Drupal; it seems like it may have both performance and licensing issues. I think we can overcome the licensing issue by talking to a lawyer about this. However, I'd love for us to discuss the performance implications of this (on mobile browsers). It looks like we may have to download 4 additional files to get a custom font.

I'd also love to see a better 'before and after' of an admin page with and without the font. This will help us better understand the implication of option (3). The image in https://groups.drupal.org/node/283223#Typography looks nice but blurry and doesn't really help us understand the 'before and after'. Would it be much work to create this?

Thanks! :)

tkoleary’s picture

@Dries

There's a new js library by google and typekit that comprehensively handles many @font-face issues across different services as well as local fonts and offers asynchronous loading and character subsetting to improve performance.

https://github.com/typekit/webfontloader

effulgentsia’s picture

Following up on #38, can someone expand the issue summary to provide more reasoning on how Source Sans Pro would improve UX or whatever other benefit it will bring? The only thing it currently says (unless I missed something) is:

Source Sans is arguably even better in this respect, with glyphs such as lowercase L and upper/lower I all easily distinguishable from one another, even at small sizes.

We'll need to weight whatever benefits are claimed against the performance cost (#39 might help lower that cost, but not to 0) and the effort involved in clearing #37.1 with legal. Per #38, before and after screenshots that demonstrate the claimed benefits would be helpful.

effulgentsia’s picture

Assigned:Dries» Unassigned

Unassigning from Dries until the summary is updated per #40.

tkoleary’s picture

@effulgentsia

There are definitely usability and legibility benefits to using Source Sans but to me the biggest benefit is a polished and professional administrative theme. Typography is the soul of design and generic, broadly available fonts simple do not have the flexibility and elegance of well crafted contemporary web fonts with multiple weights (particularly lighter weights).
If we truly care about Drupal becoming a center of great design as well as usability there is no issue more important than this one.

andymartha’s picture

StatusFileSize
new63.83 KB
new66.98 KB
new43.2 KB
new56.66 KB
new81.29 KB

Here are some screenshots of Drupal using Source Sans Pro font for visual testing purposes. The first two images are current Drupal.
old1.png1986082old2.png1986082new1.png1986082new2.png1986082new3.png

nod_’s picture

We'll need tools like acquia dev desktop or even drush to install the font on user's systems so that people won't have to dl it all the time.

tim.plunkett’s picture

I think in places like the right column of the node add/edit, it is much much worse.

There is only a negligible improvement in non-bold text.

And at what technical expense? (That's rhetorical.)

LewisNyman’s picture

The screenshots in #43 are not correct representations of the typographyproposed in the styleguide. There are tweaks to font sizes, line heights, and letter spacing to accommodate the new font. Simply swapping out the two fonts, while keeping the styling optimised for Lucida Grande is going to portray Source Sans in a very unflattering light.

I hope to be able to work on a more complete comparison this week. I don't think simply holding up two screenshots is enough of a demonstration, I don't expect developers to have to same eyes as typographers.

tim.plunkett’s picture

I don't expect developers to have to same eyes as typographers.

GFY, you don't know me.

tkoleary’s picture

@andymartha

Lewis is right. Each font has has it's own optimal visual sizing and spacing and to judge them fairly we need to see a true visual comparison using CSS from the styleguide. Also your second screenshot shows Times, not Lucida. Not sure why.

@tim.plunkett

Looks to me like the right column of node edit is taking "Source Sans Pro" and "forcing" it bold (applying an outline) rather than referencing the font: "Source Sans Pro Bold" which would be much more legible and properly hinted.

andymartha’s picture

I would like to second the motion that this is not how the final Drupal would look with new font, it was just an attempt to give mention to effulgentsia's request in #40 with a font-swap.

andymartha’s picture

I would like to second the motion that this is not how the final Drupal would look with new font, it was just an attempt to give mention to effulgentsia's request in #40 with a font-swap.

LewisNyman’s picture

GFY, you don't know me.

I don't remember mentioning you by name... Maybe I should clarify what I meant anyway: in the same way it is a skill to read and understand code, it is also a skill to read and understand the nuances and subtleties of a typeface. It's a skill that is developed over time. We shouldn't expect everyone who is part of this issue to have that skill.

tim.plunkett’s picture

It remains an incredible pretentious and condescending thing to say.
This is the second time in one of these styleguide issues I've seen self-proclaimed "designers" telling people they assume are "just developers" that they are somehow inadequate. It needs to stop.

LewisNyman’s picture

Ok, I can see that. I should of phrased it differently. Let's not go on about it here, if you want to talk more about what I should of said I'm on IRC most of the day.

On the issue, I still think it's helpful to point out some of the details just so everyone can form an opinion with all the information and reasoning that went into the original decision, if not more. If some people don't need things pointed out to them then I guess that feels patronising. I'm not trying to be patronising, I'm trying to be helpful.

LewisNyman’s picture

Once I switched in Source Sans into HEAD I realised there a load of design tweaks that need to be made to get Source Sans comfortable, as the new style guide designs were made with it in mind and the current state of D8 is not.

I quickly spoke to Bojhan and yory on IRC and they agree the best way to show comparisons is to introduce Lucida into the style guide designs instead. I'll be working on a Lucida branch of the Seventy Eight sandbox. #2067057: Create a Lucida Grande variant of the style guide

tkoleary’s picture

@tim.plunkett @LewisNyman

Now now. Let's simmer down.

Tim, I don't think Lewis' intent was to suggest that developers are visual morons. In fact, carefully read, you'll see the intent was:

"A few screenshots are an insufficiently detailed and in-depth study in the fine details of typography that we (designers) make the differences between these fonts important enough for this to be committed to core. I don't expect all developers to be aware of those fine details, therefore i will provide a more lengthy and informative comparison."

I don't think there's anything offensive there.

Crell’s picture

I know Dries asked for a better before/after example, but he also indicated that shipping a non-GPL font is not the best option. Before we spend much more time trying to demonstrate why Source Sans Pro is such a good font, are there really *no* GPL-friendly fonts that look good/professional? We may not have Source Sans available, but I can't believe there's no GPL-friendly fonts out there that wouldn't get approving nods from typography geeks.

LewisNyman’s picture

@Crell

That would be great, I'd encourage anyone to take a look. Here's a great article on good UI typography. Source Sans was chosen for reasons included in that article and the letter forms represent the Seven visual principles a bit better (I'm working on a more detailed explanation).

Our three troublesome thresholds for quality fonts are:
1. Free
2. Open source
3. GPL compatible

Quality free/open source fonts are available but finding one that is GPL compatible is really hard because SIL OFL is popular.

ry5n’s picture

Mozilla recently announced Fira Sans, a new UI typeface for FireFox OS designed by the awesome Erik Spiekermann. It will come in several weights with matching italics. At-a-glance, it looks excellent (as you would expect). But – as usual – we can’t use it, because it is Apache licensed, which is not GPL v2 compatible.

At this point we should abandon any efforts to use a more readable (and more beautiful) typeface for Drupal 8 and stick with specifying system versions of Lucida (Lucida Sans/Grande). There are very real performance considerations that would need to be throughly explored and shown not to cause regressions, even without the licensing challenges. Add in the licensing issue and the prospect becomes untenable.

tkoleary’s picture

@Crell

but I can't believe there's no GPL-friendly fonts out there that wouldn't get approving nods from typography geeks.

Unfortunately that is precisely the case. All of the (very small number of) fonts that are GPL fail to meet my approving nod, or that of any other designer I know.

jpamental’s picture

The licensing issue is what's keeping us from being able to use icon fonts like Font Awesome. The creator of that would be happy to work with us on the icons but not about the licensing, as he feels the SIL is more permissive/less restrictive than GPL.

The advantage in using the web font is that it's the only way to present something uniform across mobile and desktop platforms. iOS may have Lucida but Android does not - so at the very least whatever we decide has to be tested pretty extensively to look at UI control rendering with different typefaces being loaded. Not a deal breaker, but it does hurt the consistency across platforms.

Is it possible to get clarification on why SIL is not acceptable? (from legal) If we could get past that we could include icon fonts and a very good web font and have a well-polished UI to present that could be entirely resolution-independent.

Performance considerations are pretty negligible when fonts are included properly: only the font file that is usable by that browser would be downloaded, not all 4 formats - and font files when served locally like that (from the host site) are cached - so no repeat downloads page-to-page.

Dries’s picture

I don't think the font has to be GPL-compatible. At the end of the day, this is a trade-off between keeping it simple (limit everything to the GPL or GPL-compatible licenses) and giving the community more creative freedom (allow non-GPL compatible projects to be used where possible). Technically, it is sufficient for the font to be an Open Source / Free font as there is no 'binding' or 'shared memory space' issues, although it may require some changes to drupal.org policies and/or packaging scripts. The packaging scripts are responsible for adding the GPL license to all projects, including core. I think these changes are limited to clarifying that "stand-alone assets" (insert correct legal term) like fonts are not necessarily GPL-compatible and that they are bound by their own license(s). This is probably something for the Technical Working Group to evaluate and discuss.

tkoleary’s picture

Given Dries comment above It seems that, pending the Technical Working Group evaluation, fonts under other open-source licenses like SIL will be allowed in core.
And if, as jpamental (and others including Paul Irish) have said, performance is not an issue, then the only remaining question is whether Source Sans is the appropriate font.
The UX group has already approved Source Sans but I think that decision was partially driven by a mistaken belief that Source Sans was GPL. Given that Dries has said that the only restriction is that the font be open source there are several others that might be as good or better (such as Fire sans suggested by ry5n above in #58).
Maybe we can toss this around in UX happy hour on Monday and come up with a recommendation.

Crell’s picture

Kevin: Don't count your fonts before they're committed. :-) What Dries is suggesting is changing the current "every line of code in a d.o repository is GPL or GPL-inbound-compatible" policy; working out where and when and how it's appropriate to make exceptions to that is likely not a short-and-sweet task, and I'd actually be rather worried if it happens quickly as that means it may not have been fully thought-through.

(FTR, I have no opinion on Source Sans itself vs. any particular other font; I freely admit to having no eye for fonts whatsoever. I'm just cautioning that the policy/legal implications of that change are non-trivial, even if they do end up being an acceptable net-win.)

tkoleary’s picture

@Crell

Well, ok. I understand that there are still bureaucratic hurdles, but the fact that Dries supports this in principle is important.

As to legal ramifications, we're actually the last to get on this bandwagon. The "font exception" language for GPL has been in use since 2005: http://en.wikipedia.org/wiki/GPL_font_exception

tkoleary’s picture

Issue summary:View changes

Updated issue summary.

joelpittet’s picture

What are the hurdles we need to jump to get progress on the licensing issues?

philipz’s picture

I don't know if this is still going to happen but I have one thought on this.

Webfonts are great but they need multilingual support. The chosen font would need to have as wide language specific characters. This of course results quickly in big file size. Maybe it would be possible to include just the needed subset of characters depending on current site language?
For example there is a beta option on Google fonts to include not by subset but by single characters like this:

http://fonts.googleapis.com/css?family=Inconsolata&text=ążćęńłóĄŻĆĘŃŁÓ

LewisNyman’s picture

Issue tags:+frontend

We still need an issue summary update if we are going to move forward on this. I'll speak to Bojhan and Roy this week.

gisle’s picture

Issue tags:+licensingpolicy
gisle’s picture

FYI: There is already a discussion about revising Drupal's Policy on hosting 3rd party files and/or files that is not strictly GPL: #1856762: Revisit and Redefine Drupal's Policy on hosting 3rd party files and/or files that is not strictly GPL.

For an even broader perspective, search for the tag licensingpolicy.

I find it encouraging that Dries (see #38 and #61 above) does not rule out having a font in the core repo that is not GPL-compatible.

The first item in the issue summary says:

  1. Figure out if we can, license-wise.

The answer to that is a clear "Yes".

Compare the following language from GPLv2:

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. (my emphasis)

with the following from SIL OFL FAQ:

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. (my emphasis)

Both says the same thing: mere aggregates does not have to be under the scope of GPL. It is OK to have an aggregated asset under a non-GPL compatible permissive license in a repo where all the code is strictly under GPL.

In other words, the only thing that blocks this from moving forward is our own policy, which currently says that everything must be under GPL (and IMNSHO GPL is a horrible license for fonts).

This means we could always grant ourselves an exception from this policy.

However, I personally believe this policy should be changed to also allow contributions hosted on Drupal.org to contains fonts, icons and images as long as these are included as 1) mere aggregates and; 2) an exception is granted.

gisle’s picture

jwilson3’s picture

I have some experience implementing Source Sans Pro on a multi-lingual site. This font is great for western languages and most recently the 2.010 version just got support for Cyrillic and Greek, which makes this font super promising, since it now has support for Central European languages using the "latin-extended" option from Google fonts for languages like Czech, Hungarian, Polish, Slovak, Serbian, and Turkish. Even Vietnamese has a separate option but is also supported. The main issue I encountered was maintaining look and feel across into languages that the font doesn't support -- particularly when the light weight of the font is used (such as in headings).

If the exception were not to be granted for Source Sans Pro, then perhaps a good fallback would be Open Sans which I believe has even wider language support, and a really good looking light weight very similar to Source Sans.

Update: so Open Sans is Apache 2, and not compatible with Drupal's GPL v2 either.

Bojhan’s picture

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

After discussion with Lewis and Bojhan. This is being moved to 8.1, it is an improvement that can still go in without affecting interfaces much if any. However we do not wish to spend our time on it for 8.x development.