LibUSB for Xojo in next MBS Plugins

Quite a few Xojo developers use our MBS Xojo USB Plugin to connect to devices, do measurements, exchange data and query information for their applications. Wether this is a scale to weight items, barcode devices, various sensors or just a special label printer, we do provide classes to help you.

For some time now we got HIDAPI classes to replace the older MacHID, LinuxHID and WinHID classes to provide a cross platform interface for USB devices with HID protocol.
And now we replace MacUSBConnect and WinUSB classes with our new LibUSB classes.

The new plugin classes are based on the open source LibUSB library, which works on MacOS, Windows and Linux. With quite a few Linux distributions, it comes preinstalled. The library itself is licensed LGPL, so you can load it in commercial applications, but distribute it as DLL/so/dylib file.

The new LibUSBDeviceMBS class provides functions to list devices and query information. You can open a connection to a device and transfer data as needed. The example project lists all the devices and even works nice on Raspberry Pi.

Will be included in next prerelease or if you like to try now, please do not hesitate to contact us.

Shouldn’t that be can’t?

Can is right.
GPL is not okay, but LGPL is okay.

LGPL has the caveat that you can use it in a commercial application without the need to open source the commercial app so long as you include/make available the source code for the library as part of your app. For example, the C library is LGPL or you wouldn’t be able to create ANY commercial, closed source app for Linux at all. Wikipedia’s discussion is actually right on for a change:

[quote]The GNU Lesser General Public License (LGPL) is a free software license published by the Free Software Foundation (FSF). The license allows developers and companies to use and integrate software released under the LGPL into their own (even proprietary) software without being required by the terms of a strong copyleft license to release the source code of their own components. The license only requires software under the LGPL be modifiable by end users via source code availability. For proprietary software, code under the LGPL is usually used in the form of a shared library, so that there is a clear separation between the proprietary and LGPL components. The LGPL is primarily used for software libraries, although it is also used by some stand-alone applications.

The LGPL was developed as a compromise between the strong copyleft of the GNU General Public License (GPL) and more permissive licenses such as the BSD licenses and the MIT License. The word “Lesser” in the title shows that the LGPL does not guarantee the end user’s complete freedom in the use of software; it only guarantees the freedom of modification for components licensed under the LGPL, but not for any proprietary components.[/quote]

Hi Tim, can you explain that a little more for someone not familiar with legal issues and English language?

Example: I’m going to use a LGPL plugin and I will include the library with my app. The person released the library as freeware and the zip file does not include the source code, just the library/plugin. If my app is commercial do I need to ask for the source code and include it with my app? The “as part of your app” confuses me, my translation could be “as part of your .exe and not as a .dll”, but it also be “even as .dll if your app needs it”.

We are not lawyers and this is not a legal advise.

LGPL plugin doesn’t sound like it would be possible, as you hard link the plugin into the app. Which would make your app at least LGPL.

For my plugin (commercial), well it has the possibility to load a DLL under LGPL license. And user can bring their own DLL and the app can life without DLL, but may have less features.

when it comes to legal things, I would always suggest talking to a lawyer.

Having lived in the GPL/LGPL world since 1994 (BRU was the first commercially available application for Linux and FreeBSD/BSD386), what we are doing here doesn’t require legal advice as we are just discussing the general nature of these licenses. My lawyers have made it very clear to me and my team as to where the line is drawn. However, if the discussion leaves you with the slightest doubt, communicating with an Intellectual Property lawyer is definitely the way to go.

First, if you are using an LGPL library and the creator is not providing the source code, they are already breaking the rules of LGPL. You should ask them about the source code and remind them that it’s required for their tool to be LGPL.

Here’s an analogy that a member of the FSF team came up with back in the early days of the GPL as to why the LGPL was needed:

Imagine if concrete was a licensed building material and that every time you built a building that used concrete you have to turn ownership of your house over to the manufacturer of the concrete. That analogy is the GPL - the concrete (library/APL) is restricting your ownership of your building (App) - you can’t build the building without the concrete, but the restriction for use of concrete forces you to give up your work.

In another instance, the concrete manager retains ownership of the concrete, but allows you to build your building and retain ownership - so long as you don’t claim ownership of the concrete used and don’t restrict the person who buys the building from you from replacing your concrete with another brand or type of concrete. That is the LGPL. You still need the concrete, but the manufacturer of the concrete let’s you retain ownership of your building design and construction.

In a third scenario, the manufacturer of the concrete has released the formulation to the world and allows you to use it, modify it, claim it for you own, and take full responsibility for it. That is the BSD license.

In almost any compiled app, you depend on a lot of external libraries for the app to run - especially on Mac OS where they do not allow you to statically compile your app (that is a very different rant of mine). if you dig deeply into the license text for most development tool sets, you will find text that states that you are allowed to link against the development platform libraries without assigning rights to your application to the creator of the libraries. Imagine if every application running on Windows or Mac OS had to be handed over to Microsoft or Apple just because you were using their graphics API and libraries. The Xojo Framework libraries that are included in your compiled project is another example - since they provide a license for you to build commercial applications that use the functionality of the Xojo frameworks, you don’t have to assign the rights and ownership of your application over to Xojo.

The LGPL simply means that as long as the .so/.dylib/.DLL library file that you are using in your application is separate from your compiled code (supposedly so that the user could replace the said library with a different version), you can call the functionality of the library from your app without the need to release your app as open source. The only restriction being that you make the source code available if a user requires it and that if you make any modifications to the LGPL code, you submit those changes back to the original author(s) of the LGPL code.

Thank you all for you comments.

Tim, special thanks for taking the time to explain things with such detail. Now I understand that you can’t:

  • use GPL code unless you want your code to become GPL
  • say your code is LGPL if you don’t release the source
  • keep control of changes to your code if you release it as BSD

Christian, sorry for the off-topic question. Keep up the great work you do.

I think this is not correct.

if you use code under GPL, your code becomes GPL.
But that is not happening for LGPL or BSD.

Just with LGPL you need to let people rebuild the LGPL part and use a newer version of DLL.