[ Note that we decided to include the debian-devel list in our reply, as this issue seems to have already found a wider audience, which we want to invite to this discussion too. Please stay ontopic and away from ranting about Ubuntu/Canonical/Whatever, gains nothing for anyone, but help to resolve the issues at hand. Thanks. ] On 12462 March 1977, Paul Sladen wrote: > Hello all, I've see the following message to pkg-font; (at the moment > I'm on a quest for information and not seeking to take a viewpoint): > "[Pkg-fonts-devel] ubuntu-font-family-sources_0.70.1-1_amd64.changes REJECTED" > http://lists.alioth.debian.org/pipermail/pkg-fonts-devel/2011-April/006515.html Yes. Turns out there was a slight misunderstanding on our side. It was believed that a prod message containing an explanation had already been sent out before the reject happened, so the reject was more concise than it should have been. > Juliank has forwarded the above to a bug report: > "Naming restrictions in UFL considered non-free by Debian" > https://bugs.launchpad.net/ubuntu-font-licence/+bug/769874 Heck, thats large already. Oh fun. > and tried to guess/interpret. The email above notes a "discussion in > the FTP Team". Would you/FTP master be able to provide a summary of > the that discussion and add it to the bug report (LP: #769874)---this > would make it easier to pass on to right people and flag up that > there's a serious issue if there is one. "To post a comment you must log in." - Sorry, but no, thanks. If there would be a useful mail interface given (asking on IRC got one, but it needs registered mail addresses which just sucks), sure, but we are not jumping through extra hoops here. Please pass this mail to wherever it should end up additionally instead. > If it's helpful, there's a diff against the SIL OFL at: > http://font.ubuntu.com/ufl/ofl-1.1-ufl-1.0.diff.html > and there is a FAQ about the interim status/changed from the SIL OFL > at (if for TL;DR, there are 9 bullet points at end): > http://font.ubuntu.com/ufl/FAQ.html > Some people on #debian-devel have raised versioning interaction with: > http://www.debian.org/social_contract.html#guidelines (4) > "The license may require derived works to carry a different name > or version number from the original software." > For clarity, I don't think the aim in developing an open/libre font is > to distribute it under a non-DFSG licence! Thus, it would be useful > to be take an FTP master summary back, to the people who can further > deal with it and to be able to hold up the individual points > specifically. Ok, well, lets try. The definitions include ---------------------- "Substantially Changed" refers to Modified Versions which can be easily identified as dissimilar to the Font Software by users of the Font Software comparing the Original Version with the Modified Version. ---------------------- What constitutes "easily identified as dissimilar"? Is it necessary to check all characters in the font and if so, what check is meant? Is it different if the md5sum of the font file is different? Is there a set of special characters to check? We actually doubt there can be an agreement when a font is dissimilar for users, not with that text. Typographers would likely see something as dissimilar where most users (us included) would see no difference at all. Taken alone this may not be a show-stopper, but the definition is used later on in such a way that the lack of clarity becomes a major issue. §1 seems ok, except for some curiousity about the definition of "easily viewed by the user"? Is a "strings font.ttf" easy? Or does it need to be some kind of ttf viewer app? Does one need to make sure there is one for all the platforms one intends to distribute? That might be a FAQ entry somewhere, but that curious part just had to ask it. This is not a reject reason though. §3 sounds ok to us. §4 in itself is free, even though it does take away even the authors possibility to dual-license a work, should one chose to use this license. Harsh, but nothing keeping it out of the archive. So, the interesting part is §2, which is why it is listed last. And as a short summary: We think that aspects of this section make the license unsuitable for works in Debian main. Taking §2b first. This subsection is in itself ok, DFSG 4 does allow to require a different name for a distribution of modified version, although "similar names" seems to be a bit of a gray area. The major issues arise in subsections §2a and c. These two subsections include between them an invariant section. This type of invariance is not something covered by DFSG 4. DFSG 4 tries to allow a copyright holder to say "If you change foo, you must not call it foo", but does not have similar provisions to allow a copyright holder to say things such as "You must not call foo by any other name" or "If you change foo, the name you must use is bar". Especially noting the parenthetical statement at the end of DFSG 4, we don't believe it would be in the spirit or intent of the DFSG to make the leap that would be required to say that §2a and c are allowed by this clause. The vote[0] taken by the Debian project relating to the GFDL also reinforces the project's dislike for invariance in main. It is also unclear as to whether "font name" refers to the name of the font file on disk, the package name, some form of internal font name or a combination of these. If the reference is to the name of the font file or the internal font name, this becomes a restriction on how you can modify the software, which also fails to comply with DFSG 3. Additionally §2c states exactly how you must change the name to follow the license, which will cause issues if you want to combine multiple fonts licensed using this license into a new derivative work, possibly even making this impossible. This on its own is not a reject reason. [0] http://www.debian.org/vote/2006/vote_001 Note that, while researching (basically reading IRC and bug logs) we found claims that the preferred form of modification of those fonts are in a format that is currently not able to be processed with tools available in main. Remember that main needs to stay self contained, and that it needs to be able to build itself. What we can read in the current font tarball about the tools used does not seem to ensure this, as it points to some "Free-as-in-beer" programs to process the source, as well as some Commercial tool. And the build process description also uses those tools. If the fonts get released under a free license, that would put them into contrib only, not main. (Yes, we know that there are fonts in Debian that only ship .ttf files. To the best of our knowledge they are modified using ttf editors and ttf editors are available in Debian main. This font family here is pretty clearly not modified using ttf editors and therefore this doesn't apply here). -- bye, Joerg That's it! You people have stood in my way long enough. I'm going to clown college!
Attachment:
pgpcE5_JpS8QX.pgp
Description: PGP signature