Re: [Starlink] raptor codes

Re: [Starlink] raptor codes

[David P. Reed]

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


Since you asked about GPL and fountain codes, I'll add another comment, both inline below, and in a preface.
 
I also had a side discussion with Mike Luby regarding IPR. He clarified that the fountain code patents of Digital Fountain, Inc. were acquired by Qualcomm entirely when Digital Fountain was acquired by Qualcomm, and also mentioned that there had been subsequent work at Qualcomm by employees and contractors (and more patents have been filed, and some may be in process).
 
He also would wish that others would use the term "fountain codes" rather than the term "rateless erasure codes". The two terms actually define two different, but largely overlapping, sets of codes, with a lot of common properties. The codes I described are arguably covered by either term.
 
Now I respect the law. I am not criticizing Luby for using the patent law. If it had been me, because of the subject matter I would not have sought patent rights, for the same reason that I don't patent abstract algorithms or data structures - even if the USPTO would allow them. But that's a personal, political view.
 
IANAL, but with regard to GPL, my understanding is that all code licensed under GPL must not implement any patented algorithm, unless there is a specific license that covers the specific use in the code as it was when authorized. This was true based on court precedent in GPLv2, and is specifically included in GPLv3's license. So, the contributor of any such code to a GPL project must obtain that license as well as granting their assignment of copyright to the actual code. (please don't trust me, ask a patent attorney, preferably one who also understands copyright licenses and specializes in GPL).
 
To use anything that might infringe any of those patents, other than the one case handled by the very narrow licenses for Raptor and RaptorQ used within the limited cases described, you must negotiate a patent license. That's clear from Luby here and from my discussion with him.
 
On Sunday, December 12, 2021 7:32pm, starlink-request@lists.bufferbloat.net said:



> Message: 2
> Date: Sun, 12 Dec 2021 16:32:38 -0800
> From: Dave Taht <dave.taht@gmail.com>
> To: starlink@lists.bufferbloat.net
> Subject: [Starlink] raptor codes
> Message-ID:
> <CAA93jw642KEqNAOja36KX2o+DYyE978F==rpYD978J954-c=bQ@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> "Mike" Luby (formerly of qualcomm, now the CEO of bitripple) and I
> exchanged some email today.
> 
> He sent me the attached document explaining in detail how they work.
> Up until now I knew of these things, and how they were used, but not
> much about their foundations.
> 
> I'm a simple guy, I just wanted to know if we could incorporate this
> stuff in GPL'd software (e.g. the linux kernel), how big the codebase
> needs to be, what APIs made the most sense, what the cpu overheads
> were, what code was already available, and the memory (more broadly -
> capacity) requirement that vint's still working on...
> 
> ...
> 
> "An identical IPR declaration was made by Qualcomm on the earlier
> generation of Raptor codes specified in IETF RFC 5053. One could
> argue that one would like to use another variation of the fountain
> codes, but honestly this would lead to the opposite of what David is
> trying to achieve, which is interoperability — we designed RaptorQ
> specified in IETF RFC 6330 very carefully with essentially ideal
> properties so that it could be used as the basis for a agreed upon and
> widely deployed standard..."
> 
> ... If there are hundreds of variants of weird fountain codes out
> there, how does that help with interoperability? RaptorQ is part of
> the NextGen TV standard (ATSC 3.0) as well, and the reason is for
> interoperability"
That's why the license is so very narrow to the case described in the RFC - only ATSC 3.0 transmission can use this, Qualcomm reserves all other rights, as far as they have revealed.
> 
> And lastly: " we at BitRIpple don’t own the IPR rights to RaptorQ, but
> I know how to interpret the IPR statement and I know we are just fine.
> In fact, BitRipple recently collaborated with Qualcomm and Verizon to
> provide the data delivery technology to support the following:
>
 
The thing BitRipple describes may be open source, and could even be GPL licensed (I don't know), 
but that would be because there is a specific license for the entire distributed collection of GPL
code.
To make it into the Linux *kernel* (GPLv2) would probably require a new license for the broader audience served by the Linux kernel's downstream distributions. Again, IANAL.
 
> Qualcomm CEO Cristiano Amon (in Hawaii) and Verizon CTO Kyle Malady
> (in New Jersey) had the first ever 8K HDR live video conferencing call
> between smartphones enabled by BitRipple technology, which was the
> first demo during Cristiano’s keynote at the Qualcomm Snapdragon
> Technical Summit.
> 
> See Qualcomm’s post about this on LinkedIn (https://lnkd.in/g5xTaXDm)
> and my post about this as well
> (https://www.linkedin.com/posts/michaelluby_watch-qualcomm-and-verizon-demo-worlds-first-activity-6871600498093506560-xl6R).
> There is also a Youtube video of the demo
> (https://www.youtube.com/watch?v=Au20PiI27Mg)."
> 


[-- Attachment #2: Type: text/html, Size: 7995 bytes --]

[Starlink] raptor codes

[Dave Taht]

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

"Mike" Luby (formerly of qualcomm, now the CEO of bitripple) and I
exchanged some email today.

He sent me the attached document explaining in detail how they work.
Up until now I knew of these things, and how they were used, but not
much about their foundations.

I'm a simple guy, I just wanted to know if we could incorporate this
stuff in GPL'd software (e.g. the linux kernel), how big the codebase
needs to be, what APIs made the most sense, what the cpu overheads
were, what code was already available, and the memory (more broadly -
capacity) requirement that vint's still working on...

...

"An identical IPR declaration was made by Qualcomm on the earlier
generation of Raptor codes specified in IETF RFC 5053.  One could
argue that one would like to use another variation of the fountain
codes, but honestly this would lead to the opposite of what David is
trying to achieve, which is interoperability — we designed RaptorQ
specified in IETF RFC 6330 very carefully with essentially ideal
properties so that it could be used as the basis for a agreed upon and
widely deployed standard..."

... If there are hundreds of variants of weird fountain codes out
there, how does that help with interoperability? RaptorQ is part of
the NextGen TV standard (ATSC 3.0) as well, and the reason is for
interoperability"

And lastly: " we at BitRIpple don’t own the IPR rights to RaptorQ, but
I know how to interpret the IPR statement and I know we are just fine.
In fact, BitRipple recently collaborated with Qualcomm and Verizon to
provide the data delivery technology to support the following:

Qualcomm CEO Cristiano Amon (in Hawaii) and Verizon CTO Kyle Malady
(in New Jersey) had the first ever 8K HDR live video conferencing call
between smartphones enabled by BitRipple technology, which was the
first demo during Cristiano’s keynote at the Qualcomm Snapdragon
Technical Summit.

See Qualcomm’s post about this on LinkedIn (https://lnkd.in/g5xTaXDm)
and my post about this as well
(https://www.linkedin.com/posts/michaelluby_watch-qualcomm-and-verizon-demo-worlds-first-activity-6871600498093506560-xl6R).
  There is also a Youtube video of the demo
(https://www.youtube.com/watch?v=Au20PiI27Mg)."




-- 
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC

[-- Attachment #2: Raptor_Codes_Foundations_and_Trends®_in_Communications_and_Information_Theory.pdf --]
[-- Type: application/pdf, Size: 1952784 bytes --]