Software licenses and releasing Python programs for review

[Andreas Kostyrka]

Am Donnerstag, den 02.06.2005, 17:52 +0000 schrieb Karl A. Krueger:
> Andreas Kostyrka <andreas at kostyrka.org> wrote:
> > *) GPL is not acceptable for "library" stuff, because as a software
> >   developer I'm sometimes forced to do "closed" stuff.
> >   (Yep, even nowadays there are place where it's basically a legal
> >    requirement.)
> 
> I'm curious about this last one.
> 
> The GPL does not require that derivative works be published, or that
> they be donated back to the original author.  All it requires is that
> you pass on the rights that you received to the recipient of your
> derivative work -- in this case, your customer alone.
> 
> Of course, if your customer is a proprietary software firm looking to
> own and sell the software restrictively, then they don't want those
> terms.  But if they're just looking to use it privately and internally,
> I'm curious how the GPL would get in the way of that.
Well, basically there are some obstacles:
a) legal departments
b) the feeling of the customer that he gets something "less" (because
the customer doesn't have full control)
c) problem cases like external contractors

Basically my points are:
a) there are certain "feelings" that seem to be common to most open
source people. They might vary quite a bit in details but somehow we all
swim more or less in the same river.
b) as an example I've explained what my personal position in this is.

Another take on the GPL (again my philosophy) is, that a license is good
if it doesn't restrict. GPL'ed projects are successful mostly when the
GPL adds benefits.

GPL licensed projects have benefits:
      * strong anti-fork pressure. (Because you cannot just fork the
        code and go closed. Any fork must have a real good reason d'etre
        or it will die.)
      * community orientation -> GPL gives a strong "it's our code we
        are working on" feeling.
      * a growing number of software that is only available under the
        GPL.
But it also has a number of drawbacks, like:
      * It forces the GPL (more or less) on all users [applies only to
        library building blocks]
      * Without copyright assignments it leads to patchy ownership
        structure. E.g. changing the license for the Linux kernel would
        be a really major undertaking.

The point is that the license should be tailored to the intended use of
your software.

And think about it like that: "What can I give my users so that they
become interested in my software?"

Just being able to do something like burning a DVD might be enough for
many "typical" Windows users, but the opensource crowd usually demands
more. Like in more blueprints, more rights, etc.

And fact is that the basic environment without artifical constructs like
intellectual property legaslation favors the users:

Without patents, in most cases somebody will reimplement your software,
if there is need.

Without copyrights, the users will just copy your binary ;)

Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://mail.python.org/pipermail/python-list/attachments/20050602/f097cd2a/attachment.sig>