Open Source License Question

[Kenneth Dombrowski]

Hi, I was just browsing the group as a newbie to python, and I would
hate to be thought (or be baited by) a FOSS licensing troll with my
first post, so I apologize if these issues have been gone over already;
in fact several people have said that they have, but I am compelled to
reply to this thread:


!??

I can only assume you're referring to the restriction that authors of
non-free software can't link to your libraries

With your code under the GPL, anybody can use your code for commercial
purposes, or any other purposes. Anybody can sell it, anybody can link
to it and sell the derivative work, with the provision that in that case
they use the GPL for that derivitave work

This seems like an appropriate post to which to attach a reference
to a nice article contrasting the GPL and the Mozilla Public License
(MPL): http://croftsoft.com/library/tutorials/gplmpl/

Summary of that essay, in the words of its author:

This is a very misleading article to point someone to.

in the words of its author:

"The GPL prevents code from being sold by itself or as part of a larger
work."

This is thoroughly false. There is no restriction on selling GPLed
software; from the FSF GNU GPL FAQ:
http://www.gnu.org/licenses/gpl-faq.html#TOCDoesTheGPLAllowMoney

"Does the GPL allow me to sell copies of the program for money?
Yes, the GPL allows everyone to do this. The right to sell copies
is part of the definition of free software. Except in one special
situation, there is no limit on what price you can charge. (The one
exception is the required written offer to provide source code that must
accompany binary-only release.)"


He continues,

"However, it leaves the door open for the authors to commercially sell
the code under different licensing terms if they so choose.
For example, this can easily occur:

1. a single author may initially release code as GPL;
2. the author later decides that the code has commercial viability;
3. the author stops distributing the code with the GPL.
4. the author then reissues the exact same code with a fee-based
license.

What does this mean? It means that the GPL is a nice hedge for an author
or organization who wants to reserve the exclusive right to commercially
sell the software at some future point without competition."


This argument is expanded on in some detail; but relies on two
misinterpretations of the GPL:

1. An author is certainly free to sell his/her code while it is under
the GPL. As is anyone else, there simply is no "right to sell the code
exclusively" in the GPL, see above.

2. As the copyright holder, I believe the author is certainly free to
change his/her license with a future release -- regardless of whether
the code had changed. But even if all reference to the GPL were removed
from the future release, that would not revoke earlier releases' GPL
licenses; anyone who cared to could fork a GPL release and continue
development provided they used the GPL license. Thus the GPL achieves
the one thing the author of this article attributes as the benefit of
the MPL: a free market incentive to keep software free.


His next argument is with the "viral" nature of the GPL, but his first
point supporting the argument is not true:

"First, it prevents the use of code released under other Open Source
licenses, with the exception of Public Domain, from being used in
combination to create a larger work. For example, suppose that you have
located a third of the source code components that you need for your
project under the GPL, another third under the X consortium/MIT style
licenses, and the final third as Public Domain. Problem solved? No, you
will either have to rewrite the GPL or the X consortium/MIT components
as GPL will not co-exist with the other."

From the top of http://www.gnu.org/philosophy/license-list.html:

"We classify a license according to certain key questions:

* Whether it qualifies as a free software license.
* Whether it is a copyleft license.
* Whether it is compatible with the GNU GPL. (This means you can
combine a module which was released under that license with a
GPL-covered module to make one larger program.)"

In fact his X11/MIT example is listed as compatible with the GPL on that
page; I can't say whether this has changed since 1999, when this article
was written, but it is clearly wrong today.


Last he complains that the GPL effectively creates a gulf between
proprietary developers and FOSS developers... this certainly was an
issue for a lot people in 1999, but I don't consider it important enough
anymore to bore the list further


btw, I am a big fan of Mozilla, & had never bothered to read up on their
license. I see a version 1.1 (which presumably came out since that
article was written) can, under certain conditions be compatible with
the GPL -- at least according to the FSF:

http://www.gnu.org/philosophy/license-list.html#TOCGPLIncompatibleLicenses

