Hi I’m currently working on a substantial project (On my own) which must meet specific requirements imposed by myself and an organization (University) and I’m in need of some pointers in the direction that I can go with developing a feature that’s causing a headache with regards to licensing.
The main part of this feature is to be able to distribute certificates in a secure way with no possibility of a middle man attack at a physical location. In the project brief, it was noted, Bluetooth would be the option selected for this task though not a requirement for the functionality of the software. This means that Bluetooth is the ideal solution but where Bluetooth is unavailable, other solutions (Networked, hardwired or other means of communication) are options.
Essentially Bluetooth should be used as an option for the user to use if hardware is available.
The caveat for this project however is that the source code must remain undisclosed to the end user. This means the license for the software can’t be GPL or LGPL. However this is causing issues as the project must be able to run on a wide variety of hardware and OS’s. The main target platform being Linux on a Raspberry Pi 3/Pi Zero W.
So going by this, the software needs to access the Bluetooth hardware on the raspberry pi and in the process, not inherit the GPL license. For the purposes of this project, Java is used as it allows for developing to multiple platforms at once without requiring multiple variants of the software.
So I have been looking at options for Bluetooth in Linux that can be interfaced with Java. The first and most common solution is BlueCove. Licensed under Apache 2.0 in Windows and Mac however requires a GPL license under Linux.
This obviously causes issues with the source code requirement of the project.
The caveat (Or loophole for Free software fanatics) is that the GPL license isn’t inherited where a proprietary software can interface with a GPL Licensed software at an arms length where both applications serve a purpose and don’t rely on each other to run. By definition, A GPL API compiled into software won’t work, A wrapper of a GPL API also is invalid as it holds no value outside of the specific application. But a hardware manager with applications beyond your application where they communicate at arms length will be fine? Also dynamically linking to a LGPL API is also fine while hard coded (Compiled) linking is not.
I’m struggling to wrap my head around this licensing issues. I believe I have found a LGPL library that can be used dynamically but that’s another headache to use as the question of what is considered static vs dynamic linking in Java is complicated. And I’m not 100% sure what direction I should go.
The question of interfacing with another program over bash might be fine? I’m really not sure either way.
Is there anyone who can point me in the right direction? Best software to use on Linux to get around the licensing issues or an alternative?
The issue with that is the linux bindings are GPL which is the whole issue. As soon as I’m using a GPL licensed API, I need to include source code for my code, even if it’s just one features or even a single line of code.
The GPL says that you have to relicense regardless of static or dynamic linking, but the current legal prior art states that clause is absolutely not enforceable. If you use an interpreted language (python, perl, ruby) or take care to dynamically link the needed libraries, you’re 100% in the clear.
also if you’re interfacing with a liberally licensed library that itself links GPL code, you’re also totally fine as long as you keep that link dynamic.
The issue is more API’s than software. I’m trying to find software that allows for dynamic linking but the use of GPL API’s in the industry is causing issues.
From what I can see, the people behind the API don’t want the GPL license imposed on their api itself but are forced due to using something that requires it.
as long as an API isn’t AGPL you should still be fine, just don’t compile them into your binary.
What most devs do is fork whatever they need onto a public git repo, then just redistribute the dynamically linked stuff that points to those github/lab repo to comply with the forks’ licenses without having to statically link for easy packaging.
Is seems like the bluecove people have an overly naive interpretation of their licensing requirements
From what I can see, As long as I’m not copying the code and using it as a library, Java’s import features of external libraries is in fact dynamic linking in itself. So using and LGPL should be fine in any instance for Java.
The only thing after spending today reading over so much jargon in Stack overflow and other forums/blogs and whatnot is that the open source community is very strict on the interpretation of GPL and so are the people behind GNU. Whether that’s actually enforceable is another question but I have seen comments that they do sue to attempt to hold the integrety of their copyright license. https://encodable.com/tech/blog/2006/02/25/Why_the_GPL_is_Incompatible_with_Commercial_Software
It seems GPL is very absolute in their definition to enforce the “infection” of their license. The other side is to reduce any backlash from the open source community for not explicitly following the GPL license. Though I’m getting ahead of myself there.
That appears to be true as per gnu.org though they hide it and removed it with v3
Does the libstdc++ exception permit dynamic linking?
Yes. The intent of the exception is to allow people to compile proprietary software using gcc.
I understand the reason behind it though if they stuck with the LGPL standard for most things, allowing for the use of free software in a proprietary environment and only forcing the sharing of source code of modifications of the free software itself, that would be great. Community driven evaluation and development of free software is great but when it comes to proprietary software, the user is given too much power. I don’t believe the user should have the right to see all source code of specific software. Rather given the right to chose between copy left and copy right software. The way at least GPL v3 is written means that if a proprietary needs a feature that can only be developed using software licensed under GPL v3, then it’s either give away hard work that should be rewarded to hard working developers or tough luck, either develop your own software that does the same job without breaching copyright or give up.
That’s especially hard when source code isn’t readily available for all software under GPL licenses and with some behind a distribution pay wall.
They would never do this, they are a political organization and liberally licensed software does better under bsd style conditions anyway. People don’t license GPL for practical reasons.
and literally every de-facto standard with the exception of 2 pieces of software in the open source world is non-GPL OSS licensed. This is not a coincidence.
The FSF and the GPL are perpetual motion machines. They stay relevant by pushing themselves uneccessarily into an ecosystem that would be healthier without them.
In practical terms, the GPL evaporates community support and cloisters it in the same burdened ecosystem that created it. If you want plenty of best effort and monetary support for your project, MIT, BSD or apache licenses will ensure that companies that do use it will contribute and backport, because maintaining their own fork makes no sense from a business perspective. It also ensures regular devs will be able to incorporate your work into anything they need it for, and through increased practical use, find and fix problems collaboratively
The GPL is essentially the same thing as getting a protective patent license for a pipe fitting, and then restricting its use to hydraulics systems that release their designs under your patent agreement. You may or may not have the best tool for the job, but no one will use it outside of hobbyists dicking around in their shops at home.
You could compile multiple times, not a big deal, probably preferable to running jre on pi w.
IANAL
Wrap GPL software using some GPL compatible RPC API wrapper that you can opensource. And use that from your proprietary code. Make sure you distribute the two pieces separately so end user can pick and choose what to install.
Yes, but distribute separately.
Basically, nobody can prohibit you from publishing stupid software (wrapper), nobody can prohibit the end user from trading their freedoms. You can use those two principles.
Well I finally managed to interface with BlueZ (GPL) through a LGPL licensed library so I won’t be using BlueCove anyway.
Just on the off chance that the GPL license does cause issues.
And even though BlueZ is under GPL, it’s considered part of the kernal and therefor falls under the exemption of dynamic linking for kernal software.
