Eleftherios Gkioulekas wrote:
>
> Dear Todd Veldhuisen,
>
> I am potentially interested in Blitz++ and I was very much encouraged
> by the fact that you distributed under the terms of the GNU GPL.
> In the web page you indicate that a lot of people have written to you
> suggesting that it may be a problem that this licensing is not friendly
> to commercial software. I hope that it is helpful that I add my input into
> this issue.
>
> Before doing so, I AM NOT A LAWYER, AND THIS IS NOT LEGAL ADVICE.
>
> I think that it is important that if some alternative licensing is used,
> that it is compatible with the GNU GPL (unless you decide to dual license,
> see bellow). There exist licenses that are within the Debian Free Software
> guidelines but are still incompatible with the GNU GPL. An example of such a
> license is the Netscape license. I don't know with certainty if it is
> possible for a license to be open source and incompatible with the GPL, and
> because I don't know I am not reassured by the comment in the web: "the core
> of the license will remain unchanged". The problem with these cases is that
> such work can't be used on a project that also needs to use GPLed code.
>
> As a free software developer, Blitz++ licensing will be friendly to me if
> it can assure me that I will be able to develop Blitz++ based free software
> with the most recent version of Blitz++ and distribute the combined work under
> the GPL.
>
> If it is useful to be friendly to commercial software, then a way that
> is at least equally friendly to free software should be prefered.
> I appreciate it a lot that you published the current version with the
> GPL. But your comment about changing the license terms worries me, and
> since I haven't started a Blitz++ based project yet, it forces me to wait
> for the final version of the licensing terms before starting one.
> I wouldn't worry however, if I was assured that the final terms will be
> compatible with the GNU GPL.
>
> In the rest of the message, I make suggestions for realizing licensing
> terms that are compatible with the GNU GPL that will not exclude proprietary
> developers. There are mainly 3 possible approaches that I can think off the
> top of my head:
> 1. The LGPL.
> 2. Dual licensing. The second license can be anything that all the
> contributors can agree on. For example Perl dual licenses under the
> GPL and the Artistic License.
> 3. "Modifications" of the GPL. The way this works is that the notice
> added to every file saying "You may use ... under the terms of the
> GNU General Public License ..." gets another paragraph saying.
> "Permission is also granted ... " where you add additional terms that
> loosen up the licensing. An example of this is in libstdc++.
>
> Evaluating methods:
> 1. I am not sure how the LGPL mixes with the fact
> that the majority of the code is in header files. But the spirit of
> the LGPL is that it says: "you can use this to write your stuff, and you
> can do with the derived work whatever you wish, but if you make any changes
> on the stuff you got from me, I'd want _that_ to be freely available".
> I have less experience with using the LGPL than with using the GPL, so I'd
> suggest to keep an open mind about this and get opinions from people who know
> better. This scheme wouldn't be friendly to someone who wants to fork
> a non-free version of Blitz++. But it would be friendly to someone who
> wants to write a useful non-free application with Blitz++. If you have
> to invent an LGPL-like license, a possible downside is that it is not
> obvious to GPL developers that the new license is compatible with the GPL.
> We know that the LGPL is compatible with the GPL. For something we haven't
> seen before, that looks like it might be compatible, we'd still need
> legal advice to be certain. The other two approaches don't have this
> problem. Also, inventing a whole new license is a difficult task.
> Even so, if the FSF comes out, studies the new license, and makes a public
> statement that it is compatible with the GPL, many people will trust the
> FSF opinion. Many of these people trust the FSF enough to assign their
> copyrights to them.
>
> 2. Dual licensing is the most flexible approach. License #1 is the GPL.
> License #2 can be whatever you want. To dual license, the entirety of the work
> must owned by you or the contributors must all agree on the same licenses.
> The second license can be very permissive (as in Perl) or
> demanding (e.g. nontransferable, or demanding financial compensation, etc.)
> Also, if you can dual license Blitz++, then the commercial developer has
> the freedom to negotiate with you the terms of the second license, if he is
> not satisfied with the default options. So given the open door, you don't
> have to worry a whole lot about getting the second license exactly right.
> You just have to make it right for you and the contributors. Then
> it's up to negotiation. This scheme lets you be as friendly as you like
> and vice versa. It also lets you allow someone to fork Blitz++, but not
> if you don't want to. So it is the most flexible option but it requires some
> caution because of that flexibility. Because one of the two licenses will be
> the GPL, it is obvious to GPL developers that the licensing is GPL compatible.
>
> 3. What the third approach can be really useful is in modifying the
> default license. That may be the only license you use, or the 1st license
> in a dual license scheme. Me and many developers have a lot of good reasons
> to prefer the GPL. If you have different reasons and goals, you may decide
> that you want your default stance to be more relaxed than the GPL.
> The third approach allows you to do that without compromising GPL
> compatibility. It is also less work than reinventing an entire new license
> under a GPL compatibility constraint.
>
> The clause the FSF uses in libstdc++ looks like this:
> /*
> ** This library is free software .....
> ** ....
> ** As a special exception, if you link this library with files
> ** compiled with a GNU compiler to produce an executable, this does not cause
> ** the resulting executable to be covered by the GNU General Public License.
> ** This exception does not however invalidate any other reasons why
> ** the executable file might be covered by the GNU General Public License.
> */
> As it stands you could use it if you were writing say runtime libraries
> for a GPLed compiler. Blitz++ might be thought of as an extension of the
> C++ runtime library, it's like an STL for numerics, so perhaps this wording
> might be your solution, and it is simple and elegant. You may want to extend
> it to non-GNU compilers. Perhaps an alternative wording may be
> "a C++ compiler".
>
> I think it is important to get legal advice before playing with wording that
> has never been used before. It is hard to know what unwanted loopholes you open
> up by loosening up the permissions. Not being a lawyer causes me to be paranoid
> when I deal with legal texts. I think that's a healthy state of mind. This
> scheme will let you be at least as friendly as the GPL is, and then add
> extra sugar for proprietary developers.
>
> Depending on how and why you want to be friendly to proprietary developers,
> you can decide which of these 3 options is best and how exactly to exercise the
> option you choose without compromising being friendly to the free software
> community.
>
> I hope these comments are helpful. Feel free to forward my message in
> its entirety or in pieces to other people. Definitely feel free to
> forward it to someone who is a lawyer :-)
>
> Elef
> PS: actually, it is more accurate to talk about "proprietary" developers,
> because the emphasis is on the license they use and not on whether they
> are individuals or companies. For example, RedHat is a commercial
> entity, and rpm is "commercial software" since it was written and owned
> by them, but it is not "proprietary software" because it is under the GPL.
> These semantics can get rather confusing sometimes. Sometimes they
> confuse me too.
> --
> Eleftherios Gkioulekas | "Don't be too proud of this
> http://www.amath.washington.edu/~lf/ | technological terror you have
> Proud user of GNU/Linux | constructed" -- Darth Vader
>
This archive was generated by hypermail 2b29 : Wed Feb 20 2002 - 04:30:06 EST