[Libusbx-devel] Linux patches for 1.0.9 release

[Pete Batard]

On 2012.03.28 09:12, Xiaofan Chen wrote:
> I'd like to see more examples distributed to the library user.

Same here.

> Travis has done a good job for libusbK. Maybe similar examples
> can be done with libusbx.
>    http://sourceforge.net/p/libusbk/code/216/tree/trunk/libusbK/examples/
>    http://libusbk.sourceforge.net/UsbK3/examples.html

That'd be nice.

> One thing I'd like to add is libusb0.sys and libusbk.sys integration.
> Ideally it could be after 1.0.11 but before 2.0.

Yeah. I haven't created an entry for 1.0.12 yet, but at the very least, 
it would go there. It may also go into 1.0.11 if we find things are 
moving smoothly.

> Maybe the target
> date will be like 5 months: 1-Sept-2012. But that is again depending
> on the approach to take.

That's cool with me. I'll try to add 1.0.12 when I get a chance.

> If we use Graeme's approach (directly talking to libusb0.sys) then the
> duration may need to be longer.

It will indeed, especially as, and this is something that people do not 
appreciate, Graeme's work has always needed some fixup. He took some 
liberties in his own branch, because he was short of time, which we 
would need to address. He also has stated that he has zero interest in 
supporting his work.

> The advantage is that there is no dependency on libusbk.dll.

That's a false problem. If the dependency on libusbk is an issue, and 
provided the licenses are compatible, we can move the libusbk code we 
need into libusb and remove the dependency altogether. This is actually 
something that I would like to do eventually, as I'm hoping that 
libusbx-1.0 will become the more popular approach to using libusb0.sys 
and libusbk.sys (compared to using the libusb-win32 or libusbk 
libraries), so it would make a lot of sense.

If you have two libraries with source, and their licensing terms are 
compatible, then it's not much of an issue to create a single library to 
remove the dependency. A library is essentially a binary object (.o) 
with some decoration added. But when the whole source is under your 
control, whether you choose to separate object files into separate 
entities (2 libs or one exe and a lib) or a single one is up to you, and 
merging the objects that build 2 libraries into a single one isn't 
something difficult to achieve.

Also, you have to realize that libusbk and Graeme's patch really do the 
same thing, even as their implementation may differ slightly. Thus, in 
terms of code, it doesn't change much whether we go with one or the 
other (and still in terms of code, what Graeme did doesn't strike me as 
better than what Travis did - on the contrary, it takes some dangerous 
liberties here and there, that I asked Graeme to address but that he 
wouldn't).
On the other hand, libusbk has the following major advantages:
- It is in real-world use, with quite a few users, therefore has been 
tried and tested, unlike Graeme's proposal
- It is well maintained and bugs are fixed by its author (which means 
someone else doesn't have to)
- It provides us with BOTH libusbK.sys and libusb0.sys support, whereas 
Graeme's code only provides us with libusb0.sys, which will leave us 
having to do the same thing for libusbk.

All in all, an IMO, reusing libusbk seems to beat the other approach 
hands down.

> If we use libusbk.dll then the duration could
> be shorter. I am more inclined to use Graeme's approach since
> less dependency is a good thing.

As explained above, dependency is not really an issue, as we could very 
easily remove it... provided we can sort the K vs X licensing issue.

Currently K is dual BSD/GPLv3 whereas we are still LGPLv2.

Now, I personally would not have an issue with switching libusbx to 
GPL3, since I actually very much prefer it over any other license, even 
for a library. And for what is worth, that is also the stance of the FSF 
[1].

If libusbx was my project alone, and if I wanted to remove 
dependency/integrate code that was GPLv3, I'd switch libusbx to GPLv3 in 
a heartbeat (since anybody can create a fork of an LGPL work and switch 
it to GPLv3 without asking) whilst leaving people who think they have a 
problem with the new license switch to dynamic linking. Despite how it 
looks, an LGPL -> GPLv3 doesn't exactly equate closing the door on 
anyone - it just means that some people may have to link dynamically 
instead of statically, which, no matter how you want to make it look, 
isn't exactly a big deal.

Then again, that's just me, and I'm pretty sure we have some people here 
who would take a major objection on not being able to statically link 
against libusbx in their proprietary work (or work that can be 
relicensed into proprietary, which is pretty much the same), and who I'd 
expect to go up in arms at the idea of going GPLv3 (But if that's not 
the case, and if there's a majority here who would like to go with 
GPLv3, it will be my pleasure to oblige).

Therefore, we may have to solve a problem with regards to removing the K 
dependency, that has very little to do with a technical hurdle, but 
everything to do with licensing.

NB: As an aside, and just in case you wonder, the only reason I have 
other projects with parts that aren't GPLv3 (such as libwdi who is 
mostly LPGLv3 with some exceptions, such as Zadig, which is GPLv3), is 
precisely because I expect people to take an objection otherwise and, in 
as much as it doesn't become an issue, I will try to be permissive. But 
as Xiaofan and Travis can attest, there's only so far I will go there.

> For 1.0.11, there is a big thing which may need to be delayed
> depending on Mac OS X resources -- Mac OS X HID backend.

Yeah, that's why I broke the task in two entities, with OS-X being a 
separate one that we can move separately if needed.
AFAIK, there's nothing we should need to do for HID support in 
OpenBSD... or is there?

> On the other hand, some HIDAPI codes may be used as a
> reference.

The thing is, if I had the time, I wouldn't mind producing the HID 
implementation on OS-X, for the sole reason that this is pretty much how 
I approached creating the libusb/Windows backend in the first place: 
"This looks like a nice little challenge in an area I'd like to become 
familiar with". If Peter hadn't forcibly removed HID support on Windows, 
and since Nathan stated that he wouldn't add it for OSX, I probably 
would have had a look at it already...

Regards,

/Pete

[1] http://www.gnu.org/licenses/why-not-lgpl.html