Re: musl licensing

[Christopher Lane <lanechr@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 7198 bytes --]

On Thu, Mar 17, 2016 at 9:01 AM, Rich Felker <dalias@libc.org> wrote:

> On Thu, Mar 17, 2016 at 08:14:04AM -0700, Christopher Lane wrote:
> > On Mar 17, 2016 1:18 AM, <u-uy74@aetey.se> wrote:
> > >
> > > On Wed, Mar 16, 2016 at 07:06:25PM -0700, Christopher Lane wrote:
> > > > ... if releasing under e.g. BSD0 is OK when PD isn't
> > > > valid, why isn't it OK for all situations.
> > >
> > > I expect that it is illegal in certain jurisdictions to claim
> > > copyright on a public domain matter.
> > >
> > > This is not a problem for the musl user (Google) but potentially
> endangers
> > > the developer who wrote the questionable copyright statement.
> > >
> > > This may explain why Google explicitly mentions "non-copyrightable" in
> a
> > case
> > > when it represents the developer party:
> > >
> > > On Wed, Mar 16, 2016 at 11:31:25AM +0100, Szabolcs Nagy wrote:
> > > > 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 this is actually all about which party shall take the risks,
> > > musl or Google. Isn't it?
> >
> > This isn't about shoveling risk from Google to musl.  We want musl to be
> a
> > clear and unambiguously licensable product so we can use it.
> Incidentally,
> > figuring out the licensing stuff here is a large distraction for our team
> > (and we knew it would be), but we're willing to put in the time and
> effort
> > because we think it's beneficial for the open source community overall,
> and
> > because it's ethically correct. This isn't just CYA, and it's not some
> > nefarious scheme.
> >
> > WRT bionic, I don't know what they're doing and I don't have any insight
> > into what went into that decision.  I only know what our team has been
> told
> > about using musl.
> >
> > If it comes down to it, it might be possible for us to avoid using any of
> > the public domain parts of musl - maybe in a fashion similar to what
> bionic
> > did, I don't know yet.  If that's good enough for our lawyers, it'll get
> > our team unblocked and that's good enough I guess.  Though, I'd prefer we
> > solve this without such a workaround so others can benefit.
>
> I understand that's a possibility, but I'd like to work with you to
> make sure that's not one you have to take, since using these parts is
> actually one of the best aspects of using musl.
>
> Rich
>

I've returned from the land of lawyers with answers.  Please pardon the
length of this email.

1. Why doesn't the MIT license apply in the case where PD one doesn't?

Essentially, because the relevant decision point is at time of
contribution.  When work is contributed to an open source project, it's
taken as wide spread convention that the work is being contributed under
the license the open source project itself is released under.

As an aside, this has apparently never been litigated and therefore is not
necessarily true, but it's taken as fact in the vast majority of the open
source community.  Google won't accept contributions to its open source
projects under a mere convention, so it requires CLA (that isn't directly
applicable here, I just thought it was an interesting fact.)

Anyway, applying the open source convention above to the case of musl, if
work is contributed to the include/*, arch/*/bits/* or crt/* directories,
that work is assumed to be contributed as public domain.  In the event that
public domain doesn't hold, that work is not then retroactively assumed to
have been contributed under MIT.  Instead, that work is considered to have
been contributed without a license.  We could argue over whether this would
_actually_ happen, but it doesn't matter -- that chain of events is
plausible enough for it to be a problem.

2. Is it sufficient to add the language you wrote earlier? ("Should the
release of these files into the Public Domain be judged legally invalid or
ineffective ... [Redistribution and use] with or without modification, are
permitted.")

No.  Why?  Well, because here's what would happen.  Let's say this claim is
tested - the phrase "judged legally invalid or ineffective" comes under
attack.  Judged by whom?  What is legally invalid exactly?  This is
ambiguous enough that it can still result in a lawsuit.

Also, just adding the language doesn't address the first point - that the
(presumed) relevant text of the COPYRIGHT file is the text when the files
were contributed.

3. Is adding a musl CLA a requirement, a suggestion, or what?

If you assume the validity of the whole "open source licensing convention"
I mentioned earlier, it's not required for future contributions.  I mean,
obviously right, because there are plenty of open source projects without
them.

But if you do end up removing the public domain claim from the COPYRIGHT
file (which we seriously recommend) you should at least collect agreements
from folks who contributed work that might be affected (to make sure they
agree to contributing that work under e.g. BSD-0).  I believe musl went
through a relicense of the whole project at some point, so I'm sure you're
familiar with this concept already.  We're definitely not suggesting a
relicense of the whole project -- we're suggesting explicitly licensing the
stuff that is today claimed to be PD.

[end of q/a]

OK, so where does that leave us?  One invariant exists: as a team that
works for Google, we can't use anything that was contributed to musl as
PD.  Others probably shouldn't, but we strictly *can't*.  We can approach
this from different angles:

Practically: By claiming that things are public domain, you're having the
inverse effect of what you want -- fewer people can actually use the work.
Just because you claim something is PD doesn't make it so - it sucks, but
that's the current legal situation.  If you really want something to be as
widely usable as possible, not only now but years from now, license it
BSD-0.

Ideologically: Sure, things like numbers or APIs aren't (or shouldn't be)
copyrightable, but that's not all there is here.  The musl headers don't
look exactly like any other libc's headers.  Work has gone into them over
the years.  They're ordered differently.  Variable names are different.
Look at include/alltypes.h.in or math.h for more differences.  You may
consider this work to be trivial, but it IS original.  We can't (and
shouldn't) use it without a license.

Our suggestion: please get permission from the relevant people to release
their work as BSD-0, remove the public domain text from COPYRIGHT, license
the headers and crt, etc. files as BSD-0.  In a separate file, register
your opinions and intent that the public headers, etc. should be freely
usable and unowned by anyone but the current state of affairs WRT software
and copyright is complete shit (which it so totally is).

[-- Attachment #2: Type: text/html, Size: 9375 bytes --]