[gentoo-dev] Guidance on distributed patented software

[gentoo-dev] Guidance on distributed patented software

[Alec Warner]

The devmanual discusses licensing as a core concept
(https://devmanual.gentoo.org/general-concepts/licenses/index.html)
but does not cover patents. My understanding is that we:

 - set RESTRICT=bindist when we are unable to redistribute binaries
(e.g. due to a license or patent restriction.)
 - set RESTRICT=mirror when we are unable to redistribute source code
(e.g. due to a license of patent restriction.)
 - Sometimes, we remove patent encumbered source code from packages
(e.g. with USE=bindist) so that we can build redistributable binaries
with the patented features removed.

Could we add some text to the license concepts covering patents? It
seems to have been omitted?
Is my understanding of how we manage patented software correct?

-A

Re: [gentoo-dev] Guidance on distributed patented software

[Rich Freeman]

On Mon, Sep 20, 2021 at 12:46 PM Alec Warner <antarus@gentoo.org> wrote:
>
> Could we add some text to the license concepts covering patents? It
> seems to have been omitted?
> Is my understanding of how we manage patented software correct?

I think you have the gist of it.  Is there actually anything in the
repo these days which is patent-encumbered?  I realize this is a
little tangential, but I think this is probably why we don't have a
well-thought policy: it just doesn't come up much.

The situation comes up less often since everything is copyrighted by
default, but software patents in FOSS are relatively rare.  (Partially
because they're such a minefield that it discourages even creating
FOSS in the first place.  Partially because they're such a minefield
that people tend to favor non-encumbered algorithms for things that
are commonplace now.)

Things that used to be patent-encumbered that were prevalent in FOSS
in the past include:
1. The GIF file format.
2. FAT-based filesystems.
3. MPEG-related codecs (codecs might be a space where patents are
still relevant).
4. RSA

I'm sure there are others I'm not thinking of offhand.  All of these
helped drive adoption of more open standards, which is why we don't
run into this stuff as often.

Another topic like this are encryption keys like for DVDCSS and so on.
Those fall outside both copyright and patent law, but are legally
troublesome.  Then there are export controls like ITAR/etc - less of
an issue today but might still apply to some things.

-- 
Rich

Re: [gentoo-dev] Guidance on distributed patented software

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 2536 bytes --]

On Mon, Sep 20, 2021 at 01:27:37PM -0400, Rich Freeman wrote:
> On Mon, Sep 20, 2021 at 12:46 PM Alec Warner <antarus@gentoo.org> wrote:
> >
> > Could we add some text to the license concepts covering patents? It
> > seems to have been omitted?
> > Is my understanding of how we manage patented software correct?
> 
> I think you have the gist of it.  Is there actually anything in the
> repo these days which is patent-encumbered?  I realize this is a
> little tangential, but I think this is probably why we don't have a
> well-thought policy: it just doesn't come up much.
Elliptic Curve cryptography is the most topical & impactful thing I'm
aware of.

RedHat have for many years stripped parts of it out of their OpenSSL &
libgcrypt packages, and continue to do it with OpenSSL-3 [1] (I note
that somebody has dropped these patches from Gentoo's openssl as of v3
and I intend to restore them).

RedHat's legal team clearly know something there that they aren't
disclosing the details of publicly, because the patches said the patents
expire in 2020, but when I asked off-list if EC could be re-enabled
based on the expiry dates in the files, they claimed that patent issues
were still present, without giving any detail.

Somebody else ALSO asked about the Brainpool EC curves specifically and
similarly got nowhere [2].

[1] https://src.fedoraproject.org/rpms/openssl/c/347681c6b246d9b6a08c73bb40e5eefaf8596d71?branch=rawhide
[2] https://www.spinics.net/linux/fedora/fedora-legal/msg03673.html

I feel that generally software patents as an issue for FOSS became less
common because of patent grant programs: grants existed to encourage
broad adoption of newer ideas from patents.

> Things that used to be patent-encumbered that were prevalent in FOSS
> in the past include:
> 1. The GIF file format.
> 2. FAT-based filesystems.
> 3. MPEG-related codecs (codecs might be a space where patents are
> still relevant).
> 4. RSA
I have some more fields for patents to add, where I believe active
patents DO still exist:

5. Elliptic Curve cryptography
6. "Quantum" cryptography
7. 3D Printing
8. DRM
9. UAVs/Drones (also hits EAR/ITAR)
10. Rocketry (also hits EAR/ITAR)

