On Sun, 19 Apr 2015 13:31:14 +0200, Emmanuel Blot <eblot...@gmail.com> wrote:
> A quick note about the licensing scheme of pyftdi (and friends). > Some parts are LGPL-licensed because I've initially developed cftdi on > top of libftdi - a Python-to-C wrapper for libftdi, and used an API > which is very close to libftdi, which is released as LGPL. > ... > I have no objection to move to MIT license the whole pyftdi > package, I just do no want to deal with this licensing nightmare. I understand. I think what I was proposing was less drastic: I think the UsbSerial class (and indeed the whole serialext package) is more general than just for FTDI chips, and would make more sense as a part of pyusb. Then all different USB-serial chip drivers, including pyftdi, could share it as common code. In my first message I wondered whether pyusb wanted to grow beyond just wrapping libusb, but then I read this in pyusb's README.rst: > Until 0.4 version, PyUSB used to be a thin wrapper over libusb. > With 1.0 version, things changed considerably. Now PyUSB is an > API rich, backend neutral Python USB module easy to use. That convinces me even more that for pyusb to absorb the serialext common code and UsbSerial base class from pyftdi would make sense all around. I think everything in serialext already *is* BSD licensed, so that much should be easy. The only sticking point is that it makes some incidental use of UsbTools from the LGPL part of pyftdi. The most significant thing used there is parse_url. Did you also derive parse_url from something in libftdi? I just looked over the libftdi API and I didn't see something similar. If parse_url was something you added, then maybe it is not a problem for you to BSD license it to match the serialext code, and it could also be raised to the status of something more general in pyusb, where it could unify the way you specify a device whether pyftdi or something else is the driver. In fact, if we could do that, it might be worth thinking out a url scheme that applies even to non-serial USB devices. I was just setting something up recently to talk to a device that needs only control transfers, not a whole serial interface, and it would be nice to be able to specify that device as a URL also. I'm only beginning to think about what a general usb url scheme might look like, so take this as brainstorming, but maybe the 'scheme' portion should just be 'usb://' and I could pass something like usb://0x067b:0x2303 as an argument to a script that just does a pyusb device lookup and a control transfer. Or if I have a script that expects some kind of serial port and uses pyserial. I could pass it /dev/ttyS0 or /dev/ttyUSB0 if the kernel driver is in place, or usb://0x0683:0x1550?driver=ftdi and it gets a Serial instance in every case and Just Works. If the url scheme gets generalized a bit away from what's now in pyftdi, maybe that also moots the license question around the existing parse_url. But perhaps it is still good to BSD license the existing parse_url if that is possible, just so there is less to worry about. What do you think? -Chap ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ pyusb-users mailing list pyusb-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pyusb-users
