Menu
▾
▴
bitpim-devel
|
From: Roger B. <ro...@ro...> - 2004-03-03 06:09:18
|
I have been made aware that it will be a really good idea to update BitPim to use the Artistic License Version 2.0 due to many loopholes in version 1.0. (That is mainly due to the age of version 1.0 back when there were fewer lawyers and fewer scumbags). I would like to go ahead with this, but need the consent of the other copyright holders (ie your name is on one or more source files). Here is a list of issues in 1.0: http://dev.perl.org/perl6/rfc/211.html Here is 2.0: http://dev.perl.org/perl6/rfc/346.html Note that I am not proposing dual licensing. Several of the 3rd party components would not work if BitPim was GPL, and there is no value in BitPim being LGPL. One of my major concerns is people making modified versions of BitPim and misrepresenting them as the main version as has happened once already. AL 2.0 absolutely locks that down. It also ensures that redistributed versions are open source. Roger |
|
From: Steven P. <n9...@n9...> - 2004-03-04 02:27:46
|
On Mar 3, 2004, at 12:04 AM, Roger Binns wrote: > I would like to go ahead with this, but need the consent of > the other copyright holders (ie your name is on one or more > source files). I give full consent for any portions of the code I have authority to speak for. ;-) |
|
From: Stephen W. <sa...@us...> - 2004-03-04 05:28:12
|
V2.0 looks basically OK, but what is the point of section 8. It seems to say that if you embed the software (bitpim) in your own application and hide it really well, then the license basically no longer applies. You can charge whatever you want, not give out source code, not report modification back to the authors, and not acknowledge the code. I guess this neatly deals with the "problem" of embedded device manufacturers improperly including GPL'd code in their products by just declaring such inclusion. Since my contribution to BitPim (drivers for some phones) is a likely target for embedding in other applicaitons, I am not entirely happy with this. I would prefer someone embedding my code to either acknowledge my code (the dreaded BSD advertising clause), or make their source code open (the viral GPL). The comment that some 3rd party components would not work if BitPim was GPL got me looking at the licenses of those components, which brought me to the wxWidgets license which is basically LGPL, except if you distribute binary, then do whatever you want. I guess what that is saying, is, if you distrubute binaries, do whatever you want but don't blame the authors, or if you distribute source code, then here are the rules so that it plays nicely with other free software. Stephen |
|
From: Roger B. <ro...@ro...> - 2004-03-04 06:17:19
|
Stephen Wood wrote: > V2.0 looks basically OK, but what is the point of section 8. I have just posted to the Perl licensing list asking about that using your precise example. Dunno if I will get an answer. > happy with this. I would prefer someone embedding my code to either > acknowledge my code (the dreaded BSD advertising clause), or make their > source code open (the viral GPL). I do very much agree with your sentiments. The Artistic license is very strong on distinguishing standard from modified versions, which is my biggest concern. The problem with the GPL is that it is "freedom or nothing". Technically anything you link in (such as BitPim does with wxWidgets, DSV, libusb, Python, pySerial, win32all, cx_Freeze) must also be under the GPL. I don't like the idea of linking to other peoples components and then effectively relicensing them, although maybe I am misreading the GPL. However the GPL does seem to be more attractive every day since it is rigidly "freedom or nothing". That means no loopholes or other vagaries. Ok, as a last shot, how about the LGPL. It doesn't appear to "infect" other libraries and components that share the same executable. Section 5 of the LGPL does make my head spin though. Section 6 does bring in the "advertising" which is nice. Roger |
|
From: Stephen W. <sa...@us...> - 2004-03-04 19:30:35
|
On Thu, 2004-03-04 at 01:11, Roger Binns wrote: > The problem with the GPL is that it is "freedom or nothing". Technically > anything you link in (such as BitPim does with wxWidgets, DSV, libusb, > Python, pySerial, win32all, cx_Freeze) must also be under the GPL. > I don't like the idea of linking to other peoples components and then > effectively relicensing them, although maybe I am misreading the GPL. I think it OK to combine GPL and non-GPL parts as long as the non-GPL parts are GPL-Compatible. (More permissive?) This: http://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses lists licenses that the FSF believes to be GPL compatible. I think a big part of what makes it GPL compatible is that whoever receives the software is free to modify it and redistribute it. But it is not entirely trivial. For example, a seemingly minor change in the XFree86 license has apparently made the latest XFree86 incompatible with the GPL. A lot of the 3rd party components look to be GPL compatible according to the gnu.org page. Python, wxWidgets, Python-DSV, libusb all clearly are. Not sure about pySerial since its license file seems to date back to a time when python licenses were not GPL compatible. I don't think the licenses of the installers and freezers are relevant to GPL compatibility. > However the GPL does seem to be more attractive every day since > it is rigidly "freedom or nothing". That means no loopholes > or other vagaries. > > Ok, as a last shot, how about the LGPL. It doesn't appear to "infect" > other libraries and components that share the same executable. Section > 5 of the LGPL does make my head spin though. Section 6 does bring > in the "advertising" which is nice. I'm not sure that the LGPL really fits and the talk of Library could be confusing in the context of BitPim. I guess my preference is to either stick with the V2.0 perl license or decide to use the full GPL after making sure that all the other components are GPL compatible. The latter still leaves options for proprietary software developers that would like to use BitPim in some way. They can try to negotiate a separate license with us, or they can use the "facts" (i.e. sync protocols for various phones) documented by BitPim in applications that don't use any BitPim code. Stephen |
|
From: Roger B. <ro...@ro...> - 2004-03-05 00:31:25
|
> are. Not sure about pySerial since its license file seems to date back > to a time when python licenses were not GPL compatible. As far as I can tell, the pySerial license is identical to the Python Software Foundation license: http://www.opensource.org/licenses/PythonSoftFoundation.php > I don't think > the licenses of the installers and freezers are relevant to GPL > compatibility. They are :-) On both Linux and Windows, a stub binary supplied by the freezer (py2exe/cx_Freeze) is what is actually run. It arranges for the Python shared library to be loaded and locates the BitPim code (typically in a seperate zip file, or in a zip file appended to the end of the stub binary). I believe they are both ok anyway. I think the Mac is just running the Python binary directly. > I'm not sure that the LGPL really fits and the talk of Library could be > confusing in the context of BitPim. I agree, although based on how the freezers work you could argue it is a library :-) > I guess my preference is to either stick with the V2.0 perl license or I haven't had any response from the maintainer of that license or from the Perl6 licensing mailing list. Not a good thing. I don't quite see why all the various places kept saying to use that if it is dead (or not particularly lively anyway). > decide to use the full GPL after making sure that all the other > components are GPL compatible. I think I am sold on this now. I don't forsee any problems with the components, but would appreciate other people checking. Start from this link: http://bitpim.sourceforge.net/testhelp/3rdparty.htm > The latter still leaves options for > proprietary software developers that would like to use BitPim in some > way. They can try to negotiate a separate license with us, or they can > use the "facts" (i.e. sync protocols for various phones) documented by > BitPim in applications that don't use any BitPim code. This also serves as a reminder to anyone who contributes code to ensure that they appropriately mark their copyrights. That means that you have to be consulted for any use of your work outside the scope of the license (which is a good thing). You are also welcome to assign your copyright to me (for example if you no longer intend to be active with BitPim, or you really just don't care). Roger |
|
From: Roger B. <ro...@ro...> - 2004-03-05 01:20:51
|
> > decide to use the full GPL after making sure that all the other > > components are GPL compatible. > > I think I am sold on this now. I don't forsee any problems with the > components, but would appreciate other people checking. Start from > this link: > > http://bitpim.sourceforge.net/testhelp/3rdparty.htm Actually I do see one problem with OpenSSL. The BitFling stuff I am working on uses m2crypto which in turn produces a wrapper around OpenSSL. http://www.gnu.org/licenses/license-list.html shows OpenSSL as not GPL compatible, but not the circumstances that apply. (In this case OpenSSL is being used through two layers of indirection of runtime library loading.) Roger |
|
From: Roger B. <ro...@ro...> - 2004-03-05 01:45:08
|
> Actually I do see one problem with OpenSSL. The BitFling stuff I am > working on uses m2crypto which in turn produces a wrapper around > OpenSSL. http://www.gnu.org/licenses/license-list.html > shows OpenSSL as not GPL compatible, but not the circumstances that > apply. (In this case OpenSSL is being used through two layers > of indirection of runtime library loading.) It looks like one can place an exception in the COPYING file to solve this problem. For example, see 3rd paragraph of http://www.opensource.apple.com/darwinsource/10.1.2/fetchmail-4.1/fetchmail/COPYING Roger |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X