Thread: [Hamlib-developer] Licensing
Library to control radio transceivers and receivers
Brought to you by:
n0nb
Menu
▾
▴
hamlib-developer
|
From: Nate B. <n0...@ne...> - 2002-11-13 22:28:02
|
Hi Stephane.
I see you updated the README.developer file and added:
! 8. Coding guidelines
! Your code must be LGPL.
!
which I have no problem with. However, this is a question I was going
to bring up sooner or later. Some of the files written by Frank
Singleton in the yaesu directory still have the GPL preamble and not the
LGPL preamble.
I was going to make this change in the ft920.c/.h files, but since I had
borrowed so heavily from Frank's ft747.c/.h files I was reluctant to do
so until I had discussed this matter.
If I recall, Frank had agreed to the LGPL change and these files were
likely just an oversight. I want to be sure until I change my files.
Perhaps we should carefully go through the remaining files and be sure
they are all LGPL before the 1.1.4 release.
Some GPL and som LGPL code could cause projects such as Debian
heartburn.
I'm willing to make sure the yaesu subdirectory is up to snuff as I seem
to be the one working in it currently.
73, de Nate >>
--
Wireless | Amateur Radio Station N0NB | "We have awakened a
Internet | n0...@ne... | sleeping giant and
Location | Bremen, Kansas USA EM19ov | have instilled in him
Amateur radio exams; ham radio; Linux info @ | a terrible resolve".
http://www.qsl.net/n0nb/ | - Admiral Yamomoto
|
|
From: Black M. <mdb...@ya...> - 2016-09-03 19:33:42
|
There are 3 files with GPL instead of LGPL licensing. android/ltdl.cmicrotune/module_4702.cc microtune/module_4937.cc And getopt.c / geopt-long.c are GPL and only use for programs in tests...but their inclusion in the library subjects the whole library to GPL licensing (i.e. the more restrictive of the two). Can the licensing be changed on the backend files and the getopt functions directly linked to the tests programs instead of via the library? de Mike W9MDB |
|
From: Stephane F. <f8...@fr...> - 2016-09-04 15:11:03
|
Hi, sab, Sep 03, 2016, Black Michael skribis: > There are 3 files with GPL instead of LGPL licensing. > android/ltdl.cmicrotune/module_4702.cc > microtune/module_4937.cc > And getopt.c / geopt-long.c are GPL and only use for programs in tests...but their inclusion in the library subjects the whole library to GPL licensing (i.e. the more restrictive of the two). > Can the licensing be changed on the backend files and the getopt functions directly linked to the tests programs instead of via the library? There's no need to bother with the microtune backend. It has been long deprecated, and it can be safely removed altogether. The ltdl.c and getop*.c are another story. Cheers -- Stephane - F8CFE |
|
From: Nate B. <n0...@n0...> - 2016-09-04 16:30:11
|
* On 2016 03 Sep 14:35 -0500, Black Michael wrote: > There are 3 files with GPL instead of LGPL licensing. > android/ltdl.cmicrotune/module_4702.cc > microtune/module_4937.cc If this backend is deprecated, then it can be safely removed. > And getopt.c / geopt-long.c are GPL and only use for programs in > tests...but their inclusion in the library subjects the whole library > to GPL licensing (i.e. the more restrictive of the two). Can the > licensing be changed on the backend files and the getopt functions > directly linked to the tests programs instead of via the library? de > Mike W9MDB My understanding is that these files are only compiled and linked on systems that lack native getopt functions. They are only ever linked to the rigctl*/rotctl* utilities which themselves are licensed GPL v 2 or later. It is my opinion that their use in this manner does not contaminate the library as they're never linked into the library and they should remain as is. The use of the GPL v 2 or later for the test programs and utilities likewise does not contaminate the library. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us |
|
From: Nate B. <n0...@n0...> - 2016-09-04 17:21:34
|
CC'ing the list as the discussion started there. * On 2016 04 Sep 11:48 -0500, Black Michael wrote: > I can't quite tell for sure but it appears to me that getopt can end > up in libhamlib.soAt that point GPL takes over the library whether the > functions are linked into an app or not since you're distributing a > shared library with the routines in it.The libham.a with getopt file > would be GPL...but if you did not link the GPL functions from the > static lib your app would not inherit the license.That was one of the > bad things about GPL which led to LGPL. I honestly do not see the difference between the object code being in an archive or the source file being in the same tarball as it is essentially the same thing. The source is human readable and the object is machine readable. Nothing magical happens to the license just because a file is run through a compiler despite the fact the some seem to claim otherwise. To use the same logic would require that we distribute the source files in separate tarball archives to avoid having GPL sources in the same tarball as LGPL sources. Such a claim is so nonsensical that not even the GNU project does it. > So...at the moment...my patch says if android or getopt or getopt_long > then library is GPLV2 otherwise LGPL. I strongly disagree. Of course, I am not an expert in copyright law. The fact is that we as original authors can license things as we wish. If you feel as strongly about this issue as I do on the other side, then I would be comfortable with the following compromise, we include a file that declares that the files in question are not an integral part of libhamlib.* and their inclusion in an object archive only results in the objects derived from those specific files being licensed under the GPL v 2 or later while the rest of the archive remains licensed under the LGPL v 2.1 or later. But, see below as well. > If we move getopt.c into the tests directory and compile directly with > the apps then only android causes a problem right now (I'm waiting to > hear from Lada if we can switch to LGPL). If your only intention is to statically link the files in question to the apps that need them AND that those functions are then available when otherwise not available on the host platform, then disregard the above and proceed with your patch. While the odds of finding a system without the getopt/getopt_long functions are getting less these days, they're out there and we should continue to support Hamlib on them as support already exists. > de Mike W9MDB 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us |
|
From: Jae S. (K5JAE) <k5...@st...> - 2016-09-04 18:52:00
|
I just downloaded the latest glibc source (http://ftp.gnu.org/gnu/glibc/) and getopt.h is listed as LGPL. Perhaps we just need to upgrade? de Jae K5JAE On Sun, Sep 4, 2016 at 12:21 PM, Nate Bargmann <n0...@n0...> wrote: > CC'ing the list as the discussion started there. > > * On 2016 04 Sep 11:48 -0500, Black Michael wrote: >> I can't quite tell for sure but it appears to me that getopt can end >> up in libhamlib.soAt that point GPL takes over the library whether the >> functions are linked into an app or not since you're distributing a >> shared library with the routines in it.The libham.a with getopt file >> would be GPL...but if you did not link the GPL functions from the >> static lib your app would not inherit the license.That was one of the >> bad things about GPL which led to LGPL. > > I honestly do not see the difference between the object code being in an > archive or the source file being in the same tarball as it is > essentially the same thing. The source is human readable and the object > is machine readable. Nothing magical happens to the license just > because a file is run through a compiler despite the fact the some seem > to claim otherwise. To use the same logic would require that we > distribute the source files in separate tarball archives to avoid having > GPL sources in the same tarball as LGPL sources. Such a claim is so > nonsensical that not even the GNU project does it. > >> So...at the moment...my patch says if android or getopt or getopt_long >> then library is GPLV2 otherwise LGPL. > > I strongly disagree. Of course, I am not an expert in copyright law. > > The fact is that we as original authors can license things as we wish. > > If you feel as strongly about this issue as I do on the other side, then > I would be comfortable with the following compromise, we include a file > that declares that the files in question are not an integral part of > libhamlib.* and their inclusion in an object archive only results in > the objects derived from those specific files being licensed under the > GPL v 2 or later while the rest of the archive remains licensed under > the LGPL v 2.1 or later. > > But, see below as well. > >> If we move getopt.c into the tests directory and compile directly with >> the apps then only android causes a problem right now (I'm waiting to >> hear from Lada if we can switch to LGPL). > > If your only intention is to statically link the files in question to > the apps that need them AND that those functions are then available when > otherwise not available on the host platform, then disregard the above > and proceed with your patch. While the odds of finding a system without > the getopt/getopt_long functions are getting less these days, they're > out there and we should continue to support Hamlib on them as support > already exists. > >> de Mike W9MDB > > 73, Nate > > -- > > "The optimist proclaims that we live in the best of all > possible worlds. The pessimist fears this is true." > > Ham radio, Linux, bikes, and more: http://www.n0nb.us > > ------------------------------------------------------------------------------ > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Greg T. <gd...@le...> - 2016-09-05 00:15:11
Attachments:
signature.asc
|
Nate Bargmann <n0...@n0...> writes: > CC'ing the list as the discussion started there. > > * On 2016 04 Sep 11:48 -0500, Black Michael wrote: >> I can't quite tell for sure but it appears to me that getopt can end >> up in libhamlib.soAt that point GPL takes over the library whether the >> functions are linked into an app or not since you're distributing a >> shared library with the routines in it.The libham.a with getopt file >> would be GPL...but if you did not link the GPL functions from the >> static lib your app would not inherit the license.That was one of the >> bad things about GPL which led to LGPL. > > I honestly do not see the difference between the object code being in an > archive or the source file being in the same tarball as it is > essentially the same thing. The source is human readable and the object > is machine readable. Nothing magical happens to the license just > because a file is run through a compiler despite the fact the some seem > to claim otherwise. To use the same logic would require that we > distribute the source files in separate tarball archives to avoid having > GPL sources in the same tarball as LGPL sources. Such a claim is so > nonsensical that not even the GNU project does it. I see where you are coming from -- that linking with a libham.a archive which contains some GPL members does not, if one does not use the functions in the GPL files, lead to a GPL executable. A case, perhaps slightly more arguable, can be made for the same situation with dynamic linking. The overall point is not about linking but about what constitutes a "work based on the program". All that said, it could be nice to avoid confusion by not having GPL-proper files in libham.a, so that the library itself could be treated entirely under LGPL, and thus understanding the situation would be simpler. >> So...at the moment...my patch says if android or getopt or getopt_long >> then library is GPLV2 otherwise LGPL. > > I strongly disagree. Of course, I am not an expert in copyright law. I don't follow. To distribute a library, one needs permission from all the copyright holders, and if part of a library is GPL, that permission is only granted if the entire library is licensed under the GPL. Alternatively, I think you are saying that the inclusion of getopt library is mere aggregation, and that one can license a .a library piecewise, just like multiple programs on a CDROM. > If you feel as strongly about this issue as I do on the other side, then > I would be comfortable with the following compromise, we include a file > that declares that the files in question are not an integral part of > libhamlib.* and their inclusion in an object archive only results in > the objects derived from those specific files being licensed under the > GPL v 2 or later while the rest of the archive remains licensed under > the LGPL v 2.1 or later. As a more or less disinterested license geek (but IANAL, TINLA as always), that sounds ok. Part of the point is that getopt and getopt_long appear in many operating systems, so programs that use the interface are not derived From any particular implementation. > But, see below as well. > >> If we move getopt.c into the tests directory and compile directly with >> the apps then only android causes a problem right now (I'm waiting to >> hear from Lada if we can switch to LGPL). > > If your only intention is to statically link the files in question to > the apps that need them AND that those functions are then available when > otherwise not available on the host platform, then disregard the above > and proceed with your patch. While the odds of finding a system without > the getopt/getopt_long functions are getting less these days, they're > out there and we should continue to support Hamlib on them as support > already exists. That sounds like the best answer to me; the test programs will be GPL sometimes, but that shouldn't bother anyone, and there will be no confusion about the licensing of the main hamlib library. Also, NetBSD's libc (not derived in any way from glibc) has getopt/getopt_long under a BSD license. So another option, probably more work than it's worth, would be to switch to that. Somewhat separately, what platforms are known to actually need this? I wonder how reasonable it would be to just drop the getopt implementation, but it sounds like it's not. 73 de n1dam |
|
From: Stephane F. <f8...@fr...> - 2002-11-17 16:28:14
|
On Wed, Nov 13, 2002, Nate Bargmann wrote: > If I recall, Frank had agreed to the LGPL change and these files were > likely just an oversight. I want to be sure until I change my files. > Perhaps we should carefully go through the remaining files and be sure > they are all LGPL before the 1.1.4 release. (fillods@charybde:hamlib)$ grep '"GPL"' */*.c gnuradio/gr.c: .copyright = "GPL", yaesu/ft100.c: .copyright = "GPL", yaesu/ft817.c: .copyright = "GPL", yaesu/ft920.c: .copyright = "GPL", - gnuradio is GPL, on library constraint. - IIRC, ft100 and ft817 were written by Chris AA1VL, cloning Frank's work before the licensing change. I hope he'll be okay to relicense accordingly. - ft920: Nate, you decide :) > Some GPL and som LGPL code could cause projects such as Debian > heartburn. It should be fine, since the frontend library is LGPL, and backends are plugins, i.e. the end user is reponsible to load them or not, according to their license. Maybe it should also be possible to compile selectively backends. 73 Stephane |
|
From: Nate B. <n0...@ne...> - 2002-11-22 02:21:07
|
* Stephane Fillod <f8...@fr...> [2002 Nov 17 21:42 -0600]: > (fillods@charybde:hamlib)$ grep '"GPL"' */*.c > gnuradio/gr.c: .copyright = "GPL", > yaesu/ft100.c: .copyright = "GPL", > yaesu/ft817.c: .copyright = "GPL", > yaesu/ft920.c: .copyright = "GPL", > > - gnuradio is GPL, on library constraint. > - IIRC, ft100 and ft817 were written by Chris AA1VL, cloning Frank's work > before the licensing change. I hope he'll be okay to relicense > accordingly. > - ft920: Nate, you decide :) Okay we can safely convert the remaining files in the yaesu directory as I received the following message from Frank today (I was able to reach him through sourceforge address): >Subject: >Request to relicense source cod in Hamlib >From: >Nate Bargmann <n0...@ne...> >Date: >Wed, 20 Nov 2002 16:35:37 -0600 >To: >vk...@ix... > > >Hi Frank. > >Long time no hear on the Hamlib list. > >I have been using your ft747.c and ft747.h files as the base for >support >for the FT-920 in Hamlib. About a year ago a licensing change for the >main front-end library to the Lesser GPL was announced. Consistent >with >that action Stephane has requested that new code contributed to Hamlib >be licensed under the LGPL. > >Your files still carry the GPL boilerplate and as such I am carrying >the >GPL boilerplate in the files I am working with. So, for consistency >with the rest of the project, I would like to ask your permission to >re-license the files which carry your copyright to the LGPL. > >73, de Nate >> > Hi Nate, Nice to hear from you. I have no problem with LGPL being used instead of GPL, and you have my permission to make the changes. It should promote more usage of our libs. My old address gets spammed so much I rarely visit it, but I am glad you found me :-) Since we last spoke we are enjoying our new child, and I am training to be a GA Pilot here in Dallas, so there has been little time for other things.. So how has hamlib been going latelty ?? I am still a developer for http://www.ethereal.com/ mainly the CORBA part of it. 73's de Frank -- So I will change the ft920.* files to the LGPL boiler plate. Chris, would you like to change your files or shall I do it? BTW, we need to carefully examine the boilerplate of each file as Stephane's grep output above missed ft747.c which still carries the GPL boilerplate but has the LGPL string in the rig_caps structure! 73, de Nate >> -- Wireless | Amateur Radio Station N0NB | "We have awakened a Internet | n0...@ne... | sleeping giant and Location | Bremen, Kansas USA EM19ov | have instilled in him Amateur radio exams; ham radio; Linux info @ | a terrible resolve". http://www.qsl.net/n0nb/ | - Admiral Yamomoto |
Thanks for helping keep SourceForge clean.
X