Dear maintainer of fonts-cardo,

this package is affected by two licensing issues:

1) RFN: The file is licensed under OFL-1.1 with the Reserved Font Name
clause. However the RFN "Cardo" is used in Debian, although the font is
modified during the build process. FAQ 5.9 of SIL states that modified
fonts cannot use the RFN and must be renamed.

2) NO SOURCES: The font files are not built from the font sources
("preferred form of modification"). d/rules decompiles the TTF files,
patches them, and rebuilds them again. According to the manual «Cardo is
produced using FontLab Studio 5» so the original sources are probably in
the proprietary VFB format (for which there are converters to more open
formats).

Could you please contact the upstream author to integrate the patches
shipped by the Debian package (RFN) and to release the source?

Regards,

I have just fixed issue 1) RFN. This might introduce a regression
because the patches do something even if I have not researched what it
is. Please do not revert it without renaming the font.

I have contacted the font author at his listed address but it is no
longer in service. So I am asking for removal.

was the email on his website, since this seems like something that could
easily be remedied with modest attention. I believe he retired from his
job as a Latin teacher all the way back in 2015, so he has every reason
to be retired from email as well.

Google Fonts does have source files for Cardo at
https://github.com/googlefonts/CardoFont (sfm files that have been
converted to glyphs files as well), but they do not 100% match the
author's latest version at https://scholarsfonts.net/cardofnt.html

Metadata from Google's version:
    <fontRevision value="1.0451"/>
    <created value="Mon Oct 24 05:35:45 2005"/>
    <modified value="Sun Sep  4 18:15:57 2011"/>
Metadata from Perry's version:
    <fontRevision value="1.045"/>
    <created value="Mon Oct 24 05:35:45 2005"/>
    <modified value="Wed Apr 20 10:46:36 2011"/>

There is a good chance Google's source files were created *from* the
original TTF files in order to optimize for web.

I suppose that means we are in the silly situation where, if someone
were to rename the font to something like CMaximus and use those files
to create a version with Google's and Debian's patches, we would say we
had files in the preferred form for modification, but if the goal is to
*not* modify the font and keep the original well-known name, then this
is problematic because we do not have files in the preferred form for
modification.

Regards,
Timothy Gaskell

Yes, the googlefonts version is an import from the ttf and is probably
in violation of the license because they have not kept the reserved font
name.

There are SFD sources at https://github.com/googlefonts/CardoFont which
appear to be the original import to Google Fonts. Being hosted under the
"googlefonts" username mostly indicates that the original upstream
repo/site no longer exists or something similar.

Can you be more specific about the existence of the RFN(s)? I don't see
that on the repo above. So it's possible that either (a) the designer
removed the RFN after being asked to do so (which is not uncommon; a lot of
folks don't fully understand its downstream effects and just add them
without determined intent) or (b) Google Fonts separately negotiated an RFN
exception.

With a font project that old, I'd be surprised if it was a separate
negotiation, but it's clearly important to determine which case it is.

Nate

https://github.com/googlefonts/CardoFont/tree/main/old/version-1.000/

(Also I guess I did not see Timothy's reply for some reason, so that
probably seemed even more confusing as a result. But I do think that the
repo looks like what would have happened when a designer donated SFD
sources as a drop, back in the day, rather than maintaining it actively in
any VCS. The .glyphs sources in the ./sources/ directory are certainly
conversions, as the git history notes.)

Nate

Yes, the googlefonts version does not have it and that is why I suggest
they are probably violating the license.

So, from further reading in the thread, it sounds like you're suggesting
not that Google Fonts merely redistributed an RFN-covered font binary with
a functional difference (which would be an RFN violation), but that
somebody at Google Fonts actually altered the text of the license. That's a
considerably more egregious offense.

The more plausible explanation is that Google Fonts asked him to remove the
RFN clause as a condition for including it in Google Fonts. That's
consistently been the standard procedure, and back in 2010 Google Fonts was
not doing the whole rebuild-from-source in CI process.

I haven't been able to find a Wayback Machine link (yet) that first links
to a downloadable binary from the Google Fonts site for comparison. But
considering that Cardo was one of the very first 10-12 fonts on the
service, that's a lot of searching. It might be faster just to ask Google
Fonts people.

Nate
--
nathan.p.willis
nwillis@glyphography.com

The reserved-name restriction is on the metadata of the sources Google
Fonts derived from the TTF, but when Iooked at an old version of the Google
Fonts API website, it just hyperlinked the to the OFL itself. I think a
likely scenario is simply that that the site/project structure resulted in
folks loosing track of the reserved name requirement over time.