Other past patent stuff touching open source:
11. Model Trains (see JMRI vs Katzer)

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1113 bytes --]

Re: [gentoo-dev] Guidance on distributed patented software

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 763 bytes --]

>>>>> On Mon, 20 Sep 2021, Robin H Johnson wrote:

> RedHat's legal team clearly know something there that they aren't
> disclosing the details of publicly, because the patches said the
> patents expire in 2020, but when I asked off-list if EC could be
> re-enabled based on the expiry dates in the files, they claimed that
> patent issues were still present, without giving any detail.

If there are remaining patent issues then they should be able to support
their claim by facts, like a patent number. Why would this be difficult,
or what reason would they have not to disclose it?

> [1] https://src.fedoraproject.org/rpms/openssl/c/347681c6b246d9b6a08c73bb40e5eefaf8596d71?branch=rawhide
> [2] https://www.spinics.net/linux/fedora/fedora-legal/msg03673.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

Re: [gentoo-dev] Guidance on distributed patented software

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 1526 bytes --]

On Mon, Sep 20, 2021 at 08:41:21PM +0200, Ulrich Mueller wrote:
> >>>>> On Mon, 20 Sep 2021, Robin H Johnson wrote:
> 
> > RedHat's legal team clearly know something there that they aren't
> > disclosing the details of publicly, because the patches said the
> > patents expire in 2020, but when I asked off-list if EC could be
> > re-enabled based on the expiry dates in the files, they claimed that
> > patent issues were still present, without giving any detail.
> 
> If there are remaining patent issues then they should be able to support
> their claim by facts, like a patent number. Why would this be difficult,
> or what reason would they have not to disclose it?
I don't have any answer from them, but my own research did turn up a few
current patents around EC (sorted by expiry):

US8462944B2 exp 2021-12-26
US8189772B2 exp 2023-05-28
US9160530B2 exp 2024-10-28
US8213605B2 exp 2025-11-14
US10756893B2 exp 2026-01-23
US10284370B2 exp 2026-03-03
US20100023775A1 exp 2031-08-02
US8631240B2 exp 2031-08-02
US8572367B2 exp 2031-12-25
US8918648B2 exp 2032-01-31
US10079673B2 exp 2032-02-15 ** not specifically EC, more general about Entropy
US9800418B2 exp 2035-07-17

IANAL, but the difficult question is: does any open-source end up
implementing those algorithms?

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1113 bytes --]

Re: [gentoo-dev] Guidance on distributed patented software

[Joshua Kinard]

On 9/20/2021 14:15, Robin H. Johnson wrote:
> On Mon, Sep 20, 2021 at 01:27:37PM -0400, Rich Freeman wrote:
>> On Mon, Sep 20, 2021 at 12:46 PM Alec Warner <antarus@gentoo.org> wrote:
>>>
>>> Could we add some text to the license concepts covering patents? It
>>> seems to have been omitted?
>>> Is my understanding of how we manage patented software correct?
>>
>> I think you have the gist of it.  Is there actually anything in the
>> repo these days which is patent-encumbered?  I realize this is a
>> little tangential, but I think this is probably why we don't have a
>> well-thought policy: it just doesn't come up much.
> Elliptic Curve cryptography is the most topical & impactful thing I'm
> aware of.
> 
> RedHat have for many years stripped parts of it out of their OpenSSL &
> libgcrypt packages, and continue to do it with OpenSSL-3 [1] (I note
> that somebody has dropped these patches from Gentoo's openssl as of v3
> and I intend to restore them).
> 
> RedHat's legal team clearly know something there that they aren't
> disclosing the details of publicly, because the patches said the patents
> expire in 2020, but when I asked off-list if EC could be re-enabled
> based on the expiry dates in the files, they claimed that patent issues
> were still present, without giving any detail.
> 
> Somebody else ALSO asked about the Brainpool EC curves specifically and
> similarly got nowhere [2].
> 
> [1] https://src.fedoraproject.org/rpms/openssl/c/347681c6b246d9b6a08c73bb40e5eefaf8596d71?branch=rawhide
> [2] https://www.spinics.net/linux/fedora/fedora-legal/msg03673.html
> 

[snip]

Is there any advice on how this impacts net-misc/dropbear?  That has ECC
(both ECDSA and Ed25519) support, and I use it for SGI/MIPS netboot images.
 The build doesn't have any bindist uses in it, and ECC support is a