"MPL 1.1 has a provision (section 13) that allows a program (or parts of
it) to offer a choice of another license as well. If part of a program
allows the GNU GPL as an alternate choice, or any other GPL-compatible
license as an alternate choice, that part of the program has a
GPL-compatible license."


I certainly don't believe that the GPL is best for everyone, and if your
main issue with the GPL is its viral nature, the MPL looks like it may
be a good alternative, after the LGPL & X11 licenses

of course,
IANAL
TINLA
etc...

Kenneth

 

[Joachim Bowman]

Hi,

Joachim Bowman:

I'd also like to prevent people
selling derivative works where my stuff forms the substantial part of
the poduct.

I'd prefer to use an OSI approved license - but it's not essential.

These two don't go together. Read "6. No Discrimination Against Fields
of Endeavor" in "The Open Source Definition"[0].
>>[0] http://www.opensource.org/docs/definition.php

I don't see a conflict at all on that point.....

Well, selling a derivative work of your software is some kind of
endeavor. If you include a restriction in your license forbidding this,
it doesn't comply to The Open Source Definition.

You will not find any OSI approved license which will include a clause
like the one you probably have in mind.

J

 

[Joachim Bowman]

Hi,

Fair enough. LGPL, X, or BSD should allow you to do that.

So does the GNU GPL. Freedom/Open Source and commercial use are two
orthogonal concepts. The two don't interfere in any way.

You can have Free Software (under the GPL) that is used and distributed
commercially, Free Software that is used and distributed in a non
commercial way (Python), proprietary software that is used and
distributed commercially (think about MS Word), and proprietary software
that is used and distributed free of charge and without a commercial
background (sometimes called freeware).

J

 

[Joachim Bowman]

Hi,

This seems like an appropriate post to which to attach a reference
to a nice article contrasting the GPL and the Mozilla Public License
(MPL): http://croftsoft.com/library/tutorials/gplmpl/

Summary of that essay, in the words of its author:
"I state in this essay that MPL is more free and open than GPL."

There is, of course, a controversy about this point. The GNU people
claim[0] that people who call the GNU GPL "viral" and other licences
"more free" actually aren't talking about freedom but about power.

J

[0] http://www.gnu.org/philosophy/freedom-or-power.html

 

[Andrew Dalke]

Michael Foord:

So does the GNU GPL. Freedom/Open Source and commercial use are two
orthogonal concepts. The two don't interfere in any way.

It so nice to organize things. Each file is in a directory,
each book on a shelf, each concept on its own axis. The
Aristotelian logic of one or the other.

But life is full of platypuses. That's what makes things
messy, fun, frustrating, and interesting.

"Freedom/Open Source" isn't a single dimension. How can it be
when licenses can be both free and mutually exclusionary? (See
http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses )

Odds are good you can find three licenses A, B, and C such that
A is compatible with B is compatible with C, but where A is not
compatible with C. A messy space indeed!


Let B be a point in business space. Let L be a point in the
software licensing space. The statement "don't interfere in any way"
means that for all B and all L there is a point (B, L) which is
in (business space x licensing space).

That's provably false - choose B = "a company making money selling
binaries but not also distributing source". Those exist. Let
L = "a library licensed under the GPL." Those also exist. Suppose
company B wanted to include that library as part of the software.
Is (B, L) a point in business space x software licensing space?

The answer of course is no, so we're left with one or more of the
following:
1. B and L are not orthogonal (I'm backing this one
2. B is not a valid point in business space (the way GNU would
like it to be)
3. L is not a valid point in licensing space (some others would
like this to be true)
4. there's another definition of "don't interefere in any way"
5. using a dimensional space metaphor doesn't make sense (but
you believe otherwise)
6. I'm missing some other reason

Let's assume #5 and #6. I can't think of more reasonable way
to handle #4 under the dimensional metaphor. From observation
I see that #2 and #3 do exist. So I'm left concluding that
there is at least one business model which conflicts with at
least one license model.


In other words, I disagree.

But as it turns out, you actually used the phrase "commercial
use" and not "business setting" in your reply. You've reduced
the high-dimensional "business space" down to a single
binary descriptor, "commercial."

You said you think of the high-dimensional "software license
space" as a single dimension, and your example implies
you think of it as also being binary dimension (is/is not free).