If you look at the author's website, he writes favourably about getting
selected by Google Fonts but later complains about websites that remove
less-frequently-used characters from his font in violation of the Reserved
Name claus. From a quick look at Google's FontForge source files, I don't
think they were a culprit on that front in 2010. If anyone knows who the
first hand to touch the font for Google Fonts was, it would be great to ask
whether those initial 2010 changes (version increment of .001 likely
corresponding to optimizations for web and file size without removing
characters) were done in coordination with the author.

At any rate, my two-cents as someone who is very much not in charge here
are that reverting to the exact version of the font currently shipped on
the author's website was exactly the right call but that worrying about
only having the TTF as both source and binary is unnecessary given that
this "binary" was perfectly adequate for Google to use as source for their
questionable changes and most likely also the source for the fellow who has
extended the font under another name in the TeX community.

Regards,
Timothy

On Wed, 12 Aug 2026, 9:23 am Nathan Willis, <nwillis@glyphography.com> wrote:

Google does not operate under DFSG, so it is okay for them to treat TTF
as source even when there is an unpublished (other format) source. That
is not okay for Debian. The manual clearly states that the source is in
VFB format.

Please do not point to other packages where similar things are the case.
This was handled very sloppily for some time unfortunately.

I think you misunderstood me. My point was NOT that the Google font or the
CTAN fbb package are examples of appropriate source inclusion. I know full
well that both of those organizations have their own admission standards.
Rather my point was that having only TTF and not VFB is not an actual
barrier to people wishing to edit the font the way having only binaries of
an application would be. People both can and *have* used the TTF to edit
this exact font multiple times.

My understanding is that that if someone converted the TTF to a FontForge
project tomorrow, made a few changes, and submitted it to Debian as a new
font, that would be admissable as long as they included the FontForge
source files that they, as the new upstream, were working from. And that's
even though those new source files would contain hardly any information not
already in the TTF here. That's where I think strictly demanding that every
existing package must have original font-editor files gets a little silly.
Insisting that people never ever ignore and omit available font-editor
files is supremely reasonable, but treating a font as something in the same
category as a binary assembly blob if it never ever had that kind of
sources publically available despite multiple people happily editing it
from the TTF seems to me an unnecessarily narrow reading of "include source
code".

https://wiki.debian.org/Fonts/PackagingPolicy does not yet say *anything*
about font source code and in fact gives and example of a font where the
upstream consists of nothing but a TTF.

https://wiki.debian.org/Fonts says that fonts should be built from source
but makes no explicit ruling that only fonts with specific types of source
are admissable.

Regards,
Timothy

Quoting Timothy Gaskell (2026-08-13 03:25:10)

Technically, anyone can decide for themselves what they treat as source
format.

Legally, the copyright holder of the former project may or may not have
restrictions about availability of source for derived works of theirs,
and if they do then *their* preferred form for source is what counts,
not whatever form I or you prefer for source of our fork.

 - Jonas

Hello,

Bug #1128206 in fonts-cardo reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/fonts-team/fonts-cardo/-/commit/47f98c4cc89cb27803680af6d8c403845c561026

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1128206

An OpenType glyph table (glf, CFF, or CFF2) is fine as source for glyph
contours, because it is simple Bezier geometry. This is true not just for
for Google Fonts, but for other projects — including the TeX derivative
font project already mentioned.

There is not a "human readable" representation of Bezier curves; they are
(x,y) point sequences. You can see the same thing in SFD, Glyphs, UFO, or
any of the font-editor file formats that are not, themselves, somehow
obfuscated or encrypted.

There have been encrypted file formats in the past, such as .EOT, for which
that would not be true. This is not that. One can also compare how the
Bezier curves are stored in OpenType files to how they are stored in other
formats, like SVG.

That fact, that the curve geometry is already in the form needed to read
and modify it, is why OpenType fonts are acceptable as source. _Not_
because we can cite examples of people already doing it(*), but _because_
that's what the actual file contents are. The proof that it works is that
all font editors can open .otf/.tt/.otc/.ttc files without issue or
ambiguity. They use the contour geometry, exactly as FreeType or whichever
other renderer is involved. There isn't a "lost" representation of which
the glyph table representation is a mere bad copy.

