Re: musl licensing

[Szabolcs Nagy <nsz@port70.net>]

* Rich Felker <dalias@libc.org> [2016-03-15 18:41:26 -0400]:
> On Tue, Mar 15, 2016 at 02:59:24PM -0700, Petr Hosek wrote:
> > The first issue is the lack of clarity around per-file licensing and
> > copyright attribution.
> 
> It's always been my intent to be document copyright status of the
> various parts of musl in detail in the COPYRIGHT file. If adding
> one-line notices to non-trivial source files would help gain
> acceptence by lawyers, I don't think that would be terribly
> controversial.

there should be a way to document copyright without changing
source files.  if google has some best practice for that we
can follow it i think.  (one line comment is ok, but i'd prefer
no license related text in source files.)

> > The other issue is the claim that some files
> > (in particular, the public headers and C runtime) are in the public
> > domain. While this might be technically correct, it's not legally
> > sound and we would be legally unable to use these files without them
> > being placed under copyright and an open source license. The most
> > appropriate way of addressing both issues would be to include a
> > copyright notice in individual source and header files.
> 
> As far as the public headers, it's my view that the vast majority do
> not contain any copyrightable original content. For the standard
> interfaces they all just match the interface requirements of ISO C and
> POSIX; only some specific type definitions and numeric constants are
> implementation-specific, and these are just minimal factual
> definitions matching ABIs/kernel. Some places have a very small amount
> of what you might call 'code' in public headers, but they're all the
> obvious/only way to express what they're doing, not anything creative.

bionic actually generates its kernel interface headers from (gpl) code
and each file has the comment:

 ***   This header was automatically generated from a Linux kernel header
 ***   of the same name, to make information necessary for userspace to
 ***   call into the kernel available to libc.  It contains only constants,
 ***   structures, and macros generated from the original header, and thus,
 ***   contains no copyrightable information.

so it is ok to claim 'not copyrightable', we just have to find a way
to do this without cluttering each header file.

> > address these issues. We believe that our company's interpretation of
> > the copyright and authorship is the same across the entire industry

i don't believe that.

> > license). Furthermore, all past and future contributors will have to
> > to sign the Contributor License Agreement (CLA). Since the majority of
> > musl authors are present in this forum, we're reaching out to you to
> > ask whether this is something you would agree with and also to start
> > the discussion within the wider musl community.
> 
> I don't think anything CLA-like is acceptable to our community. All
> the evidence points to it being a huge barrier to entry for new
> contributors. There is plenty of documentation of development process
> in the git log and on the mailing list to show that our contributors
> are submitting code with the intent that it be used in musl under the
> project's license.

linux kernel uses Signed-off-by: in commit messages for this
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=refs/tags/v4.5#n416

i think even that's superfluous (the Author: is already there
we just have to document what it means)

ideally anonymous contributions would work too in some way.