localoptions.h compile-time option (enabled by default).  ECC is much faster
on old SGI hardware and generating the hostkeys at bootup takes just a
second or two, whereas RSA can take up to 10-15 seconds.  So I'd like to be
able to use ECC on these platforms and distribute netboot images using them.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] Guidance on distributed patented software

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 1274 bytes --]

On Wed, Sep 22, 2021 at 08:54:40AM -0400, Joshua Kinard wrote:
> Is there any advice on how this impacts net-misc/dropbear?  That has ECC
> (both ECDSA and Ed25519) support, and I use it for SGI/MIPS netboot images.
>  The build doesn't have any bindist uses in it, and ECC support is a
> localoptions.h compile-time option (enabled by default).  ECC is much faster
> on old SGI hardware and generating the hostkeys at bootup takes just a
> second or two, whereas RSA can take up to 10-15 seconds.  So I'd like to be
> able to use ECC on these platforms and distribute netboot images using them.
RedHat doesn't seem to disable ECC in Dropbear:
https://src.fedoraproject.org/rpms/dropbear/blob/rawhide/f/dropbear.spec

Based on what they've said for OpenSSL, I would expect that they SHOULD
have disabled ECC there, but there is certainly no consistency from
them.

Probably nobody asked legal and just shipped dropbear anyway.

If you wanted to stir the pot, you could post to the Fedora legal list
and ask for consistency ;-).


-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1113 bytes --]

Re: [gentoo-dev] Guidance on distributed patented software

[Joshua Kinard]

On 9/22/2021 12:37, Robin H. Johnson wrote:
> On Wed, Sep 22, 2021 at 08:54:40AM -0400, Joshua Kinard wrote:
>> Is there any advice on how this impacts net-misc/dropbear?  That has ECC
>> (both ECDSA and Ed25519) support, and I use it for SGI/MIPS netboot images.
>>  The build doesn't have any bindist uses in it, and ECC support is a
>> localoptions.h compile-time option (enabled by default).  ECC is much faster
>> on old SGI hardware and generating the hostkeys at bootup takes just a
>> second or two, whereas RSA can take up to 10-15 seconds.  So I'd like to be
>> able to use ECC on these platforms and distribute netboot images using them.
> RedHat doesn't seem to disable ECC in Dropbear:
> https://src.fedoraproject.org/rpms/dropbear/blob/rawhide/f/dropbear.spec
> 
> Based on what they've said for OpenSSL, I would expect that they SHOULD
> have disabled ECC there, but there is certainly no consistency from
> them.
> 
> Probably nobody asked legal and just shipped dropbear anyway.
> 
> If you wanted to stir the pot, you could post to the Fedora legal list
> and ask for consistency ;-).

Hmm, it looks like dropbear is relying heavily on the ecc/ecdsa functions
provided in libtomcrypt, and that library's homepage states all its code is
public domain.  Our ebuild has no bindist restrictions on that library.
Perhaps that is how dropbear, and thus Red Hat, avoids the issues with
licensing or patents?

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] Guidance on distributed patented software

[Peter Stuge]

Joshua Kinard wrote:
> Hmm, it looks like dropbear is relying heavily on the ecc/ecdsa functions
> provided in libtomcrypt, and that library's homepage states all its code is
> public domain.  Our ebuild has no bindist restrictions on that library.
> Perhaps that is how dropbear, and thus Red Hat, avoids the issues with
> licensing or patents?

Licenses apply to implementations and patents apply to inventions/ideas.

A software license can allow you to theoretically use an implementation
while a patent says no you can't without licensing that right separately.

The reverse is equally possible; an expired patent means that using the
invention/idea is not restricted by the patent anymore, but there may
still be no free/open source implementation (yet).


AIUI USE=-bindist is all three variants (swlicense_says_no || patent_says_no)
while USE=bindist promises that (swlicense_says_yes && patent_says_yes)
is guaranteed to be true at the cost of functionality?


//Peter

Re: [gentoo-dev] Guidance on distributed patented software

[Joshua Kinard]

