[Bitpim-devel] Licensing (again :-)

[Roger Binns]

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

[Steven Palm]

Post by Roger Binns
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. ;-)

[Stephen Wood]

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

[Roger Binns]

Post by Stephen Wood
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.

Post by Stephen Wood
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

[Stephen Wood]

Post by Roger Binns
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.

Post by Roger Binns
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

[Roger Binns]

Post by Stephen Wood
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

Post by Stephen Wood
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.

Post by Stephen Wood
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 :-)

Post by Stephen Wood
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).

Post by Stephen Wood
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

Post by Stephen Wood
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

[Roger Binns]

Post by Roger Binns

Post by Stephen Wood
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
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

[Roger Binns]

Post by Roger Binns
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