Bluetooth JNI contaminated with GPL header files?

[Jackson Fan]

To Google staff (maybe Nick) who work on BlueZ integration, please
confirm whether you know that GPL code is not cleanly isolated within
user space.
JNI native code examples:
android_bluetooth_BluetoothAudioGateway.cpp
android_bluetooth_HeadsetBase.cpp
android_bluetooth_RfcommSocket.cpp
android_bluetooth_ScoSocket.cpp
are including <bluetooth/bluetooth.h> embraced by condition "#ifdef
ARCH_ARM" in 1.0 release or "#ifdef HAVE_BLUETOOTH" in cupcake.
Those 4 cpp files are claimed as Apache license, but bluetooth.h is a
BlueZ header file under GPL v2 license. So speaking from legal
perspective, license term for those 4 files should be changed to GPL
as well when compiling option HAVE_BLUETOOTH is TRUE.

- What does this mean?

If device manufacturer builds a phone with Bluetooth ON, possibly
there is a legal risk to open all user space native code. Reason is
that Bluetooth JNI as system library code, is linked up with all other
user space libraries via AndroidRuntime.cpp. For example, if one
Android device has a specific RIL implementation to enhance call
performance, then its manufacturer might be asked to open related
native code in user space.
Today we did not see HTC G1(QCOM chip based) experiencing this
problem, perhaps because the BlueZ contributor (QCOM and BlueZ people)
will not sue it. Just kidding...

BTW, I noticed that BlueZ is listed as (L)GPL usage exception in user
space, inside open source project minutes
http://source.android.com/project/core-technical-team/minutes/2009-01-20.
However, from legal point of view it is a risk of contamination - code
claimed as Apache license but actually linked with GPL header files.

[Jackson Fan]

