freetype: disable patent-encumbered code by default

[ttuegel]

The Infinality patches were enabled by default, but they enabled patent-encumbered code (subpixel rendering).

I have also added myself as maintainer, since noone else was listed.

[bluescreen303]

as far as I know subpixel rendering itself is ok.
It's just specific implementations (Microsoft ClearType) that are patented.

The effect of disabling these patches by default would be that enabling them (as a user) leads to massive local rebuilds of almost any gtk/qt package on every upgrade.

[ttuegel]

@bluescreen303 Freetype has a page dedicated to this:
http://www.freetype.org/patents.html

The subpixel rendering code in Freetype uses color filter technology that the authors believe is encumbered by the Microsoft ClearType patent. This is the code enabled by Infinality. It is also the exact same code enabled if useEncumberedCode = true here.

The NixOS wiki has a page describing how to use a patched Freetype without rebuilding everything: https://nixos.org/wiki/How_to_enable_subpixel_rendering_in_freetype
The instructions were designed for useEncumberedCode only, but you can do the same with useInfinality also.

[edolstra]

@vcunat, you added Infinality support, what is your opinion on this?

[bluescreen303]

Those instruction will probably give a messy system as there is no way to update the environment on upgrades (nixos-rebuild switch) apart from logging out and back in again. Not doing this will lead to newly started applications trying to use the old version of freetype. To make matters worse: this old version can be garbage collected (as there is a new version available and the current (but not yet activated) environment points to that). So the workaround is a no-no for me.

But if there is indeed a legal issue I will turn to building stuff locally.
Although I'm pretty sure pure software patents aren't really valid in most non-US countries.

[ttuegel]

Although I'm pretty sure pure software patents aren't really valid in most non-US countries.

It would be nice if Nixpkgs/NixOS could legally be distributed it the US.

[vcunat]

No, from what I found before, infinality should be a patent-free alternative to the other patent-encumbered color filtering in freetype. I'm no lawyer, but I believe the state is that infinality provides that custom color filtering mentioned in http://freetype.org/patents.html (in fact you can override the parameters by env vars).

[ttuegel]

@vcunat Infinality doesn't implement a new filter algorithm, it just lets you adjust the parameters to the existing one. Freetype already ships with three presets ("default", "light", and "legacy"). Infinality merely lets you customize the default filter parameters, it doesn't implement a new algorithm. I'm not a lawyer, but that can't be enough to circumvent the patent.

[vcunat]

Quoting from the link above:

Note that subpixel rendering per se is prior art; using a different colour filter thus easily circumvents Microsoft's patent claims.

[ttuegel]

Infinality doesn't use a different color filter.

The patent-encumbered Freetype color filter algorithm takes 5 numbers as parameters. Infinality lets you change them at runtime, but you can always change them at compile time. Those input parameters are not the subject of the Microsoft patent. The algorithm itself is the subject of the patent. Infinality doesn't change the algorithm. Infinality doesn't even change the parameters by default. Can you cite some other source for why the Infinality patches aren't encumbered?

[vcunat]

The patch is huge and does add new algorithms (I skimmed it now again). Whether it uses some patented stuff is hard to say, especially for people like me who don't know the insides of freetype. Browsable updated version of the patch (we use older but analogical): https://github.com/bohoomil/fontconfig-ultimate/blob/pkgbuild/01_freetype2-iu/infinality-2.5.3.patch

Anyway, it might be dangerous to use anything similar to ClearType, I don't know.

I'm just trying to work out a good way of allowing the user to choose without rebuilding everything. Having a global lib override is a fragile solution, and per-package wrappers are cumbersome. From patent point of view, any idea whether it is a problem if you have the algorithms compiled in but subpixel rendering is disabled?

[ttuegel]

