mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Solar Designer <solar@openwall.com>
To: musl@lists.openwall.com
Subject: Re: License survey
Date: Sun, 19 Feb 2012 21:08:20 +0400	[thread overview]
Message-ID: <20120219170820.GA16821@openwall.com> (raw)
In-Reply-To: <20120219161812.GS146@brightrain.aerifal.cx>

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


  reply	other threads:[~2012-02-19 17:08 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-19  4:12 Rich Felker
2012-02-19  7:00 ` Isaac Dunham
2012-02-19 14:31   ` gs
2012-02-19  7:27 ` Kurt H Maier
2012-02-19 11:55   ` Hiltjo Posthuma
2012-02-19 12:17 ` Solar Designer
2012-02-19 13:55 ` Christian Neukirchen
2012-02-19 15:48   ` Solar Designer
2012-02-19 16:18     ` Rich Felker
2012-02-19 17:08       ` Solar Designer [this message]
2012-02-19 22:25       ` Kurt H Maier
2012-02-19 22:51         ` Rich Felker
2012-02-20  0:55           ` Kurt H Maier
2012-02-22 17:51       ` Isaac Dunham
2012-02-22 23:20         ` Rich Felker
2012-02-19 14:01 ` Luka Marčetić
2012-02-19 16:03 ` aep
2012-02-19 16:28   ` Solar Designer
2012-02-21 15:42 ` Szabolcs Nagy
2012-02-21 16:59   ` Bobby Bingham
2012-02-21 17:16     ` Rich Felker
2012-02-21 21:22       ` Szabolcs Nagy
2012-02-21 18:31 ` Nathan McSween

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120219170820.GA16821@openwall.com \
    --to=solar@openwall.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).