In that restricted, projected subspace then your argument works.
You successfully enumerated all four possibilities in that
narrow view of things. It just not what the original poster
said.

Life is complex. Organization helps understanding. Toy
models give clarity. But take away an essential complexity
and the toy is a curiosity only; the platypus removed.

Though I think echidnas look cuter than platypuses and are
just as interesting.


Andrew
(e-mail address removed)

 

[Donnal Walter]

Reading Lawrence Rosen's book on open source licensing is highly
recommended as well for people interested in this sort of thing. It's
oddly readable for a law (IPR law at that) book.

Ok, I browsed most of the opensource.org mailing list for the past six
months, and while enlightening, it didn't answer my specific questions
(and I have not asked them there, as most questions there are about
specific licenses). Rosen's book is not available to me at the moment,
but I have been reading St. Laurent's book, which has been helpful.
Nevertheless, may I pose the following scenario here?

Given:
1. PA, the "primary author" in this scenario.

2. FW, a "framework" authored by PA for developing small custom
applications in Python, especially by non-programmers who are
professionals in another field.

3. OApps, a suite of "original applications" written by PA using FW.

4. CApps, "contributed apps" to be written by other professionals in the
field using FW.

5. BigApp, an integrated version of OApps/CApps into a single "big
application" managed by PA using FW.

Now, PA wishes to make FW, CApps, and BigApp available as free software
such that:
a. pros in the field will be encouraged to use OApps and BigApp
b. pros will be encouraged to help improve OApps and BigApp
c. pros will be encouraged to contribute CApps to Bigapp
d. other programmers will be encouraged to help improve FW.

PA would like derivatives of OApps and BigApp to remain free (seeing no
reason why they should ever be proprietary), and is therefore leaning
toward copyleft (CL) licensing for these.

For similar reasons, PA wants to *encourage* CApps to be released under
CL or CL-compatible license so that they can be included in BigApp.

PA sees little advantage in allowing derivatives of FW to be proprietary
(and therefore is leaning toward CL for this, too). However, see next
paragraph.

PA does not currently plan on combining FW with other software, but is
aware of:
a. another framework (FW2) that is non-copyleft (NCL), and
b. another framework (FW3) that is CL,
with which FW might be merged one way or another in the distant future.

Here are my questions.

1. Is there a compelling reason for PA *not* to use a CL license (say
Gnu GPL) for OApps and BigApp? These are "end-user" applications, not
system components.

2. Am I right in thinking that the license for FW will have little or no
legal bearing on the licenses contributors choose for CApps?

3. Am I right in thinking that a CL license for BigApp would encourage
(but not require?) using CL for CApps (if they want them included)?

4. Will either a CL or NCL license for FW affect the likelihood of
receiving improvements from programmers outside the field of interest?

5. If PA chooses a CL license for FW, can it later be changed to NCL in
order to be combined with FW2?

6. If PA choses a NCL license for FW, can it later be changed to CL in
order to be combined with FW3?

Thanks,
Donnal Walter
Arkansas Children's Hospital

 

[Dan Perl]

Hi,



So does the GNU GPL. Freedom/Open Source and commercial use are two
orthogonal concepts. The two don't interfere in any way.

I beg to differ. Let's take a possible scenario. Let's say that my company
has a complex software product that sells for $1M a piece. And let's also
say that I need some encryption for the product. I find an encryption
library that is free and is GPL licensed. What happens if I use it?
Correct me if I'm wrong in any part (and I genuinely admit that I may be
wrong). I have to release my entire product under a GPL license and I have
to publish the entire code (I assume that the use of the encryption library
is not isolated to only one part of the product). Would my company want to
do something like that? I don't think so. Sure, we are still entitled to
try to sell the product but who would pay $1M when with a little effort they
can put the entire product together from the code and any support that we
could sell is never going to be worth the money we are asking for?

Red Hat can make money from selling their Linux distribution, but apart from
companies that have deeper pockets and for whom getting the support and
warranties that Red Hat offers are worth a relatively small fee, how many
small consumers buy the commercial distribution when they can just download
the same thing for free? No wonder that Red Hat also sells things like mugs
and T-shirts.