On 9/23/2021 12:10, Alec Warner wrote:
> On Wed, Sep 22, 2021 at 10:54 PM Joshua Kinard <kumba@gentoo.org> wrote:
>>
>> On 9/22/2021 12:37, Robin H. Johnson wrote:
>>> On Wed, Sep 22, 2021 at 08:54:40AM -0400, Joshua Kinard wrote:
>>>> Is there any advice on how this impacts net-misc/dropbear?  That has ECC
>>>> (both ECDSA and Ed25519) support, and I use it for SGI/MIPS netboot images.
>>>>  The build doesn't have any bindist uses in it, and ECC support is a
>>>> localoptions.h compile-time option (enabled by default).  ECC is much faster
>>>> on old SGI hardware and generating the hostkeys at bootup takes just a
>>>> second or two, whereas RSA can take up to 10-15 seconds.  So I'd like to be
>>>> able to use ECC on these platforms and distribute netboot images using them.
>>> RedHat doesn't seem to disable ECC in Dropbear:
>>> https://src.fedoraproject.org/rpms/dropbear/blob/rawhide/f/dropbear.spec
>>>
>>> Based on what they've said for OpenSSL, I would expect that they SHOULD
>>> have disabled ECC there, but there is certainly no consistency from
>>> them.
>>>
>>> Probably nobody asked legal and just shipped dropbear anyway.
>>>
>>> If you wanted to stir the pot, you could post to the Fedora legal list
>>> and ask for consistency ;-).
>>
>> Hmm, it looks like dropbear is relying heavily on the ecc/ecdsa functions
>> provided in libtomcrypt, and that library's homepage states all its code is
>> public domain.  Our ebuild has no bindist restrictions on that library.
>> Perhaps that is how dropbear, and thus Red Hat, avoids the issues with
>> licensing or patents?
> 
> I don't see a patent grant in the unlicense; so I don't see how this
> works around that problem. Now it's hard for us to say (because we
> don't know what patents openssl might contain, to be able to look at
> dropbear and compare.)
> Note that openssl 3.0 is released under a new license (The Apache 2.0
> license) which has a patent grant in it. Note that the grant itself is
> not bulletproof, but it's often better than nothing.
> 
> The apache 2.0 grant basically says if the patent author writes the
> code and submits it as apache 2.0 they grant you a license to do a
> bunch of stuff with the code. If I'm just some individual who writes
> the patented code and I license it as apache 2.0; obviously I have no
> right to grant you a patent license....so the grant in apache2 is not
> useful in that context. In the latter case I'd expect the project to
> remove the code in question in most circumstances.
> 
> In general we trust upstream (because we have no other option.) If we
> become aware that there is patented material in a package we should
> take the requisite action (typically restrict=bindist) so that we are
> not violating the patents (and we did that for openssl, for example.)
> I want to get away from this concept that we can easily tell whether
> something is protected or not, or contains patents or not; it's a hard
> problem. In many cases its similar to licensing. We trust upstream
> until we learn otherwise and then we endeavour to fix the issue.
> Sometimes that means removing code; or changing the LICENSE variables,
> etc.
> 
> -A

If I remember this weekend, I'll e-mail the libtomcrypt author and see if
they have any insight.  One would hope they did their own research before
possibly putting patented code out into the public domain.

Any idea if the Ed25519 forms are unencumbered?  As far as I know, those
were developed by DJB completely independent of ECDSA, so it seems like
those should be fine.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] Guidance on distributed patented software

[Joshua Kinard]

On 9/24/2021 03:55, Hanno Böck wrote:
> On Fri, 24 Sep 2021 03:46:51 -0400
> Joshua Kinard <kumba@gentoo.org> wrote:
> 
>> If I remember this weekend, I'll e-mail the libtomcrypt author and
>> see if they have any insight.  One would hope they did their own
>> research before possibly putting patented code out into the public
>> domain.
>>
>> Any idea if the Ed25519 forms are unencumbered?  As far as I know,
>> those were developed by DJB completely independent of ECDSA, so it
>> seems like those should be fine.
> 
> I would like to point out that we have no evidence that ECDSA is
> currently patent-encumbered either.
> The patents that are listed in Red Hat's openssl patches and the ones
> that people have been discussing around ecc are all expired. The only
> "evidence" we have around patent problems is that red hat does not give
> a clear answer when asked whether there are still issues. My hunch is
> that this is more of a "large company not answering questions"-problem
> than a patent problem, but of course I don't know that for sure.
> 
> ECDSA and the NIST curves have been around since > 20 years, so it's
> simply impossible that there are any valid patents covering those.
> (There is of course a slight possibility that there may be patents
> covering specific implementation details of ECDSA/NIST curves that were
> only described later.)

Then we are either A) being too paranoid and should just drop bindist from
the OpenSSL ebuilds, or B) we are not being paranoid enough and packages
like dropbear/libtomcrypt need bindist added, no?  It seems we're stuck in
the middle here because we don't have the right information.  If Red Hat or
IBM are being non-responsive over this, then surely some other distro out
there has already figured things out?


