Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20160316225058.a99cf7cd3487085e30633148@frign.de>
Date: Wed, 16 Mar 2016 22:50:58 +0100
From: FRIGN <dev@...gn.de>
To: musl@...ts.openwall.com
Subject: Re: musl licensing

On Wed, 16 Mar 2016 17:35:51 -0400
Rich Felker <dalias@...c.org> wrote:

Hey Rich,

> One claims copyright but then gives unlimited permission to use/etc.
> The other disclaims copyright and thereby avoids placing any
> copyright-based restrictions on use. In terms of what you can do there
> is no difference, but there is an ideological difference in claiming
> "these facts belong to me, and you can only use them because I was
> willing to give you permission" rather than "I just wrote these facts
> down, but they don't belong to me or to anyone, and you can freely use
> them".

So in practice there is no difference. The thing with copyright is, and
that's why some jurisdictions don't accept "public domain", that no
matter what you do, you as the author always have the copyright for a
certain piece of code and you have the special right to relicense it to
whatever you want. You are however allowed to pass this right on.

I think it would be wise to reflect here if just using BSD-0 would be
enough to calm your mind. It's a question of deontologism or teleologism.
Is the way the goal or the end result? In my opinion, the end result is
all that matters, and in this case given BSD-0 practically gives you the
same results as public domain while being legally sound everywhere really
makes the cut.

> I tend to agree. I also find that it's problematic trying to decide
> whether someone who makes a 1-line or 5-line patch to an existing
> nontrivial file is a copyright holder for the file, and rather
> pointless since it really makes no difference except to someone
> contacting all copyright holders trying to get permission to
> relicense. As far as I am aware, the vast majority of FOSS projects do
> not waste their time trying to make such determinations.

At suckless.org we usually only list contributors of large patches or
multiple commits. People who just simply fix a bug cannot be thought of
as copyright holders.
Now the point at which a work is copyrightable is not clear, and at some
point we decided that people who do not add themselves to the LICENSE
are at fault. It's much easier this way.

> My view is that a project and its maintainer should document these
> things sufficiently well that users of the code can feel comfortable
> that they actually have the license permissions you tell them they
> have, and that further pedantry that does not affect license validity
> should be left to lawyers only to be done when there's actually a need
> for it (since their time costs a lot :). Stupid things like whether a
> 1-line patch author is a copyright holder may even vary by
> jurisdiction. FWIW in my experience even the FSF is satisfied that
> patches consisting of trivial changes, even a fair number of such, do
> not require having a copyright assignment on file with them, so their
> lawyers presumably are not concerned about such contributors claiming
> copyright.

Lawyers make everything complicated. My interest is really for the people
trying to get stuff done and wanting to use code sections they found in
musl. The licensing should be clear and easy to understand and find.
If I find code that is under the BSD0, I consider it public domain.
Maybe lawyers draw a finer line, but I don't really care. In reality, both
can be handled equally.
Also the warranty clause protects you from charges, public domain gives
you no such protection. And it would not be the first time that a
company tries to put charges on an innocent developer. These allcaps
warranty clauses are there for a reason, not just for entertainment.

Cheers

FRIGN

-- 
FRIGN <dev@...gn.de>

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.