>>>>> "R" == R Padraic Springuel <[EMAIL PROTECTED]> writes:
R> Stéfan suggested that I include an example script to show
R> people what the package could do. I thought this was a good
R> idea, so I wrote one and have uploaded a new version of the
R> package with the example script. I've also added copyright and
R> license information, for those that care.
Hi this looks very nice. Are you sure you want to go with GPL?
pycluster and the C clustering license, as well as matplotlib, scipy,
and Numeric/numpy, are all based on BSD/PSF compatible licenses, and
so none of these projects can reuse your code if it is GPL.
Here is my "licensing pitch" on why I encourage people not to use the
GPL, written for another project but applicable here...
I'll start by summarizing what many of you already know about open
source licenses. I believe this discussion is broadly correct,
though it is not a legal document and if you want legally precise
statements you should reference the original licenses cited
here. The Open-Source-Initiative is a clearing house for OS
licenses, so you can read more there.
The two dominant license variants in the wild are GPL-style and
BSD-style. There are countless other licenses that place specific
restrictions on code reuse, but the purpose of this document is to
discuss the differences between the GPL and BSD variants,
specifically in regards to my experience developing matplotlib and
in my discussions with other developers about licensing issues.
The best known and perhaps most widely used license is the GPL,
which in addition to granting you full rights to the source code
including redistribution, carries with it an extra obligation. If
you use GPL code in your own code, or link with it, your product
must be released under a GPL compatible license. I.e., you are
required to give the source code to other people and give them the
right to redistribute it as well. Many of the most famous and widely
used open source projects are released under the GPL, including
linux, gcc and emacs.
The second major class are the BSD-style licenses (which includes
MIT and the python PSF license). These basically allow you to do
whatever you want with the code: ignore it, include it in your own
open source project, include it in your proprietary product, sell
it, whatever. python itself is released under a BSD compatible
license, in the sense that, quoting from the PSF license page
There is no GPL-like "copyleft" restriction. Distributing
binary-only versions of Python, modified or not, is allowed. There
is no requirement to release any of your source code. You can also
write extension modules for Python and provide them only in binary
form.
Famous projects released under a BSD-style license in the permissive
sense of the last paragraph are the BSD operating system, python and
TeX.
I believe the choice of license is an important one, and I advocate
a BSD-style license. In my experience, the most important commodity
an open source project needs to succeed is users. Of course, doing
something useful is a prerequisite to getting users, but I also
believe users are something of a prerequisite to doing something
useful. It is very difficult to design in a vacuum, and users drive
good software by suggesting features and finding bugs. If you
satisfy the needs of some users, you will inadvertently end up
satisfying the needs of a large class of users. And users become
developers, especially if they have some skills and find a feature
they need implemented, or if they have a thesis to write. Once you
have a lot of users and a number of developers, a network effect
kicks in, exponentially increasing your users and developers. In
open source parlance, this is sometimes called competing for mind
share.
So I believe the number one (or at least number two) commodity an
open source project can possess is mind share, which means you want
as many damned users using your software as you can get. Even though
you are giving it away for free, you have to market your software,
promote it, and support it as if you were getting paid for it. Now,
how does this relate to licensing, you are asking?
Many software companies will not use GPL code in their own software,
even those that are highly committed to open source development,
such as enthought, out of legitimate concern that use of the GPL
will "infect" their code base by its viral nature. In effect, they
want to retain the right to release some proprietary code. And in my
experience, companies make for some of the best developers, because
they have the resources to get a job done, even a boring one, if
they need it in their code. Two of the matplotlib backends (FLTK and
WX) were contributed by private sector companies who are using
matplotlib either internally or in a commercial product -- I doubt
these companies would have been using matplotlib if the code were
GPL. In my experience, the benefits of collaborating with the
private sector are real, whereas the fear that some private company
will "steal" your product and sell it in a proprietary application
leaving you with nothing is not.
There is a lot of GPL code in the world, and it is a constant
reality in the development of matplotlib that when we want to reuse
some algorithm, we have to go on a hunt for a non-GPL version. Most
recently this occurred in a search for a good contouring
algorithm. I worry that the "license wars", the effect of which are
starting to be felt on many projects, have a potential to do real
harm to open source software development. There are two unpalatable
options. 1) Go with GPL and lose the mind-share of the private
sector 2) Forgo GPL code and retain the contribution of the private
sector. This is a very tough decision because their is a lot of very
high quality software that is GPL and we need to use it; they don't
call the license viral for nothing.
The third option, which is what is motivating me to write this, is
to convince people who have released code under the GPL to
re-release it under a BSD compatible license. Package authors retain
the copyright to their software and have discretion to re-release it
under a license of their choosing. Many people choose the GPL when
releasing a package because it is the most famous open source
license, and did not consider issues such as those raised here when
choosing a license. When asked, these developers will often be
amenable to re-releasing their code under a more permissive
license. Fernando Perez did this with ipython, which was released
under the LGPL and then re-released under a BSD license to ease
integration with scipy and other enthought products. The LGPL is
more permissive than the GPL, allowing you to link with it
non-virally, but many companies are still loath to use it out of
legal concerns, and you cannot reuse LGPL code in a proprietary
product.
So I encourage you to release your code under a BSD compatible
license, and when you encounter an open source developer whose code
you want to use, to do the same. Feel free to forward this document
on them.
Comments, suggestions for improvements, corrections, etc, should be
sent to [EMAIL PROTECTED]
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