> I'm not entirely sure what you'd like to ask the libtomcrypt authors.
> "We think there may be patents, but we don't know. Did you consider
> that?"

No, actually, I was thinking something more along the lines of "Hey, are you
aware of these supposed patent claims about ECC/ECDSA implementations that
Red Hat says exist, and if so, did you do any research on them that you
could possibly share that led you to feeling confident to release your
implementation into the public domain".

But I am open to better language.  I just don't wanna sit here not knowing.
 Someone out there has to have the right information to settle this.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] Guidance on distributed patented software

[Peter Stuge]

Joshua Kinard wrote:
> > I'm not entirely sure what you'd like to ask the libtomcrypt authors.
> > "We think there may be patents, but we don't know. Did you consider
> > that?"
> 
> No, actually, I was thinking something more along the lines of "Hey, are you
> aware of these supposed patent claims about ECC/ECDSA implementations that
> Red Hat says exist, and if so, did you do any research on them that you
> could possibly share that led you to feeling confident to release your
> implementation into the public domain".
> 
> But I am open to better language.

There's not neccessarily a conflict between a patented idea and a
public domain implementation of that idea.

Take a fictional example:

You and I independently invent the same thing. You patent it, then
write and publish an LGPL implementation. I, ignorant of your
accomplishment, later write and publish a different implementation,
placing it in the public domain.

You having a patent doesn't neccessarily matter to me publishing my
implementation.

It can be problematic for *users*. They might violate your patent
terms (or not; it depends on your terms in the patent) if they use
*any* implementation without having licensed the right to use your
patented idea from you. (Of course only until your patent expires.)

What users have to do is determined by the terms set forth in the
patent. E.g.: the QR-code patent has (I believe) not expired yet but
has always permitted using the idea without any explicit license under
the condition that all use is actually spec conformant.

The license for a software isn't connected to patents unless it
explicitly states so, like GPL-3 Section 11 or Apache-2.0 Section 3.
Public domain has no license text, so can have no such language. :)

You seem to expect some due diligence from libtomcrypt authors before
having decided to publish their work and I don't find that reasonable.
I hope I've managed to explain why?


Kind regards

//Peter

Re: [gentoo-dev] Guidance on distributed patented software

[Rich Freeman]

On Sun, Sep 26, 2021 at 1:09 PM Peter Stuge <peter@stuge.se> wrote:
>
> There's not neccessarily a conflict between a patented idea and a
> public domain implementation of that idea.

It kind of depends on what you mean by "conflict."

>
> Take a fictional example:
>
> You and I independently invent the same thing. You patent it, then
> write and publish an LGPL implementation. I, ignorant of your
> accomplishment, later write and publish a different implementation,
> placing it in the public domain.
>
> You having a patent doesn't neccessarily matter to me publishing my
> implementation.

Sure it does.  Depending on the claims of the patent, your publication
of the completely independent implementation is basically a public
confession that you violated the original patent.  Now, if you didn't
obtain any commercial value from it and were ignorant it is pretty
unlikely that somebody would actually go after you for it or get
damages, but you can infringe on a patent while being completely
ignorant of it and doing all your own independent work.  The patent
covers the idea, no matter how many times it is independently
invented.

> What users have to do is determined by the terms set forth in the
> patent. E.g.: the QR-code patent has (I believe) not expired yet but
> has always permitted using the idea without any explicit license under
> the condition that all use is actually spec conformant.

Generally patents, like copyright registrations, do not have "terms"
for how you are allowed to use the patented technology.  The patent
just makes claims as to what is covered.  For something completely new
those claims often are pretty broad covering anything somebody could
imagine the technology being used for.  For something repurposed the
claims tend to be narrow, as the inventor didn't actually come up with
the original idea but claims the new application of it is novel in
some way, and if you use it for anything else you're more likely to be
free and clear.

What you are talking about is a patent license, which is similar to a
software license.  You don't "copyright software under the GPL" - you
just copyright the software full stop.  Then, as a separate act, you
issue however many licenses you wish to anybody you wish allowing them
to do things that would otherwise infringe on the copyright.  In the
same way all a patent does is stake a claim on an idea, and then any
licenses are a completely separate matter.  If a patent holder wants
to sue somebody they would point to what they're doing and then to the
patent, and the court would determine if the action infringed, but the
defense would be free to provide any license they believe they
legitimately have from the patent holder that makes the action legal.