So getting back to my scenario, leaving theory and "orthogonality" aside,
practical reasons will stop many companies from using GPL licensed code in a
commercial product. I think that constitutes interference.

Dan

 

[Josiah Carlson]

I beg to differ. Let's take a possible scenario. Let's say that my company
has a complex software product that sells for $1M a piece. And let's also
say that I need some encryption for the product. I find an encryption
library that is free and is GPL licensed. What happens if I use it?
Correct me if I'm wrong in any part (and I genuinely admit that I may be
wrong). I have to release my entire product under a GPL license and I have
to publish the entire code (I assume that the use of the encryption library
is not isolated to only one part of the product). Would my company want to
do something like that? I don't think so. Sure, we are still entitled to
try to sell the product but who would pay $1M when with a little effort they
can put the entire product together from the code and any support that we
could sell is never going to be worth the money we are asking for?

If other posters on this topic are correct; you don't need to lose your
application in order to use that GPL library, you merely need to write a
wrapper for that library, which is then released under the GPL. Since
you are the original author, you can do whatever you want with the
wrapper; including using it in a commercial setting where you don't
release your application.

The wrapper is the derivative work, which is licensed under the GPL.
But being the original author, you can do whatever you want with the
wrapper, including using it from a non-GPL'd piece of software, without
needing to tell anyone about it.

If anyone asks about the fact that your main software is not GPL'd,
point them to the wrapper software, and as long as your wrapper is
nontrivial, I don't believe it is a big deal.

This is just a restatement of perhaps a half-dozen other people that
have posted in the last week or so on this same topic. If they are
wrong on this topic, then so am I.

Red Hat can make money from selling their Linux distribution, but apart from
companies that have deeper pockets and for whom getting the support and
warranties that Red Hat offers are worth a relatively small fee, how many
small consumers buy the commercial distribution when they can just download
the same thing for free? No wonder that Red Hat also sells things like mugs
and T-shirts.

Red Hat doesn't make money on selling their Linux distribution, they
make money on the /support contracts/ for large companies who need
guaranteed support.


- Josiah

 

[Robert Kern]

Donnal Walter wrote:

[snip]

1. Is there a compelling reason for PA *not* to use a CL license (say
Gnu GPL) for OApps and BigApp? These are "end-user" applications, not
system components.

Not terribly compelling to my mind, but:
Some people avoid copylefted works out of (pick one or more: habit,
ignorance, irrational fear, rational avoidance of licensing
complexity/uncertainty, any number of things I can't think of off the
top of my head). CApp authors will almost assuredly use OApps as
examples for using the framework. A license like the GPL for BigApp
could limit which CApps you can include because of incompatibilities.

2. Am I right in thinking that the license for FW will have little or no
legal bearing on the licenses contributors choose for CApps?

If the license you use for the framework is strong copylefted (e.g. GPL)
as opposed to weak copylefted (e.g. LGPL), then the license *will* have
a strong bearing on the license used for contributed apps.

3. Am I right in thinking that a CL license for BigApp would encourage
(but not require?) using CL for CApps (if they want them included)?

*shrug* I think that strongly depends on the community that you build
around your software. If I'm not involved in the community, I'm more
likely to choose a license for my apps which is in my best
interests/desires and meets the requirements of the licenses of the
libraries I am using. Only if there is a strong community that pushes
for a particular license am I likely to deviate from that preference.
BigApp's license alone wouldn't do that for me.

4. Will either a CL or NCL license for FW affect the likelihood of
receiving improvements from programmers outside the field of interest?

