Hi all!
I'm currently developing a (C++) Bluetooth (server) application under Linux=
, =
and recently noticed that the BlueZ library (-lbluetooth) is licensed under =
the GPL, at least according from the bluez-libs sources which I was scannin=
g =
for documentation (and according to quite a few mails on this list from =
others asking, but which never seem to gather enough interest to =
actually "deserve" a longer and more detailed reply than "yes, it is").
The BlueZ website documentation and FAQ pages have no single mention of =
linking (or, rather, not linking) BlueZ against commercial apps, though, =
which I gather should be put there at some update (for helpless souls like =
me... :-)).
Anyway, as my application links against -lbluetooth for SDP service =
registration (and also has source files include bluetooth/bluetooth.h and =
others for the AF_*- and similar constants to open and manage server socket=
s =
offered by the kernel modules), I don't see a big chance of keeping BlueZ a=
s =
my bluetooth stack, though, as the SDP service registration architecture =
isn't offered through the D-BUS interface yet (at least not according to th=
e =
documentation, if I understood that properly), and neither is server socket =
creation. Is this true?
Finally: is anyone feeling qualified and interested enough to properly expl=
ain =
to what extent BlueZ can and/or cannot be used in commercial (bluetooth =
server, in my case an implementation of the server-side of the OBEX File =
Transfer Profile) applications? I'm thinking of the fact that the constants =
that define Bluetooth sockets (in bluetooth/*) are specific to BlueZ and ar=
e =
GPL-marked by the file headers, but the kernel headers that define other =
Linux-specific constants have all been stripped of a license completely, =
which might, but not necessarily must mean something, as if I include a =
header file I don't link code, but only data.
Thanks in advance! I'd hate to be having to move to FreeBSD... :-)
-- =
Heiko Wundram
Product & Application Development
-------------------------------------
Office Germany - EXPO PARK HANNOVER
=
Beenic Networks GmbH
Mail=E4nder Stra=DFe 2
30539 Hannover
=
Fon +49 511 / 590 935 - 15
Fax +49 511 / 590 935 - 29
Mail [email protected]
Beenic Networks GmbH
-------------------------------------
Sitz der Gesellschaft: Hannover
Gesch=E4ftsf=FChrer: Jorge Delgado
Registernummer: HRB 61869
Registergericht: Amtsgericht Hannover
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
Having read further comments by the OP, it sounds like he needs more than
just a simple constant to describe how to bind a socket, but actually a
bunch of structures to define the API. In which case, I'd agree that the
only way to remain compliant is to make a GPL bridge to some other
interface, although the GPL also makes this process a massive legal quagmire
too (e.g. if the bridge is GPL, so is everything that uses it, if the bridge
relies on an external bridge in order to be built, that also must be GPL,
...)
I fully respect your decision to license with the GPL, and apologies in
advance for dragging this out further, but as a developer that finds that
GPL massively complicates other open-source development [basically if you
provide your software as binaries as well as source to make life easier for
end-users, you are suddenly obligated to mirror the source for all your
dependencies, which is frankly difficult for most OSS hobbyists], I find it
quite frustrating when people confer even more restrictions into the GPL
than actually exist in the terms of the licence. You neatly summed it up
with:
> You wanna use software from the community so you have to play with our
rules.
However, GPLv2 explicitly states in the preamble that does not cover how you
use the software, only you how you copy, distribute and modify it.
> You read GPL code and this would make it derived work.
The act of "reading GPL code" does not make anything a derived work. The act
of copying or inclusion of part or all of it is what makes something a
derived work.
I can legally state a fact about the software - e.g. "it uses 532 bytes of
kernel RAM", "it runs on port 80", "it provides socket family 42", etc
without violating any terms of the GPL. What I can't do is copy any part of
that software verbatim.
But more worrying, is this thinly veiled threat:
> > The number itself isn't covered by the GPL however. The constant name,
> > I'm less sure about, but I see no reason why you couldn't define your
> > own constant FAMILY_BLUETOOTH which happens to have the same value as
> > a publically known magic value.
> contact a lawyer before making such statements.
I agree that the OP would be well advised to involve a lawyer, but my
personal opinion was clearly labeled as such, and anyone making a commercial
decision based on a personal opinion from someone they know know nothing
about only has themselves to blame, frankly. Just to make it clear, I am not
in a position to offer legal advice.
But, just to clarify... why do you say I need a lawyer? Because I said
something you didn't like, or because I was defamatory to the product, or
because the contract was under NDA?
In any case, this particular constant also happens to be defined in
<bits/socket.h> which is distributed as part of glibc and explicitly
licensed as LGPL, which allows the header file to be included in commercial
works as long as that doesn't cause any code to be inlined or linked. Or are
you saying that glibc is non-compliant with the GPL?
Cheers,
Ralf.
Am Freitag 06 Juli 2007 um 08:09:25 schrieb Marcel Holtmann:
> the D-Bus IPC is a public API with no restrictions. You only have to
> obey with the license of the bindings. However make sure that you don't
> link -lbluetooth into your application. If you do then it becomes GPL.
> And just as a side note. The OpenOBEX library can become GPL, too. So
> you better should involve a lawyer at some point.
I'm not using OpenOBEX; the OBEX (packet parser and builder) implementation=
in =
the product I'm talking about is done from scratch (or rather, from the =
specs) completely by us (and will be released under a BSD-style license, bt=
w, =
once I finish it up). The decision to implement OBEX on our own was driven =
by =
the need for a "proper" object (meaning C++) model for OBEX, which simply =
isn't (easily) possible with OpenOBEX.
So, it's pretty much only BlueZ I was concerned about, and that's why I cam=
e =
here.
> The D-Bus API works perfectly fine for Nokia and Access. It will also
> work for OpenMoko. The decisions behind its design are driven by the
> applications need.
Yup, that's why I asked. But, again, the important points I need the wrappe=
r =
library (D-BUS in this case) to have is service registration (which you say =
is possible, and I'll have to recheck the sources for the way to do that, =
because it's not stated anywhere specifically in the Wiki) and RFCOMM =
server-socket support (which you didn't say anything about, so I guess it's =
not).
By the way: even if server socket support were available in the D-BUS API (=
and =
which I'd happily agree to write), how would you want to map that to the =
D-BUS IPC model? Mapping server socket creation and handling to an IPC-API =
is =
slightly... Strange. Simply because either you handle the socket completely =
transparently and only pass the data send/received (which would mean that =
most of the application dispatcher logic is part of the "wrapper", but whic=
h =
would introduce different problems because of the inherently difficult natu=
re =
of trying to map a server-client model over a client-server model), or you =
pass the accepted socket directly to the application by some means of =
SCM_RIGHTS control message. But, all of this isn't clean for me in any =
acceptable definition I have of "clean" code and application modelling.
And, on a second note: small- to medium-scale product only meant that I don=
't =
have the means to implement a Bluetooth stack on my own. Which is what I'd =
need to do, simply because any form of "raw" Bluetooth communication is =
disallowed in non-GPL'd code (even implementing SDP on my own) by having =
bluetooth.h and the other protocol-defining headers be GPL'd, see my reply =
to =
Ranulf.
> To be quite honest. That is not my problem. I am not making any money
> with selling a Bluetooth solution. However it seems that the current
> solution is enough for the Nokia N800 and other commercial systems and
> so I don't see your problem. If you wanna simply have a cheap solution
> that is developed by someone else and that you can use in potential
> products to make money with, you might wanna re-think your business
> model.
I said, just to repeat it, that I didn't want to complain about the licensi=
ng =
decision you as the maintainer and the other contributors of BlueZ have =
taken. The GPL is a perfectly sensible license, and using "GPL-circumventin=
g" =
code like IPC also works smoothly on most tasks where the system you're =
trying to map fits into an IPC client-server model anyway. But, especially =
with server socket code, it will not.
> Let me make this bluntly clear. The BlueZ project moves with the needs
> of its users, but users that don't contribute have no say whatsoever. I
> simply don't care. So if you want changes or additions, then start
> working on them and play with the open source rules and be active in the
> community.
You don't have to educate me about open source rules; maybe you'd just chec=
k =
up my name on Google Code to see contributions to large open source project=
s =
I have done in the past. I simply thought that maybe you'd point me in a =
direction, possibly also in a direction where I could contribute code (whic=
h =
is fine by me), where BlueZ would be usable for the need I have. Finally, I =
don't want to make this an ideological discussion, but simply thought that =
because the Website doesn't include a single line of text in what respect =
BlueZ is used/usable in commercial applications, that some feedback from th=
e =
developers is sensible. And I guess that basically we've fixed what's =
possible and what's not.
-- =
Heiko Wundram
Product & Application Development
-------------------------------------
Office Germany - EXPO PARK HANNOVER
=A0
Beenic Networks GmbH
Mail=E4nder Stra=DFe 2
30539 Hannover
=A0
Fon =A0 =A0 =A0 =A0+49 511 / 590 935 - 15
Fax =A0 =A0 =A0 =A0+49 511 / 590 935 - 29
Mail =A0 =A0 =A0 [email protected]
Beenic Networks GmbH
-------------------------------------
Sitz der Gesellschaft: Hannover
Gesch=E4ftsf=FChrer: Jorge Delgado
Registernummer: HRB 61869
Registergericht: Amtsgericht Hannover
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Heiko,
> > This is not fully true. You need soem glue layer which needs to be GPL or
> > LGPL. Check http://www.tomtom.com/page.php?Page=gpl for examples.
> >
> > And I think you agree that the Tom Tom Navigation systems are commercial
> > products.
>
> Totally true, and that's why I asked about the D-BUS interface because that is
> (supposedly, as it's LGPL-licensed) a glue layer which would work for my case
> (without me having to implement the glue code).
the D-Bus IPC is a public API with no restrictions. You only have to
obey with the license of the bindings. However make sure that you don't
link -lbluetooth into your application. If you do then it becomes GPL.
And just as a side note. The OpenOBEX library can become GPL, too. So
you better should involve a lawyer at some point.
> But generally, this means that in case the available glue layers don't fit my
> need, I will have to write a glue layer between my commercial application and
> BlueZ, which not only costs resources and time but also makes the application
> more complex (and error-prone, because of blown code size and the need for
> IPC, as wrapping BlueZ in another library would defeat the purpose of the
> GPL-circumventing glue code), which is generally not acceptable for the
> small- to medium-scale fully integrated solution we're currently working on.
The D-Bus API works perfectly fine for Nokia and Access. It will also
work for OpenMoko. The decisions behind its design are driven by the
applications need.
> Anyway, I respect the licensing decision on the BlueZ developers part fully,
> which is not what I'm trying to debate about. But, as I said, as long as
> there is no fully functional glue code which works out of the box with
> commercial applications - the socket-API being one form of such glue code
> (but because that requires a GPL'd header to actually function, think of
> AF_BLUETOOTH defined only in bluetooth/bluetooth.h, it's out of the
> question) - BlueZ is simply unusable for our current needs, and I guess quite
> a lot of other commercial Bluetooth developers would feel the same.
To be quite honest. That is not my problem. I am not making any money
with selling a Bluetooth solution. However it seems that the current
solution is enough for the Nokia N800 and other commercial systems and
so I don't see your problem. If you wanna simply have a cheap solution
that is developed by someone else and that you can use in potential
products to make money with, you might wanna re-think your business
model.
Let me make this bluntly clear. The BlueZ project moves with the needs
of its users, but users that don't contribute have no say whatsoever. I
simply don't care. So if you want changes or additions, then start
working on them and play with the open source rules and be active in the
community.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Ranulf,
> > the socket-API being one form of such glue code
> > (but because that requires a GPL'd header to actually
> function, think of
> > AF_BLUETOOTH defined only in bluetooth/bluetooth.h, it's out
> of the
> > question)
>
> The number itself isn't covered by the GPL however. The constant name,
> I'm less sure about, but I see no reason why you couldn't define your
> own constant FAMILY_BLUETOOTH which happens to have the same value as
> a publically known magic value.
contact a lawyer before making such statements. How do you learned about
that number. You read GPL code and this would make it derived work. Be
really careful. The licenses are in place for a reason. You wanna use
software from the community so you have to play with our rules. If you
don't want that, then you can always buy a Bluetooth stack from someone
else.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
QW0gRG9ubmVyc3RhZyAwNSBKdWxpIDIwMDcgdW0gMTM6MDQ6Mzggc2NocmllYiBSYW51bGYgRG9z
d2VsbDoKPiA+ID4gdGhlIHNvY2tldC1BUEkgYmVpbmcgb25lIGZvcm0gb2Ygc3VjaCBnbHVlIGNv
ZGUKPiA+ID4gKGJ1dCBiZWNhdXNlIHRoYXQgcmVxdWlyZXMgYSBHUEwnZCBoZWFkZXIgdG8gYWN0
dWFsbHkgZnVuY3Rpb24sIHRoaW5rCj4gPiA+IG9mIEFGX0JMVUVUT09USCBkZWZpbmVkIG9ubHkg
aW4gYmx1ZXRvb3RoL2JsdWV0b290aC5oLCBpdCdzIG91dCBvZiB0aGUKPiA+ID4gcXVlc3Rpb24p
Cj4KPiBUaGUgbnVtYmVyIGl0c2VsZiBpc24ndCBjb3ZlcmVkIGJ5IHRoZSBHUEwgaG93ZXZlci4g
VGhlIGNvbnN0YW50IG5hbWUsIEknbQo+IGxlc3Mgc3VyZSBhYm91dCwgYnV0IEkgc2VlIG5vIHJl
YXNvbiB3aHkgeW91IGNvdWxkbid0IGRlZmluZSB5b3VyIG93bgo+IGNvbnN0YW50IEZBTUlMWV9C
TFVFVE9PVEggd2hpY2ggaGFwcGVucyB0byBoYXZlIHRoZSBzYW1lIHZhbHVlIGFzIGEKPiBwdWJs
aWNhbGx5IGtub3duIG1hZ2ljIHZhbHVlLgoKSSB3b3VsZG4ndCBiZSB0b28gc3VyZSB3aGV0aGVy
IHRoZSBudW1iZXIgaXNuJ3QgY292ZXJlZCBieSB0aGUgR1BMIGluZGlyZWN0bHksIApzaW1wbHkg
YmVjYXVzZSBJIGJlY29tZSAidGFpbmVkIiB3aGVuIHVzaW5nIHRoYXQgbWFnaWMgdGhlIG1vbWVu
dCBJIGhhdmUgdG8gCmxvb2sgYXQgdGhlIEdQTCdkIHNvdXJjZXMgdG8gZ2V0IGl0cyB2YWx1ZS4g
V2hpY2ggaXMgc2ltcGx5IGFsd2F5cyB0aGUgY2FzZSwgCmJlY2F1c2UgdGhlIHZhbHVlIGRlZmlu
ZWQgZm9yIEFGX0JMVUVUT09USCBpc24ndCAic2VsZiBleHBsYW5hdG9yeSIgb3IgdXNlZCAKaW4g
c29tZXRoaW5nIEkgY2FuIHJldmVyc2UtZW5naW5lZXIgaW4gYSBjbGVhbi1yb29tIGVudmlyb25t
ZW50LCBsaWtlIGEgZmlsZSAKZm9ybWF0LCBidXQgcmF0aGVyIG9ubHkgaW4gYmx1ZXRvb3RoLmgg
YW5kIHRoZSBrZXJuZWwgc291cmNlcywgYm90aCBvZiB3aGljaCAKYXJlIEdQTCdkLiBPa2F5LCBJ
IGNvdWxkIGdldCBhdCB0aGUgdmFsdWUgImNsZWFuLXJvb20iIGJ5IHJldmVyc2UtZW5naW5lZXJp
bmcgCmEgY29tcGlsZWQgR1BMJ2QgYmluYXJ5LgoKT24gYSBkaWZmZXJlbnQgbm90ZSwgdGhlIGxl
Z2FsIGV4cGVydGlzZSByZXF1aXJlZCBzaW1wbHkgdG8gZ3Vlc3MgKHRoYXQncyB3aGF0IApJJ20g
ZG9pbmcgYXQgdGhlIG1vbWVudCwgYW5kIGFsc28gcGxheWluZyBhZHZvY2F0dXMgZGlhYm9saSBh
IGxpdHRsZSBiaXQpIAp3aGF0IHBhcnQgb2YgdGhlIEFQSSBJIGNhbiB1c2UgYW5kIHdoYXQgcGFy
dCBub3QgaW4gYSBjb21tZXJjaWFsIGFwcGxpY2F0aW9uIAppcyB3aGF0IGRyaXZlcyBtZSBvZmYu
IFRoYXQncyB3aHkgSSByZXF1ZXN0ZWQgYSBxdWFsaWZpZWQgY29tbWVudCBmcm9tIG9uZSBvZiAK
dGhlIEJsdWVaIGRldmVsb3BlcnMgaW4gbXkgb3JpZ2luYWwgbWFpbCwgc2ltcGx5IGJlY2F1c2Ug
YWxsIG9mIHRoaXMgaXNuJ3QgCmZpeGVkIChhdCBsZWFzdCBub3QgZm9yIG1lKSwgYW5kIEkgd291
bGRuJ3Qga25vdyBob3cgcGVvcGxlIHdvdWxkIHJlYWN0IGlmIEkgCndlcmUgdG8gInJlZGVmaW5l
IiBhbGwgb2YgdGhlIG1hZ2ljIGNvbnN0YW50cyBvZiBibHVldG9vdGguaCBhbmQgcmZjb21tLmgg
Cih3aGljaCBpcyBxdWl0ZSBhIGZldykgaW4gYSBwcml2YXRlIGhlYWRlci4KCi0tIApIZWlrbyBX
dW5kcmFtClByb2R1Y3QgJiBBcHBsaWNhdGlvbiBEZXZlbG9wbWVudAotLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tCk9mZmljZSBHZXJtYW55IC0gRVhQTyBQQVJLIEhBTk5PVkVS
CsKgCkJlZW5pYyBOZXR3b3JrcyBHbWJICk1haWzDpG5kZXIgU3RyYcOfZSAyCjMwNTM5IEhhbm5v
dmVyCsKgCkZvbiDCoCDCoCDCoCDCoCs0OSA1MTEgLyA1OTAgOTM1IC0gMTUKRmF4IMKgIMKgIMKg
IMKgKzQ5IDUxMSAvIDU5MCA5MzUgLSAyOQpNYWlsIMKgIMKgIMKgIHd1bmRyYW1AYmVlbmljLm5l
dAoKCkJlZW5pYyBOZXR3b3JrcyBHbWJICi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0KU2l0eiBkZXIgR2VzZWxsc2NoYWZ0OiBIYW5ub3ZlcgpHZXNjaMOkZnRzZsO8aHJlcjog
Sm9yZ2UgRGVsZ2FkbwpSZWdpc3Rlcm51bW1lcjogSFJCIDYxODY5ClJlZ2lzdGVyZ2VyaWNodDog
QW10c2dlcmljaHQgSGFubm92ZXIKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KVGhpcyBTRi5uZXQgZW1haWwg
aXMgc3BvbnNvcmVkIGJ5IERCMiBFeHByZXNzCkRvd25sb2FkIERCMiBFeHByZXNzIEMgLSB0aGUg
RlJFRSB2ZXJzaW9uIG9mIERCMiBleHByZXNzIGFuZCB0YWtlCmNvbnRyb2wgb2YgeW91ciBYTUwu
IE5vIGxpbWl0cy4gSnVzdCBkYXRhLiBDbGljayB0byBnZXQgaXQgbm93LgpodHRwOi8vc291cmNl
Zm9yZ2UubmV0L3Bvd2VyYmFyL2RiMi8KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KQmx1ZXotZGV2ZWwgbWFpbGluZyBsaXN0CkJsdWV6LWRldmVsQGxpc3Rz
LnNvdXJjZWZvcmdlLm5ldApodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0
aW5mby9ibHVlei1kZXZlbAo=
>
> > the socket-API being one form of such glue code
> > (but because that requires a GPL'd header to actually function, think of
> > AF_BLUETOOTH defined only in bluetooth/bluetooth.h, it's out of the
> > question)
>
The number itself isn't covered by the GPL however. The constant name, I'm
less sure about, but I see no reason why you couldn't define your own
constant FAMILY_BLUETOOTH which happens to have the same value as a
publically known magic value.
You'd only be using standard POSIX interfaces at that point.
Ralf.
Am Donnerstag 05 Juli 2007 um 11:20:31 schrieb Peter Wippich:
> This is not fully true. You need soem glue layer which needs to be GPL or
> LGPL. Check http://www.tomtom.com/page.php?Page=3Dgpl for examples.
>
> And I think you agree that the Tom Tom Navigation systems are commercial
> products.
Totally true, and that's why I asked about the D-BUS interface because that=
is =
(supposedly, as it's LGPL-licensed) a glue layer which would work for my ca=
se =
(without me having to implement the glue code).
But generally, this means that in case the available glue layers don't fit =
my =
need, I will have to write a glue layer between my commercial application a=
nd =
BlueZ, which not only costs resources and time but also makes the applicati=
on =
more complex (and error-prone, because of blown code size and the need for =
IPC, as wrapping BlueZ in another library would defeat the purpose of the =
GPL-circumventing glue code), which is generally not acceptable for the =
small- to medium-scale fully integrated solution we're currently working on.
And, most importantly, we don't have a team of programmers like TomTom does=
to =
develop this glue.
Anyway, I respect the licensing decision on the BlueZ developers part fully=
, =
which is not what I'm trying to debate about. But, as I said, as long as =
there is no fully functional glue code which works out of the box with =
commercial applications - the socket-API being one form of such glue code =
(but because that requires a GPL'd header to actually function, think of =
AF_BLUETOOTH defined only in bluetooth/bluetooth.h, it's out of the =
question) - BlueZ is simply unusable for our current needs, and I guess qui=
te =
a lot of other commercial Bluetooth developers would feel the same.
Anyway, thanks you two for taking the time to answer me.
-- =
Heiko Wundram
Product & Application Development
-------------------------------------
Office Germany - EXPO PARK HANNOVER
=A0
Beenic Networks GmbH
Mail=E4nder Stra=DFe 2
30539 Hannover
=A0
Fon =A0 =A0 =A0 =A0+49 511 / 590 935 - 15
Fax =A0 =A0 =A0 =A0+49 511 / 590 935 - 29
Mail =A0 =A0 =A0 [email protected]
Beenic Networks GmbH
-------------------------------------
Sitz der Gesellschaft: Hannover
Gesch=E4ftsf=FChrer: Jorge Delgado
Registernummer: HRB 61869
Registergericht: Amtsgericht Hannover
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Heiko,
On Thu, 5 Jul 2007, Heiko Wundram (Beenic) wrote:
> Am Donnerstag 05 Juli 2007 um 10:04:31 schrieb Marcel Holtmann:
> > there is no long reply needed. The library is GPL and this means every
> > application using it has to be GPL, too. Period. No exception.
>
> Okay. For me, this basically means that Linux cannot support commercial
> Bluetooth applications at the moment (without licensing a commercial
> Bluetooth stack), because Affix is also GPL'd, which is fine.
This is not fully true. You need soem glue layer which needs to be GPL or
LGPL. Check http://www.tomtom.com/page.php?Page=gpl for examples.
And I think you agree that the Tom Tom Navigation systems are commercial
products.
Ciao,
Peter
| Peter Wippich Voice: +49 30 46776411 |
| G&W Instruments GmbH fax: +49 30 46776419 |
| Gustav-Meyer-Allee 25, Geb. 12 Email: [email protected] |
| D-13355 Berlin / Germany |
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Am Donnerstag 05 Juli 2007 um 10:04:31 schrieb Marcel Holtmann:
> there is no long reply needed. The library is GPL and this means every
> application using it has to be GPL, too. Period. No exception.
Okay. For me, this basically means that Linux cannot support commercial =
Bluetooth applications at the moment (without licensing a commercial =
Bluetooth stack), because Affix is also GPL'd, which is fine.
Anyway, this question was asked before, and never answered clearly (search =
the =
bluez-devel archives if you don't believe me), which is why I felt compelle=
d =
to ask it again, and adding this to the FAQ would IMHO make perfect sense, =
so =
that others won't have to ask it again.
> You can register SDP record via D-Bus.
Is there any documentation on this, except for the source? The Wiki doesn't =
state anything in this respect, at least not that I found.
> All BlueZ files are GPL. There is no exception and no difference between
> kernel headers and library headers. The whole kernel is covered by GPL
> and if a GPL note is missing in some files, doesn't mean that they are
> not GPL.
This is not entirely true. The kernel headers (/usr/include/linux =
and /usr/include/asm) are _mostly_ (not all, esp. not the netfilter-headers =
and some other driver headers) stripped from licensing infos by the kernels =
make process (or are auto-generated by it), and are included in libc header=
s. =
One example of such an inclusion is asm/page.h, which is used pretty widely =
in the libc headers, which are licensed under the LGPL.
If asm/page.h was GPL (the licensing info wasn't stripped or rather, =
explicitly not set by the generation process which creates the header), no =
program would be able to _not_ be GPL if it linked against the standard lib=
c =
headers (which is kind'a necessary).
This is the question that popped up in my mind when thinking about the Blue=
Z =
headers...
-- =
Heiko Wundram
Product & Application Development
-------------------------------------
Office Germany - EXPO PARK HANNOVER
=A0
Beenic Networks GmbH
Mail=E4nder Stra=DFe 2
30539 Hannover
=A0
Fon =A0 =A0 =A0 =A0+49 511 / 590 935 - 15
Fax =A0 =A0 =A0 =A0+49 511 / 590 935 - 29
Mail =A0 =A0 =A0 [email protected]
Beenic Networks GmbH
-------------------------------------
Sitz der Gesellschaft: Hannover
Gesch=E4ftsf=FChrer: Jorge Delgado
Registernummer: HRB 61869
Registergericht: Amtsgericht Hannover
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Heiko,
> I'm currently developing a (C++) Bluetooth (server) application under Linux,
> and recently noticed that the BlueZ library (-lbluetooth) is licensed under
> the GPL, at least according from the bluez-libs sources which I was scanning
> for documentation (and according to quite a few mails on this list from
> others asking, but which never seem to gather enough interest to
> actually "deserve" a longer and more detailed reply than "yes, it is").
there is no long reply needed. The library is GPL and this means every
application using it has to be GPL, too. Period. No exception.
> Anyway, as my application links against -lbluetooth for SDP service
> registration (and also has source files include bluetooth/bluetooth.h and
> others for the AF_*- and similar constants to open and manage server sockets
> offered by the kernel modules), I don't see a big chance of keeping BlueZ as
> my bluetooth stack, though, as the SDP service registration architecture
> isn't offered through the D-BUS interface yet (at least not according to the
> documentation, if I understood that properly), and neither is server socket
> creation. Is this true?
You can register SDP record via D-Bus.
> Finally: is anyone feeling qualified and interested enough to properly explain
> to what extent BlueZ can and/or cannot be used in commercial (bluetooth
> server, in my case an implementation of the server-side of the OBEX File
> Transfer Profile) applications? I'm thinking of the fact that the constants
> that define Bluetooth sockets (in bluetooth/*) are specific to BlueZ and are
> GPL-marked by the file headers, but the kernel headers that define other
> Linux-specific constants have all been stripped of a license completely,
> which might, but not necessarily must mean something, as if I include a
> header file I don't link code, but only data.
All BlueZ files are GPL. There is no exception and no difference between
kernel headers and library headers. The whole kernel is covered by GPL
and if a GPL note is missing in some files, doesn't mean that they are
not GPL.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel