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?
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.
[1] https://src.fedoraproject.org/rpms/openssl/c/347681c6b246d9b6a08c73bb40e5eefaf8596d71?branch=rawhide
[2] https://www.spinics.net/linux/fedora/fedora-legal/msg03673.html
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.)
- 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?
On Mon, Sep 20, 2021 at 12:46 PM Alec Warner <antarus@gentoo.org> wrote:Elliptic Curve cryptography is the most topical & impactful thing I'm
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.
Things that used to be patent-encumbered that were prevalent in FOSSI have some more fields for patents to add, where I believe active
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 don't have any answer from them, but my own research did turn up a few current patents around EC (sorted by expiry):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?
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?
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:Elliptic Curve cryptography is the most topical & impactful thing I'm
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.
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
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.RedHat doesn't seem to disable ECC in Dropbear: https://src.fedoraproject.org/rpms/dropbear/blob/rawhide/f/dropbear.spec
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.
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 ECCRedHat doesn't seem to disable ECC in Dropbear: https://src.fedoraproject.org/rpms/dropbear/blob/rawhide/f/dropbear.spec
(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.
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?
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.RedHat doesn't seem to disable ECC in Dropbear:
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.
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
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.)
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?"
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?
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.
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.
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?
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?
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.
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.
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
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 294 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 247:50:00 |
| Calls: | 6,626 |
| Calls today: | 2 |
| Files: | 12,175 |
| Messages: | 5,320,897 |