> You seem to expect some due diligence from libtomcrypt authors before
> having decided to publish their work and I don't find that reasonable.
> I hope I've managed to explain why?

So, I can't speak for libcrypt at all specifically, but I wouldn't
assume that somebody has actually done due diligence before publishing
anything.  For all you know the authors of some random piece of
software live someplace the patent is unenforceable and don't even
care if it infringes, or they're protected by anonymity online.  Back
in the PGP ITAR days I believe somebody went through some loopholes to
publish the software outside the US, and it is probably debatable
whether that was legal under US law, but presumably the people who did
it didn't care, and enforcement was unlikely at all, and especially
unlikely if you didn't have plans to visit the US after bragging about
distributing it.

Really the same is true of software patents in general.  For random
individuals other than your own conscience it is pretty unlikely for
there to be any kind of enforcement.  For a business or concern of any
size though it obviously is a risk that is probably not worth taking.
This is arguably one of the value-adds a commercial distro could add:
providing an assurance that anything in the distro is systematically
and competently screened.  Whether commercial distros actually due
this in practice is something I don't know, though if they make
promises and have the appearance of a decent program it might
accomplish the CYA needs of due diligence for most companies...

-- 
Rich

Re: [gentoo-dev] Guidance on distributed patented software

[Marek Szuba]

On 2021-09-26 21:20, Rich Freeman wrote:

> Back in the PGP ITAR days I believe somebody went through some 
> loopholes to publish the software outside the US,

Yes, PGP 2.6 source code got published as an OCR-friendly book 
(https://dl.acm.org/doi/book/10.5555/207390) which was then legally 
taken from the US abroad.

> and it is probably debatable whether that was legal under US law,

I am no expert on US law but from what I have read (in many different 
sources, with me having begun using PGP in either late 1996 or early 
1997 i.e. when it was still very much subject to US export restrictions) 
about this case, both the publishing of the source-code book and it 
having subsequently been taken out of the country has been legal - the 
former due to publishing the first amendment and the second due to the 
scope of ITAR as far as crypto software was concerned.

> but presumably the people who did it didn't care, and enforcement was
> unlikely at all, and especially unlikely if you didn't have plans to
> visit the US after bragging about distributing it.

I don't know if Ståle Schumacher (the person who scanned the book and 
subsequently published "international" versions of PGP 2 in Norway) ever 
visited the US afterwards. On the other hand the source-code book 
itself, the purpose of which was rather clear given it even contained 
notes on how to OCR it, was written by a US person (Phil Zimmermann 
himself) and published by a US company (MIT Press) - so I am not quite 
convinced they either thought they would be our of reach of US law 
(indeed, wasn't PRZ still being persecuted by US Customs at the time?), 
or didn't care.


Not that any of this changes the point you have tried to make regarding 
due diligence, mind you.

-- 
Marecki

Re: [gentoo-dev] Guidance on distributed patented software

[Rich Freeman]

(This is all tangential to the main issue of this thread and just
discussing internet history - skip as you wish...)

On Mon, Sep 27, 2021 at 2:14 PM Marek Szuba <marecki@gentoo.org> wrote:
>
> I am no expert on US law but from what I have read (in many different
> sources, with me having begun using PGP in either late 1996 or early
> 1997 i.e. when it was still very much subject to US export restrictions)
> about this case, both the publishing of the source-code book and it
> having subsequently been taken out of the country has been legal - the
> former due to publishing the first amendment

Well, based on the little I know of US export controls, I doubt that
being in book form vs some other form really has any bearing in
principle.

HOWEVER, I think it was probably done specifically as a challenge to
the constitutionality of the law.  Ie, the argument would be that it
ought to be legal to take the source code out in any form.  By doing
it via a formally published book though they take away all the "exotic
internetness" out of the equation and this way all the 60 year old
judges (in the 90s) who might get involved are forced to confront it
as suppression of book distribution.  In principle though I think most
of us would agree that there is no difference in sharing information
no matter the way in which it is conveyed.  It was probably their hope
that if it did go to court any ruling that secured the right to
distribute via book could then be leveraged against other modes.

I'm guessing that it was never challenged in court precisely for this
reason.  US export controls cover the communication of information via
any mode:
https://www.bis.doc.gov/index.php/policy-guidance/deemed-exports

If they had fought the export of this book it is quite possible that
there would have been a ruling that just finds all export controls to
be illegal.  Really when you think about it any sort of restriction on
communication of classified information or whatever is going to run
into the 1st amendment.  Courts are going to tend to make their
rulings on what can be restricted narrow as a result.  The government
probably prefers to maintain some FUD around where those boundaries
lie, to get companies in particular to follow policies that in the end
might not be enforceable.  (Note I'm not arguing that dissemination of
classified info ought to be legal, but as you move away from things
like locations of troops or blueprints of specific aircraft or
whatever, into more generic topics like entire classes of technology,
I think you're going down a slippery slope...)

The main reason that all of this went away though was that I think it
was Clinton that specifically granted an exception to cryptography
software from ITAR.  The concerns were that the cat was basically out
of the bag anyway, and consumers were potentially going to be harmed
by things like web browsers getting distributed with 40-bit key
limitations.  Sure, secure browsers were also probably available to
people who knew the right links to click, but do we really want
somebody reputable like Google to end up having to have a link on
their website for a non-secure version of their software, and where
the non-secure link just gives you a download, while the secure link
makes you jump through hoops to verify your location/etc?  The popular
use of SSL for entering credit card info on e-commerce sites really
was what drove it IMO.

-- 
Rich

Re: [gentoo-dev] Guidance on distributed patented software

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 4303 bytes --]



> On 25 Sep 2021, at 20:44, Joshua Kinard <kumba@gentoo.org> wrote:
> 
>> [snip]
>> 
>> ECDSA and the NIST curves have been around since > 20 years, so it's
>> simply impossible that there are any valid patents covering those.
>> (There is of course a slight possibility that there may be patents
>> covering specific implementation details of ECDSA/NIST curves that were
>> only described later.)
> 
> Then we are either A) being too paranoid and should just drop bindist from
> the OpenSSL ebuilds, or B) we are not being paranoid enough and packages
> like dropbear/libtomcrypt need bindist added, no?  It seems we're stuck in
> the middle here because we don't have the right information.  If Red Hat or
> IBM are being non-responsive over this, then surely some other distro out
> there has already figured things out?
> 

