roslibpy icon indicating copy to clipboard operation
roslibpy copied to clipboard

Add new comm layer based on websocket-client

Open gonzalocasas opened this issue 4 years ago • 6 comments

The current websocket implementation on CPython relies on Autobahn/Twisted which forces its programming model very harshly on users, and not following it leads to code that is not reliable (cooperative multitasking vs preemptive multitasking).

We should add a new comm layer based on https://github.com/websocket-client/websocket-client, and select it as default (with the option to switch back to Autobahn for those that like it).

gonzalocasas avatar Jan 12 '20 22:01 gonzalocasas

Is this a problem? https://github.com/websocket-client/websocket-client/issues/526

Edit: I guess not. See last paragraph of https://www.gnu.org/licenses/lgpl-java.html.

beverlylytle avatar Jan 29 '21 08:01 beverlylytle

Hello, maintainer of websocket-client here :wave: I wanted to chime in and say that issue 526 is now closed and the websocket-client library is now properly labeled as LGPL 2.1 (it was incorrectly labeled BSD previously). But if you would prefer a different license, I would welcome your input in issue 665 of websocket-client, where we are looking for input for a potential license migration. And if you have any questions about the library, I'll be happy to help.

engn33r avatar Feb 23 '21 03:02 engn33r

@engn33r thanks a lot for the heads up! If I am not mistaken, LGPL would be fine to include in this MIT-licensed library without affect licensing, right?

gonzalocasas avatar Feb 23 '21 06:02 gonzalocasas

I am not a lawyer and am not very knowledgeable on this topic, so while I think that LGPL is compatible with this project's current license, I think that the websocket-client code would remain under LGPL license. However, we are discussing a license change for websocket-client, so it might not remain as LGPL. I will add a couple links about license compatibility that I think are relevant and let you make a final decision. It looks like roslibpy is using the Expat license and this link from GNU describes compatibility: https://www.gnu.org/licenses/license-list.en.html#Expat One FAQ on the GNU site mentions that the "X11 license is compatible with the GPL", and X11 is very similar to the Expat license (both are commonly called "MIT License"): https://www.gnu.org/licenses/gpl-faq.html#GPLWrapper

engn33r avatar Feb 27 '21 03:02 engn33r

Indeed, we use the Expat license (MIT license 😉).

About the compatibility between X11 (MIT/Expat) and GPL, I believe is not really compatible. The short answer to "is compatible" is "No." in that FAQ. Then it goes on to clarify two distinct scenarios (one in which it is compatible), but the last part of that paragraph is what seals it: "[..] you were to incorporate them both in a larger program, that whole would include the GPL-covered part, so it would have to be licensed as a whole under the GNU GPL". And as far as I understand, almost all composition that uses GPL code is considered to fall under that view of "incorporation in a larger program", so, effectively, X11 and GPL are not compatible.

May I ask what is the motivation for changing to a GPL (or similar) license?

gonzalocasas avatar Feb 28 '21 08:02 gonzalocasas

You might be right. I focused on the first link which states that the Expat license is compatible. I thought the FAQ in the 2nd link was focused on the "proprietary system" aspect, rather than the specific license (since X11 is said to be compatible elsewhere), but I now I am less sure. Maybe some form of dual licensing is necessary if LGPL code is used if the LGPL code would retain its original license?

I see you found the websocket-client license change discussion, so I assume your question about the motivation for the change was resolved by websocket-client #665 (or issue #526 which is related).

engn33r avatar Mar 02 '21 05:03 engn33r