Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKFisceTr-5D9Cq30JHTHs4QnXP4BEgP=CNvaCAaXvi2bQz0xw@mail.gmail.com>
Date: Mon, 21 Mar 2016 15:46:18 -0700
From: Christopher Lane <lanechr@...il.com>
To: musl@...ts.openwall.com
Subject: Re: musl licensing

On Fri, Mar 18, 2016 at 9:35 PM, Rich Felker <dalias@...c.org> wrote:

> On Fri, Mar 18, 2016 at 07:47:21PM +0000, George Kulakowski wrote:
> > I wanted to mention another small thing, which is simply to update the
> > names of some files specifically mentioned in COPYRIGHT. I've attached a
> > diff.
>
> Thanks. Applied.
>
> Rich
>

Some comments on the proposed COPYRIGHT text...

"""
The implementation of blowfish crypt (src/misc/crypt_blowfish.c) was
originally written by Solar Designer and placed into the public
domain. The code also comes with a fallback permissive license for use
in jurisdictions that may not recognize the public domain.
"""

"""
The x86_64 port was written by Nicholas J. Kain. Several files (crt)
were released into the public domain; others are licensed under the
standard MIT license terms at the top of this file. See individual
files for their copyright status.
"""

Those paragraphs still reference public domain.  We can't use the things
mentioned there.  WRT the blowfish impl, there are other implementations we
can pull if we want / need that - though I'm not sure we even do want
that.  The x86_64 crt files can be cleanroom'ed here (and we'd release
those BSD0 when we're done).  If you want to fix in musl, that works for us
too, of course.  If it's not feasible to fix upstream, it might be good to
even more explicitly note which files exactly are meant to be covered by PD
-- in the event they have to be surgically removed, that would help.  If
the per-file headers are up-to-date, that might be fine.

The new text is almost OK.  The biggest problem is, you shouldn't comment
or speculate on the copyrightability of work inside the license file.
Doing so could unintentionally alter or restrict the scope of the license
you're attempting to apply.  Comments should go in the readme file or
another separate file.  In the words of one of the lawyers here, "the
license file should say X is MIT, Y is BSD, Z is BSD-2, goodbye."

Apparently license files are like code written in English (or other human
languages) where the compiler is some future, undetermined group of
people.  It takes the concept of undefined behavior to a new level...

Content of type "text/html" skipped

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.