Talking about BlueZ isolation, for RFCOMM socket or SCO it is not easy
to use same method as DBUS for HCID.
Referring to http://source.android.com/projects/bluetooth-faq,
designer may consider BlueZ user space code either be isolated by DBUS
(Free Academic License) for HCID, or by socket for RFCOMM and SCO.
However due to the difficulty to interpret the packets with BlueZ for
sockets, JNI code still need adopt the BlueZ header file for data
structure and definition.
For example:
Function connect_work() in bluetooth_ScoSocket.cpp need use a struct
sockaddr_sco defined within <bluetooth/sco.h> like this:
struct sockaddr_sco addr;
...
memset(&addr, 0, sizeof(addr));
addr.sco_family = AF_BLUETOOTH;
memcpy(&addr.sco_bdaddr, BDADDR_ANY, sizeof(bdaddr_t));
if (bind(sk, (struct sockaddr *) &addr, sizeof(addr)) < 0) {
...

otherwise it is difficult to correctly indicate BlueZ about the
request.

Another example:
BluetoothAudioGateway.cpp is using definition RFCOMM_LM_ENCRYPT from
<bluetooth/rfcomm.h>,
static int setup_listening_socket(int dev, int channel) {
...
lm = RFCOMM_LM_AUTH | RFCOMM_LM_ENCRYPT;
}
...
Although in rfcomm.h RFCOMM_LM_ENCRYPT is simply defined as 0x0004,
it is not suitable to rewrite all such value inside Apache code using
different Const name. You need redo such copying work everytime Bluez
is changing the definition.

Other technical walkarounds might be difficult either, such as pre-
allocating multiple buffers and variables to be used in about 6 JNI
cpp files, and once phone powers on to let BlueZ send a bulk of data
copying header files' content to initialize buffers and variables.
Some people ever used a proxy or agent to isolate BlueZ header files,
and "enjoy" great pain during architecture change and performance
loss.

So reasonable solution: strongly suggest Google to check with BlueZ
header file providers (Qualcomm), and get LGPL license for those
header files being used by JNI code. This way BlueZ part can become a
mixed license similar to webkit.
Additional changes after LGPL license granted, is to remove Bluetooth
APIs from AndroidRuntime.cpp which is a static link format:

extern int register_android_bluetooth_Database(JNIEnv* env);
extern int register_android_bluetooth_HeadsetBase(JNIEnv* env);
extern int register_android_bluetooth_BluetoothAudioGateway(JNIEnv*
env);
extern int register_android_bluetooth_RfcommSocket(JNIEnv *env);
extern int register_android_bluetooth_ScoSocket(JNIEnv *env);
extern int register_android_server_BluetoothDeviceService(JNIEnv*
env);
extern int register_android_server_BluetoothEventLoop(JNIEnv *env);
extern int register_android_server_BluetoothA2dpService(JNIEnv* env);

Then to get Bluetooth JNIs dynamically loaded as a library, like
Webkit's model. This way to avoid overall contamination because if
Bluetooth JNI is as a LGPL library, manufacturers only need open
Bluetooth related files.

[Nick Pelly]

Hi Jackson,

#include <bluetooth/bluetooth.h> is only an interface contract. It
contains only constants and two trivial macros. Therefore there is no
obligation for files that include bluetooth.h to abide by the terms of
the GPL license.

We will soon replace bluetooth.h with an alternate declaration of the
interface contract that does not have the GPL header, so that this
confusion does not arise again.

Nick

[Mattaku Betsujin]

Hmm, this seems to be a really loose interpretation of the GPL .....

I am not sure that triviality is a way out of your GPL obglications.

[David Turner]

It's not actually so loose.

For example, any Linux distribution provides GPL-ed kernel headers that are included
by the LGPL-ed GLibc library headers, which are themselves included by any source code
that depend on the C/POSIX headers (i.e. all of them).

[Mark Murphy]

> Hmm, this seems to be a really loose interpretation of the GPL .....

It's a position that's been debated off and on for over a decade.

See, for example:

http://lkml.indiana.edu/hypermail/linux/kernel/0109.3/0739.html
http://kerneltrap.org/node/1735
http://www.figuiere.net/hub/blog/?2005/01/01/43-gpl-violation
http://mail.python.org/pipermail/python-list/2006-January/360164.html

To quote another similar message:

"Public domain, GPL, etc.. do not apply to non-expressive, factual matter
such as [constants and interface definitions]."

This doesn't mean everything is fine. It does mean that the position Mr.
Pelly expressed (echoed by Mr. Turner while I was writing this) is not "a
really loose interpretation". It is still up to Google/OHA and BlueZ to
settle things out.

--
Mark Murphy (a Commons Guy)
http://commonsware.com
_The Busy Coder's Guide to Android Development_ Version 2.0 Available!

[Jackson Fan]

Hi Nick,

As I menioned in 2nd reply, guess it is not so easy to change
with for isolation. You will have to replace all consts and structures
inside following GPL header files in a "non-apparent" way:
bluetooth.h
hci.h (this is a large one containing definitions, but you are not
using too many fields)
rfcomm.h (this is small one and data not so complex)
sco.h (this is also a small one)
hci-lib.h
I guess the walkaround from code aspect is difficult to
proceed with. Because if you just replace the name of values or
structure fields, you are still using the GPL header's file definition
- i.e., under suspicious mode.

> Nick- Hide quoted text -
>
> - Show quoted text -

[Mike Hearn]

Again - you can't copyright facts, computer APIs are facts, thus
applying a license to them is meaningless.

Where it gets tricky is when headers include significant pieces of
inlined code.

I used to work on Wine and this issue came up every so often.
Importing the header files from Windows directly would have been a
copyright violation because that's an expression of facts, which *is*
protected. But rewriting them to contain those same definitions is
not.

[Jackson Fan]

In latest code, JNI code already links with 3 cleaned up headers
bluetooth.h, rfcomm.h and sco.h inside device\system\bluetooth\bluez-
clean-headers
\bluetooth. As claimed in the copyright notice, only pure facts are
listed so no copyrightable information.