Nathan Willis

Standards and specifications straddle the space between software and user-manual–style documentation.

This session presents a recent case study of the search for an optimal license for a FOSS specification project. It covers establishing intrinsic goals for the specification itself, documenting interoperability concerns triggered by adjacent standards, and the difficulties posed by adopting or adapting licenses used in other free standards.

Specifications may be descriptive for human readers — like documentation — but may incorporate samples and pseudocode, or snippets that can be quoted within software source files — like a derived software program. For FOSS specifications, striking the ideal balance between permissiveness and fragmentation among implementers poses additional challenges. Though no one-size-fits-all solution exists, this session will compare specification-license strategies and explain how the case-study project resolved its own decision.

The project in question is a specification for OpenType font shaping, but the licensing issues confronted are rather universal. It is a functional specification that attempts to serve as a reference for a variety of software implementations (both FOSS and otherwise) because predictable behavior across vendors is paramount, so there is no one, obvious license to pick for full compatibility. It interacts with prior standards published by other parties, such as Unicode and the multiple owners of OpenType, each of which carries its own license. And it seeks to attract support and buy-in from these outside parties, who may have competing interests.

In addition to the account of the project's search for potential licenses, the session will also look at the paucity of written resources or best-practices discussions dissecting the issues of specification licenses. It will also enumerate and compare the licenses used by other standards-publishers that impact FOSS developers, including the W3C, IEEE, IETF, and Internet Society, and will attempt to categorize the trade-offs made by each of these publishers. It will also discuss how specification licenses differ from other non-software licenses, such as licenses for datasets and general "commons" works.

Attendees will come away with a renewed perspective on the questions facing authors of standards and specifications, as well as with up-to-date knowledge of how various specification publishers have described the rights granted and withheld in their licenses and the terms and conditions placed on their consumers. Discussion is encouraged, to distill some pertinent principles primed for practical processes.

[Although the session relates to fonts and text encoding, no prior experience with font internals is required. Attendees should expect, however, to be shown the occasional UTF-8 or UTF-16 codepoint in the slides and be ready to avert their gaze if they feel unprepared.]

Or "Exploring free-software fonts in their native parametric spaces." Software interfaces for users to access their font collection are dominated by decades of legacy: generic descriptors like Bold/Italic/Bold-Italic or fixed numerical schemes like CSS and Windows' weight-and-width models. But those labels and encodings don't communicate much. Font X at weight:300 may look nothing like Font Y at weight:300. And they rarely apply well to scripts outside of European languages. Plus, there is no guarantee that fonts even have all of the necessary metadata fields complete and reasonably accurate. This session will present some alternative approaches for navigating font families via analytic means, digging into the underlying parameters and design-space variations of typographic characteristics. It will draw on analysis of letterform detail and typeface normalization that I conducted during my PhD studies, and explore how those abstract analyses could be applied to representing individual fonts, font families, and even entire font collections in alternative ways that may better line up with how readers experience type on a page. All users of fonts, from casual users who only occasionally produce a large, complex document to serious designers and typesetters who regularly grapple with finding the font that fits their needs, will come away with a new perspective on how to search for and find appropriate fonts and sets of fonts. Software developers and package maintainers will leave with new food for thought about how Debian and individual FOSS application projects could rethink how fonts are cataloged, packaged, and presented. The talk will also discuss how large-scale font libraries such as the Debian archive can be explored and queried for their coverage of design-space and for identifying various chinks and under-served spaces. It will end with a look at where libre-licensed fonts and legacy fonts can be patched or bolstered with new metadata to describe the facets of design-space that the generic schemes and coding schemes of the past rarely explore.

Photography policies have begun to appear at free-software events in recent years. These policies typically seek to address personal privacy concerns for event attendees, but they sometimes conflict with the event's desire to record talks, Q&A periods, and social gatherings in public spaces. If not drafted with care, photo policies also run the risk of creating ambiguities for journalists, other attendees making personal photo or video recordings, and members of event-hosting organizations or the public. This session will be an open discussion about photo and video-recording policies, online tagging policies, and related personal-privacy policies, with the goal of clarifying the requirements, needs, and intents of all stakeholders in the FOSS community, so that future event organizers have a solid framework from which to draft clear policies that fit their situations.

Free-software events, like free-software projects, have to maintain a delicate balance between openness as a broad principle and privacy as an individual concern. In the past few years, more and more free-software events and community projects have developed "photo policies" that are intended to define when and how individuals and groups should be captured in media from the event and when and how those same people should be identified in the media. But a haphazard approach to policy writing can create unintentional ambiguities, such as how to define when an individual is the "subject' of a photograph or merely in the background. And free-software communities must also take care to write policies that do not come into conflict with local law, especially when events take place in public spaces. Finally, event organizers need to ensure that their photo policies, real-name policies, press policies, and session-recording consent policies work in concern with one another, not in conflict.

