Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120219170820.GA16821@openwall.com>
Date: Sun, 19 Feb 2012 21:08:20 +0400
From: Solar Designer <solar@...nwall.com>
To: musl@...ts.openwall.com
Subject: Re: License survey

On Sun, Feb 19, 2012 at 11:18:12AM -0500, Rich Felker wrote:
> One thing I like about copyleft and having external copyright holders
> is that the rules apply to me too. If, for instance, I were working in
> embedded systems as a job, and my employer asked me to prepare a
> derived work of musl for purely-closed use, I could simply tell them
> that's not possible without the consent of other copyright holders.
> But with no copyleft, or if I'm the sole copyright holder, the choice
> is pretty much to do it or quit (and if I do it, then of course there
> becomes a contamination issue if I later try to make similar
> improvements to the open version).

Wouldn't you also have the choice to tell your employer that you're
willing to let them use the code provided that you retain the right to
reuse any enhancements (or at least those you put in for them yourself)
in the free musl?  Of course, this permission (from the employer) will
need to be in writing - included in the same license agreement that lets
them use musl.  If they disagree, you don't let them use musl (and if
this somehow results in them not wanting to continue to employ you, then
you quit - I think I would).

For example, Openwall's standard contract agreement for professional
services says that we retain the right to reuse any enhancements that we
implement ourselves (of course, it is actually more verbose about that).
If a prospective client does not like that, we don't sign the contract
(or at least leave these kinds of work out of scope).

> Another issue (I suspect Solar will feel differently than me about
> this one) is the possibility of offering a non-free, closed version.
> If I'm doing a BSD-licensed project and asking others to contribute
> under BSD license, it feels like I'm taking their contributions to
> build something I could turn around and make closed/commercial
> derivatives of for my own benefit. And in a way it would be wrong to
> deny myself the right to do this if everybody else who receives the
> code has a right to do it,

Exactly: everybody receives that right, not just you.  All contributors
receive that same right to the entire thing.

> but the original author and/or project
> maintainer is in a unique position of authority and trust that makes
> it much easier to commercially exploit the code.

That unique position might be justified by you starting the project
and by the amount and nature of your contributions.  On the other hand,
if someone else contributes as much as you do, they may also be in a
similar position (no longer unique).  Ditto if someone makes a popular
fork, or if you retire from the project and someone else takes over
further maintenance.  Sounds fair to me.

In a sense, it's a question of "not have the benefit such that we're
sure we're being fair to every contributor (no one gets the benefit)"
vs. "have the benefit, but not be nearly so sure about distributing
it fairly (someone might get a disproportional share)".  Once we
consider that this benefit might enable the project to evolve faster
(e.g., enable you and maybe other key/major contributors to dedicate
more time to it), then the second option feels better to me.  You can be
a saint, but do little good, or you can choose not to be a saint, but do
some more good overall.

> I don't think there's a quick and easy answer for what's best to do

This definitely involves some non-trivial tradeoffs, yet some of us were
able to make specific suggestions, as you can see.  To me, it appears
that non-copyleft wins in terms of raw vote count.

Alexander

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.