I am the author of the Google Webfont Loader API module (http://drupal.org/project/google_webfont_loader_api). Before I release a stable version of the module, I wanted to include a GPL font packaged with the project which would serve as an example on how a developer could use their own custom font (or include fonts, or use this font on their own website) to implement on their website. Specifically speaking, I wanted to include Beteckna (http://gnu.ethz.ch/linuks.mine.nu/beteckna/), which is licensed under GNU GPL, in my package. I spoke with Garrick Van Buren (who runs Kernest.com and hosts the font) and he emailed back I am free to do as I see fit regarding packaging of the font with the module. However, I wanted to run it by infrastructure before I go ahead on this matter. I would be happy to provide any other possible information to help my case with including this font in my release package.

Comments

kiamlaluno’s picture

Generally speaking, files available from third-party sites should not be committed in drupal.org repository, independently from the license. The reason is that the repository is though to host Drupal installation profiles, modules, and themes; it's not thought to be the repository of every GPL licensed files.

kiamlaluno’s picture

Component:Drupal.org module» CVS
Gerhard Killesreiter’s picture

Component:CVS» Drupal.org module

I really appreciate that you ask before the fact. Not many people do that.

ABout the poinf ot licensing: If it is GPL, it is ok. There is no problem.

However, we generally prefer to not include 3rd party software with packages from drupal.org, if they can be downloaded from elsewhere with only small effort.

Gerhard Killesreiter’s picture

Component:Drupal.org module» CVS

xpost

BTMash’s picture

I subscribe to the infrastructure group and constantly see issues with 3rd party projects pop up which is why I want to make sure whatever I do tries not to make your lives harder in the future :)

Under other circumstances, I would wholly agree with what is posted above (and other examples I am going to include do look at linking to 3rd party sources). In this scenario, I did want to provide a properly functioning font (actually, it was be a series of versions of the font: the Beteckna font I provide would be in svg, eot, otf, and woff formats for compatibility). In the top scenario, it is basically only offered in sfd (a fontforge extension), ttf, and otf. My goal would be to provide it in the missing formats for compatibility with other browsers (with instructions for others on how to do the same for any custom fonts users wish to use on their own site). So the user could get the fonts though it would be somewhat non-trivial to get it working properly across multiple browsers (and the example would give the user a very concrete idea of how to set their own font up correctly as I use something very similar to info files to set everything up).

greggles’s picture

That seems to me like a pretty significant effort and a big enough change from what is easily available to make it worthwhile to host the files in cvs.drupal.org.

Gerhard Killesreiter’s picture

I agree, we have the rule that if the files need to be modified in order to be used the files can be included.

BTMash’s picture

Status:Active» Fixed

Wow, this is great news! I will be able to package the font with my release in this case :)

dman’s picture

I currently ship a bland, GPL ("Liberation") font along with my imagecache_actions to support the text captioning it does.
If I did not, the module just wouldn't work until people had taken a dozen extra fiddly steps.

With the sample font, it's a usable and useful module. Without at least a working starting point, I'd expect many folk would give up, as it's broken out-of-the-box.

There is no point in worrying about thinking of a font as a third party library that is being 'maintained' or updated offsite. It's not like it will get a security fix added next week. With proper attribution (a README with links to the source is included) then bundling and re-using this addition is what the GPL is all about giving us the freedom to do.

soo ... although I don't modify the font at all, there is still no real problem with this?
It would be loopy if the policy required me to deliberately modify a working font in order to get an exemption.

I did think hard about this when I first added the file - but the actually working factor overruled any by-the-book rule.

Gerhard Killesreiter’s picture

Status:Fixed» Active

"until people had taken a dozen extra fiddly steps."

What are thes steps? If it is just to go somewhere and download the font, and then maybe copy a specific file, I would say that this is quite ok to expect from a user to expect.

Damien Tournoud’s picture

Fonts are really a special case. They generally don't change once created (and don't have version numbers), so having them in CVS doesn't mean 'forking' them or committing to maintaining the fork.

pwolanin’s picture

I don't object to including it - we just need a consistent policy.

What about images - are they like fonts?

dman’s picture

The extra steps are all about the difference between something that just works and something that totally doesn't.
Would you prefer a toy with batteries included or one without?