It's conceptually possible that the VFB files contained material that did
not make it into the final .ttf or .otf, such as un-exported layers. But
those, by definition, are not required to generate the resulting file. And
also by definition, there is no way of knowing if they existed by examining
the final output. They are akin to comments, which could prove helpful and
interesting to later developers if they exist, and are always nicer to have
than to not have, but they are not necessary to generate bit-for-bit
identical output files.

The same is true for overlaps, if there was a "remove overlaps" stage as
part of the build process. If there were any that were removed at export,
then by definition they are not required to reproduce the output. That,
too, is speculative; there may not have been any. Finding some might prove
a convenience to future designers, but a convenience only.


Conjecturing about what other people did in the past is not a useful
strategy and does not solve any problems.


Please do not point to other packages where similar things are the case.

I'll do as I wish.

Nate


* – Although that is demonstrably the case and has been for many years.

metadata of the sources Google Fonts derived from the TTF" here; maybe it'd
be fastest to just be totally explicit about the files being discussed. To
summarize what I see in the various sites:

Location: https://github.com/googlefonts/CardoFont/blob/main/
** this is what the GF build system uses as its upstream
- OFL.txt -> does not assert RFNs
- old/version-1.000/Cardo-Regular-TTF.SFD: version -> does not assert RFNs
- old/version-1.000/Cardo-Italic.otf: version 001.001 -> does
not assert RFNs
- old/version-1.000/Cardo-Bold-TTF.SFD: version 1.0011 -> does not assert
RFNs
- old/version-1.000/Cardo-Italic-TTF.SFD: version 0.991 -> does not assert
RFNs
- old/version-1.000/Manual104s.pdf -> asserts RFN on "Cardo"
  - refers to the font package as 1.04; that seems to mean the entire bundle
- sources/Cardo.glyphs -> does not assert RFNs
- sources/Cardo-Italic.glyphs -> does not assert RFNs


Location: https://github.com/google/fonts/blob/main/ofl/cardo/
** this is what the GF build system uses in CI/CD
- METADATA.pb -> does not assert RFNs
- OFL.txt -> does not assert RFNs
- upstream_info.md -> does not assert RFNs
  - also claims that the .ttf files were not built by the GF CI/CD system
and were provided by David Perry
  - worth noting that this "upstream info" file itself is autogenerated and
seems to come from some AI tool
- Cardo-Regular.ttf: version 1.0451 -> does not assert RFNs
- Cardo-Bold.ttf: version 1.0011 -> does not assert RFNs
- Cardo-Italic.ttf: version 0.991 -> does not assert RFNs


Location: https://scholarsfonts.net/cardofnt.html
** this is the designer's site
- site itself: asserts RFN on "Cardo"
- archive file download: https://scholarsfonts.net/cardo104.zip
  - Cardo104s.ttf: version 1.045 -> asserts RFN on "Cardo"
  - Cardob101.ttf: version 1.001 2005 -> asserts RFN on "Cardo"
  - Cardoi99.ttf: version 0.99 -> asserts RFN on "Cardo"
  - Manual104s.pdf -> asserts RFN on "Cardo"


There are also trademark claims for "Cardo" in the name tables and "all
rights reserved" copyright statements in some places, in every location.

So the only place I have found the RFN assertion in the GF repository is in
the PDF.

Based on the thread, I was expecting to see it in other places, but unless
it's somewhere I didn't find it, it seems like it's just that manual. I
think that it's plausible that the PDF was not rebuilt just for its
inclusion in the repository and was simply the same one from the designer's
site.

The fact that all of the font files in the GF repositories have their
version numbers incremented by a "1" suffix (as you noted) and the fact
that all of those files have the RFN assertion removed supports, in my
view, that the designer built a separate set of files to send to GF with
the only change being the RFN removal. (Amusingly, the "1" is a different
precision level on the Italic....)

For instance, there are OTL features in the font files that the GF service
does not support, so those were not stripped out at the same time.

That was the standard practice, and I think the sum total of the fields in
the fonts supports that as the most plausible conclusion. GF has been
opposed to including RFN-laden fonts going all the way back, because the
clause triggers renames on subsetting (not just rebuilding-from-scratch).
And subsetting gets does whenever the files are requested by a page in CSS.

I sent an informal message about this and was told by in-the-know folk that
the "font file" should be regarded as authoritative. Although I didn't
specifically ask about the PDF manual, since I hadn't looked at that yet at
that point.

It'd certainly be possible to open an issue on GitHub and ask; someone who
could either speak firsthand about the intake of the font or who has a
record of the email exchange could then post something in a public location
that would clear up mysteries about what happened back then.

Or maybe there's some other way to get in touch with the designer.