Agreed.

Furthermore, it's not clear to me that Debian or Ubuntu are "hobbling"
their OpenSSL implementations. I may have missed something, but I
don't see anything in:
- https://salsa.debian.org/debian/openssl/-/tree/debian/unstable/debian/patches (or the rules file)
- https://git.launchpad.net/ubuntu/+source/openssl/tree/debian/patches?h=applied/ubuntu/impish (or the rules file)

The only thing I have found is an old bug report for Ubuntu (https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/597984)
referencing disabling some non-EC parts.

> 
>> I'm not entirely sure what you'd like to ask the libtomcrypt authors.
>> "We think there may be patents, but we don't know. Did you consider
>> that?"
> 
> No, actually, I was thinking something more along the lines of "Hey, are you
> aware of these supposed patent claims about ECC/ECDSA implementations that
> Red Hat says exist, and if so, did you do any research on them that you
> could possibly share that led you to feeling confident to release your
> implementation into the public domain".

I'd like to make some points about our continued use of the "hobble" patch
for at least < OpenSSL 3 too:

- RH won't publicly say what they're worried about wrt EC in OpenSSL. This could be to
avoid patent trolls, but this isn't really consistent with the patch being "enough"
to protect them - or us - anyway?

- We don't know what patents the Fedora patch is allegedly preventing us
from infringing.

- If Fedora's patch is based on legal advice, there's no reason to believe
that it necessarily applies to us.

- We have no way of verifying the correctness (or completeness) of the Fedora
patch we use because it is unclear what it is protecting against.

- Even the latest version of Fedora's hobble patch _script_ only references
patents expiring, at the latest, in 2020: https://src.fedoraproject.org/rpms/openssl/blob/rawhide/f/hobble-openssl.

And, as you observed, this doesn't appear to be applied consistently anyway. Dropbear
in Fedora appears to allow EC.

Right now, I'm far more concerned about the possible security impact of
applying patches whose correctness is not vouched for, nor do we truly
understand their purpose.

In addition, some of the changes in our current OpenSSL 1.1.x patches are fragile
and easily mis-applied or mis-rebased. Here's an example of such a possibly
problematic hunk:

@@ -2026,9 +1945,9 @@ int speed_main(int argc, char **argv)
 #  endif

 #  ifndef OPENSSL_NO_EC
