Please allow building from source with a free toolchain

Thank you for releasing your new Plex font under an open source license.

I am interested in packaging Plex for Debian and Ubuntu, but your font is not buildable from source with free/open source software which is a requirement for inclusion in the main Debian repository. That is number 2 in the Debian Free Software Guidelines and the Open Source Definition.

Strictly speaking the requirement for the building chain to be libre isn't in the definitions, but would mean the fonts go into Debian contrib, not main, as I remember.

Unless the hinting is done with a ttfautohint controls file, the hinting is unlikely to be authored or compilable with libre software

Strictly speaking the requirement for the building chain to be libre isn't in the definitions

See the reject critieria from the Debian FTP Masters, the team that reviews new packages for inclusion in Debian. Specifically, see the section on Generated Files.

the fonts go into Debian contrib, not main

That is correct.

To clarify, is the .sketch file the original source?

On Nov 19, 2017 7:21 AM, "Jeremy Bicha" <notifications@github.com> wrote: Strictly speaking the requirement for the building chain to be libre isn't in the definitions See the reject critieria <https://ftp-master.debian.org/REJECT-FAQ.html> from the Debian FTP Masters, the team that reviews new packages for inclusion in Debian. Specifically, see the section on Generated Files. Sure - sorry I was unclear, I meant the fsf fsd, Debian fsg, and osi osd, definitions :) the fonts go into Debian contrib, not main That is correct. To clarify, is the .sketch file the original source? It depends on your philosophy of what source is :) Fonts are not like typical programs: their lifetime development processes pass through several overlapping epochs, which involve different tools, some of which are digital. You might start sketching in paper, first in pencil, then in ink, or vice versa. Then you might scan images of that, or you might start "digital sketching" that is informed by but not directly derived from the analog media; this could be in a vector based illustration app, a vector based font app, or a raster based image app. It could be drawing contour outlines or brush strokes. You might print that out and sketch in pencil or ink over the top and then scan the result back in. Eventually you get to a font editor app, which again might be used to develop contour outlines or skeletons that are stroked with a nib; what defines a font editor is that it has features for you to set the side bearings of the letters and preview them in arbitrary strings. It's essential to do drawing and spacing together and see text blocks (even with just a few letters) for the design process, because human perception of the black/opaque shapes is strongly effected by the white/transparent shapes inside and between the former. There may even be different font editors in use in this phase, or going back and forth too a sketching app or paper. But as the drawing and spacing of shapes in wrapping up, then you move to a production phase, where you design and finalize OpenType Features, kerning classes (exceptions to the overall side bearings) and hinting (improving rasterization of the contours) and these may be done in different applications to the drawing editor that are specialized to that task. You may start on some aspects of this phase in earlier phases, for example in an extreme case, if you are designing for a specific pixel size, your first sketches might have been on graph paper, even. Eventually you end up with a set of "build sources" which are the files that when passed through a (set of) compiler tools produce the binaries used by end users. That is, for example, the definition of source in gplv3. The free software movement is quite weak at writing comprehensive font editor tools, so it's extremely unusual for type designers to work using only free software for everything. Even the last stage is hobbled by the lack of hinting editors; however since hinting most matters on non-free platforms and doesn't matter on free platforms, there's little incentive to fix that in either the hobbyist or commercial sides of the movement, and those outside the moment are by definition uninterested in replacing the proprietary software they use (which is today I think always at $0 marginal cost to them.) Switching costs are real. What is confounding for Debian is that popular opentype feature and hinting editor applications, Microsoft Visual OpenType Layout Tool (VOLT) and TrueType (VTT), are architected on the assumption that they are the final and discrete steps in the design process, so the start by reading a binary and they store their "source" data as binary data in the file, which they finally strip out in the final compilation action. When Debian says,

"Your package contains generated files (such as compressed .js libraries)

without corresponding original form. They're not considered as the preferred form of modification, so you will either have to provide corresponding original form, or remove them from your tarball, eventually depending on an already available packages to provide missing features." The corresponding source form for volt or vtt is another binary file. So. The point is that fonts have such nonlinear and heterogeneous workflows associated with them that access to source files is not like typical software, like consumption media (audio/video), where there is a clean path from text authored by people to binary executables, and the binaries are pretty close to the sources anyway so recreating sources from binaries is trivial, which is unlike most consumption media. So for me, the sketch file is not source, strictly speaking, as Sketch isn't a font editor. But it is useful if you want to understand how the letters came to be the way they are, for example if you are in the country of Georgia, which is often way way down the list of scripts to extend a Latin font to. So, if a font project owner (like IBM) is seeking to maximize the value of contributions to the upstream, I recommend to publish all the digital files from all of the stages, for people to pick and choose from depending on their own workflow and "level" of work. For Debian today, since the OFL RFN option has been used, Debian can't modify the fonts with the Plex name intact, and needs to rename the fonts anyway. If you fork and rename, you can forget about hinting and package those fonts for main; you can get started on that today, because you can reverse engineer build sources from the binaries that are in a form suitable for long term maintenance; this is how the Bitstream Vera fonts became the DejaVu fonts. If you want to keep the hints, as DejaVu did, you can make a funky build process which merges your work on top of the original binaries... Hope this is helpful :)

