> -----Original Message-----
> From: [email protected]=20
> [mailto:[email protected]] On Behalf Of=20
> Marcel Holtmann
> Sent: Tuesday, January 27, 2004 17:39
> To: [email protected]
> Cc: BlueZ Mailing List
> Subject: Re: [Bluez-devel] Windows Port
>=20
> Hi Antony,
>=20
> > I've just been looking at the code (from 2.4 - I'm running=20
> > RH9). As far as I can see L2CAP and RFCOMM are connected=20
> > by a socket interface, and L2CAP and the HCI layer are=20
> > connected by a callback interface, yes?
> >=20
> > After a very cursory investigation, I don't think it's a=20
> > lot of work to create an abstraction layer so that Windows=20
> > can provide the same APIs that BlueZ is using. In fact=20
> > Microsofts BT implementation also uses a socket-based=20
> > approach (unfortunately, because MS don't want us innovating
> > in Bluetooth, everything other than RFCOMM is locked down).
> >=20
> > Of course, the hci_ API would have to be re-written to=20
> > accomodate the new driver (probably need to use sockets=20
> > there as well), but I don't see why L2CAP and RFCOMM=20
> > couldn't communicate in the same way on Windows. I'd
> > probably move them up into user space as services -=20
> > this of course means you have a messy route back into=20
> > kernel mode for Virtual Serial port functions, but=20
> > still, I'd say it's doable.
> >=20
> > I would draw the line at Virtual Serial Port and BNEP, and=20
> > let Windows have it's own user services (not the same as=20
> > the gnome stuff for BlueZ).
> >=20
> > What do you think? Am I right in that we are basically=20
> > talking about sockets for L2CAP and RFCOMM?
>=20
> I don't believe that it is possible to port BlueZ to the
> Windows platform, but I also don't wanna keep you from=20
> trying it. Personally I think it is easier to start from=20
> scratch and then offer the same interfaces as BlueZ does=20
> for Linux.
>=20
> Regards
>=20
> Marcel
I may be stating the obvious, but do not forget about the=20
license issue. As far as I can tell from a quick search=20
through the BlueZ repository, only the code in libs2/lib=20
and utils2/lib is under LGPL, the rest (including the "old"=20
libraries) are under GPL. This means that any program or
kernel driver that uses any of the GPLed parts need to be=20
GPLed too. (This, btw, goes for Linux applications too that=20
use or link with the GPLed parts.)
//Peter
Marcel Holtmann wrote:
>Hi Antony,
>
>
>
>>Thanks for the warning. The stuff I want to port will be isolated in the
>>services provided and all the code in this application will, as
>>required, still be GPL. However, the parts which interface to these
>>services (the hardware driver and the API) would be a modified GPL that
>>does not require the entire program to be made public but only the
>>original source code and any modifications made to it.
>>
>>
>
>if a program contains one line GPL code, the complete source code must
>be available. If you link a library under GPL, the final program will
>also be GPL.
>
>
True. In this respect the program would be the l2cap and rfcomm
services. The UI stuff and the driver are separate programs, which don't
contain any GLP'ed code. If the interfaces to RFCOMM and L2CAP are
socket based (or pipe based or whatever), then you don't need to link
with any GPL'ed libs.
That's my thinking. My intention is not to "misuse" GPL'ed code. My
intention is to give people something that they can innovate with
commercially. I believe this is good for Bluetooth. It's important for
Bluetooth that it gets a truely intuitive presence on Windows. Let's not
turn this discussion into a GPL/non-GPL argument, though.
Besides, I don't even yet know whether or not I am going to heed your
warnings and implement without using the BlueZ sources. The first step
is to get the USB driver working and being able to initiate basic HCI
stuff - that will be a completely new implementation and nothing to do
with BlueZ. Once I've gotten there, I'll make a definite decision.
Regards,
Antony C. Roberts.
Hi Antony,
> Thanks for the warning. The stuff I want to port will be isolated in the
> services provided and all the code in this application will, as
> required, still be GPL. However, the parts which interface to these
> services (the hardware driver and the API) would be a modified GPL that
> does not require the entire program to be made public but only the
> original source code and any modifications made to it.
if a program contains one line GPL code, the complete source code must
be available. If you link a library under GPL, the final program will
also be GPL.
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Antony,
> I have no problem with GPL in the RFCOMM and L2CAP bits. My aim is to
> have a sub-system (set of services) which are accessible from an API.
> The RFCOMM and L2CAP bits can remain GPL no problem. The driver would be
> open-source (but not GPL) as would the API itself and any user mode apps.
be very careful with putting your code not under GPL. You should read
what the FSF says about derived work etc. Actually this would be another
reason for me to start from scratch.
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Peter,
> I may be stating the obvious, but do not forget about the
> license issue. As far as I can tell from a quick search
> through the BlueZ repository, only the code in libs2/lib
> and utils2/lib is under LGPL, the rest (including the "old"
> libraries) are under GPL. This means that any program or
> kernel driver that uses any of the GPLed parts need to be
> GPLed too. (This, btw, goes for Linux applications too that
> use or link with the GPLed parts.)
actually there is no problem with GPL or LGPL software on the Windows
platform, but you are right that every kernel driver or program must be
licensed under GPL, too.
The libs2 is not really LGPL at the moment (even if the header of the
files say so). Max and I already agreed that we should make the new
library LGPL, but there are still some code snippets that are copyright
by Qualcomm. And this code is GPL only at the moment, which means that
the complete code will be still under the GPL. Maybe it is a good time
to discuss this now. Max, what is the current status on this?
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann wrote:
>Hi Antony,
>
>
>
>>I have no problem with GPL in the RFCOMM and L2CAP bits. My aim is to
>>have a sub-system (set of services) which are accessible from an API.
>>The RFCOMM and L2CAP bits can remain GPL no problem. The driver would be
>>open-source (but not GPL) as would the API itself and any user mode apps.
>>
>>
>
>be very careful with putting your code not under GPL. You should read
>what the FSF says about derived work etc. Actually this would be another
>reason for me to start from scratch.
>
>Regards
>
>Marcel
>
>
>
>
Thanks for the warning. The stuff I want to port will be isolated in the
services provided and all the code in this application will, as
required, still be GPL. However, the parts which interface to these
services (the hardware driver and the API) would be a modified GPL that
does not require the entire program to be made public but only the
original source code and any modifications made to it.
Regards,
Antony C. Roberts.
>>I may be stating the obvious, but do not forget about the
>>license issue. As far as I can tell from a quick search
>>through the BlueZ repository, only the code in libs2/lib
>>and utils2/lib is under LGPL, the rest (including the "old"
>>libraries) are under GPL. This means that any program or
>>kernel driver that uses any of the GPLed parts need to be
>>GPLed too. (This, btw, goes for Linux applications too that
>>use or link with the GPLed parts.)
>>
>>
>
>actually there is no problem with GPL or LGPL software on the Windows
>platform, but you are right that every kernel driver or program must be
>licensed under GPL, too.
>
>The libs2 is not really LGPL at the moment (even if the header of the
>files say so). Max and I already agreed that we should make the new
>library LGPL, but there are still some code snippets that are copyright
>by Qualcomm. And this code is GPL only at the moment, which means that
>the complete code will be still under the GPL. Maybe it is a good time
>to discuss this now. Max, what is the current status on this?
>
>
>
I have no problem with GPL in the RFCOMM and L2CAP bits. My aim is to
have a sub-system (set of services) which are accessible from an API.
The RFCOMM and L2CAP bits can remain GPL no problem. The driver would be
open-source (but not GPL) as would the API itself and any user mode apps.
Regards,
Antony C. Roberts.