Add fields for patent encumbrance and patent license

[rohanlean]

The freedesktop SDK for flatpak by default installs openh264, which is encumbered by patents and in the specific form shipped comes with a limited patent license. Please add fields to specify these.

As an interim workaround I suggested to the maintainers to use:

<project_license>
  LicenseRef-Proprietary=https://www.openh264.org/BINARY_LICENSE.txt
</project_license>

They have requested an "official" blessing for this.

[hughsie]

Software licences are nothing to do with patents. We use <project_license>LicenseRef-Proprietary</project_license> where the project license is nonfree, but should not use the project_license field to indicate software covered by patents. In fact, as a free software developer I don't want to know what software is covered under which patent, and the Red Hat legal team don't want us doing any kind of patent research ourselves whatsoever.

Also, you should note that some of my free software projects are subject to patents that are in the Red Hat patent pool. That doesn't change the license or make them any less free.

[rohanlean]

A agree that the copyright license is independent of patents. In the case that prompted the issue, there are known and seemingly respected patents covering the implementation, causing special care being taken by, for example, Fedora and Mozilla. I think that software that acts based on appstream metadata (such as flatpak) should get a chance to handle such cases with care also, which is why I requested fields for known patent issues and patent licenses.

I suggested to link to a page listing both copyright and limited patent license as an interim workaround, because the documentation of <project_license> did not specify that the field is for copyright only, and because I view the outcome as an improvement over the current situation where known-encumbered software is listed as free.

[nanonyme]

While I agree license is possibly wrong field for this, there possibly should be some way to flag something as being patent-encumbered to allow filtering in clients. Currently we have no good field to put that information in.

[hughsie]

Does the patent situation depend on the end user and distributor legal location? I think this is a slippery slope that isn't a good idea.

[rohanlean]

@hughsie my view is that the more information programs and users have to make a decision that is ultimately in the users favour -- the better. If the applicability of a patent depends on geographic locations then ideally that would be communicated to the user. For example one might choose not to install software if its use plausibly opens one up to a lawsuit while travelling, or choose to install it if it is safe to use in the EU.

There are also distributions that want to help users to install only free software. Unless they add filtering to flatpak based on the proposed tags, installing almost any app from flathub pulls in openh264, which in my opinion cannot be called free:

• Fedora and Mozilla do not distribute it. I do not know if this is to protect users or themselves. In either case the practical freedom of people wanting to make and distribute modifications, or that of people wanting to use them seems plausibly threatened -- at least for some combinations of legal locations.
• Even the distribution of binaries through Cisco, who extend a limited patent license, does not grant users the right to commercial use.

What is the argument in favour of omitting the information? Deniability?

[hughsie]

What is the argument in favour of omitting the information? Deniability?

The opposite. I'm not a lawyer, and don't pretend to be, but I am prepared to listen to what they say.

[rohanlean]

I too would be happy to listen to what they say about this. Will you ask the Red Hat legal team to have a look at this issue?

[hughsie]

Will you ask the Red Hat legal team to have a look at this issue?

I don't think it would be helpful, it would be meaningless for them. It's up to @ximion if he wants to capture patents in AppStream, but this is something I would never support in Fedora. Google "double damages" if you want to see the difference between accidental and wilful infringement.

[rohanlean]

Whom do you want to protect from double damages? If it is the end user, then perhaps it would suffice to design Gnome Software and other consumers of AppStream such that the end users can deny having seen the information -- if they so wish.

If it is the curator of the app data, then she can just omit the field. But if the curator is not also the distributor, then I think that she has nothing to fear for including the information.

[nanonyme]

After digging through appstream documentation, I found out that there's a field "agreement". It currently has eula or privacy types. It seems to me that accepting eula might well be what accepting openh264 binary license implies. I'm not sure there's any support for handling agreement in any flatpak clients but that's another thing.

[nanonyme]

"Fedora and Mozilla do not distribute it." neither does Flathub. Flathub distributes an installer that downloads openh264 from Cisco on end-user machine. Mozilla does exactly the same with Firefox. Based on https://blogs.gnome.org/uraeus/2019/09/23/fedora-workstation-31-whats-new/ Fedora is going to follow suit. The question is mostly whether we're providing sufficient amount of information and control for end-user to satisfy requirements of the license terms.

[rohanlean]

Based on https://blogs.gnome.org/uraeus/2019/09/23/fedora-workstation-31-whats-new/ Fedora is going to follow suit.

Minor correction: Fedora already has an arrangement with Cisco that lets their users download a Fedora build of openh264 from Cisco -- on an opt-in basis. The article mentions improvements to openh264, but no change in this arrangement.

I would like the ability for flatpak clients to also filter openh264 and similarly burdened software out by default. Currently it is automatically installed together with the freedesktop platform. (Causing a separate download of a non-reproducible binary from somewhere else than the flatpak repository, but that issue is perhaps best explained in the <description>, once the automatic installation is disabled.)

[rohanlean]

@nanonyme I agree that an EULA field seems to fit with Cisco's own requirements for distributing their openh264 binary. (If clients would require acceptance of the EULA before downloading the package.) That would also solve my immediate concern with the automatic installation of openh264. OT: can you please pull the package until this or an equivalent solution is fully implemented?

It also occurred to me that Apache-2.0 and GPL-3.0-only are two accepted values of the <project_license> field that refer to combined copyright and patent licenses. So there is some precedent for treating the field value as more than a copyright license. I also think it is fair to call a combined copyright and patent license proprietary if the patent license restricts essential software freedoms; for if there were good reason to believe that no credible patent claim will be made, one could just use the software under the terms of the copyright license only. The <project_license> could choose to refer to just the copyright license in such cases. But perhaps this line of reasoning is too obscure..

I still desire a general solution that can handle all situations where the software is similarly tainted by credible patent threats; the solutions outlined in the preceding paragraphs would only work if there is a patent license.

I am more than happy to change my mind on this if I hear a good argument for why such cases would not in practice restrict software freedoms in a least some regions.

[hughsie]

can you please pull the package until this or an equivalent solution is fully implemented

No.

I also think it is fair to call a combined copyright and patent license proprietary if the patent license restricts essential software freedoms

Are you a lawyer?

[rohanlean]

I also think it is fair to call a combined copyright and patent license proprietary if the patent license restricts essential software freedoms

Are you a lawyer?

The definition of free software is a social issue, not a legal question. Independently I also think that not only lawyers are allowed to have opinions on legal matters.

Nevertheless, to satisfy an apparent desire for a more authoritative voice, here are some quotes from the GPLv3:

patents applied to a free program could make it effectively proprietary

If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of [the GPLv3], through a publicly available network server or other readily accessible means, then you must either (1) cause the Corresponding Source to be so available, or (2) arrange to deprive yourself of the benefit of the patent license for this particular work, or (3) arrange, in a manner consistent with the requirements of [the GPLv3], to extend the patent license to downstream recipients. “Knowingly relying” means you have actual knowledge that, but for the patent license, your conveying the covered work in a country, or your recipient's use of the covered work in a country, would infringe one or more identifiable patents in that country that you have reason to believe are valid.

A patent license is “discriminatory” if it does not include within the scope of its coverage, prohibits the exercise of, or is conditioned on the non-exercise of one or more of the rights that are specifically granted under [the GPLv3]. You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license (a) in connection with copies of the covered work conveyed by you (or copies made from those copies), or (b) primarily for and in connection with specific products or compilations that contain the covered work, unless you entered into that arrangement, or that patent license was granted, prior to 28 March 2007.

The last quoted paragraph explicitly condemns the arrangement used to distribute openh264.

[hughsie]

Independently I also think that not only lawyers are allowed to have opinions on legal matters

Bzz, that's me out., sorry.

[ximion]

FWIW, I don't think we should add an explicit patents list to AppStream. It may look like a good idea to do that, and I totally get where you are coming from, but ultimately I strongly believe it's a bad idea and will lead people down a very slippery slope.
Ultimately, a list of patents in AppStream metadata wouldn't be something companies can actually rely on, as they need their lawyers to look at the respective piece of software in detail anyway. For users it's also of questionable use, as projects first have to know that they are actually violating any patents, list them correctly, and then users need to determine whether that is actually a problem.
All in all, there is also a good reason why you don't find an exhaustive list of patents that affect a certain software product that aren't owned by the company publishing it.
On top of that, patents and especially software patents are highly region specific. So in order to autodetect whether a patent is actually an issue, we would need to add complex logic that determines by region whether a certain patent even applies. That's quite a huge task, and something I certainly don't want to attempt without strong legal support and a strong motivation to have this feature in the first place.

I do actually think for your usecase that mentioning such issues in the license or license string is best. Additional legal protection can also be given by the software repository, e.g. Linux distributions usually don't ship code that is covered by a patent that is actively enforced by an entity.

[ximion]

IÄm going to close this bug report - I think that within AppStream, adding a field to list patents will be the wrong incentive.
I think to solve the issue at hand, we will need a much bigger solution that covers many countries and has some legal backing. In the shorter term, it would already help if all components had a metainfo file, such as openH264 - then a tool could check for the presence of its component-ID and immediately give the users some patent information. This will of course only work for well-known patented stuff and needs an externally updated list. But given the difficulty of getting patent information right, that is likely a feature and not a bug.