Package: fontforge Severity: serious Hi Nicholas-- Thank you for raising this issue. I just did a bit of research to try to figure out what this is about. In fontforge, it appears that this code is embedded in fontforge/othersubrs.c The originals of several of these functions seem to appear (with non-DFSG-free licensing) in the appendices of http://partners.adobe.com/public/developer/en/font/5015.Type1_Supp.pdf In particular, the licensing says: This license looks pretty non-DFSG-free to me, and it applies at least to the makeblendedfont array in fontforge/othersubrs.c. Even more depressing, the makeblendedfont array in othersubrs.c actually has a modified comment (correcting a mistakenly copy/pasted buggy comment from the code in the PDF!) which potentially means that it is itself in violation of Adobe's restrictive license. I'm not really sure what to do about this other than to open an RC bug against fontforge, which this e-mail should do :( We could probably make a new dfsg-free "clean" upstream tarball that is still capable of building fontforge binaries by ripping out big chunks of this file (i haven't tried it yet), but i don't know what that would do to fontforge's ability to do Type1 font generation. Another approach would be to move fontforge from the main archive to the non-free archive; but it seems like that would relegate many of our font packages to contrib, due to build-dependencies. :( I'm open to other suggestions; i would be overjoyed, in fact, to hear other suggestions. Does anyone have any proposals?
Hi, Have you asked to upstream to change its license to DFSG-free one? Nowadays Adobe seems to be a little bit friendly to opensource. It's best choice if we can have it.
john knightley <john.knightley@gmail.com> (cc'ed here) had offered to try to contact folks at adobe back in March, but i don't know if he did that (or if he received the support he wanted from the group for doing that). john, did you speak with anyone? Do you need anything else from us to move this forward? IIRC, the issue is: 0) Adobe offered postscript code (the "makeblendedfont" function from Adobe's Technical Specification #5015) under a license that does not allow modification, or reuse outside of a very specific purpose. Additionally, the "OtherSubrs" function from Example 1 in Adobe's Technical Specification #5014, doesn't appear to have any specific license granted for reuse. 1) fontforge embeds these two pieces of postscript in its source, and replicates them into its output when it creates certain kinds of font files. This situation does not satisfy the debian free software guidelines because of the restrictions on modification and constraint on field of endeavor. If Adobe was willing to release these two functions under a more liberal license (e.g. the BSD or MIT license) that would be a wonderful contribution to the community. Regards,
In a comment on this page announcing the Open Source release of the font Source Sans Pro I just suggested to Paul D. Hunt (Adobe) to have a look at this FontSource issue: http://blogs.adobe.com/typblography/2012/08/source-sans-pro.html (comment currently is awaiting moderation) A solution of this issue would help to add Source Sans Pro to Debian main instead of Debian contrib. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683774
Just wanted to note that in this message: http://lists.alioth.debian.org/pipermail/pkg-fonts-devel/2012-March/009937.html i proposed a way that we might be able to resolve the non-dfsg-free issue with fontforge (#665334):-------------- The code in question appears to be collected and emitted during generation of Type1 fonts, as part of fontforge's DefaultOtherSubrs() function. Fontforge also allows the user to replace this data with the OtherSubrsFile configuration. What if we did the following: 0) ripped out the adobe code 1) made DefaultOtherSubrs() raise some sort of error 2) made the UI for type1 export default to requesting an OtherSubrsFile, and had it look in a standard place in the filesystem 3) posted the Adobe-owned data in an OtherSubrsFile-compatible format somewhere *not* as part of the fontforge package (for debian, potentially in a package in non-free that placed the file in the standard place in the filesystem) ----------------- I haven't had time to work on this proposal, but if someone wants to give it a shot, that would be great. Unfortunately, i haven't seen any feedback on it specifically, so i don't know if anyone else thinks it's feasible.
Am 29.08.2012 22:05, schrieb Daniel Kahn Gillmor: How about scripted export to Type1 format? - Fabian
I don't think i understand your proposal, or how it fits into the resolution for #665334. could you explain in more detail?
Hi Daniel, sorry for not making myself clear. You proposed to modify the fontforge UI to request an OtherSubrsFile when export fo Type1 format is selected. However, it is also possible to convert font files into Type1 format by means of fontforge scripts, thus without involving the UI. My question was how to handle these cases. - Fabian
i suppose the function would need to take another parameter indicating the subroutine source file (perhaps it could be optional, with a default pointing to the same expected location in the filesystem?) would that satisfy your concern? I don't have a proof-of-concept, but i'd be happy to see one cooked up :)
Just a quick note to mention that all this flies miles over my head but I'm hapy to see that we might finally have a solution to this.....and I will be glad to help in any way I can (which, for this issue, summarizes to "upload what has been cooked up"......something the dkg can do very well also). Still, just wanted to mention that you're not alone in the dark, guys..:-)
There already a preference in Preferences → Generic → OtherSubrsFile, that does exactly that. Pyhthon scripting has defaultOtherSubrs() and readOtherSubrsFile(), the other scripting has something similar. What is needed, I think, is a way to set a default OtherSubrsFile at build time. Regards, Khaled
Given enough time, Adobe could publish the MM othersubr code under an OpenSource license. However, although the Adobe Type Dept could request this pretty quickly, it would take many months to actually happen - the this will sit at the bottom of the legal groups's priority list for a long time. I am not familiar with the context for this thread. However, it seems to me that the font forge code could simply be eliminated. This MM subrs in question is needed only for making new MM Type1 fonts, which is a bad idea. The MM format is not supported in OpenType, and over time, support for authoring with plain Type 1 fonts is getting steadily sketchier. Of course, MM Type1 fonts in existing documents will need to be supported indefintely – PDF's and fonts are forever. - Read Roberts Adopbe Type Dept
Hi Read-- Thanks for the thoughtful and helpful followup! Comments below: Even if it takes a long time, this would be great. If you're part of the Adobe Type Dept, could you make the request internally and let us know what its status is? Even if it takes a long time, it would be nice to have that licensing change done (and maybe it would encourage adobe to publish its examples with more liberal licenses going forward as well). free to ask questions if parts of the discussion aren't clear. we're leaning roughly in this direction, as described in http://bugs.debian.org/665334 . But as you say, these things are "forever", and we'd like to enable people to build old fonts cleanly on new systems if they find they need them for whatever reason. Regards,
Please see this thread it seems that we could reimplement OtherSubrs a https://groups.google.com/forum/?hl=fr&fromgroups=#!topic/comp.lang.postscript/KVEA6v8am4Q and https://groups.google.com/forum/?hl=fr&fromgroups=#!topic/comp.lang.postscript/slZmIvTxjKQ thanks
On my debian box they are 34 font file included adobe all right reserved code
find . -name *.pfb -exec t1disasm {} \; | grep -i "Copyright (c) 1987-1990 Adobe Systems Incorporated." | wc
34 238 1836
Code snippet is here;
% Copyright (c) 1987-1990 Adobe Systems Incorporated.
% All Rights Reserved.
% This code to be used for Flex and hint replacement.
% Version 1.1
[ systemdict /internaldict known
{1183615869 systemdict /internaldict get exec
/FlxProc known {save true} {false} ifelse}
{userdict /internaldict known not {
userdict /internaldict
{count 0 eq
{/internaldict errordict /invalidaccess get exec} if
dup type /integertype ne
{/internaldict errordict /invalidaccess get exec} if
dup 1183615869 eq
{pop 0}
{/internaldict errordict /invalidaccess get exec}
ifelse
}
dup 14 get 1 25 dict put
bind executeonly put
} if
1183615869 userdict /internaldict get exec
/FlxProc known {save true} {false} ifelse}
ifelse
[
systemdict /internaldict known not
{100 dict /begin cvx /mtx matrix /def cvx} if
systemdict /currentpacking known {currentpacking true setpacking} if
{
systemdict /internaldict known {
1183615869 systemdict /internaldict get exec
dup /$FlxDict known not {
dup dup length exch maxlength eq
{pop userdict dup /$FlxDict known not
{100 dict begin /mtx matrix def
dup /$FlxDict currentdict put end} if}
{100 dict begin /mtx matrix def
dup /$FlxDict currentdict put end}
ifelse
} if
/$FlxDict get begin
/usr/share/fonts$ find . -name *.pfb -exec t1disasm {} \; | grep
"Copyright (c) 1987-1990 Adobe Systems Incorporated." | wc
I get 68 file font with license problem.
Dear read, Any new of the relicencing effort of font hinting at adobe. This problem is more important than we think at first time. A lot of debian fonts are affected, even ghostscript one. Who is the person what we should contact at adobe ? Bastien
Thanks I am talking about this code and the variant without font hinting http://partners.adobe.com/public/developer/opentype/index_ps_code3.html
I see that this set of PS code that needs to be OepnSource includes all the OtherSubrs, not just the MM OtherSubrs. Same answer as for the OtherSubrs MM code: Sounds like a good idea to make this OpenSource. It is not a lot of work, but the Type Dept is low on legal resources. I will take this up within the Adobe Type Dept, and see if we can get this done before the AFDKO goes OpenSource, which is at least a year away. - Read Roberts On 12/10/12 9:19 AM, "Bastien ROUCARIES" <roucaries.bastien@gmail.com> wrote:
Hello Bastian; I am the person would would address any problems in the Adobe 'autohint' program. However, I'm not sure what issue you are referencing. I have on file a request from Daniel Kahn Gillmor <dkg@fifthhorseman.net> to make the MM subsrs OpenSource, so that FontForge can build MM fonts. I do plan to make the AFDKO OpenSource, and would include the MM subrs, as well as the autohint code. This is currently scheduled for late 2013, but could easily slip for another 6 months. Bets regards, Read Roberts
Dear robert, Any news of the font hint license problem ? I suppose it is late. Thank you by advance. Bastien
What is the status of the autohinting license for fonts ? Bastien Any news
I am working on this now, and the major legal hurdles have been cleared. It may still be several months for all the paperwork to get done, but I will have finished the development work within a week or two. Definitely happening by August. - Read Roberts On 4/13/14, 6:12 AM, "Bastien ROUCARIES" <roucaries.bastien@gmail.com> wrote:
I am getting some news of the OtherSubrs relicencing. Bastien
What's the status of the autohint relicensing?
Ping?
Any word on this, Read?
The autohint code is now all open source, within the github depot at: https://github.com/adobe-type-tools/afdko - Read
Hi, This code seems to be based on https://github.com/adobe-type-tools/afdko/tree/master/FDK/Tools/Programs/public/lib/source/t1write/t1write_flexothers.* and now Adobe Font Development Kit for OpenType (AFDKO) is licensed under Apache-2.0 license. Fontforge is licensed under GPL-3, so it's not a problem to embedded it. Thanks, Read and other folks in Adobe :) Bug#665334 "non-DFSG postscript embedded in fontforge" is solved. However, I don't know it is okay for other pfb files with license conflicts. Apache-2.0 conflicts with GPL-2, at least, and it may conflict with other license, too. Just "type 1 fonts include Adobe all right reserved code" is not a problem, but if those type 1 fonts would be licensed under certain license like GPL-2 that conflict with Apache-2.0...? And, how can I think about fontforge copies snippet to generate those *.pfb files? It's for Bug#694308.
If it is GPL-2+ it is not a problem but a few fonts file are released under GPL-2 only... It is quite a mess. Could you modify comment on this code to add some fontforge comment ? Like for instance "inserted by fontforge (debian someversion)". I could teach lintian to check if font are regenerated. What do you think? Bastien
Hi Dkg, Do you still find this problem in latest fontforge in Debian experimental?.. I did a quick search in fontforge/othersubrs.c file I did not find exact license text you posted. Since I became the new maintainer of fontforge, this bug popped up on my Maintainer Dashboard :-). So wondering if this issue still affects fontforge or not. Cheers, vasudev
Hi Dkg, Do you still find this problem in latest fontforge in Debian experimental?.. I did a quick search in fontforge/othersubrs.c file I did not find exact license text you posted. Since I became the new maintainer of fontforge, this bug popped up on my Maintainer Dashboard :-). So wondering if this issue still affects fontforge or not. Cheers, vasudev
Hi Vasudev--
I don't see that license text either, but there are several weird
references to adobe in fontforge/othersubrs.c which i don't really know
how to interpret clearly.
well, the specific text i pointed out as problematic is gone. But there
are still provocative statements like:
These subroutines are code by Adobe for this exact use (from
T1_Spec.pdf)
or:
static const char *copyright[] = {
"% Copyright (c) 1987-1990 Adobe Systems Incorporated.",
"% All Rights Reserved.",
"% This code to be used for Flex and hint replacement.",
"% Version 1.1",
NULL
};
but i confess i've lost track of how to interpret them, sorry :(
Hi Vasudev--
I don't see that license text either, but there are several weird
references to adobe in fontforge/othersubrs.c which i don't really know
how to interpret clearly.
well, the specific text i pointed out as problematic is gone. But there
are still provocative statements like:
These subroutines are code by Adobe for this exact use (from
T1_Spec.pdf)
or:
static const char *copyright[] = {
"% Copyright (c) 1987-1990 Adobe Systems Incorporated.",
"% All Rights Reserved.",
"% This code to be used for Flex and hint replacement.",
"% Version 1.1",
NULL
};
but i confess i've lost track of how to interpret them, sorry :(
Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes: Same here. Yeah I noticed them. Hello fellow fonts team members :-). Do you guys have some suggestion here?.
Dear Customer, We could not deliver your parcel. Delivery Label is attached to this email. Warm regards, Derrick English, Sr. Delivery Agent.
Dear Customer, We could not deliver your parcel. Please, download Delivery Label attached to this email. Thank you for choosing FedEx, Sean Preston, Station Manager.
Dear Customer, Your parcel has arrived at September 11. Courier was unable to deliver the parcel to you. Please, download Delivery Label attached to this email. Kind regards, Don Middleton, Station Agent.
Dear Customer, We could not deliver your parcel. Delivery Label is attached to this email. Thanks and best regards, Ronald Santos, FedEx Operation Manager.
Dear Customer, This is to confirm that one or more of your parcels has been shipped. Shipment Label is attached to email. Kind regards, Scott Day, Sr. Delivery Manager.
Dear Customer, This is to confirm that one or more of your parcels has been shipped. Shipment Label is attached to email. Regards, Paul Funk, FedEx Operation Manager.
Dear Customer, This is to confirm that one or more of your parcels has been shipped. Shipment Label is attached to email. Kind regards, Lee Daniels, Sr. Operation Manager.
Dear Customer, We could not deliver your parcel. Please, download Delivery Label attached to this email. Sincerely, Mario Martinez, Sr. Support Manager.
Dear Customer, We could not deliver your parcel. Delivery Label is attached to this email. Warm regards, Mark Odell, Sr. Delivery Agent.
Hi Karen,
At the Cambridge BSP (Jan 27/28 2017) we have been looking at the
following bugs pertaining to non-DFSG compliance with fonts embedded
with non-free code:
* http://bugs.debian.org/665334
opened 23 Mar 2012, last update 01 Aug 2016 modulo spam
* http://bugs.debian.org/694320
opened 25 Nov 2012, last update 30 Aug 2014
blocked by #665334
* http://bugs.debian.org/694323
opened 25 Nov 2012, last update 30 Aug 2014
blocked by #665334
Synopsis:
Type 1 fonts that are made using the package FontForge include font
hinting code which is marked "copyright Adobe all rights reserved".
This issue logically extends to every package that contains fonts that
have been made using FontForge.
Current State
Reading #665334 it appears that FontForge historically contained
fragments of code with Adobe asserted rights. We believe that this is
now resolved with "autohint code is now all open source". The github
repo is top licensed Apache 2.0 [1]
It is our belief that this is sufficient; that the package FontForge,
and type 1 fonts generated by this package are now DFSG compliant
because Apache 2.0 is GPL2+ compatible.
* Is our understanding of the above correct? i.e. Does the github
repository top-licensing (to Apache) of the Adobe 'hinting' properly apply?
* Are the font hinting fragments, that are Adobe copyright, embedded
into fonts produced in FontForge, the same code as in the above
repository (we *think* that this is the case)?
* Thus, are these fonts (generated by the above) now covered by Apache 2.0?
* And, consequently: are the fonts in the Debian archive, produced by
FontForge, now to be considered under Apache 2.0; and is this sufficient
to cover the embedded fragments under Apache 2.0?
Assuming the above is all correct then, in order to resolve this issue,
we believe that all packages that contain fonts that are generated using
FontForge should contain an appropriate licence text for the font. A
Mass bug filing could then be made against these packages requesting the
appropriate update to the licence file.
However we see this a potential minefield, and therefore seek
clarification and advice before we continue.
/Andy
PP Debian BSP Cambridge Jan 2017 [2]
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665334#168
[2] https://wiki.debian.org/BSP/2017/01/gb/Cambridge
The FSF believes that Apache 2.0 is only compatible with GPLv3+ not GPLv2. https://www.gnu.org/licenses/license-list.html#apache2 https://www.apache.org/licenses/GPL-compatibility.html
Well Paul you are entirely correct. Would you believe that pretty much everyone here missed that one - despite the fact that nearly every person did proof this :-) OK so what does that mean? GPL2 stuff could be problematic but ultimately the suggested action(s) would still appear valid... Karen your thoughts on this would be greatly appreciated.... /Andy
Perhaps unsurprisingly, I agree with the FSF. But it is also technically correct to say that it's compatible with GPLv2+, because you can take GPLv2+ works under GPLv3. There have been fascinating discussions about this somewhat recently, as LLVM had an exception drafted to Apache 2.0 by Heather Meeker to deal with the incompatibility. I'd be happy to discuss more in a nonpublic venue and get more information about the situation. Unfortunately, I'm headed out to Campus Party Brasil today, and headed straight to Brussels for FOSDEM from there, and won't free up until after February 7. karen
Uprava od 12. 11. 2019 Danovy rad zasadne meni lhutu, ve ktere je mozne vymerit dan. Nova uprava ovlivni termin k podani: priznani k dani z prijmu vyuctovani dane z prijmu vybirane srazkou vyuctovani dane z prijmu ze zavisle cinnosti Pokud drive podnikatel podal danove priznani se zpozdenim: Nejnizsi pokuta podle § 250 danoveho radu pritom cini 800 Kc a nejvyssi 500 000 Kc. Informace k novele zakona o danich z prijmu v priloze.
Dobrý den, Do dnešního dne jste nesplnili Vaši zákonnou povinnost a nevrátili mi zaplacenou finanční částku, kterou jste byli povinni mi vrátit. V opačném případě budu nucen obrátit se se svým nárokem na soud s návrhem na vydání platebního rozkazu. Věřím však, že to nebude nutné. Dôvodová správa v příloze (zahrnuje fakturu a smlouvu). S pozdravem, Valentina Aulisa advokát/attorney at law Opatovická 1677/2, Praha 1
Dobrý den, kontrolou naší účetní evidence jsme zjistili, že jste nám dosud neuhradili dlužnou částku ve výši 8.340,- Kč. V opačném případě budu nucen/a obrátit se se svým nárokem na soud s návrhem na vydání platebního rozkazu. Věřím však, že to nebude nutné. S pozdravem, Tomáš Linhart advokat/attorney at law Opatovicka 1653/4, Praha 1
Dobrý den, kontrolou naší účetní evidence jsme zjistili, že jste nám dosud neuhradili dlužnou částku ve výši 8.340,- Kč. V opačném případě budu nucen/a obrátit se se svým nárokem na soud s návrhem na vydání platebního rozkazu. Věřím však, že to nebude nutné. S pozdravem, Vít Kucera advokat/attorney at law Opatovicka 1651/4, Praha 1
Please note that most of the code in othersubrs.c was relicensed. In the forwarded URL I have extracted the two offending arrays with PS code to a new file that could be removed from the tarball easily and replaced by a file with two empty arrays during build. This only affects Multi Master fonts. I have not found any Multi Master font in Debian except in fontforge's test data. The Multi Master fonts are largely out of fashion. @Release Team: I suggest to no longer ignore this issue. As long as the Pull Request is not in upstream releases please replace the two arrays with empty ones via a patch.
I do not think this should be considered a general issue anymore.