@jbicha

Hi @jbicha and @davelab6, please review our latest release and let us know if it serves this issue’s needs.

@seejamescode

@seejamescode Current method for building from sources does not use a free toolchain. Since there is currently no FOSS for editing/manipulating TrueType hinting instructions it will be hard to achieve this I think.

@BoldMonday

Since there is currently no FOSS for editing/manipulating TrueType hinting instructions it will be hard to achieve this I think.

@BoldMonday @jbicha but there could be a build only for the OpenType, does not it? Maybe the Debian package does not really need the TrueType formats.

Debian package will likely need to rename, due to trademark and rfn requirements.

…

On Fri, Mar 30, 2018, 6:18 AM Pau Ruŀlan Ferragut ***@***.***> wrote: Since there is currently no FOSS for editing/manipulating TrueType hinting instructions it will be hard to achieve this I think. @BoldMonday <https://github.com/BoldMonday> @jbicha <https://github.com/jbicha> but there could be a build only for the OpenType, does not it? Maybe the Debian package does not really need the TrueType formats. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#98 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAP9ywbK2eGFJtpdRBIuTdH392VTYl0pks5tjgZugaJpZM4Qi2QM> .

@seejamescode

Good point, Dave. It would be nice to have a statement about this by @seejamescode.

@BoldMonday

This is out my scope. I just know web use of font files. @BoldMonday would be the go-to person.

I'm working at the Debian packaging of Plex. The Apache+OFL dual licensing that came with v1.1.4 is great news: we can stop worrying of the RFN clause. Unfortunately I think it will have to be distributed in contrib anyway, as I don't think there is a free tool that is able to build TTF or OTF fonts following the hinting instructions.

@paride

@paride While you don't need to worry about the RFN, I'm not entirely sure if the dual-licensing model allows for unlimited creation and distribution of derivatives of fonts named "IBM Plex", because, on addition to "Plex" being RFN under OFL, "IBM" is also a registered trademark of IBM, and AFAIK, "Plex" is a trademark of IBM.

It would be fantastic if IBM could clarify how users are expected to apply these trademarks when creating derivatives.

@twardoch

@twardoch you are right, we should consider trademarks. The trademark is on "IBM Plex"

https://trademarks.ipo.gov.uk/ipo-tmcase/page/Results/1/UK00003255123

so calling a derivative font "Plex" alone should be fine. Still I don't like the idea of renaming it, as it causes compatibility issues and confusion. The Apache license says that:

This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.

and this could be enough to be allowed to call "IBM Plex" a font built from unmodified source. Anyway it seems that we can't even (properly) rebuild it for the moment...

Well, no more Apache: #190 (comment).

@paurullan

Is it possible to build the OTF on Linux, as @paurullan suggested?

@mjabbink

@mjabbink so is this officially a WONTFIX?

@BoldMonday

I thought resolved. @BoldMonday to chime in on source code. Trademark is for IBM Plex. If shapes are not being altered or no no glyphs added and we have opportunity to checkout the final output we can grant permission to still use the name. If changescandcadditiinscare made it would require a new name.

Fact is there is no open source tool chain for building these fonts. That is out of our control unfortunately.

Since it’s OFL-only now, both trademark and the RFN limitation apply. While the trademark may be “IBM Plex“, the Reserved Font Name is “Plex”.

So — without the copyright owner’s permission — no 3rd party is allowed to distribute derivative (non-original) fonts that have “Plex” in their name.

The copyright owner is of course free to grant the permission to any 3rd party, or to lift or change the RFN in a future release.

https://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=ofl-faq_web#1db14da7 explains the thinking behind RFN and font format conversions: the idea is that a lossless compression such as WOFF or possibly WOFF2 is not considered “modification”, so changing the name is not necessary, but other conversions that entail modification would require a name change unless the copyright owner grants permission to use the reserved name.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Please allow building from source with a free toolchain #98

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Participants

Please allow building from source with a free toolchain #98

Description

Activity

davelab6 commented on Nov 19, 2017

jbicha commented on Nov 19, 2017

davelab6 commented on Nov 20, 2017

seejamescode commented on Feb 22, 2018

BoldMonday commented on Feb 22, 2018

paurullan commented on Mar 30, 2018

davelab6 commented on Apr 2, 2018

paride commented on Apr 11, 2018

seejamescode commented on Apr 13, 2018

paride commented on Aug 14, 2018

twardoch commented on Aug 14, 2018

paride commented on Aug 14, 2018

paride commented on Aug 23, 2018

vvug commented on Sep 10, 2018

paride commented on Nov 1, 2018

mjabbink commented on Nov 1, 2018

BoldMonday commented on Nov 2, 2018

twardoch commented on Nov 2, 2018

twardoch commented on Nov 2, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Participants

Issue actions