Why abandoned?

[hazinstore]

Just wondering why you guys decided to stop working on this and if there is a better alternative, or is it that there is some security flaw? RFC-6330 looks fascinating and you did a lot of work. Shame to see it come to an end like that.

[baranovmv]

@hazinstore My pet project uses OpenFEC by default, it looks a little bit more mature than OpenRQ. Although it doesn't incorporate Raptor code.

BTW, I'd rather let user choose any of code schemes if I can statically link OpenRQ to a library written in C++.

[zemasa]

Hi @hazinstore,

I fail to see why you would assume the OpenRQ has come to an end or been abandoned? It is not being actively developed, but we still maintain it if needs be. AFAIK there are no open issues or known bugs with it.

The reason we are not actively developing it is because we have achieved our goal of implementing a flexible open source library for RaptorQ encoding/decoding - that is 100% compliant with the RFC (AFAIK we haven't implemented packet interleaving, but that would be only useful for extremely large files, which is not the general use case really).

To the best of my knowledge, OpenRQ was and still is, the only open source library for RaptorQ codification.

If you have ideas on how to improve it, or develop it further, then by all means! We're happy to accept contributions, that's the magic of open source after all :)

P.S. @hazinstore I do agree RFC 6330 is awesome. By the time I was done with OpenRQ I knew it by heart. Literally. P.S.2 @baranovmv the only goal of OpenRQ was to implement an open source library for RaptorQ, thus I don't understand the "maturity" comparison. OpenRQ was never advertised nor intended to do anything more than what it does: encode and decode data following the RFC 6330 standard; and AFAIK no one else does it better (yet) - other than Qualcomm ofc. For the record, you should be able to implement RFC 6330 with greater ease in C++ than in Java. I'd recommend it, implementing RFC 6330 is a great exercise! Unfortunately for us, we had to comply with a bigger project OpenRQ would be inserted in, which was written in Java.

[rjpfonseca]

I have stopped contributing to this project for a while due to lack of incentives to work on it. At the time when I was still actively working on it, I was being paid to do it, and my employer's main goal for this project was to achieve a good performance in the decoding function, on the same order of magnitude as Qualcomm's decoder. However, this has never been successful and soon the interest in OpenRQ was dropped, and I moved on to other things.

As far as I know, it is possible to implement a better decoding algorithm than the one specified in RFC 6330, since that one was only an example of a possible implementation. I suspect that a faster implementation, such as the commercial one by Qualcomm, uses a few tricks that are not specified in the RFC, one being perhaps an iterative solution that continuously decodes the original data as source/encoding symbols are made available to the receiver (unlike the standard decoder which we implement that performs the full decoding operation in one go once sufficient symbols are available).

Finally, I also had plans to enhance the API by giving support for file and stream manipulation besides simple arrays of bytes, and to complete our wiki tutorials by providing decoding examples, which are still missing. Unfortunately, the lack of incentives have made it hard for me to find the time to accomplish any of these goals.

[mortenvp]

Is the RaptorQ related patents now in public domain i.e. can one implement RFC 6330 freely now?

[zemasa]

@mortenvp You could always have implemented RFC 6330 freely. AFAIK the patents are not public domain, but they do not affect the RaptorQ standard. They might patent the encoding/decoding algorithms themselves, or transport protocols around RaptorQ, but not the standard itself. You could even implement RaptorQ using Gaussian elimination! It would just be very slow... OpenRQ uses the algorithm suggested in RFC 6330, which is not under patent (AFAIK).

I'm in no position to give any legal advise though. All I can say is that Qualcomm is aware of our implementation since 2013, and so far we haven't been sued.

[mortenvp]

Hi @zemasa thanks for your input. There is an IPR disclosure on the RFC. If you go here https://tools.ietf.org/html/rfc6330 and click the IPR link top right corner. It may be that Qualcomm's patents only are asserted in certain application areas or regions or something.

I'm also not a lawyer - I just always assumed I could not implement this due to the patents - but I may have been wrong :)

[ruckc]

I've been wanting to use OpenRQ for years now, but havn't been able to due to not having the time to develop a transport protocol around it.

December 14 2016 12:41 PM, "Jose Lopes" wrote: @mortenvp (https://github.com/mortenvp) You could always have implemented RFC 6330 freely. AFAIK the patents are not public domain, but they do not affect the RaptorQ standard. They might patent the encoding/decoding algorithms themselves, or transport protocols around RaptorQ, but not the standard itself. You could even implement RaptorQ using Gaussian elimination! It would just be very slow... OpenRQ uses the algorithm suggested in RFC 6330, which is not under patent (AFAIK).

I'm in no position to give any legal advise though. All I can say is that Qualcomm is aware of our implementation since 2013, and so far we haven't been sued. 

—

You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub (https://github.com/openrq-team/OpenRQ/issues/8#issuecomment-267101744), or mute the thread (https://github.com/notifications/unsubscribe-auth/ABXD4SS0oDS8huPfI6JDaHDkMhzlXH6_ks5rICpkgaJpZM4LLcDC).

[hazinstore]

The Qualcomm patents are only related to use of it in wireless networking hardware. I'm reasonably certain this algorithm is part of the 4G standard not sure if WiMax or LTE though. Anyways Qualcomm is only interested in people who use it in hardware as far as I can tell.

As for why I thought it was abandoned it's because on the front page it says

Staled for the moment. No planned time to return to an active development.

Then no activity for 2 years. Hence abandoned. If it's complete you should make it clear "project is complete, but PRs are accepted." Otherwise people like me will think you've gone away. :D

[zemasa]

@hazinstore point taken. I've updated the README to better reflect that we are not in active development, but still maintaining the project should bug reports or pull requests come in. issue closed

[urijah]

Have you looked at the much higher performance https://github.com/cberner/raptorq

https://www.cberner.com/2019/03/30/raptorq-rfc6330-rust-optimization/

@zemasa @rjpfonseca