This session will be a broad discussion of photography policies and how they interact with other policy concerns. The intent will be to enumerate the concerns of all stakeholders, identify potential areas of confusion, note best practices, and — most importantly — establish resources and spaces for further discussion for project and community members creating photo policies in the future.

Font packages preset a distinct mix of challenges for an OS project like Debian. In addition to their fundamental weirdness (providing bits that are simultaneously a content element and executable code), fonts can be installed in multiple locations — system-wide and per-user, free-software and proprietary, from upstream repositories and from downloaded .zip files — and user applications are expected to gracefully handle all of the permutations within a single "Font" menu item. Font packages are a recurring stumbling block for smaller language communities, where operating-system support may lag behind and upstream designers may be wholly unacquainted with free software. Furthermore, the low-level privileges granted to font binaries poses practical and security challenges for newer application-packaging formats like Snap and Flatpak, as well as for transactional system-image operating system projects like OSTree and Ubuntu Core. This talk will outline the concerns of such app-packaging and OS-image projects, then present a possible solution in the form of a simple thought experiment: what if Debian stopped providing font packages altogether? In the hypothetical font-packageless world, individual users would install their own fonts on a per-user basis only. That change would trigger a number of ripple effects, from altering how system libraries like fontconfig match font names, to how GTK and Qt access fonts, to how end-user applications provide fonts. A user-only font stack would be simpler and have fewer security issues, and it could reduce the lag between an upstream font's release and its availability to Debian users. This talk will conclude with a look at the down sides of upending the font-packaging mindset, such as font management on the desktop, font versioning, global-language support, font synchronization, and font discovery. But it will, hopefully, ask attendees to reconsider how and why individual fonts are packaged for Debian and for other free-software distributions, and to explore possible alternatives in the years ahead.

The FreedomBox blend of Debian offers people the chance to run a suite of personal web services free from the control of third parties ... but it does still require a traditional Internet connection, complete with all of the privacy and anonymity concerns that entails. That caveat disappears, however, if the FreedomBox has the Tor network as its only connection to the outside world. Entirely by chance, I found myself cut off from own public FreedomBox machine last year, but I soon discovered that Tor-only access has some distinct advantages. This talk will describe my personal experience installing and running a FreedomBox installation that is accessible only over Tor. Some of the difficulties found in combining FreedomBox and Tor are easily overcome, such as properly configuring multiple Tor hidden ".onion" services and securely distributing cryptographic key material. Other hurdles, however, point to weak points that users would be unwise to fiddle with, such as using long-term cookies with Tor Browser. The talk will describe the challenges and shortcomings encountered in depth — including Tor hidden-service management en masse, working with Let's Encrypt, key management, service persistence, remote monitoring, and mobile-device access. It will offer suggestions for expanding what packages FreedomBox offers, and will detail the configuration and preference settings required to use Tor Browser and Tor for Android with essential services. Whatever the obstacles, however, audience members will see that it is possible to not only combine the user freedom of FreedomBox with the anonymity of the Tor network, but to come away with a stronger system when the two work in concert.

Now that libre fonts are widely available through projects like Google Fonts and Open Font Library, what's next for free-software typography? Font selection and access for users relies on support from the entire operating system stack. Our font packages, however, are still structured like command-line applications. Documentation and supplemental data are not integrated with system or application-layer help frameworks. Metadata is not tracked by the desktop environment as it is for other content types. The OS provides little to no help for users downloading fonts online or simply maintaining a large library. We can make improvements to how fonts are packaged and how font metadata is handled throughout the OS that will make it easier for application developers to create font managers or to provide richer experiences for finding and choosing fonts in GUI applications—including those that use custom widgets, as design applications often do. Designers and authors, who make the most use of fonts on a day-to-day basis, will gain from these improvements first. But the same changes that simplify life for users whose daily work involves their font library will benefit others. Enhancing font packaging will improve the experience for translators and internationalization projects, simplify the build process for Debian and downstream developers, and reduce the number of bugs caused by the peculiarities of font licensing. This talk will cover proposed changes to the contents and policy of font packages as well as in-progress work on improving font support in AppStream and other metadata tools, software centers, and package managers. It will address upcoming changes to SPDX to better support font-licensing details like Reserved Font Names (RFNs) and how those changes will affect license-compliance work, and it will look at the possibilities of integrating a Debian desktop with online font libraries and services.