In any case, it doesn't seem like there are other differences between the
available files.
Nate

I stand corrected. That is the file I thought I saw an RFN in when was
comparing with files from scholarsfonts.net, but I can see now I was
mistaken. My apologies for reading diffs and such badly. I think your
analysis here is very good.

Regards,
Timothy

We believe that the bug you reported is fixed in the latest version of
cardo, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1128206@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Bastian Germann <bage@debian.org> (supplier of updated cardo package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sat, 15 Aug 2026 18:19:55 +0200
Source: cardo
Binary: fonts-cardo
Architecture: source all
Version: 1.04-5
Distribution: unstable
Urgency: medium
Maintainer: Debian Fonts Task Force <debian-fonts@lists.debian.org>
Changed-By: Bastian Germann <bage@debian.org>
Description:
 fonts-cardo - font for scholarly use in classical and medieval languages
Closes: 1128206
Changes:
 cardo (1.04-5) unstable; urgency=medium
 .
   * Team upload
   * Move to contrib (Closes: #1128206)
Checksums-Sha1:
 be7b1c401742be51fb4832634e62c8fc55f79dd6 1741 cardo_1.04-5.dsc
 0c7a905af8bdc7ad245fcf83b3b2a4c87d0aa7b0 4320 cardo_1.04-5.debian.tar.xz
 7a83bf7fd38fa7fbcf6bf67d44fd30c36a4842d5 5796 cardo_1.04-5_amd64.buildinfo
 cb7cc3f39bb0853ed5bcfc9b0f5677bdf3c3312d 495876 fonts-cardo_1.04-5_all.deb
Checksums-Sha256:
 3b34f10ec470b3ecc9ea98eba3cb6dc6d0e9a1f06618104e182e802e070ff8ff 1741 cardo_1.04-5.dsc
 edfc84e7c7afea5ea26c69a264db3fab854fb66713ec805af9bde908753c8304 4320 cardo_1.04-5.debian.tar.xz
 2cf39a08d4f929117b32adcb8fffe0843e9f687fd7773ac6bcdd4b38cf5a71a4 5796 cardo_1.04-5_amd64.buildinfo
 419e5462797e91554fd3311ede3dd9ada1ace88541862bb1965d5a0fc8767463 495876 fonts-cardo_1.04-5_all.deb
Files:
 077c1eb1ab77f1a5301ee8379e0cc237 1741 contrib/fonts optional cardo_1.04-5.dsc
 b9035c4b5b8e12ae697f97ee8b872d37 4320 contrib/fonts optional cardo_1.04-5.debian.tar.xz
 0502bdc617334da6c4e641a008dd45ae 5796 contrib/fonts optional cardo_1.04-5_amd64.buildinfo
 9d7bb6ccedf5d1690ebbf73c80b20f01 495876 contrib/fonts optional fonts-cardo_1.04-5_all.deb
-----BEGIN PGP SIGNATURE-----

iQHEBAEBCgAuFiEEQGIgyLhVKAI3jM5BH1x6i0VWQxQFAmqAkeEQHGJhZ2VAZGVi
aWFuLm9yZwAKCRAfXHqLRVZDFCBuC/41hiwAXkmi0rkgUaoACt8eaVeFu+ok3kEt
1kmsNYOB+4ooE5Xbym96tdRCpqluOwbGrsJaO/7uN2SvjeL7GhXy2TrpEpKnrVSB
vu5HeKPFsf7540Xkb+nIp/ZAlobeTjOgX5kCw+3MjhT9aegw1z0Wa1Ea5O91c1Q1
cUQz2EBQnNcxL2hYjULMeQaTFyRDW3xP1H4cCHZOyUsI7lg5ErCaPFDk6sK9Usoe
XAeMgiZezPsNYm02tuVSvbyWY+MF1dVEUxyPnLHyxeseezJO27pBHguHwH+vhN0s
1k4lsxvzBEh6mSuzoD3n7Cyx4MKJ+LFGR4WQxktdSrIRj1226hxoq/uv/QxlEZYn
4Ut8+Nz0LtAggLiL3WT3KtizgzqDt0qVLtD33dCOKqLZmlCwCfLXV7XENhsjB9yD
OxyWDH5WNY6Y9HoTZI0C12DSc4qOSLz0NM2sCTotyS+HeeezH3tsBMMa1a090dvK
zm8IMStjedF9UqwHTIhV5NKabHlBJSE=
=IN1+
-----END PGP SIGNATURE-----