Picking a license

Patrick Maupin pmaupin at gmail.com
Fri May 14 22:55:54 EDT 2010


On May 14, 9:32 pm, Steven D'Aprano <st... at REMOVE-THIS-
cybersource.com.au> wrote:
> > Don't be silly.  That's why I started writing open source software in
> > the first place.  But if I start writing stuff to put in the commons
> > with strings removed, why would I bother with a license that just adds
> > some strings back?
>
> To maximise the likelihood of it staying in the commons, of course.

Well, it's your opinion that it would do that, and you have some
reasonably good reasons for that opinion, but I don't personally buy
into all of them.

[...]

> Obviously no licence can guarantee that people will want to use your
> software. Unpopular software will remain unpopular no matter what licence
> you use. But it is precisely the viral nature of the GPL that means that,
> *if* your software is useful enough for people to want to distribute it,
> it will remain in the commons even if you, the original author, are hit
> by a bus, your web server crashes, and you lose the original sources.

Sure, there's an additional guarantee.  But I don't believe there is a
real distinction.  I believe, for example, that all the major Linux
distributions don't try to save bandwidth or disk space by
discriminating against non-GPL packages.  For example, the Ubuntu
policy clearly states that to be in "main" rather than "restricted" a
package "must include source code."

> Under the GPL, of course work can be lost from the commons if nobody
> distributes it and the original is lost. But the viral nature is designed
> so that *if* the software propagates legally, it remains in the commons
> and not out of it. This is different from MIT-style licences, which are
> indifferent to whether the software propagates in the commons or not, and
> proprietary licences, which typically prohibit it.

While that is a theoretical difference, I don't believe it is a
practical one.  I don't download all the source for my Linux distro,
but they make all the source available.

> >> In practice, I believe most MIT-licenced code never even makes it into
> >> the commons in the first place.
>
> > Interesting assertion.
>
> I think it is a safe one. So far in the discussion, you and Ed (and
> possibly others, I may have forgotten) have repeatedly declared that you
> use the MIT licence for work you write for clients.

I think there is a serious misunderstanding there.  For me, there are
usually 3 types of licenses involved:

1) proprietary license or work-for-hire agreement for the customer's
secret sauce
2) Stuff that the author has put under a permissive license before, or
gets the customer to agree is not part of the secret sauce, and the
customer agrees to allow the author to put under a permissive license
after he writes it
3) Stuff that somebody else wrote under a permissive license

For most of my career, I've been an employee with a work-for-hire
clause, so pretty much all my writing falls under (1) unless I can
make a compelling argument for (2), which is finally starting to
happen a bit more.

> This implies two
> obvious business models:
>
> (1) You write open source software, put it on the Internet, and wait for
> the donations to come flooding in.
>
> (2) Clients pay you to write software for them, which you then use a non-
> GPL open source licence so that they don't need to release the source
> code if/when they distribute it further.

The bulk of the code is probably (3) Customer dictates the license.

[Snipped a bunch of stuff predicated on a misunderstanding of the way
things work for me]

> It's strictly irrelevant to this discussion, but I'm curious why you
> choose to licence your work to your clients rather than just working for
> hire and assigning copyright to them.

In the past, work-for-hire was practically the rule (during the times
I've been an employee).  I've been trying to release open stuff from
the workplace from over a decade with little traction, but it's
finally happening a bit.  There are multiple good reasons to open-
source, including the hope for coopetition, and the building of a
resume.  Given that other people who might cooperate with me on an
open source project are often similarly situated (working for
proprietary employers who wouldn't necessarily want to worry about the
GPL), using a permissive license makes great sense.

Regards,
Pat



More information about the Python-list mailing list