Sorry, I wasn't trying to say that Infinality doesn't add new filtering algorithms. (I realize now that's how it came out.) Infinality's filters are all in addition to the encumbered subpixel color filter that comes with Freetype. Infinality doesn't replace the encumbered filter. In fact, the patch intentionally enables it.

It's pretty easy to figure out where the encumbered filter is by grepping for FT_CONFIG_OPTION_SUBPIXEL_RENDERING. There are primarily two blocks of code where it appears; once where the color filter is defined (in src/base/ftlcdfil.c) and once in the renderer where it is used (in src/smooth/ftsmooth.c). You can see from the link you posted that the Infinality patch does nothing in either of those places to replace the encumbered filter.

[vcunat]

It seems you are right. To get more confidence I asked upstream, as I found practically no mention of patents around there http://www.infinality.net/forum/viewtopic.php?f=2&t=346.

If we are to switch the default behavior soon, I would do it at once with major freetype update.

[bluescreen303]

on a sidenote: microsoft also claims to have patents on various techniques used in the linux kernel.
Stupid things like the FAT filesystem and long filenames, but other things as well. They bully companies (android device makers among others) into paying for their use.
We better remove these uses as well then!

[vcunat]

@bluescreen303: if it can be split into a loadable module... perhaps we should introduce "I'm afraid of patents"-switch in nixos for such things. Most common users will want to have FAT because of USB keys and memory cards, and they are at a low risk when infringing SW patents, especially inside EU.

[bluescreen303]

Most users also want decent font rendering, especially with higher-resolution displays,
Indeed, providing a limited US-only version which does not include any possibly-patented stuff might be the best option so everybody else can keep a functioning system.

It would indeed be nice if we can manage to do this without (US or other) users having to build everything themselves though. Perhaps a different channel can help?

[vcunat]

I certainly don't want to duplicate each build on Hydra. BTW, the value of subpixel rendering decreases when your DPI increases as it's common nowadays (the "retina" trend, FullHD on phones, etc.).

[vcunat]

Right, I propose to use replaceDependency to avoid rebuilds (the stuff is supposed to be ABI-compatible).
https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/replace-dependency.nix

Reasons:

• global library overrides are fragile (mismatching versions, etc.);
• wrapping everything sucks, and each machine will typically use only one of the two possibilities (with or without subpixel rendering);
• it's fast -- it stresses HDD most.

I didn't look yet much into the details of replaceDependency implementation; we may want to improve it when used so massively. If this is agreed, two questions remain:

• Will the rewriting be done on Hydra? (double space usage, otherwise probably negligible additional build time)
• If not, we have to do it on clients and it becomes important which way we do the rewriting? (most will want patented stuff, but that way others would have to download the patented binaries to get the patent-free ones, which might be illegal)

[ambrop72]

How about enabling patented code by default but not distributing it via the cache? Nix will build it itself when it fails to get a cached build, so it's transparent except for a few minutes of compiling. Or just not distributing it to clients in the US.

[ttuegel]

@ambrop72 That's probably safe. It's basically equivalent to what Gentoo does.

@vcunat I could adapt this patch very simply to do that. I don't think it would cause a rebuild for anyone who already has Freetype, and it would stop redistribution immediately. Should I amend the pull request?

[vcunat]

@ambrop72: I don't understand what you mean:

• Almost all packages with GUI depend (transitively) on freetype. AFAIK Hydra only distributes transitively closed sets, so it would mean we would distribute practically no binaries.
• How would this allow to get people a patent-free setup? I don't think there is need to only distribute patent-free binaries. The patented stuff can get downloaded only if one triggers it with an explicit switch.

[ambrop72]

@vcunat I think the only issue regarding patent encumbered code is that NixOS may get into a legal dispute if it distributes patent encumbered code. My proposed solution obviously solves this problem (and would be an exception to Hydra distributing only closed sets).

How would this allow to get people a patent-free setup?

If anyone wants or needs to avoid the patent encumbered code, he can still override the flags and rebuild (and/or use the LD hacks people currently use to enable the encumbered code). But I believe only a minority of NixOS users want a patent free setup, and it doesn't make sense to support the minority better than the majority (by providing patent-free builds but not patent-encumbered builds).

[ambrop72]

Additionally, if we agree that enabling patent encumbered code by default is all right, it might be a good idea to disable Infinality and use the other rendering code (whatever useEncumberedCode=true useInfinality=false does). It results in much nicer fonts than the current default (Infinality).

[vcunat]

As mentioned above, currently the default rendering is as freetype upstream. You need to switch infinality on with env vars. What is better is highly subjective; infinality has the advantage of allowing you to tweak the parameters (or choose from a few defaults, e.g. mimicking Windows, etc.).

[ttuegel]

@ambrop72 We definitely do not want useInfinality=false by default. The Infinality patches are disabled at runtime unless you set Infinality's environment variables and enable Infinality in Fontconfig. Now, we really need to decouple fontconfig-infinality from freetype-infinality, which I am working on a patch to do, but that's a separate issue.

[ambrop72]

Unimportant note: the nix expression for Freetype seems to be confusing between licences and patents: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/freetype/default.nix#L68

Enabling patent encumbered code doesn't change the licence of Freetype. It's still GPL/FTL. Maybe we need a way to track patented code in the metadata as a separate field? Such a feature could then be used to prevent distribution by Hydra.

[vcunat]

• Unfree licenses: I think the current only meaning of license = "unfree" is that Hydra.nixos.org doesn't build it (and thus doesn't distribute it). That's why it's used for that purpose, and IMO redistribution restrictions is what matters most for us in nixpkgs (note that currently nix-copy-closure and similar don't take this into account). EDITed not to claim incorrect stuff, thanks @edolstra.
• Other problems: This reminds me... I think Hydra has binaries for many other problematic packages and stuff depending on them. For example libdvdcss -- distributing such "circumvention tools" might be a problem in much wider range of countries, including EU ones. http://en.wikipedia.org/wiki/Anti-circumvention
• Nix(os) is no legal entity, so the problem would probably fall down to the university running Hydra (a nice repayment for their support). Moreover, @shlevy mentioned none of the most active developers is employed by that university anymore (!)
• Suggested solutions: is it even legal (worldwide) to distribute nixpkgs? If it's a tool that creates (downloads and builds) law-breaking code? In any case, I don't think we are truly fit to decide by ourselves what is and what isn't legal to distribute (worldwide). If we want to be safe, I can only think of adopting decisions made by some companies that take this seriously (e.g. suse AFAIK).

[edolstra]

• Hydra does not build packages that depend on a package marked as unfree.
• The nature of software patents is such that almost any non-trivial piece of software infringes upon some patents. If you worry about that too much, you shouldn't be distributing any software.
• It doesn't matter whether Nixpkgs is legal everywhere. What matters is whether it's legal in the Netherlands (and maybe Ireland, given the location of the nixos.org server). IANAL, etc.
• For the specific case of Infinality, given that (as far as I know) no major Linux distribution uses it, it can hardly be described as essential. So we should probably just turn it off. (Which also gets rid of bugs like Infinality breaks some fonts in Firefox #663).

[ttuegel]

• If the only concern is what is legal for Hydra to distribute, we should enable the Infinality patches, but disable them in fontconfig at runtime by default. AFAIK, EU countries don't recognize software patents, and if we don't care about legality for the downloading user, so be it. Enabling Infinality should be a completely runtime issue, if we don't care about patents.
• I don't think it's fair to compare the risk of infringing unspecified patents on unspecified software, to the risk of infringing patents the upstream author acknowledges encumber his software.

Footnote: Right now, by default, the environment settings for Infinality aren't made, so the patches are mostly disabled, but Infinality's fontconfig settings are left enabled. This is probably the cause of most font rendering glitches on NixOS. As I alluded to before, I'm working on a patch to make it possible to truly disable Infinality's fontconfig settings at runtime.

[vcunat]

BTW, the fact that we use global font configuration has been preventing me from fontconfig update. See e40a059. The problem is that the xml format changed, so the files distributed by default are mutually incompatible. Moreover, when fontconfig finds an ivalid one, it fails to load any config at all (IMO bug), resulting into unusable state. (EDIT: this in turn prevents updating pango and transitively librsvg for a long time.)

[edolstra]

Yeah, fontconfig is bad in that way. I remember a while back programs linked against an older fontconfig would segfault due to a change in the fontconfig cache format...

[ttuegel]

@vcunat Have you considered installing the new configuration files in, e.g., /etc/fonts-2.11 and pointing new fontconfig there? (Should I make a new ticket where we can discuss this?)

[vcunat]

@ttuegel: how simple :-) Thanks! It will probably be best that way, only in nixos I expect we need to install both old and new fontconfig files, at least for some months. Infinality could get a configuration.nix switch, so that the config used was either upstream or infinality. Freetype can then contain infinality code by default, activated by env-vars set by that configuration.nix variable.

(People that don't like patented stuff can solve it by setting an option in packageOverrides and rebuild, or if there was enough interest we could later have some easy-to-use dependency exchanger without rebuilding for such cases.)

[ttuegel]

@vcunat I have such a configuration for Infinality in my personal repo already, as well as a fix for #1827. I just need to clean them up and make a PR.

[edolstra]

Using non-standard paths like /etc/fonts-2.11 is a problem because Nixpkgs is supposed to work on non-NixOS systems, which won't have /etc/fonts-2.11. But it's better to discuss this in another issue.

[shlevy]

Was there a resolution to this discussion? Should this be merged?

[ttuegel]

@shlevy No, this should not be merged.