-    ecdsa_c[R_EC_P160][0] = count / 1000;
-    ecdsa_c[R_EC_P160][1] = count / 1000 / 2;
-    for (i = R_EC_P192; i <= R_EC_P521; i++) {
+    ecdsa_c[R_EC_P224][0] = count / 1000;
+    ecdsa_c[R_EC_P224][1] = count / 1000 / 2;
+    for (i = R_EC_P256; i <= R_EC_P521; i++) {
         ecdsa_c[i][0] = ecdsa_c[i - 1][0] / 2;
         ecdsa_c[i][1] = ecdsa_c[i - 1][1] / 2;
         if (ecdsa_doit[i] <= 1 && ecdsa_c[i][0] == 0)
@@ -2040,7 +1959,7 @@ int speed_main(int argc, char **argv)
             }
         }
     }
-#   ifndef OPENSSL_NO_EC2M
+#   if 0

By not using easy macros where possible, we're making it far easier to have compile-time
or even runtime errors.

> 
> But I am open to better language.  I just don't wanna sit here not knowing.
> Someone out there has to have the right information to settle this.
> 

Yep. We consult legal advice or stop using half-measures.

Best,
sam


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] Guidance on distributed patented software

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]

Am Montag, 20. September 2021, 19:27:37 CEST schrieb Rich Freeman:
> On Mon, Sep 20, 2021 at 12:46 PM Alec Warner <antarus@gentoo.org> wrote:
> > Could we add some text to the license concepts covering patents? It
> > seems to have been omitted?
> > Is my understanding of how we manage patented software correct?
> 
> I think you have the gist of it.  Is there actually anything in the
> repo these days which is patent-encumbered? 

media-libs/openh264 for example

(It right now prevents me from building firefox and chromium for the 
experimental binary package hosting [1], since I blanket mask everything with 
bindist restriction. That is likely a bit of overkill, it would be enough to 
not make any binary package from it (which ends up being distributed), but 
that function needs to still be programmed in portage.)

[1] Blog post with details coming soon. Please wait for it before asking 
questions.

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[gentoo-dev] Re: Guidance on distributed patented software

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1120 bytes --]

>>>>> On Mon, 20 Sep 2021, Alec Warner wrote:

> The devmanual discusses licensing as a core concept
> (https://devmanual.gentoo.org/general-concepts/licenses/index.html)
> but does not cover patents. My understanding is that we:

>  - set RESTRICT=bindist when we are unable to redistribute binaries
> (e.g. due to a license or patent restriction.)
>  - set RESTRICT=mirror when we are unable to redistribute source code
> (e.g. due to a license of patent restriction.)

IANAL, but IIUC patents only apply to programs that can run on a
computer. This is the case for binaries but not for source code.

In other words, we don't need mirror restriction for source tarballs
because of patents.

>  - Sometimes, we remove patent encumbered source code from packages
> (e.g. with USE=bindist) so that we can build redistributable binaries
> with the patented features removed.

We do, but normally this doesn't prevent us from distributing the source
code.

> Could we add some text to the license concepts covering patents? It
> seems to have been omitted?
> Is my understanding of how we manage patented software correct?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

[gentoo-dev] Re: Guidance on distributed patented software

[Alec Warner]

On Mon, Sep 20, 2021 at 11:30 AM Ulrich Mueller <ulm@gentoo.org> wrote:
>
> >>>>> On Mon, 20 Sep 2021, Alec Warner wrote:
>
> > The devmanual discusses licensing as a core concept
> > (https://devmanual.gentoo.org/general-concepts/licenses/index.html)
> > but does not cover patents. My understanding is that we:
>
> >  - set RESTRICT=bindist when we are unable to redistribute binaries
> > (e.g. due to a license or patent restriction.)
> >  - set RESTRICT=mirror when we are unable to redistribute source code
> > (e.g. due to a license of patent restriction.)
>
> IANAL, but IIUC patents only apply to programs that can run on a
> computer. This is the case for binaries but not for source code.
>
> In other words, we don't need mirror restriction for source tarballs
> because of patents.
>
> >  - Sometimes, we remove patent encumbered source code from packages
> > (e.g. with USE=bindist) so that we can build redistributable binaries
> > with the patented features removed.
>
> We do, but normally this doesn't prevent us from distributing the source
> code.

Great, I'll send a patch to devmanual to add details about how we
treat patented software in Gentoo (the original goal of the thread; I
don't care what happens to openssl as much ;p)

-A

>
> > Could we add some text to the license concepts covering patents? It
> > seems to have been omitted?
> > Is my understanding of how we manage patented software correct?