Probably, but I would doubt that anyone can tell you how either choice
will affect contributions. Many people will come up with arguments for
either position ("GPL will drive programmers away!" "GPL will gives
programmers assurance that everyone will give back to the community!").
Ignore them. They know less than you.

5. If PA chooses a CL license for FW, can it later be changed to NCL in
order to be combined with FW2?

If you not only are the principal author but also the sole copyright
owner, then yes. If you fold in changes from other people without having
them assign copyright to you or have them license those changes under a
permissive license (BSD, MIT, PSF, and the like), then you must obtain
permission to relicense from each of them. This can be a problem sometimes.

6. If PA choses a NCL license for FW, can it later be changed to CL in
order to be combined with FW3?

Similar answer as above. If the non-copyleft license is permissive like
BSD, etc. then your headaches are greatly reduced.

IANAL. TINLA.

--
Robert Kern
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

 

[Robert Kern]

Josiah Carlson wrote:

[snip]

If other posters on this topic are correct; you don't need to lose your
application in order to use that GPL library, you merely need to write a
wrapper for that library, which is then released under the GPL. Since
you are the original author, you can do whatever you want with the
wrapper; including using it in a commercial setting where you don't
release your application.

The wrapper is the derivative work, which is licensed under the GPL.
But being the original author, you can do whatever you want with the
wrapper, including using it from a non-GPL'd piece of software, without
needing to tell anyone about it.

If anyone asks about the fact that your main software is not GPL'd,
point them to the wrapper software, and as long as your wrapper is
nontrivial, I don't believe it is a big deal.

What kind of wrapper are you talking about? An executable program that
communicates with the rest of your software via pipes? If you are
linking in the GPL library and distributing the result, the whole code
must be licensed compatibly with the GPL no matter how much wrapper code
you put around it.

--
Robert Kern
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

 

[Josiah Carlson]

Josiah Carlson wrote:

[snip]

If other posters on this topic are correct; you don't need to lose your
application in order to use that GPL library, you merely need to write a
wrapper for that library, which is then released under the GPL. Since
you are the original author, you can do whatever you want with the
wrapper; including using it in a commercial setting where you don't
release your application.

The wrapper is the derivative work, which is licensed under the GPL.
But being the original author, you can do whatever you want with the
wrapper, including using it from a non-GPL'd piece of software, without
needing to tell anyone about it.

If anyone asks about the fact that your main software is not GPL'd,
point them to the wrapper software, and as long as your wrapper is
nontrivial, I don't believe it is a big deal.

What kind of wrapper are you talking about? An executable program that
communicates with the rest of your software via pipes? If you are
linking in the GPL library and distributing the result, the whole code
must be licensed compatibly with the GPL no matter how much wrapper code
you put around it.

Let us say that my commercial (non-GPL) software A links my GPL wrapper
B. Wrapper B links GPL'd library C.

B is the derivative of C, so must be GPL'd, and is. Since B is owned by
me, I can do what I want with it. So I do what I want, I link it from
my commercial software A.

Now, I can ship B and C as with a GPL license along with my non-GPL
software, stating quite clearly that since I am the owner of B, I am
going to link B as I find necessary.

From what I understand, as long as B is nontrivial, the above is
sufficient. And as I said before, if the original posters are incorrect
about this, so am I.


With all that said, if one /could not/ use GPL'd libraries from
commercial software, then nVidia and ATI would have lawyers knocking on
their doors for not GPLing their video drivers, as technically, the
nVidia drivers are derivative works of the Linux kernel. Not being
privy to the inner workings of nVidia nor ATI, I will not guess how they
have managed to release binary-only drivers for linux, and will just say
that it is being done.

- Josiah

 

[Cliff Wells]

With all that said, if one /could not/ use GPL'd libraries from
commercial software, then nVidia and ATI would have lawyers knocking on
their doors for not GPLing their video drivers, as technically, the
nVidia drivers are derivative works of the Linux kernel. Not being
privy to the inner workings of nVidia nor ATI, I will not guess how they
have managed to release binary-only drivers for linux, and will just say
that it is being done.

AFAIK there are no ATI binary drivers for Linux. Those drivers are part
of x.org, developed from ATI's specs. The NVidia drivers are binary ad
use the GPL'd wrapper approach. The driver comes in two parts: the
proprietary binary module, where all the interesting stuff happens, and
a GPL-compatible shim between it and the kernel.

Whether or not this is *really* GPL-compliant is still up in the air.
Just because nobody complains about it doesn't mean it's legal. I
seriously doubt any of the kernel developers have any intention of
"sending lawyers" to NVidia's door over it if it isn't, so the lack of
action doesn't really prove anything other than it works for practical
purposes

 

[Robert Kern]

Let us say that my commercial (non-GPL) software A links my GPL wrapper
B. Wrapper B links GPL'd library C.

B is the derivative of C, so must be GPL'd, and is. Since B is owned by
me, I can do what I want with it. So I do what I want, I link it from
my commercial software A.

Now, I can ship B and C as with a GPL license along with my non-GPL
software, stating quite clearly that since I am the owner of B, I am
going to link B as I find necessary.

You're still distributing C linked in with A. A derives from C. The fact
that you've stuck B in the middle is irrelevant unless it's part of a
communications bridge between a process consisting of A+B communication
via some form of IPC (sockets, pipes, whatever, just not static or
dynamic linking) with C (or A communicating with B+C, or A+B with B+C,
however it's arranged).

From what I understand, as long as B is nontrivial, the above is
sufficient. And as I said before, if the original posters are incorrect
about this, so am I.


With all that said, if one /could not/ use GPL'd libraries from
commercial software, then nVidia and ATI would have lawyers knocking on
their doors for not GPLing their video drivers, as technically, the
nVidia drivers are derivative works of the Linux kernel. Not being
privy to the inner workings of nVidia nor ATI, I will not guess how they
have managed to release binary-only drivers for linux, and will just say
that it is being done.

They use a wrapper (they call it a "shim") somewhat similar to what you
describe. The key difference is that their shim uses the standard kernel
API to talk with the binary-only drivers in much the same way that a
proprietary, binary-only application uses the standard kernel API. Using
the standard kernel API is considered (at least by Linus; see COPYING in
the Linux kernel distribution) to be *use* of the Linux kernel and thus
unrestricted and not creating a derivative work.

Wrapping C with, for example, an XML-RPC interface (GPL-compatible
license) and connecting to it via that interface from A
(GPL-incompatible) would be the appropriate analogy here.

--
Robert Kern
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

 

[Donnal Walter]

Donnal Walter wrote:

[snip]

2. Am I right in thinking that the license for FW will have little or
no legal bearing on the licenses contributors choose for CApps?

If the license you use for the framework is strong copylefted (e.g. GPL)
as opposed to weak copylefted (e.g. LGPL), then the license *will* have
a strong bearing on the license used for contributed apps.

This is not an exact analogy, but if Python were licensed under GPL (or
OSL), would *all* programs written *in* Python need to have the same
license? (My intuition says no, but I would not be totally surprised to
find that my intuition is wrong.)

Donnal Walter
Arkansas Children's Hospital

 

[Andrew Dalke]

This is not an exact analogy, but if Python were licensed under GPL (or
OSL), would *all* programs written *in* Python need to have the same
license?

It's in the GPL FAQ:
http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL

"""
If a programming language interpreter is released under the GPL,
does that mean programs written to be interpreted by it must be
under GPL-compatible licenses?

When the interpreter just interprets a language, the answer is
no. The interpreted program, to the interpreter, is just data;
a free software license like the GPL, based on copyright law,
cannot limit what data you use the interpreter on. You can run
it on any data (interpreted program), any way you like, and
there are no requirements about licensing that data to anyone.

However, when the interpreter is extended to provide "bindings"
to other facilities (often, but not necessarily, libraries),
the interpreted program is effectively linked to the facilities
it uses through these bindings. So if these facilities are
released under the GPL, the interpreted program that uses them
must be released in a GPL-compatible way. The JNI or Java Native
Interface is an example of such a facility; libraries that are
accessed in this way are linked dynamically with the Java programs
that call them.

Another similar and very common case is to provide libraries with
the interpreter which are themselves interpreted. For instance,
Perl comes with many Perl modules, and a Java implementation
comes with many Java classes. These libraries and the programs
that call them are always dynamically linked together.

A consequence is that if you choose to use GPL'd Perl modules or
Java classes in your program, you must release the program in a
GPL-compatible way, regardless of the license used in the Perl
or Java interpreter that the combined Perl or Java program will
run on.
"""

Andrew
(e-mail address removed)