Fonts sit at a peculiar crossroads in the software license-compliance world. They contain executable instructions as well as static, visual data. They are binary files that, even when "open", are often shipped without source code. They are sensitive to namespace collision problems but are only exposed in user interfaces by name. The files themselves are governed by copyright, but the design they encode is not considered copyrightable in the US and other jurisdictions. Furthermore, the typemaking industry has long vacillated on the appropriateness of reviving, reusing, and extending earlier works as new designs. This talk provides an overview of the intellectual-property law and the community norms that concern sharing, reusing, and extending typeface designs. It will help developers navigate the intellectual-property and license-compliance issues they may encounter when using and redistributing free-software and open-source fonts.

Fonts sit at a peculiar crossroads in the software license-compliance world. They contain executable instructions as well as static, visual data. They are binary files that, even when "open", are often shipped without source code. They are sensitive to namespace collision problems but are only exposed in user interfaces by name. The files themselves are governed by copyright, but the design they encode is not considered copyrightable in the US and other jurisdictions. Furthermore, the typemaking industry has long vacillated on the appropriateness of reviving, reusing, and extending earlier works as new designs.

This talk provides an overview of the intellectual-property law and the community norms that concern sharing, reusing, and extending typeface designs. It highlights several specific issues relevant to modern digital font projects:

• The law has struggled to keep up with industry practices on the subject of copying a competitor's type design. In the cold-metal era, foundries routinely copied and sold designs originating from the competition, even mechanically reproducing metal type in bulk. When digital fonts arrived in the 20th Century, the files themselves were originally not regarded as intellectual property, and wholesale copying picked up once again. Today, the files are considered copyrighted, but the designs are not. This can leave users in an uncertain position, as modern tools allow designs to be copied digitally, without copying the original file, and the law has not drawn clear lines around what practices are permissible. • Reviving a historical typeface is generally considered an acceptable practice if the design process begins with primary materials (such as metal types, proofs, or out-of-copyright prints). There is fierce disagreement, however, about how far in the past a designer must go before a typeface is considered fair game; revivals of typefaces that were "works for hire" by a corporate foundry or printer in particular are controversial because ownership of the intellectual property is debatable. Moreover, there is disagreement about how the original designers of a typeface can and should be credited in a revival, particularly when the revival makes alternations and updates. Users need to be particularly aware of these issues when selecting typefaces for branding and advertising purposes, which can attract public criticism. • Font names can attract more attention than the visual design itself, for the simple reason that installed fonts are, traditionally, searchable and accessible on computer systems only by their name. Name collisions between fonts are increasingly common, yet little effort has gone into addressing these collisions through trademark law. • The leading license used for free-software fonts, the SIL Open Font License (OFL), is often misunderstood, and those misunderstandings can place developers and users of open fonts in a bind on compliance issues. For example, the OFL does not require source-code availability, but it does include restrictions limiting the circumstances under which the fonts can be sold. It also includes an optional clause that, at the licensor's discretion, requires users to change the user-visible name of the font if any alteration is made to the binary, including common practices like subsetting the font to deliver it over the web. Downstream projects that user OFL-licensed fonts and assume that the OFL is broadly compatible with common free-software licenses may not be aware when license-compliance problems occur.

There are no easy answers for resolving these issues in free software, but this talk will provide developers and communities with advice for identifying and coping with licensing issues relating to the fonts that they utilize in their projects.

The number of free-software fonts has exploded, thanks to CSS webfont services like Google Fonts and Open Font Library. But open fonts have yet to make gains in document-creation systems beyond web pages: print-on-demand publishing, print-on-demand merchandise, eReaders and EPUB generation, games, and bundled with FOSS applications. This talk will look at the obstacles, bottlenecks, and disconnects behind this situation and explain what needs to happen next in order to move forward.

The number of free-software fonts has exploded since 2011, thanks primarily to CSS webfont services like Google Fonts and Open Font Library. But open fonts have yet to make gains in document-creation systems beyond web pages. This is attested to by the lack of open fonts used in other service types and communities of practice, including print-on-demand publishing, print-on-demand merchandise, eReaders and EPUB generation, games, and even in the default fonts bundled into binary packages of free-software applications like LibreOffice.

This talk will look at the obstacles, bottlenecks, and disconnects that have prevented open fonts from reaching the hands of users beyond the CSS @font-face directive. These issues include missing or proprietary-format source files, licensing cruft, the user experience of discoverability and installation, build tools for font binaries, and character coverage.

We will also discuss solutions, including what distributions and upstream application projects can do to mitigate these issues as well as what the broader free-software community can do to advocate for the usage of free-software fonts in documents and display typography outside of the browser window.