After downloading, unpacking, enabling a module and finding your way to the settings, it's a diversion to find it broken, then go and find the README, and scroll down through all the paragraphs to find that there are missing pieces, then figure out what to do about it, and do it. If you count the individual clicks switching between OS, filesystem, web browser, text editor, Drupal UI and back (don't forget file permissions on the commandline) it's a hassle that can be avoided entirely if the developer had just thought about the user a bit and done one thing to make all those steps by all those people un-needed.
I trial modules several times a day, and I'm really good at this rigmarole now, but it's still a pain. I see other folk lose half a day with any module that is "some assembly required".
I'd completely understand if this one speedbump lots 30% of the audience because it "didn't work" first time.

If I can't have a font to rely on, I can't produce automated tests or working preset examples.

It's not like having a handy copy of a GPL font is a license problem, or a security problem, or a maintenance problem. What's the remaining practical objection? File size?

pwolanin’s picture

There are plenty of Drupal modules that don't work without getting an external code library - it's a matter of policy.

However, fonts/images and the like might not have the same concerns as Damien suggests.

sreynen’s picture

As maintainer of another font module, I'm very interested in this issue.

It sounds like there's some consensus on clarifying the policy slightly to allow 3rd party GPL files in CVS so long as the files are of a type that doesn't typically go through revisions (e.g. fonts, images), making maintenance a non-issue. Is that correct?

sreynen’s picture

Related: Ember (the Spark theme) is including a 3rd party GPL font. Can we now explicitly change this policy so everyone else has that option?

greggles’s picture

Issue tags:+Legal

I think there might be a way to package font files with the module/theme using a make file and the external packaging/whitelist process. If that's not the case then:

It sounds like there's some consensus on clarifying the policy slightly to allow 3rd party GPL files in CVS so long as the files are of a type that doesn't typically go through revisions (e.g. fonts, images), making maintenance a non-issue. Is that correct?

Seems good to me. How long should we wait for comment before going ahead with this policy change? Do we want a +1 comment from anyone in particular?

sreynen’s picture

Looks like pwolanin wrote most of the current policy, so he's maybe the best person to +1 a change. Some specific text we might add:

Fonts and images, when licensed under GPL, are excepted from this policy, as they are unlikely to change or require updates.

webchick’s picture

Hi, I was directed to this discussion from #1730836: 3rd party library policy and Source Sans font. I'm really sorry, it never even occurred to me that a font could be considered a "third party library" since there is no code, it is therefore not executable, and has no chance for leaving behind security holes (which was the rationale for this policy originally).

I support the consensus that seems to be building here, which is that the policy is about "libraries" + "code" (this is the only wording found in http://drupal.org/node/422996) and I'd actually argue that adding fonts under a policy intended for code would be a "feature request" which I would highly -1.

webchick’s picture

Oh, and same goes for images.

greggles’s picture

and has no chance for leaving behind security holes (which was the rationale for this policy originally).

I think that was part of the motivation, but also just not wanting to mirror lots of large third party stuff. IIRC it was created in part after gheydon committed the tinymce repository to cvs.d.o which was more code than most other projects combined.

webchick’s picture

I remember the "bloat" being one factor of that discussion, but the main overriding factor was leaving insecure versions of third-party libraries we don't control in our CVS repo. This is irrelevant with things like fonts and images.

Unfortunately http://drupal.org/node/422996 doesn't specify the rationale for the policy. It just says "libraries" and "code," neither of which fonts and images are.

killes@www.drop.org’s picture

I am ok with fonts and also GPLed images, of people don't start to abuse this.

The problem with images was that they usually were not GPLed, though.

webchick’s picture

Yeah, 100% agreed that everything in Drupal.org's repo needs to be under standard GPLv2+ which means no incompatible licenses like CC-BY-SA (like the famfamfam silk icons, which have come up in the past). That, though, is already covered by Drupal Git Repository Usage policy.

pwolanin’s picture

Sure, that sounds fine to me too.

sreynen’s picture

Status:Active» Fixed

Great, looks like everyone's agreed. I changed the text on http://drupal.org/node/422996

Status:Fixed» Closed (fixed)
Issue tags:-Legal

Automatically closed -- issue fixed for 2 weeks with no activity.

Component:CVS» Other