musl licensing

musl licensing

[Petr Hosek]

We work on Chromium project at Google. Our team, as well as several
other teams here at Google, would like to start using musl in various
open-source projects. This includes shipping musl as a part of SDKs
and toolchains. However, after performing a standard license review,
our open-source lawyers told us that there are two obstacles to us
being able to use musl.

The first issue is the lack of clarity around per-file licensing and
copyright attribution. 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.

Rather than working around these issues by reimplementing parts of
musl, we would like to work with the musl community to directly
address these issues. We believe that our company's interpretation of
the copyright and authorship is the same across the entire industry
and resolving these issues would benefit both musl as well as projects
which already do or plan to use musl.

To address both issues, authors of all files in musl that are "public
domain" or any other non-license will have to agree with relicensing
their work under the MIT license (or any other compatible open-source
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.

Re: musl licensing

[croco]

On Tue, Mar 15, 2016 at 02:59:24PM -0700, Petr Hosek wrote:
 
> To address both issues, authors of all files in musl that are "public
> domain" or any other non-license will have to agree with relicensing
> their work under the MIT license (or any other compatible open-source
> license). 

Well, this sounds strange but may (or may not) be reasonable, as 'public
domain' is a licensing status of a work, just as well as any license.  In
some countries it is not legally possible to put anything into public
domain until the copyright expires; for such countries, there's a
possibility to add a clause like "for countries where this is not legally
possible, the premission is hereby granted to anyone to do whatever (s)he
wants with this work".

However, ...

> Furthermore, all past and future contributors will have to
> to sign the Contributor License Agreement (CLA). 

Please clarify, what does THIS have to do with any licensing problems?
Does Google recognize open source licenses or not?  If it does, there must
be no need for signing any additional agreements, as the license IS THE
agreement; and if it doesn't, then there's, to my mind, no point of further
discussion at all.


P.S. I'm not a musl developer, but I'm very interested in the field of
copyright-related and opensouce-related law, and I believe the others on
this list might want similar clarification, too.


--
Croco

Re: musl licensing

[Alexander Cherepanov]

On 03/16/2016 01:17 AM, croco@openwall.com wrote:
>> Furthermore, all past and future contributors will have to
>> to sign the Contributor License Agreement (CLA).
>
> Please clarify, what does THIS have to do with any licensing problems?
> Does Google recognize open source licenses or not?

Yeah, this is a crucial question IMHO. There was a similar discussion 
about LLVM licensing recently:

http://lists.llvm.org/pipermail/llvm-dev/2015-October/thread.html#91536

 From this thread I gathered that:
1) Google is quite serious about CLAs;
2) Google has ideas about copyright/licensing/etc which contradict 
beliefs held widely in the community;
3) Google is not inclined to explain the situation to the community, 
judging by

http://lists.llvm.org/pipermail/llvm-dev/2015-October/091752.html

Given its past legal troubles, Google has enough stimuli to study the 
topic very carefully and it could be right. But could be wrong as well. 
Anyway, I don't think that just saying that CLAs are required is going 
to change the opinion of the community.

-- 
Alexander Cherepanov

Re: musl licensing

[Petr Hosek]

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

On Wed, Mar 16, 2016 at 9:32 AM Alexander Cherepanov <ch3root@openwall.com>
wrote:

> Yeah, this is a crucial question IMHO. There was a similar discussion
> about LLVM licensing recently:
>
> http://lists.llvm.org/pipermail/llvm-dev/2015-October/thread.html#91536
>
>  From this thread I gathered that:
> 1) Google is quite serious about CLAs;
> 2) Google has ideas about copyright/licensing/etc which contradict
> beliefs held widely in the community;
> 3) Google is not inclined to explain the situation to the community,
> judging by
>
> http://lists.llvm.org/pipermail/llvm-dev/2015-October/091752.html
>
> Given its past legal troubles, Google has enough stimuli to study the
> topic very carefully and it could be right. But could be wrong as well.
> Anyway, I don't think that just saying that CLAs are required is going
> to change the opinion of the community.
>

To clarify the CLA bit, we're not asking musl authors to sign the Google
CLA. Instead, what we proposed was coming up with a CLA specifically for
musl. Since someone, in this case most likely Rich as the project
maintainer, has to re-license the files which are currently in public
domain, one way is to have the past contributors sign a "musl project" CLA
as a way to keep a track of the legal permission to use and distribute
these files. However, this is a decision of the musl community and how you
do the re-licensing is up to you, as long as you have the permission to
re-license the files in question.

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

Re: musl licensing

[Josiah Worcester]

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

On Wed, Mar 16, 2016 at 3:50 PM Petr Hosek <phosek@chromium.org> wrote:

> To clarify the CLA bit, we're not asking musl authors to sign the Google
> CLA. Instead, what we proposed was coming up with a CLA specifically for
> musl. Since someone, in this case most likely Rich as the project
> maintainer, has to re-license the files which are currently in public
> domain, one way is to have the past contributors sign a "musl project" CLA
> as a way to keep a track of the legal permission to use and distribute
> these files. However, this is a decision of the musl community and how you
> do the re-licensing is up to you, as long as you have the permission to
> re-license the files in question.
>

Ah, that makes a lot more sense.

For what it's worth, to my knowledge any of the files that could
potentially need relicensing are the sole work of Rich Felker. (before just
whole-sale doing that, though, I would recommend that we confirm that; my
general feel != legal certainty, and if an actual licensing change does
need to happen here, legal certainty is what we want)

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

Re: musl licensing

[Rich Felker]

On Wed, Mar 16, 2016 at 10:50:18PM +0000, Petr Hosek wrote:
> On Wed, Mar 16, 2016 at 9:32 AM Alexander Cherepanov <ch3root@openwall.com>
> wrote:
> 
> > Yeah, this is a crucial question IMHO. There was a similar discussion
> > about LLVM licensing recently:
> >
> > http://lists.llvm.org/pipermail/llvm-dev/2015-October/thread.html#91536
> >
> >  From this thread I gathered that:
> > 1) Google is quite serious about CLAs;
> > 2) Google has ideas about copyright/licensing/etc which contradict
> > beliefs held widely in the community;
> > 3) Google is not inclined to explain the situation to the community,
> > judging by
> >
> > http://lists.llvm.org/pipermail/llvm-dev/2015-October/091752.html
> >
> > Given its past legal troubles, Google has enough stimuli to study the
> > topic very carefully and it could be right. But could be wrong as well.
> > Anyway, I don't think that just saying that CLAs are required is going
> > to change the opinion of the community.
> 
> To clarify the CLA bit, we're not asking musl authors to sign the Google
> CLA. Instead, what we proposed was coming up with a CLA specifically for
> musl.

Yes, I think past discussions (either here or on IRC; I don't
remember) have already clarified that. But I still don't think it's an
interesting option; CLAs seriously deter contributions from new
contibutors, and I think there's an especially large overlap between
people who are interested in musl and contributing to it, and people
who are deterred by CLAs.

> Since someone, in this case most likely Rich as the project
> maintainer, has to re-license the files which are currently in public
> domain, one way is to have the past contributors sign a "musl project" CLA
> as a way to keep a track of the legal permission to use and distribute
> these files. However, this is a decision of the musl community and how you
> do the re-licensing is up to you, as long as you have the permission to
> re-license the files in question.

I still don't see what the problem is, unless your lawyers are under
the impression that there are "public domain" sources from third
parties. The COPYRIGHT file states:

"musl as a whole is licensed under the following standard MIT
license."

and:

"All other files which have no copyright comments are original works
produced specifically for use as part of this library, written either
by Rich Felker, the main author of the library, or by one or more
contibutors listed above. Details on authorship of individual files
can be found in the git version control history of the project. The
omission of copyright and license comments in each file is in the
interest of source tree size."

and finally:

"All public header files (include/* and arch/*/bits/*) should be
treated as Public Domain as they intentionally contain no content
which can be covered by copyright. Some source modules may fall in
this category as well. If you believe that a file is so trivial that
it should be in the Public Domain, please contact the authors and
request an explicit statement releasing it from copyright."

So as an aggregate/as part of musl, all of the "public domain" files
are _already_ licensed under musl's main license (by the very first
sentence) by people (their authors, i.e. primarily me) who would be
entitled to license them as such even if they were subject to
copyright.

What I would like to do, if it would satisfy your lawyers, is add a
paragraph at the end (right after the public domain release text):

"Should the release of these files into the Public Domain be judged
legally invalid or ineffective, permission is hereby granted to use
these files under the following terms:

Redistribution and use in source and binary forms, with or without
modification, are permitted."

Does this work? And are there other blocking issues with copyright
status/documentation?

Rich

Re: musl licensing

[Christopher Lane]

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

On Wed, Mar 16, 2016 at 4:46 PM, Rich Felker <dalias@libc.org> wrote:

> On Wed, Mar 16, 2016 at 10:50:18PM +0000, Petr Hosek wrote:
> > On Wed, Mar 16, 2016 at 9:32 AM Alexander Cherepanov <
> ch3root@openwall.com>
> > wrote:
> >
> > > Yeah, this is a crucial question IMHO. There was a similar discussion
> > > about LLVM licensing recently:
> > >
> > >
> http://lists.llvm.org/pipermail/llvm-dev/2015-October/thread.html#91536
> > >
> > >  From this thread I gathered that:
> > > 1) Google is quite serious about CLAs;
> > > 2) Google has ideas about copyright/licensing/etc which contradict
> > > beliefs held widely in the community;
> > > 3) Google is not inclined to explain the situation to the community,
> > > judging by
> > >
> > > http://lists.llvm.org/pipermail/llvm-dev/2015-October/091752.html
> > >
> > > Given its past legal troubles, Google has enough stimuli to study the
> > > topic very carefully and it could be right. But could be wrong as well.
> > > Anyway, I don't think that just saying that CLAs are required is going
> > > to change the opinion of the community.
> >
> > To clarify the CLA bit, we're not asking musl authors to sign the Google
> > CLA. Instead, what we proposed was coming up with a CLA specifically for
> > musl.
>
> Yes, I think past discussions (either here or on IRC; I don't
> remember) have already clarified that. But I still don't think it's an
> interesting option; CLAs seriously deter contributions from new
> contibutors, and I think there's an especially large overlap between
> people who are interested in musl and contributing to it, and people
> who are deterred by CLAs.
>
> > Since someone, in this case most likely Rich as the project
> > maintainer, has to re-license the files which are currently in public
> > domain, one way is to have the past contributors sign a "musl project"
> CLA
> > as a way to keep a track of the legal permission to use and distribute
> > these files. However, this is a decision of the musl community and how
> you
> > do the re-licensing is up to you, as long as you have the permission to
> > re-license the files in question.
>
> I still don't see what the problem is, unless your lawyers are under
> the impression that there are "public domain" sources from third
> parties. The COPYRIGHT file states:
>
> "musl as a whole is licensed under the following standard MIT
> license."
>
> and:
>
> "All other files which have no copyright comments are original works
> produced specifically for use as part of this library, written either
> by Rich Felker, the main author of the library, or by one or more
> contibutors listed above. Details on authorship of individual files
> can be found in the git version control history of the project. The
> omission of copyright and license comments in each file is in the
> interest of source tree size."
>
> and finally:
>
> "All public header files (include/* and arch/*/bits/*) should be
> treated as Public Domain as they intentionally contain no content
> which can be covered by copyright. Some source modules may fall in
> this category as well. If you believe that a file is so trivial that
> it should be in the Public Domain, please contact the authors and
> request an explicit statement releasing it from copyright."
>
> So as an aggregate/as part of musl, all of the "public domain" files
> are _already_ licensed under musl's main license (by the very first
> sentence) by people (their authors, i.e. primarily me) who would be
> entitled to license them as such even if they were subject to
> copyright.
>

That's a good question.  We'll find out why, if the claimed PD files aren't
actually PD, they don't then fall under the overall MIT license.


>
> What I would like to do, if it would satisfy your lawyers, is add a
> paragraph at the end (right after the public domain release text):
>
> "Should the release of these files into the Public Domain be judged
> legally invalid or ineffective, permission is hereby granted to use
> these files under the following terms:
>
> Redistribution and use in source and binary forms, with or without
> modification, are permitted."
>
> Does this work? And are there other blocking issues with copyright
> status/documentation?
>

We asked about conditional statements like this one and the answer we got
was (paraphrasing; any trampling on legal terms is accidental) "the extra
conditional language would then become the subject of argument."
 Essentially, it provides attack surface for future litigation.

In reply, they asked us: if releasing under e.g. BSD0 is OK when PD isn't
valid, why isn't it OK for all situations.  From previous replies, I gather
that the answer is because PD most closely matches the contributors'
ideological and ethical standpoints, and thus you'd like to include it in
the license text.  Please correct me if I'm wrong.

We're in the situation of trying to mediate a solution that lets us get
back to work and not have to give up on using musl.  I'm hoping we can find
that middle ground.  So I'll run the specific language you provided past
some people here and find out what they suggest for providing clear
licensing while still preserving the ideological viewpoint.


>
> Rich
>

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

Re: musl licensing

[Rich Felker]

On Wed, Mar 16, 2016 at 07:06:25PM -0700, Christopher Lane wrote:
> > I still don't see what the problem is, unless your lawyers are under
> > the impression that there are "public domain" sources from third
> > parties. The COPYRIGHT file states:
> >
> > "musl as a whole is licensed under the following standard MIT
> > license."
> >
> > and:
> >
> > "All other files which have no copyright comments are original works
> > produced specifically for use as part of this library, written either
> > by Rich Felker, the main author of the library, or by one or more
> > contibutors listed above. Details on authorship of individual files
> > can be found in the git version control history of the project. The
> > omission of copyright and license comments in each file is in the
> > interest of source tree size."
> >
> > and finally:
> >
> > "All public header files (include/* and arch/*/bits/*) should be
> > treated as Public Domain as they intentionally contain no content
> > which can be covered by copyright. Some source modules may fall in
> > this category as well. If you believe that a file is so trivial that
> > it should be in the Public Domain, please contact the authors and
> > request an explicit statement releasing it from copyright."
> >
> > So as an aggregate/as part of musl, all of the "public domain" files
> > are _already_ licensed under musl's main license (by the very first
> > sentence) by people (their authors, i.e. primarily me) who would be
> > entitled to license them as such even if they were subject to
> > copyright.
> >
> 
> That's a good question.  We'll find out why, if the claimed PD files aren't
> actually PD, they don't then fall under the overall MIT license.

Yes, that's my view. From a practical what-you-can-do standpoint the
only purpose of declaring them PD (or BSD0 or something else more
permissive than MIT) is to lift the requirement of acknowledgement. I
didn't want .o files compiled using the headers or dynamic-linked
programs which used the headers and linked with crt*.o having to
include acknowledgements for musl just because of this trivial usage
of files which are themselves trivial.

> > What I would like to do, if it would satisfy your lawyers, is add a
> > paragraph at the end (right after the public domain release text):
> >
> > "Should the release of these files into the Public Domain be judged
> > legally invalid or ineffective, permission is hereby granted to use
> > these files under the following terms:
> >
> > Redistribution and use in source and binary forms, with or without
> > modification, are permitted."
> >
> > Does this work? And are there other blocking issues with copyright
> > status/documentation?
> >
> 
> We asked about conditional statements like this one and the answer we got
> was (paraphrasing; any trampling on legal terms is accidental) "the extra
> conditional language would then become the subject of argument."
>  Essentially, it provides attack surface for future litigation.
> 
> In reply, they asked us: if releasing under e.g. BSD0 is OK when PD isn't
> valid, why isn't it OK for all situations.  From previous replies, I gather
> that the answer is because PD most closely matches the contributors'
> ideological and ethical standpoints, and thus you'd like to include it in
> the license text.  Please correct me if I'm wrong.
> 
> We're in the situation of trying to mediate a solution that lets us get
> back to work and not have to give up on using musl.  I'm hoping we can find
> that middle ground.  So I'll run the specific language you provided past
> some people here and find out what they suggest for providing clear
> licensing while still preserving the ideological viewpoint.

I certainly hope so too.

The main thing here is that I don't want to be in the business of
reneging on disclaiming copyright interest in these files, suddenly
turning around and saying that people who (re)use these files can only
do so because I gave them permission to do so.

Another option that might be possible, but I think it's more confusing
to ordinary (non-lawyer) humans, would be to have the COPYRIGHT file
define/list the "trivial source files" or such, provide an
unconditional BSD0 permission statement (without copyright statement)
for them, and also provide a statement that we both intend, and
believe based on their triviality, that they are not subject to
copyright and in the public domain.

Rich

Re: musl licensing

[u-uy74]

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?

Rune

Re: musl licensing

[Christopher Lane]

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

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.

>
> Rune
>

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

Re: musl licensing

[FRIGN]

On Thu, 17 Mar 2016 08:14:04 -0700
Christopher Lane <lanechr@gmail.com> wrote:

Hey Christopher,

> 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..

> 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 totally understand what you mean. Even for my open source works, I'm
very careful when it comes to public domain. I consider public domain
problematic because the legal definition is unclear.
Every developer here who supports his points with ideological arguments
is in my opinion stubborn and should get a reality check, and it's a
mistery for me why you literally want to make it difficult for Google and
other people to use your software by not just licensing your public
domain stuff as BSD-0 for reasons that are beyond insanity.

Only because you stamp "public domain" on something doesn't make it not
your intellectual property. That's the thing people, every work of art
has an owner, it's your responsibility to mark work you want to share
with everyone and don't want credit in a way it is legally sound.
Google cannot argue with ideology in front of courts, so can't you and
me neither in case some license hippie decided to revoke his public
domain license for some fucked up reason.

Now, if you just wrote down codetables and you think it's not
copyrightable and by that means you can just declare it to be public
domain, it won't work that way either.
In the end, only a court can decide that and up until this point you
still have to release this stuff just like anything else that is your
intellectual property.

And don't get me wrong, I'm probably one of the biggest enemies of
the term "intellectual property" in the open source context; for
companies it's another matter, however, we have to play by the
rules of the system and be clear about what we mean.
For lawyers, calling something "public domain" doesn't mean much
to them. So endure the pain, license it under BSD-0, so Google's
lawyers and future peoples' lawyers are happy and we actually get
shit done.

This entire discussion about public domain ideology has been going
on for too fucking long and is a waste of fucking time, and the
solutions have been laid out multiple times.

Cheers

FRIGN

-- 
FRIGN <dev@frign.de>

Re: musl licensing

[Hugues Bruant]

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

>
> And don't get me wrong, I'm probably one of the biggest enemies of
> the term "intellectual property" in the open source context; for
> companies it's another matter, however, we have to play by the
> rules of the system and be clear about what we mean.
> For lawyers, calling something "public domain" doesn't mean much
> to them. So endure the pain, license it under BSD-0, so Google's
> lawyers and future peoples' lawyers are happy and we actually get
> shit done.
>
Or go the SQLite way and charge a fee to get an explicit license for
companies that are not comfortable with Public Domain

http://sqlite.org/copyright.html

That's probably much stronger than the musl community would be comfortable
with and also too late as it would require all past contributors to
disclaim copyright, not just Rich but it's worth noting that public domain
ideology is not incompatible with corporate use.

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

Re: musl licensing

[Rich Felker]

On Thu, Mar 17, 2016 at 08:49:39AM -0700, Hugues Bruant wrote:
> >
> > And don't get me wrong, I'm probably one of the biggest enemies of
> > the term "intellectual property" in the open source context; for
> > companies it's another matter, however, we have to play by the
> > rules of the system and be clear about what we mean.
> > For lawyers, calling something "public domain" doesn't mean much
> > to them. So endure the pain, license it under BSD-0, so Google's
> > lawyers and future peoples' lawyers are happy and we actually get
> > shit done.
> >
> Or go the SQLite way and charge a fee to get an explicit license for
> companies that are not comfortable with Public Domain
> 
> http://sqlite.org/copyright.html

I've asked that we try to stay on-topic. The topic is not relicensing
or new licensing models (and certainly not unbalanced ones), only
fixing the issues that are making Google's lawyers go into paranoid
mode. :-)

> That's probably much stronger than the musl community would be comfortable
> with and also too late as it would require all past contributors to
> disclaim copyright, not just Rich but it's worth noting that public domain
> ideology is not incompatible with corporate use.

I don't think this is entirely accurate because there's plenty of
legacy PD code that made it into products with major corporate use. It
would take some research to produce a list but I'm quite confident
it's there. So the issue is not that "PD is incompatible with
corporate use" but (from what I can tell) that corporate lawyers are
weary (possibly rightfully so) of new attempts to put things in the
public domain without a clear license from the people who would be
copyright holders if the material is actually covered by copyright in
some or all jurisdictions.

I really don't want to be the "new DJB" who's holding out on actually
giving proper permissions statements/license as an act of protest
(against what?) and I'm hopeful that we can find a nice approach that
makes both parties happy.

Rich

Re: musl licensing

[Rich Felker]

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

Re: musl licensing

[Christopher Lane]

[-- 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 --]

Re: musl licensing

[Rich Felker]

On Thu, Mar 17, 2016 at 04:32:03PM -0700, Christopher Lane wrote:
> I've returned from the land of lawyers with answers.  Please pardon the
> length of this email.

Great! No problem, detail is good.

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

I disagree with your lawyers' interpretation here, but that doesn't
mean I'm not going to work on a solution they'll like anyway, so don't
worry. For the sake of our audience/community I'd like to explain. I'm
with them up to the point of:

> 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.

If the whole project is licensed under the MIT license, and by
convention files in certain directories also come with an additional
permission grant/release (essentially a dual license, especially if
you don't accept the PD statement as actually putting something in the
PD but just as a vague imprecise license), then "contributed under the
license the open source project itself is released under" at least
includes the license of the whole project, and possibly this "dual
license". It doesn't magically become something more restrictive than
the whole-project license. However since the whole "implicitly
contributed under the license" theory lacks strong legal formalities
to begin with, I understand how lawyers could be scared here. So...

> 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.

...here's what I propose to do:

I'll contact all significant contributors to crt files and public
headers (this will mostly be port contributors, for the arch/bits/*.h
files, but does Google even want/need these for their use or will they
be providing their own?) and:

1. Explain that, due to musl's statement in the COPYRIGHT file that we
   believe these files to be in the public domain, Google's lawyers
   are unclear whether they actually granted permissions for them.

2. Ask them to clarify that their intent actually was to contribute
   these files under musl's standard whole-project (MIT) license.

3. Ask for an additional exception to the requirements of the MIT
   license for these files, that attribution not be required.
   (Alternatively a BSD0 could be used, but I think the exception
   "sounds like" less of a change despite being equivalent and matches
   the existing intent just fine anyway.)

Some version of the PD text can remain in place but I can clarify that
it's my/our belief about these files and does not negate the fact that
we're licensing the whole project, including these files as part of
it, under the MIT license. Assuming we get a suitable response for #3
above, I can also add the text that the following contributors
(listed) all grant the attribution exception for these files. And for
future port contributors I can ask them to do the same at the time of
contribution.

Is this acceptable? If it sounds like it may be but there are
questions about the specific language I can prepare a proposed diff
for the COPYRIGHT file for review.

> 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.

That language was taken almost verbatim from CC0. :-P

> 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).

Yes, as mentioned above I'll have contributors of these files clarify
that they accept licensing under the more permissive terms at the time
of contribution. I don't think we need to make a CLA-like formality
out of it though; just a license statement alongside the patch
submission is fine.

> 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.

At that point musl had exactly one contributor other than myself who
hadn't already explicitly MIT'd their contributions, so there was
essentially nothing to do. :-)

Rich

Re: musl licensing

[Christopher Lane]

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

On Mar 17, 2016 9:21 PM, "Rich Felker" <dalias@libc.org> wrote:
>
> On Thu, Mar 17, 2016 at 04:32:03PM -0700, Christopher Lane wrote:
> > I've returned from the land of lawyers with answers.  Please pardon the
> > length of this email.
>
> Great! No problem, detail is good.
>
> > 1. Why doesn't the MIT license apply in the case where PD one doesn't?
>
> I disagree with your lawyers' interpretation here, but that doesn't
> mean I'm not going to work on a solution they'll like anyway, so don't
> worry. For the sake of our audience/community I'd like to explain. I'm
> with them up to the point of:
>
> > 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.
>
> If the whole project is licensed under the MIT license, and by
> convention files in certain directories also come with an additional
> permission grant/release (essentially a dual license, especially if
> you don't accept the PD statement as actually putting something in the
> PD but just as a vague imprecise license), then "contributed under the
> license the open source project itself is released under" at least
> includes the license of the whole project, and possibly this "dual
> license". It doesn't magically become something more restrictive than
> the whole-project license. However since the whole "implicitly
> contributed under the license" theory lacks strong legal formalities
> to begin with, I understand how lawyers could be scared here. So...
>
> > 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.
>
> ...here's what I propose to do:
>
> I'll contact all significant contributors to crt files and public
> headers (this will mostly be port contributors, for the arch/bits/*.h
> files, but does Google even want/need these for their use or will they
> be providing their own?) and:

There are some architectures we don't need, so we can prune the list a bit
for sure.  Tomorrow we can send you a list of all the files we care about
that are claimed to be PD.

>
> 1. Explain that, due to musl's statement in the COPYRIGHT file that we
>    believe these files to be in the public domain, Google's lawyers
>    are unclear whether they actually granted permissions for them.
>
> 2. Ask them to clarify that their intent actually was to contribute
>    these files under musl's standard whole-project (MIT) license.
>
> 3. Ask for an additional exception to the requirements of the MIT
>    license for these files, that attribution not be required.
>    (Alternatively a BSD0 could be used, but I think the exception
>    "sounds like" less of a change despite being equivalent and matches
>    the existing intent just fine anyway.)
>
> Some version of the PD text can remain in place but I can clarify that
> it's my/our belief about these files and does not negate the fact that
> we're licensing the whole project, including these files as part of
> it, under the MIT license. Assuming we get a suitable response for #3
> above, I can also add the text that the following contributors
> (listed) all grant the attribution exception for these files. And for
> future port contributors I can ask them to do the same at the time of
> contribution.
>
> Is this acceptable? If it sounds like it may be but there are
> questions about the specific language I can prepare a proposed diff
> for the COPYRIGHT file for review.
>

I THINK this is acceptable. I've read it through 4 or 5 times and it makes
sense to me and seems to cover everyone's needs.  I'll verify for sure
though.

> > 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.
>
> That language was taken almost verbatim from CC0. :-P

Hah, yes.  One of the lawyers did make an off-hand comment of "CC0 has the
same problem, it's one of the issues with that..."

>
> > 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).
>
> Yes, as mentioned above I'll have contributors of these files clarify
> that they accept licensing under the more permissive terms at the time
> of contribution. I don't think we need to make a CLA-like formality
> out of it though; just a license statement alongside the patch
> submission is fine.

SGTM.  I know our lawyers would suggest some kind of electronic signature
(and have), but I've been trying to suss out the minimum requirements from
the recommendations.  IDK if they're particularly passionate about some
kind of additional formality, but that's a 1:1 thing for just a handful of
people, so I think we can probably handle the implementation details off
list.

>
> > 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.
>
> At that point musl had exactly one contributor other than myself who
> hadn't already explicitly MIT'd their contributions, so there was
> essentially nothing to do. :-)
>
> Rich

Overall I'm pleased with your proposal.  I'm optimistic that'll work, but I
should be able to find out for sure tomorrow.

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

Re: musl licensing

[Rich Felker]

On Thu, Mar 17, 2016 at 09:47:09PM -0700, Christopher Lane wrote:
> > I'll contact all significant contributors to crt files and public
> > headers (this will mostly be port contributors, for the arch/bits/*.h
> > files, but does Google even want/need these for their use or will they
> > be providing their own?) and:
> 
> There are some architectures we don't need, so we can prune the list a bit
> for sure.  Tomorrow we can send you a list of all the files we care about
> that are claimed to be PD.

I'll try to take care of them all anyway for the sake of future users
who might have your same problem. The reason I wondered if you need
any of these, though, is that the bits files are basically all for the
sake of interfacing with Linux syscalls. They're wanted/needed for a
libc that runs directly on Linux but I don't know if you'd want to use
them at all for something like NaCl or if it has its own mediation
layer with its own ABI (in which case you'd provide your own versions
to match that ABI).

> Overall I'm pleased with your proposal.  I'm optimistic that'll work, but I
> should be able to find out for sure tomorrow.

Great.

Rich

Re: musl licensing

[Christopher Lane]

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

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

> On Thu, Mar 17, 2016 at 04:32:03PM -0700, Christopher Lane wrote:
> > I've returned from the land of lawyers with answers.  Please pardon the
> > length of this email.
>
> Great! No problem, detail is good.
>
> > 1. Why doesn't the MIT license apply in the case where PD one doesn't?
>
> I disagree with your lawyers' interpretation here, but that doesn't
> mean I'm not going to work on a solution they'll like anyway, so don't
> worry. For the sake of our audience/community I'd like to explain. I'm
> with them up to the point of:
>
> > 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.
>
> If the whole project is licensed under the MIT license, and by
> convention files in certain directories also come with an additional
> permission grant/release (essentially a dual license, especially if
> you don't accept the PD statement as actually putting something in the
> PD but just as a vague imprecise license), then "contributed under the
> license the open source project itself is released under" at least
> includes the license of the whole project, and possibly this "dual
> license". It doesn't magically become something more restrictive than
> the whole-project license. However since the whole "implicitly
> contributed under the license" theory lacks strong legal formalities
> to begin with, I understand how lawyers could be scared here. So...
>
> > 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.
>
> ...here's what I propose to do:
>
> I'll contact all significant contributors to crt files and public
> headers (this will mostly be port contributors, for the arch/bits/*.h
> files, but does Google even want/need these for their use or will they
> be providing their own?) and:
>
> 1. Explain that, due to musl's statement in the COPYRIGHT file that we
>    believe these files to be in the public domain, Google's lawyers
>    are unclear whether they actually granted permissions for them.
>
> 2. Ask them to clarify that their intent actually was to contribute
>    these files under musl's standard whole-project (MIT) license.
>
> 3. Ask for an additional exception to the requirements of the MIT
>    license for these files, that attribution not be required.
>    (Alternatively a BSD0 could be used, but I think the exception
>    "sounds like" less of a change despite being equivalent and matches
>    the existing intent just fine anyway.)
>
> Some version of the PD text can remain in place but I can clarify that
> it's my/our belief about these files and does not negate the fact that
> we're licensing the whole project, including these files as part of
> it, under the MIT license. Assuming we get a suitable response for #3
> above, I can also add the text that the following contributors
> (listed) all grant the attribution exception for these files. And for
> future port contributors I can ask them to do the same at the time of
> contribution.
>
> Is this acceptable? If it sounds like it may be but there are
> questions about the specific language I can prepare a proposed diff
> for the COPYRIGHT file for review.
>

So yeah, this is a good idea.  Please send the diff and I'll get their
comments on the specific language.


>
> > 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.
>
> That language was taken almost verbatim from CC0. :-P
>
> > 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).
>
> Yes, as mentioned above I'll have contributors of these files clarify
> that they accept licensing under the more permissive terms at the time
> of contribution. I don't think we need to make a CLA-like formality
> out of it though; just a license statement alongside the patch
> submission is fine.
>
> > 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.
>
> At that point musl had exactly one contributor other than myself who
> hadn't already explicitly MIT'd their contributions, so there was
> essentially nothing to do. :-)
>
> Rich
>



-- 
kthxbai
:wq

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

Re: musl licensing

[Rich Felker]

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

On Fri, Mar 18, 2016 at 11:16:49AM -0700, Christopher Lane wrote:
> > Some version of the PD text can remain in place but I can clarify that
> > it's my/our belief about these files and does not negate the fact that
> > we're licensing the whole project, including these files as part of
> > it, under the MIT license. Assuming we get a suitable response for #3
> > above, I can also add the text that the following contributors
> > (listed) all grant the attribution exception for these files. And for
> > future port contributors I can ask them to do the same at the time of
> > contribution.
> >
> > Is this acceptable? If it sounds like it may be but there are
> > questions about the specific language I can prepare a proposed diff
> > for the COPYRIGHT file for review.
> >
> 
> So yeah, this is a good idea.  Please send the diff and I'll get their
> comments on the specific language.

Please let me know what you (or your lawyers) think of the attached
diff. As an extra bonus I made an effort to avoid the actual words
"Public Domain" since they apparently scare people off. Does this
work? Does anyone from the community (esp. any of the contributors I'd
be asking to agree) have objections to it?

Rich

[-- Attachment #2: COPYRIGHT.diff --]
[-- Type: text/plain, Size: 1975 bytes --]

diff --git a/COPYRIGHT b/COPYRIGHT
index 1b20b23..a60c174 100644
--- a/COPYRIGHT
+++ b/COPYRIGHT
@@ -140,15 +140,24 @@ can be found in the git version control history of the project. The
 omission of copyright and license comments in each file is in the
 interest of source tree size.
 
-All public header files (include/* and arch/*/bits/*) should be
-treated as Public Domain as they intentionally contain no content
-which can be covered by copyright. Some source modules may fall in
-this category as well. If you believe that a file is so trivial that
-it should be in the Public Domain, please contact the authors and
-request an explicit statement releasing it from copyright.
-
-The following files are trivial, believed not to be copyrightable in
-the first place, and hereby explicitly released to the Public Domain:
-
-All public headers: include/*, arch/*/bits/*
-Startup files: crt/*
+In addition, permission is hereby granted for all public header files
+(include/* and arch/*/bits/*) and crt files intended to be linked into
+applications (crt/*, ldso/dlstart.c, and arch/*/crt_arch.h) to omit
+the copyright notice and permission notice otherwise required by the
+license, and to use these files without any requirement of
+attribution. These files include substantial contributions from:
+
+[list here]
+
+all of whom have explicitly granted such permission. It is our belief
+and intent that these files do not contain substantial creative
+content, except in dlstart.c, and that, standing on their own, they
+would not be subject to copyright anyway. This belief/intent, however,
+should in no way be interpreted as negating the above grants of
+permission.
+
+Some trivial source modules may fall in this category as well. If you
+believe that a file is so trivial that it should not be subject to
+copyright claims, please contact the authors and request an explicit
+statement that the authors agree and grant permission to use it
+without attribution.

Re: musl licensing

[George Kulakowski]

[-- Attachment #1.1: Type: text/plain, Size: 1486 bytes --]

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.

On Fri, Mar 18, 2016 at 12:12 PM Rich Felker <dalias@libc.org> wrote:

> On Fri, Mar 18, 2016 at 11:16:49AM -0700, Christopher Lane wrote:
> > > Some version of the PD text can remain in place but I can clarify that
> > > it's my/our belief about these files and does not negate the fact that
> > > we're licensing the whole project, including these files as part of
> > > it, under the MIT license. Assuming we get a suitable response for #3
> > > above, I can also add the text that the following contributors
> > > (listed) all grant the attribution exception for these files. And for
> > > future port contributors I can ask them to do the same at the time of
> > > contribution.
> > >
> > > Is this acceptable? If it sounds like it may be but there are
> > > questions about the specific language I can prepare a proposed diff
> > > for the COPYRIGHT file for review.
> > >
> >
> > So yeah, this is a good idea.  Please send the diff and I'll get their
> > comments on the specific language.
>
> Please let me know what you (or your lawyers) think of the attached
> diff. As an extra bonus I made an effort to avoid the actual words
> "Public Domain" since they apparently scare people off. Does this
> work? Does anyone from the community (esp. any of the contributors I'd
> be asking to agree) have objections to it?
>
> Rich
>

[-- Attachment #1.2: Type: text/html, Size: 1920 bytes --]

[-- Attachment #2: patch --]
[-- Type: application/octet-stream, Size: 1089 bytes --]

diff --git a/COPYRIGHT b/COPYRIGHT
index f7f1a1f..3865085 100644
--- a/COPYRIGHT
+++ b/COPYRIGHT
@@ -92,14 +92,14 @@ Copyright © 2008 Stephen L. Moshier
 and labelled as such in comments in the individual source files. All
 have been licensed under extremely permissive terms.
 
-The ARM memcpy code (src/string/armel/memcpy.s) is Copyright © 2008
+The ARM memcpy code (src/string/arm/memcpy_el.S) is Copyright © 2008
 The Android Open Source Project and is licensed under a two-clause BSD
 license. It was taken from Bionic libc, used on Android.
 
-The implementation of DES for crypt (src/misc/crypt_des.c) is
+The implementation of DES for crypt (src/crypt/crypt_des.c) is
 Copyright © 1994 David Burren. It is licensed under a BSD license.
 
-The implementation of blowfish crypt (src/misc/crypt_blowfish.c) was
+The implementation of blowfish crypt (src/crypt/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.

Re: musl licensing

[Rich Felker]

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

Re: musl licensing

[Christopher Lane]

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

On Fri, Mar 18, 2016 at 9:35 PM, Rich Felker <dalias@libc.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...

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

Re: musl licensing

[Rich Felker]

On Mon, Mar 21, 2016 at 03:46:18PM -0700, Christopher Lane wrote:
> On Fri, Mar 18, 2016 at 9:35 PM, Rich Felker <dalias@libc.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.

Did they miss the part about the fallback permissive license? I'm
pretty sure Solar's implementation of bcrypt (albeit the original, not
the one he modified for musl) is used in plenty of other places with
no problem. Complaining about copyright status on this is like
complaining about fdlibm. If it's really a problem I suspect he would
be willing to clarify its status for you.

> The x86_64 crt files can be cleanroom'ed here (and we'd release
> those BSD0 when we're done).

I don't understand why they're making a meal of this again. This is
covered under the code I already said I would contact the contributors
for clarification on, which I'm happy to do once I get feedback that
the changes will meet your needs. Is the problem just that I forgot to
remove this text and replace it with a statement that the port was
contributed by Nicholas J. Kain under the project's license terms? I
can certainly do that assuming I get the clarification we discussed.

In any case the only original crt files left from this contribution
are crti/crtn which are literally _single instruction_ functions. The
idea that they could be subject to copyright (even if some of the
other things we claimed were PD were more iffy) is utterly absurd.
(All crt1.s were removed a while back and replaced by the unified C
version; the new crt_arch.h files they used are mostly original works
by me.)

> 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."

This really seems like the most natural place for this content so that
interested readers have access to it. I'm really trying to work with
you guys here, and it's frustrating when your lawyers come back with
complaints about statements of opinion/belief that are clearly
disjoint from license terms and that explicity state that they are not
to be interpreted as affecting the license. Other well-known licenses
(especially the GPL and LGPL) contain statements of belief and similar
that are not legally binding, even statements of legal theories like
"You are not required to accept this License..."

If this is still bothering them, would it make them happy to put some
"end of legal text" marking above that paragraph?

Rich

Re: musl licensing

[Christopher Lane]

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

On Tue, Mar 22, 2016 at 7:32 PM, Rich Felker <dalias@libc.org> wrote:

> On Mon, Mar 21, 2016 at 03:46:18PM -0700, Christopher Lane wrote:
> > On Fri, Mar 18, 2016 at 9:35 PM, Rich Felker <dalias@libc.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.
>
> Did they miss the part about the fallback permissive license? I'm
> pretty sure Solar's implementation of bcrypt (albeit the original, not
> the one he modified for musl) is used in plenty of other places with
> no problem. Complaining about copyright status on this is like
> complaining about fdlibm. If it's really a problem I suspect he would
> be willing to clarify its status for you.
>

I forwarded the comments without delving into this like I should have.  I
doubt our lawyers _like_ the copyright status of Solar's implementation of
bcrypt, but it's not a problem to be solved here.  And like you said, it's
used in many other places already -- so many, in fact, the status is
probably impossible to clear up at this point.  It's also a single file, so
let's not dwell on this any further.

Aside: the path has apparently changed at some point from src/misc to
src/crypt.


>
> > The x86_64 crt files can be cleanroom'ed here (and we'd release
> > those BSD0 when we're done).
>
> I don't understand why they're making a meal of this again. This is
> covered under the code I already said I would contact the contributors
> for clarification on, which I'm happy to do once I get feedback that
> the changes will meet your needs. Is the problem just that I forgot to
> remove this text and replace it with a statement that the port was
> contributed by Nicholas J. Kain under the project's license terms?


Ah, I see the misunderstanding.  It was just an oversight.  OK, no worries.


> I
> can certainly do that assuming I get the clarification we discussed.
>
> In any case the only original crt files left from this contribution
> are crti/crtn which are literally _single instruction_ functions. The
> idea that they could be subject to copyright (even if some of the
> other things we claimed were PD were more iffy) is utterly absurd.
> (All crt1.s were removed a while back and replaced by the unified C
> version; the new crt_arch.h files they used are mostly original works
> by me.)
>

Now that you've mentioned this, I'm actually looking through git blame
trying to find a file that might fall under this paragraph and I can't.
 crt/x86_64/* appears to be wholly contributed by you.
 arch/x86_64/crt_arch.h, like you said, was as well.  At this point, I
don't know what files the phrase "Several files (crt) were released into
the public domain;" would even refer to.  Though I suppose it doesn't
matter since you're replacing the claim anyway.


>
> > 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."
>
> This really seems like the most natural place for this content so that
> interested readers have access to it. I'm really trying to work with
> you guys here, and it's frustrating when your lawyers come back with
> complaints about statements of opinion/belief that are clearly
> disjoint from license terms and that explicity state that they are not
> to be interpreted as affecting the license. Other well-known licenses
> (especially the GPL and LGPL) contain statements of belief and similar
> that are not legally binding, even statements of legal theories like
> "You are not required to accept this License..."
>
> If this is still bothering them, would it make them happy to put some
> "end of legal text" marking above that paragraph?
>

I sent them a query this morning; still waiting on a reply.  I think this
is the only issue left.


>
> Rich

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

Re: musl licensing

[Rob Landley]

On Wed, Mar 23, 2016 at 3:35 PM, Christopher Lane <lanechr@gmail.com> wrote:
> On Tue, Mar 22, 2016 at 7:32 PM, Rich Felker <dalias@libc.org> wrote:
>>
>> On Mon, Mar 21, 2016 at 03:46:18PM -0700, Christopher Lane wrote:
>> > On Fri, Mar 18, 2016 at 9:35 PM, Rich Felker <dalias@libc.org> wrote:
>> >
>> > > On Fri, Mar 18, 2016 at 07:47:21PM +0000, George Kulakowski wrote:
>> > 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.
>>
>> Did they miss the part about the fallback permissive license? I'm
>> pretty sure Solar's implementation of bcrypt (albeit the original, not
>> the one he modified for musl) is used in plenty of other places with
>> no problem. Complaining about copyright status on this is like
>> complaining about fdlibm. If it's really a problem I suspect he would
>> be willing to clarify its status for you.

Upton Sinclair explained why lawyers aren't comfortable with the
public domain a century ago:
http://www.goodreads.com/quotes/21810-it-is-difficult-to-get-a-man-to-understand-something

As far as I can tell, to most lawyers a good license is one you can
sue to enforce, I.E. one which provides potential future litigation
employment opportunities for lawyers. This isn't necessarily a
conscious decision, but it's definitely part of the legal profession's
herd mentality.

So what I did was take a "safe" license and make a small specific
change to it, which is easy to analyze and hard to object to by
itself, so the result still looks "safe". Thus my license is a "good
license", even if the result is functionally equivalent to placing
code in the public domain.

I.E. Zero Clause BSD (the Toybox license, which SPDX approved as
"0BSD" ala https://spdx.org/licenses/0BSD.html) took a prominent
variant of a widely approved existing license (the "OpenBSD suggested
template license, the text of which is in the first link from
http://www.openbsd.org/policy.html) under which you _can_ sue people
(in fact AT&T lost a very prominent lawsuit about it in 1993,
https://www.bell-labs.com/usr/dmr/www/bsdi/bsdisuit.html) and made a
single small edit that just removed half a sentence:
https://github.com/landley/toybox/commit/ee86b1d8e25c

The result was a license which grants blanket permission while
requiring nothing in return, using existing and established legal
boilerplate. It had to be an acceptable license if BSD was an
acceptable license, unless you could coherently explain why the
deleted half-sentence caused a problem _other_ than no longer
providing future employment for lawyers.

I replaced the "everybody dislikes this because everybody else
dislikes this" phrase "public domain" with the "everybody likes this
because everybody else likes this" phrase "BSD license". Instead of
fighting the herd mentality, I tried to leverage it.

So far, nobody's wanted to step into the spotlight and say
"eliminating this source of future litigation threatens my job
security", and I don't think most people consciously think that
anyway. (Besides, there's always patent trolls...)

Rob

Re: musl licensing

[Christopher Lane]

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

On Wed, Mar 23, 2016 at 3:53 PM, Rob Landley <rob@landley.net> wrote:

> On Wed, Mar 23, 2016 at 3:35 PM, Christopher Lane <lanechr@gmail.com>
> wrote:
> > On Tue, Mar 22, 2016 at 7:32 PM, Rich Felker <dalias@libc.org> wrote:
> >>
> >> On Mon, Mar 21, 2016 at 03:46:18PM -0700, Christopher Lane wrote:
> >> > On Fri, Mar 18, 2016 at 9:35 PM, Rich Felker <dalias@libc.org> wrote:
> >> >
> >> > > On Fri, Mar 18, 2016 at 07:47:21PM +0000, George Kulakowski wrote:
> >> > 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.
> >>
> >> Did they miss the part about the fallback permissive license? I'm
> >> pretty sure Solar's implementation of bcrypt (albeit the original, not
> >> the one he modified for musl) is used in plenty of other places with
> >> no problem. Complaining about copyright status on this is like
> >> complaining about fdlibm. If it's really a problem I suspect he would
> >> be willing to clarify its status for you.
>
> Upton Sinclair explained why lawyers aren't comfortable with the
> public domain a century ago:
>
> http://www.goodreads.com/quotes/21810-it-is-difficult-to-get-a-man-to-understand-something
>
> As far as I can tell, to most lawyers a good license is one you can
> sue to enforce, I.E. one which provides potential future litigation
> employment opportunities for lawyers. This isn't necessarily a
> conscious decision, but it's definitely part of the legal profession's
> herd mentality.
>

From the license creation standpoint, AFAICT you're right.  Google's on the
receiving end of the musl license, so it seems a "good license" for us is
one that provides clarity on what we can do with the code.  So, the
inverse, basically -- one that we _can't_ be sued over.  A license that
introduces ambiguity through conditionals that may be argued over is not
one we can work with.


>
> So what I did was take a "safe" license and make a small specific
> change to it, which is easy to analyze and hard to object to by
> itself, so the result still looks "safe". Thus my license is a "good
> license", even if the result is functionally equivalent to placing
> code in the public domain.
>
> I.E. Zero Clause BSD (the Toybox license, which SPDX approved as
> "0BSD" ala https://spdx.org/licenses/0BSD.html) took a prominent
> variant of a widely approved existing license (the "OpenBSD suggested
> template license, the text of which is in the first link from
> http://www.openbsd.org/policy.html) under which you _can_ sue people
> (in fact AT&T lost a very prominent lawsuit about it in 1993,
> https://www.bell-labs.com/usr/dmr/www/bsdi/bsdisuit.html) and made a
> single small edit that just removed half a sentence:
> https://github.com/landley/toybox/commit/ee86b1d8e25c
>
> The result was a license which grants blanket permission while
> requiring nothing in return, using existing and established legal
> boilerplate. It had to be an acceptable license if BSD was an
> acceptable license, unless you could coherently explain why the
> deleted half-sentence caused a problem _other_ than no longer
> providing future employment for lawyers.
>
> I replaced the "everybody dislikes this because everybody else
> dislikes this" phrase "public domain" with the "everybody likes this
> because everybody else likes this" phrase "BSD license". Instead of
> fighting the herd mentality, I tried to leverage it.
>

0BSD is awesome, so thanks for your contribution.  It enables projects to
release under something that's effectively public domain w/o scaring off
the lawyers of big litigation target companies.


>
> So far, nobody's wanted to step into the spotlight and say
> "eliminating this source of future litigation threatens my job
> security", and I don't think most people consciously think that
> anyway. (Besides, there's always patent trolls...)
>
> Rob
>

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

Re: musl licensing

[Christopher Lane]

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

On Wed, Mar 23, 2016 at 1:35 PM, Christopher Lane <lanechr@gmail.com> wrote:

> On Tue, Mar 22, 2016 at 7:32 PM, Rich Felker <dalias@libc.org> wrote:
>
>> On Mon, Mar 21, 2016 at 03:46:18PM -0700, Christopher Lane wrote:
>> > On Fri, Mar 18, 2016 at 9:35 PM, Rich Felker <dalias@libc.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.
>>
>> Did they miss the part about the fallback permissive license? I'm
>> pretty sure Solar's implementation of bcrypt (albeit the original, not
>> the one he modified for musl) is used in plenty of other places with
>> no problem. Complaining about copyright status on this is like
>> complaining about fdlibm. If it's really a problem I suspect he would
>> be willing to clarify its status for you.
>>
>
> I forwarded the comments without delving into this like I should have.  I
> doubt our lawyers _like_ the copyright status of Solar's implementation of
> bcrypt, but it's not a problem to be solved here.  And like you said, it's
> used in many other places already -- so many, in fact, the status is
> probably impossible to clear up at this point.  It's also a single file, so
> let's not dwell on this any further.
>
> Aside: the path has apparently changed at some point from src/misc to
> src/crypt.
>
>
>>
>> > The x86_64 crt files can be cleanroom'ed here (and we'd release
>> > those BSD0 when we're done).
>>
>> I don't understand why they're making a meal of this again. This is
>> covered under the code I already said I would contact the contributors
>> for clarification on, which I'm happy to do once I get feedback that
>> the changes will meet your needs. Is the problem just that I forgot to
>> remove this text and replace it with a statement that the port was
>> contributed by Nicholas J. Kain under the project's license terms?
>
>
> Ah, I see the misunderstanding.  It was just an oversight.  OK, no worries.
>
>
>> I
>> can certainly do that assuming I get the clarification we discussed.
>>
>> In any case the only original crt files left from this contribution
>> are crti/crtn which are literally _single instruction_ functions. The
>> idea that they could be subject to copyright (even if some of the
>> other things we claimed were PD were more iffy) is utterly absurd.
>> (All crt1.s were removed a while back and replaced by the unified C
>> version; the new crt_arch.h files they used are mostly original works
>> by me.)
>>
>
> Now that you've mentioned this, I'm actually looking through git blame
> trying to find a file that might fall under this paragraph and I can't.
>  crt/x86_64/* appears to be wholly contributed by you.
>  arch/x86_64/crt_arch.h, like you said, was as well.  At this point, I
> don't know what files the phrase "Several files (crt) were released into
> the public domain;" would even refer to.  Though I suppose it doesn't
> matter since you're replacing the claim anyway.
>
>
>>
>> > 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."
>>
>> This really seems like the most natural place for this content so that
>> interested readers have access to it. I'm really trying to work with
>> you guys here, and it's frustrating when your lawyers come back with
>> complaints about statements of opinion/belief that are clearly
>> disjoint from license terms and that explicity state that they are not
>> to be interpreted as affecting the license. Other well-known licenses
>> (especially the GPL and LGPL) contain statements of belief and similar
>> that are not legally binding, even statements of legal theories like
>> "You are not required to accept this License..."
>>
>> If this is still bothering them, would it make them happy to put some
>> "end of legal text" marking above that paragraph?
>
>
Short answer: not really, no.

Long answer: every time I mention this to them, I get the same answer.  If
the license file includes any ambiguity by including things like
speculation on the copyrightability of the work, it's safer for us to just
avoid it.  The potential penalties for copyright infringement are
astronomical.

I understand (and agree) that the COPYRIGHT file is the most natural place
to put comments on whether content should be copyrighted, but these are not
merely inert comments.  Like code, a license file needs to be correct
before it can be convenient.  Introducing text like "It is our belief and
intent that these files ... would not be subject to copyright" is
equivalent to introducing undefined behavior because we just don't know how
a court might interpret it.  You wouldn't be satisfied with that ambiguity
in your code; I'm asking you to treat your license the same way.

Listen, if we're asking you for too much, I get it.  This is not our
project.  We didn't pour years into it, you did, and you have to do what
you think is right.  If it's beyond your personal ethics to claim copyright
over the trivial files and public headers you wrote, then that's the way it
is.  I'll be sad, but we'll deal with it.

Or, if you want, I can set up a chat with one of our lawyers for you.  I've
been so far unable to convince them to bend on this, but maybe you'll have
better luck.  You're certainly welcome to try, anyway.

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

Re: musl licensing

[Rich Felker]

On Tue, Mar 29, 2016 at 10:21:25AM -0700, Christopher Lane wrote:
> >> If this is still bothering them, would it make them happy to put some
> >> "end of legal text" marking above that paragraph?
> >
> >
> Short answer: not really, no.
> 
> Long answer: every time I mention this to them, I get the same answer.  If
> the license file includes any ambiguity by including things like
> speculation on the copyrightability of the work, it's safer for us to just
> avoid it.  The potential penalties for copyright infringement are
> astronomical.
> 
> I understand (and agree) that the COPYRIGHT file is the most natural place
> to put comments on whether content should be copyrighted, but these are not
> merely inert comments.  Like code, a license file needs to be correct
> before it can be convenient.  Introducing text like "It is our belief and
> intent that these files ... would not be subject to copyright" is
> equivalent to introducing undefined behavior because we just don't know how
> a court might interpret it.  You wouldn't be satisfied with that ambiguity
> in your code; I'm asking you to treat your license the same way.
> 
> Listen, if we're asking you for too much, I get it.  This is not our
> project.  We didn't pour years into it, you did, and you have to do what
> you think is right.  If it's beyond your personal ethics to claim copyright
> over the trivial files and public headers you wrote, then that's the way it
> is.  I'll be sad, but we'll deal with it.
> 
> Or, if you want, I can set up a chat with one of our lawyers for you.  I've
> been so far unable to convince them to bend on this, but maybe you'll have
> better luck.  You're certainly welcome to try, anyway.

I would like that. I really want to make this work, but I do not want
to be taking arbitrary demands to scrub expression of opinion.

Some specific questions for them, which we could discuss directly or
which you could convey to them first if you like:

1. If the problem is file boundaries ("if the license file
contains..."), would this be any different if there were no "license
file", only one big README, and both texts (statement of opinion, and
copyright/license statements) were in the same file but separated by
section headers? I'm not really proposing doing that (although it's
one potential silly solution) but rather trying to draw out the
absurdity (as I see it) of deeming text that specificially says it's
NOT license text as if it were just because it's in the same file.

2. Taking that in the other direction, what good does it do burying a
record of our beliefs about the matter? It's not like we can erase
past statements. Taking the text out of the COPYRIGHT file increases
its distance in space and time from the license text, but it doesn't
change the fact that they were published together in the past. If
anything I think it's a disservice to parties who are (IMO wrongly)
concerned about the implications of such beliefs not to disclose them.
Having clarified text in the same place puts emphasis on the intent
that they not conflict and that we actually put effort into clarifying
where there was a perceived conflict.

3. I understand lawyers want to minimize risk. I don't understand how
a statement of opinion that, if it were deemed relevant and deemed
true by a court, would imply that we (actually nobody) has standing to
sue creates any risk. To use the UB analogy, when someone reports a
claim of UB, we actually want to see a code path that leads to UB
happening (without UB already having occurred by violating an
interface requirement), not just a claim like "if variables X and Y
have values A and B, UB results". Of course if there's a proposed
change that's simpler and doesn't require tracking down if UB actually
occurs, we'd just consider that outright, but when the current code
has advantages, there should be a real motivation to change it. If
we're going to treat the matter here as a "bug report" against the
COPYRIGHT file, I want to have an understanding of the alleged bug.

4. I'd also like to understand what the claim-copyright vs
not-claim-copyright distinction they're making is. As an analogy,
suppose I've written a math textbook containing "1+1=2" in it. The
statement "1+1=2" is most certainly not subject to copyright, and my
saying that (within the text or outside it) does not draw into
question the copyright status of the textbook. I really don't see any
difference between this example and what we're saying here with
regards to these files. We are claiming copyright (and asserting a
right to do so) for the work as a whole. The statement of opinion is
on the matter of these files taken by themselves. If the problem is
just that this isn't clear, maybe there's a trivial way to clarify
that and make everybody happy.

I know this has been a tedious process of back-and-forth and is using
lots more time (on both of our sides) than we'd probably like. But I
do want to see something good come out of it. Let's arrange a chat
with the lawyers (this probably can/should be done off-list) and see
what comes out of it.

Rich

Re: musl licensing

[Christopher Lane]

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

On Tue, Mar 29, 2016 at 1:03 PM, Rich Felker <dalias@libc.org> wrote:

> On Tue, Mar 29, 2016 at 10:21:25AM -0700, Christopher Lane wrote:
> > >> If this is still bothering them, would it make them happy to put some
> > >> "end of legal text" marking above that paragraph?
> > >
> > >
> > Short answer: not really, no.
> >
> > Long answer: every time I mention this to them, I get the same answer.
> If
> > the license file includes any ambiguity by including things like
> > speculation on the copyrightability of the work, it's safer for us to
> just
> > avoid it.  The potential penalties for copyright infringement are
> > astronomical.
> >
> > I understand (and agree) that the COPYRIGHT file is the most natural
> place
> > to put comments on whether content should be copyrighted, but these are
> not
> > merely inert comments.  Like code, a license file needs to be correct
> > before it can be convenient.  Introducing text like "It is our belief and
> > intent that these files ... would not be subject to copyright" is
> > equivalent to introducing undefined behavior because we just don't know
> how
> > a court might interpret it.  You wouldn't be satisfied with that
> ambiguity
> > in your code; I'm asking you to treat your license the same way.
> >
> > Listen, if we're asking you for too much, I get it.  This is not our
> > project.  We didn't pour years into it, you did, and you have to do what
> > you think is right.  If it's beyond your personal ethics to claim
> copyright
> > over the trivial files and public headers you wrote, then that's the way
> it
> > is.  I'll be sad, but we'll deal with it.
> >
> > Or, if you want, I can set up a chat with one of our lawyers for you.
> I've
> > been so far unable to convince them to bend on this, but maybe you'll
> have
> > better luck.  You're certainly welcome to try, anyway.
>
> I would like that. I really want to make this work, but I do not want
> to be taking arbitrary demands to scrub expression of opinion.
>

Awesome.  I emailed you separately to determine logistics.


>
> Some specific questions for them, which we could discuss directly or
> which you could convey to them first if you like:
>

I'll forward these on ahead of time so he can have good answers prepared.


>
> 1. If the problem is file boundaries ("if the license file
> contains..."), would this be any different if there were no "license
> file", only one big README, and both texts (statement of opinion, and
> copyright/license statements) were in the same file but separated by
> section headers? I'm not really proposing doing that (although it's
> one potential silly solution) but rather trying to draw out the
> absurdity (as I see it) of deeming text that specificially says it's
> NOT license text as if it were just because it's in the same file.
>
> 2. Taking that in the other direction, what good does it do burying a
> record of our beliefs about the matter? It's not like we can erase
> past statements. Taking the text out of the COPYRIGHT file increases
> its distance in space and time from the license text, but it doesn't
> change the fact that they were published together in the past. If
> anything I think it's a disservice to parties who are (IMO wrongly)
> concerned about the implications of such beliefs not to disclose them.
> Having clarified text in the same place puts emphasis on the intent
> that they not conflict and that we actually put effort into clarifying
> where there was a perceived conflict.
>
> 3. I understand lawyers want to minimize risk. I don't understand how
> a statement of opinion that, if it were deemed relevant and deemed
> true by a court, would imply that we (actually nobody) has standing to
> sue creates any risk. To use the UB analogy, when someone reports a
> claim of UB, we actually want to see a code path that leads to UB
> happening (without UB already having occurred by violating an
> interface requirement), not just a claim like "if variables X and Y
> have values A and B, UB results". Of course if there's a proposed
> change that's simpler and doesn't require tracking down if UB actually
> occurs, we'd just consider that outright, but when the current code
> has advantages, there should be a real motivation to change it. If
> we're going to treat the matter here as a "bug report" against the
> COPYRIGHT file, I want to have an understanding of the alleged bug.
>
> 4. I'd also like to understand what the claim-copyright vs
> not-claim-copyright distinction they're making is. As an analogy,
> suppose I've written a math textbook containing "1+1=2" in it. The
> statement "1+1=2" is most certainly not subject to copyright, and my
> saying that (within the text or outside it) does not draw into
> question the copyright status of the textbook. I really don't see any
> difference between this example and what we're saying here with
> regards to these files. We are claiming copyright (and asserting a
> right to do so) for the work as a whole. The statement of opinion is
> on the matter of these files taken by themselves. If the problem is
> just that this isn't clear, maybe there's a trivial way to clarify
> that and make everybody happy.
>
> I know this has been a tedious process of back-and-forth and is using
> lots more time (on both of our sides) than we'd probably like. But I
> do want to see something good come out of it. Let's arrange a chat
> with the lawyers (this probably can/should be done off-list) and see
> what comes out of it.
>
> Rich
>

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

Re: musl licensing

[u-uy74]

On Tue, Mar 29, 2016 at 10:21:25AM -0700, Christopher Lane wrote:
> Listen, if we're asking you for too much, I get it.  This is not our
> project.  We didn't pour years into it, you did, and you have to do what
> you think is right.  If it's beyond your personal ethics to claim copyright
> over the trivial files and public headers you wrote, then that's the way it
> is.  I'll be sad, but we'll deal with it.

I appreciate your statement, but to be a little picky,
and possibly as an argument to mention to your lawyers (?) :

This is not necessarily a question of ethics, but somewhat a question
of legal safety, as well as it is for Google.

[You wrote

"Google's on the receiving end of the musl license, so it seems a "good
license" for us is one that provides clarity on what we can do with the
code.  So [...] -- one that we _can't_ be sued over."]

Rich/musl are on the other side and it certainly is illegal (somewhere)
to claim copyright on something which is not copyrightable (at that place).
The consequences may vary from place to place and from time to time.

(I understand that it is not as attractive to sue the musl project as
it would be to sue Google, where the money is, but nevertheless.
May be Rich wants to travel to a country where an "illicit" copyright
claim results in a jail term, or will happen to, in the future?)

Regards,
Rune

Re: musl licensing

[Christopher Lane]

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

On Mar 29, 2016 11:56 PM, <u-uy74@aetey.se> wrote:
>
> On Tue, Mar 29, 2016 at 10:21:25AM -0700, Christopher Lane wrote:
> > Listen, if we're asking you for too much, I get it.  This is not our
> > project.  We didn't pour years into it, you did, and you have to do what
> > you think is right.  If it's beyond your personal ethics to claim
copyright
> > over the trivial files and public headers you wrote, then that's the
way it
> > is.  I'll be sad, but we'll deal with it.
>
> I appreciate your statement, but to be a little picky,
> and possibly as an argument to mention to your lawyers (?) :
>
> This is not necessarily a question of ethics, but somewhat a question
> of legal safety, as well as it is for Google.
>
> [You wrote
>
> "Google's on the receiving end of the musl license, so it seems a "good
> license" for us is one that provides clarity on what we can do with the
> code.  So [...] -- one that we _can't_ be sued over."]
>
> Rich/musl are on the other side and it certainly is illegal (somewhere)
> to claim copyright on something which is not copyrightable (at that
place).

I don't know that this is true.  We can set aside whether the crt files and
public headers are copyrightable (I think they are; I've mentioned my
reasoning earlier); let's assume for same of argument they are not.  Given
that, I don't know that it would be illegal to claim copyright over them
anyway.  It would be an unenforceable claim, certainly, but it's not
evident to me that it would be illegal.  Your mention of the possibility is
the first I've heard of it.

https://en.m.wikipedia.org/wiki/Copyfraud gives one account that doesn't
indicate illegality, albeit from an apparently US-centric view.  Do you
know of a country that has criminal laws around this?

I could imagine it being illegal somewhere to attempt to _enforce_ a
copyright claim over public domain work (i.e. extract payment from someone
for using a public domain work,) but we're not asking Rich to do that.  And
AFAICT even that's not illegal.

> The consequences may vary from place to place and from time to time.
>
> (I understand that it is not as attractive to sue the musl project as
> it would be to sue Google, where the money is, but nevertheless.
> May be Rich wants to travel to a country where an "illicit" copyright
> claim results in a jail term, or will happen to, in the future?)
>
> Regards,
> Rune
>

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

Re: musl licensing

[u-uy74]

On Wed, Mar 30, 2016 at 07:11:45AM -0700, Christopher Lane wrote:
> On Mar 29, 2016 11:56 PM, <u-uy74@aetey.se> wrote:
> > This is not necessarily a question of ethics, but somewhat a question
> > of legal safety, as well as it is for Google.

> > Rich/musl are on the other side and it certainly is illegal (somewhere)
> > to claim copyright on something which is not copyrightable (at that
> place).
> 
> I don't know that this is true.  We can set aside whether the crt files and

Neither do I, and I regret having written "certainly". There is no
certainty unless a court has decided one's case. The uncertainty is
the only thing which can be assumed.

Claiming a "eager" copyright is invoking UB on Rich's/project's behalf,
that's my point.

This may be harmless now and may even always and everywhere remain
harmless (I really hope so!) but _possibly_ not.

Regards,
Rune

Re: musl licensing

[u-uy74]

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:
> > 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,

To make it clear - this was not about your personal position or the
position of your group. It is about the position of Google's lawers.

> 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.

I did not suggest that this is "nefarious", this is just a plain and
prudent business motivation.

Nothing wrong with CYA, which is the layers' role in this case,
but the other party (musl) should be prudent as well.

Regards,
Rune

Re: musl licensing

[Alexander Cherepanov]

On 2016-03-17 01:50, Petr Hosek wrote:
> On Wed, Mar 16, 2016 at 9:32 AM Alexander Cherepanov <ch3root@openwall.com>
> wrote:
>
>> Yeah, this is a crucial question IMHO. There was a similar discussion
>> about LLVM licensing recently:
>>
>> http://lists.llvm.org/pipermail/llvm-dev/2015-October/thread.html#91536
>>
>>   From this thread I gathered that:
>> 1) Google is quite serious about CLAs;
>> 2) Google has ideas about copyright/licensing/etc which contradict
>> beliefs held widely in the community;
>> 3) Google is not inclined to explain the situation to the community,
>> judging by
>>
>> http://lists.llvm.org/pipermail/llvm-dev/2015-October/091752.html
>>
>> Given its past legal troubles, Google has enough stimuli to study the
>> topic very carefully and it could be right. But could be wrong as well.
>> Anyway, I don't think that just saying that CLAs are required is going
>> to change the opinion of the community.
>
> To clarify the CLA bit, we're not asking musl authors to sign the Google
> CLA. Instead, what we proposed was coming up with a CLA specifically for
> musl.

I didn't mean to imply Google CLA. Sorry if it sounded that way.

> Since someone, in this case most likely Rich as the project
> maintainer, has to re-license the files which are currently in public
> domain, one way is to have the past contributors sign a "musl project" CLA
> as a way to keep a track of the legal permission to use and distribute
> these files. However, this is a decision of the musl community and how you
> do the re-licensing is up to you, as long as you have the permission to
> re-license the files in question.

Thanks for the clarification. Do I understand correctly that you would 
prefer if musl project used musl CLA but this is not a hard requirement 
for you?

-- 
Alexander Cherepanov

Re: musl licensing

[Christopher Lane]

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

On Wed, Mar 16, 2016 at 6:26 PM, Alexander Cherepanov <ch3root@openwall.com>
wrote:

> On 2016-03-17 01:50, Petr Hosek wrote:
>
>> On Wed, Mar 16, 2016 at 9:32 AM Alexander Cherepanov <
>> ch3root@openwall.com>
>> wrote:
>>
>> Yeah, this is a crucial question IMHO. There was a similar discussion
>>> about LLVM licensing recently:
>>>
>>> http://lists.llvm.org/pipermail/llvm-dev/2015-October/thread.html#91536
>>>
>>>   From this thread I gathered that:
>>> 1) Google is quite serious about CLAs;
>>> 2) Google has ideas about copyright/licensing/etc which contradict
>>> beliefs held widely in the community;
>>> 3) Google is not inclined to explain the situation to the community,
>>> judging by
>>>
>>> http://lists.llvm.org/pipermail/llvm-dev/2015-October/091752.html
>>>
>>> Given its past legal troubles, Google has enough stimuli to study the
>>> topic very carefully and it could be right. But could be wrong as well.
>>> Anyway, I don't think that just saying that CLAs are required is going
>>> to change the opinion of the community.
>>>
>>
>> To clarify the CLA bit, we're not asking musl authors to sign the Google
>> CLA. Instead, what we proposed was coming up with a CLA specifically for
>> musl.
>>
>
> I didn't mean to imply Google CLA. Sorry if it sounded that way.
>
> Since someone, in this case most likely Rich as the project
>> maintainer, has to re-license the files which are currently in public
>> domain, one way is to have the past contributors sign a "musl project" CLA
>> as a way to keep a track of the legal permission to use and distribute
>> these files. However, this is a decision of the musl community and how you
>> do the re-licensing is up to you, as long as you have the permission to
>> re-license the files in question.
>>
>
> Thanks for the clarification. Do I understand correctly that you would
> prefer if musl project used musl CLA but this is not a hard requirement for
> you?


Requiring a CLA is, I believe, the clearest way of preserving the musl
project's ability to license and relicense the contributions however they
see fit.  IANAL, but I don't think it's the only option here.

I think that if code was contributed to the musl project under one license,
the musl project needs to get permission from the original contributor
before they release it under a different license, unless the original
license already grants that permission.  In the case where code was
contributed as public domain, and it is successfully argued that public
domain isn't valid, that code is essentially unlicensed (thus no permission
was given at contribution time to relicense it).


>
>
> --
> Alexander Cherepanov
>

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

Re: musl licensing

[Kurt H Maier]

On Tue, Mar 15, 2016 at 02:59:24PM -0700, Petr Hosek wrote:
> Furthermore, all past and future contributors will have to
> to sign the Contributor License Agreement (CLA). 

I am curious:  what is the purpose of this?  How do you intend to get
Sun Microsystems or Imagination Technologies (both named in the
COPYRIGHT file) to sign your contract?

khm

Re: musl licensing

[Josiah Worcester]

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

On Tue, Mar 15, 2016 at 3:00 PM Petr Hosek <phosek@chromium.org> wrote:

> We work on Chromium project at Google. Our team, as well as several
> other teams here at Google, would like to start using musl in various
> open-source projects. This includes shipping musl as a part of SDKs
> and toolchains. However, after performing a standard license review,
> our open-source lawyers told us that there are two obstacles to us
> being able to use musl.
>
> The first issue is the lack of clarity around per-file licensing and
> copyright attribution. 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.
>
> Rather than working around these issues by reimplementing parts of
> musl, we would like to work with the musl community to directly
> address these issues. We believe that our company's interpretation of
> the copyright and authorship is the same across the entire industry
> and resolving these issues would benefit both musl as well as projects
> which already do or plan to use musl.
>
> To address both issues, authors of all files in musl that are "public
> domain" or any other non-license will have to agree with relicensing
> their work under the MIT license (or any other compatible open-source
> 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.
>

A few comments. First, is the COPYRIGHT file insufficient for making it
clear what the per-file licensing state is? If so, I suspect this could be
rather readily changed (the information is around). Second, it is believed
that those files that are marked as "public domain" are uncopyrightable. If
this legal theory doesn't quite fit, would e.g. explicitly declaring them
to be under CC0 or similar suffice? Third, is the CLA at all appropriate?
This is firmly *not* a Google-owned project, and to my knowledge Google
doesn't have similar requirements for any other third-party open source
projects used by them, even if they have contributions (substantial or
otherwise) from Google.

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

Re: musl licensing

[Rich Felker]

A quick note to clarify -- I was first contacted by Google off-list
and suggested taking this discussion on-list since I felt like
discussing these kind of licensing things myself in private would be
going behind the community's back. I'm excited about Google's interest
in using musl but also want to be open with the community, and I hope
we can discuss these things in a constructive way. A few of the ideas
below come as a surprise to me and I'll try to address them:

On Tue, Mar 15, 2016 at 02:59:24PM -0700, Petr Hosek wrote:
> We work on Chromium project at Google. Our team, as well as several
> other teams here at Google, would like to start using musl in various
> open-source projects. This includes shipping musl as a part of SDKs
> and toolchains. However, after performing a standard license review,
> our open-source lawyers told us that there are two obstacles to us
> being able to use musl.
> 
> 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.

However I do think it may be controversial to start claiming copyright
on utterly trivial source files that could have been mechanically
generated and that could not possibly be written in any way other than
how they're currently written without adding gratuitous stuff.

> 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.

What I think might be a reasonable solution is to explicitly state,
preferably just in the COPYRIGHT file alongside the current statement
that these files are in the public domain, that in the event a court
should determine that the authors hold copyright on these files
(despite expressing clearly that they don't want to and don't believe
they can :), permission to use them under a BSD0 license is granted.

> Rather than working around these issues by reimplementing parts of
> musl, we would like to work with the musl community to directly
> address these issues. We believe that our company's interpretation of
> the copyright and authorship is the same across the entire industry
> and resolving these issues would benefit both musl as well as projects
> which already do or plan to use musl.
> 
> To address both issues, authors of all files in musl that are "public
> domain" or any other non-license will have to agree with relicensing
> their work under the MIT license (or any other compatible open-source
> 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.

Rich

Re: musl licensing

[Shiz]

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


> On 15 Mar 2016, at 23:41, Rich Felker <dalias@libc.org> wrote:
> 
> What I think might be a reasonable solution is to explicitly state,
> preferably just in the COPYRIGHT file alongside the current statement
> that these files are in the public domain, that in the event a court
> should determine that the authors hold copyright on these files
> (despite expressing clearly that they don't want to and don't believe
> they can :), permission to use them under a BSD0 license is granted.

If this is acceptable by Google’s lawyers, this seems like a good
solution to me as well.

> 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.

I agree with this. I’ve only ever contributed to a single project with
a CLA, and that was because 1) I had a huge patch backlog for it,
2) the CLA did not require me to give up my full IRL details, and
3) the CLA process was very streamlined. In general, I and I think a
lot of “casual contributors” tend to be scared off by the presence and
requirement of a CLA.

> Rich

- Shiz

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: musl licensing

[Isaac Dunham]

On Tue, Mar 15, 2016 at 06:41:26PM -0400, Rich Felker wrote:
> On Tue, Mar 15, 2016 at 02:59:24PM -0700, Petr Hosek wrote:
> > 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.
> 
> What I think might be a reasonable solution is to explicitly state,
> preferably just in the COPYRIGHT file alongside the current statement
> that these files are in the public domain, that in the event a court
> should determine that the authors hold copyright on these files
> (despite expressing clearly that they don't want to and don't believe
> they can :), permission to use them under a BSD0 license is granted. 

That's OK with me.

I do note that src/misc/fmtmsg.c, written by myself, does not fall
under the "no copyrightable original content" rule.
It was my intent that it should be available to use as widely as
possible.
Since the main license of musl is MIT, which is a rough approximation of
that, I'm fine with it being marked as MIT.
0BSD is also perfectly acceptable to me.

Additionally, some of the code in src/crypt/* is marked as public domain;
as far as I can tell, this was from nsz (commit 88bf5a8a).

> > Rather than working around these issues by reimplementing parts of
> > musl, we would like to work with the musl community to directly
> > address these issues. We believe that our company's interpretation of
> > the copyright and authorship is the same across the entire industry
> > and resolving these issues would benefit both musl as well as projects
> > which already do or plan to use musl.
> > 
> > To address both issues, authors of all files in musl that are "public
> > domain" or any other non-license will have to agree with relicensing
> > their work under the MIT license (or any other compatible open-source

(See the statement above.)

> > 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.

Agreed.

Thanks,
Isaac Dunham

Re: musl licensing

[u-uy74]

On Tue, Mar 15, 2016 at 06:41:26PM -0400, Rich Felker wrote:
> However I do think it may be controversial to start claiming copyright
> on utterly trivial source files that could have been mechanically
> generated and that could not possibly be written in any way other than
> how they're currently written without adding gratuitous stuff.

+1

It's where the copyright laws are (especially) inadequate for software.

> 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.

+1

Btw which countries' laws were the obstacles for Google to use musl?
I _guess_ USA but that was never stated. Google has business all over
the world and might care of any place and use case. Does musl care
about the same thing (besides the wish of a potential user and a potential
contributor)? I can't tell.

Rune

Re: musl licensing

[Szabolcs Nagy]

* 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.

Re: musl licensing

[FRIGN]

On Wed, 16 Mar 2016 11:31:25 +0100
Szabolcs Nagy <nsz@port70.net> wrote:

Hey Szabolcs,

> 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.)

One line never hurts. It would also be convenient for new contributors,
because adding this one line automatically implies they want to be in
the central "LICENSE". This would actually favor homogenization of
licensing, which would make life much easier for everybody.

	/* See LICENSE file for copyright and license details. */

> bionic actually generates its kernel interface headers from (gpl) code
> and each file has the comment:
> (...)
> so it is ok to claim 'not copyrightable', we just have to find a way
> to do this without cluttering each header file.

I don't think we can apply this argument here. Also, there's no reason not
to just use ISC or BSD-0.
A central LICENSE file would also make it easier to see which people
contributed. Using git signs or other version control means would remove
all this valuable information if you for instance just downloaded the
tarball, which is unacceptable.

Cheers

FRIGN

-- 
FRIGN <dev@frign.de>

Re: musl licensing

[Szabolcs Nagy]

* FRIGN <dev@frign.de> [2016-03-16 11:55:27 +0100]:
> On Wed, 16 Mar 2016 11:31:25 +0100
> Szabolcs Nagy <nsz@port70.net> wrote:
> > 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.)
> 
> One line never hurts. It would also be convenient for new contributors,

it trains programmers to ignore source comments because they contain
redundant legal gibberish instead of technically relevant content.

you don't put "use the makefile to build this" in every source file
either, but describe the build process at a central location.

i kept the copyright notices of src/math/* files because there are
too many variations to describe them all in a separate file, but i
have to note that they do not represent the real authors and year of
authorship.. which is the usual case for copyright notices..
(some try to clarify the situation by assigning all the copyright
to one entity, but that makes it worse: that's clearly not about the
rights of an author, but pure coercive monopoly over ideas.)

> > bionic actually generates its kernel interface headers from (gpl) code
> > and each file has the comment:
> > (...)
> > so it is ok to claim 'not copyrightable', we just have to find a way
> > to do this without cluttering each header file.
> 
> I don't think we can apply this argument here.

why?

> Also, there's no reason not to just use ISC or BSD-0.

there are things that should not be the intellectual property
of any person and you should not claim ownership of those things.

Re: musl licensing

[Anthony J. Bentley]

Szabolcs Nagy writes:
> * FRIGN <dev@frign.de> [2016-03-16 11:55:27 +0100]:
> > One line never hurts. It would also be convenient for new contributors,
> 
> it trains programmers to ignore source comments because they contain
> redundant legal gibberish instead of technically relevant content.

A simple copyright statement that lists authors, dates and license terms
is absolutely technical relevant content.

-- 
Anthony J. Bentley

Re: musl licensing

[u-uy74]

On Wed, Mar 16, 2016 at 06:46:04AM -0600, Anthony J. Bentley wrote:
> > it trains programmers to ignore source comments because they contain
> > redundant legal gibberish instead of technically relevant content.
> 
> A simple copyright statement that lists authors, dates and license terms
> is absolutely technical relevant content.

Then we may have differing ideas of what is "technical" :)

Copyright law is a [legacy originating from the Britain's] censuring
framework, which happens to be applied to software for no technical reason
(does a copyright notice influence the functioning of the program?) but
for various political ones.

Rune

Re: musl licensing

[FRIGN]

On Wed, 16 Mar 2016 14:49:08 +0100
u-uy74@aetey.se wrote:

Hey Rune,

> Copyright law is a [legacy originating from the Britain's] censuring
> framework, which happens to be applied to software for no technical reason
> (does a copyright notice influence the functioning of the program?) but
> for various political ones.

thanks for the history lesson. It still doesn't change the fact that
this topic needs to be addressed. Copyright law is not going to change
in the forseeable future, and I think the best that can happen to musl
is when it's used broadly (which implies broad testing and more chances
of patches flowing in).
I understand the caution by the companies when licensing isn't clear.
Given public domain practically implies "all rights reserved", there's
nothing stopping a "malicious" developer from making claims after
deployment. The term "public domain" is not very clear after all.

I also want to see musl in widespread use, and even if I probably
can't expect a relicensing to ISC or something, one can still expect
the sections which are "public domain" to be licensed under BSD-0
or ISC or MIT to clear up the licensing situation.

The CLA comment by Petr was probably a misunderstanding and I assume
he probably meant the case in which a license change won't happen
upstream, but as an exception for Google.

Cheers

FRIGN

-- 
FRIGN <dev@frign.de>

Re: musl licensing

[FRIGN]

On Wed, 16 Mar 2016 13:34:14 +0100
Szabolcs Nagy <nsz@port70.net> wrote:

Hey Szabolcs,

> it trains programmers to ignore source comments because they contain
> redundant legal gibberish instead of technically relevant content.

hold your horses there for a second. It is pretty much consent that
the current licensing of musl can be described as erratic at best, with
many different licenses conflicting in the codebase in a small degree.

You for instance have done the following exception
:: The BSD PRNG implementation (src/prng/random.c) and XSI search API
:: (src/search/*.c) functions are Copyright © 2011 Szabolcs Nagy and
:: licensed under following terms: "Permission to use, copy, modify,
:: and/or distribute this code for any purpose with or without fee is
:: hereby granted. There is no warranty."
(taken from COPYRIGHT)

This is basically the poor-man's version of BSD-0, so why not just
declare it as such and be on the safe side? I'm not sure if
"there is no warranty" really protects you from warranty claims.

Also, all code sections which fall under the public domain because they
are not copyrightable: I would not go this direction and instead just
publish those sections as BSD-0.
My stance is: Public domain is worse than a proper non-copyleft license
in many countries, and BSD-0 goes as far as possible.
I could literally take a BSD-0 code, remove all the licensing and do
whatever the fuck I want with it. This is public domain for me, and
in BSD-0 the author explicitly states that he doesn't give a damn about
attribution.

> i kept the copyright notices of src/math/* files because there are
> too many variations to describe them all in a separate file, but i
> have to note that they do not represent the real authors and year of
> authorship.. which is the usual case for copyright notices..
> (some try to clarify the situation by assigning all the copyright
> to one entity, but that makes it worse: that's clearly not about the
> rights of an author, but pure coercive monopoly over ideas.)

:: Much of the math library code (src/math/* and src/complex/*) is
:: Copyright (...)
:: and labelled as such in comments in the individual source files. All
:: have been licensed under extremely permissive terms.

Now, when I take a look at src/math/lrintf.c for instance, there is
no copyright notice. And "extremely permissive terms" is vague at best.

> why?

Because there is a difference between machine generated code and
hand-written code, but both can be considered a grey-zone.
I also don't feel comfortable if an argument is given against a
more consistent licensing practice by looking at a project which
obviously has licensing issues as well.

> > Also, there's no reason not to just use ISC or BSD-0.
> there are things that should not be the intellectual property
> of any person and you should not claim ownership of those things.

If you publish source code under the BSD-0, anybody can take it,
remove the license and republish it under his name. Anybody can
sell it for any amount thinkable, modify it, release it, release
modifications and burn copies of it on a big pile without ever
having to worry that you would leverage your intellectual property.

Even if you wanted, you could not do anything about it, that's the
beauty. In my opinion, the BSD-0 _is_ a public domain license, as
it literally sets no limits on the usage of the program, except
making you not liable for any damages (which is common sense man).
And other than a public domain license, the judicial context is clear
in any country, and even the companies are happy when the terms are
clear.

---

I think everyone here should be concerned that the COPYRIGHT-file
of musl is approaching the length of the GPLv2, and if in the future
more things are added to musl, It's not unlikely that contributors will
chime in and add special clauses to this file as well.
The goal of a non-copyleft-licensed project is foremost to allow
scavenging the code if you find something that is useful without having
to go through great lengths of finding out what you are allowed to do
and what not.
Currently, this ease of use is not directly given with musl, while
at least for a GPL-licensed project the restrictions are mostly laid
out clearly due to its cancerous nature of self-proclamation.

Cheers

FRIGN

-- 
FRIGN <dev@frign.de>

Re: musl licensing

[Szabolcs Nagy]

* FRIGN <dev@frign.de> [2016-03-16 15:01:05 +0100]:
> You for instance have done the following exception
> :: The BSD PRNG implementation (src/prng/random.c) and XSI search API
> :: (src/search/*.c) functions are Copyright © 2011 Szabolcs Nagy and
> :: licensed under following terms: "Permission to use, copy, modify,
> :: and/or distribute this code for any purpose with or without fee is
> :: hereby granted. There is no warranty."
> (taken from COPYRIGHT)
> 

that's a historical accident.

(you can look it up in the mailing list archive, it happened
before musl chose the mit license and mostly had code written
by Rich so he asked under what terms he could use my changes
so i wrote something that ended up in COPYRIGHT.)

it can be cleaned up if it is a concern.

> > i kept the copyright notices of src/math/* files because there are
> > too many variations to describe them all in a separate file, but i
> > have to note that they do not represent the real authors and year of
> > authorship.. which is the usual case for copyright notices..
> > (some try to clarify the situation by assigning all the copyright
> > to one entity, but that makes it worse: that's clearly not about the
> > rights of an author, but pure coercive monopoly over ideas.)
> 
> :: Much of the math library code (src/math/* and src/complex/*) is
> :: Copyright (...)
> :: and labelled as such in comments in the individual source files. All
> :: have been licensed under extremely permissive terms.
> 
> Now, when I take a look at src/math/lrintf.c for instance, there is
> no copyright notice. And "extremely permissive terms" is vague at best.

because it was written for musl from scratch.
see git log for details.

"extremely permissive terms" is as precise as you can get
with fdlibm (and netlib.org stuff in general).

Re: musl licensing

[FRIGN]

On Tue, 15 Mar 2016 14:59:24 -0700
Petr Hosek <phosek@chromium.org> wrote:

Hey Petr,

> The first issue is the lack of clarity around per-file licensing and
> copyright attribution. 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.

in my opinion, it would be too much hassle and bloat up the tarballs
adding a license header to each particular single source file.
At suckless.org we solved this by having one central LICENSE file and
adding the remark

	/* See LICENSE file for copyright and license details. */

at the top of each source file.
The transition would be seamless, as there won't be need to add such a
notice at the top of the public domain licensed source files.

However, I have the strong opinion that there should be an initiative
to make musl licensing a bit more homogenous.
For non-copyleft licenses, I see only two valid candidates nowadays:

   - ISC[0] if you want attribution.
   - 0-clause BSD[1] if you don't want attribution (ISC without the
     attribution half-sentence)

This entire public-domain thing is built on a very loose foundation.
What more do you want than ISC or the 0-clause BSD?

An added bonus is that the ISC license is functionally equivalent
to the 2-clause BSD license modulo the text segments superfluous
since the Berne Convention of 1971. I use it for all new projects,
and as far as I know it's even okay to change BSD-2 to ISC without
asking the contributors (as they're functionally equivalent).

> Rather than working around these issues by reimplementing parts of
> musl, we would like to work with the musl community to directly
> address these issues. We believe that our company's interpretation of
> the copyright and authorship is the same across the entire industry
> and resolving these issues would benefit both musl as well as projects
> which already do or plan to use musl.

Agreed, and I must admit that I understand Google's position here.
A "public domain" "license" is not accepted by all legislations and
is considered all rights reserved there.
The company does not want to risk a lawsuit when the licensing situation
has not been clarified.

> To address both issues, authors of all files in musl that are "public
> domain" or any other non-license will have to agree with relicensing
> their work under the MIT license (or any other compatible open-source
> 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.

There's no need for a CLA when the relicensing happens at upstream,
knowing of course the internal practices regarding CLA's at Google.
I would not recommend the MIT license in favor of the licenses mentioned
above (ISC[0] and BSD-0[1]).

Cheers

FRIGN

[0]: ##########
Copyright (c) Year(s), Company or Person's Name <E-mail address>

Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.

THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
##############

[1]: #########
Copyright (C) 2006 by Rob Landley <rob@landley.net>

Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted.

THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
##############

-- 
FRIGN <dev@frign.de>

Re: musl licensing

[Rich Felker]

A few more general thoughts on this thread:

1. Staying on topic. The topic at hand is not "relicensing" or
anything crazy, just figuring out what's not sufficiently clear to
Google's lawyers about our current licensing or documentation of
copyright status, and whether there are "non-functional" (clarifying)
changes that could be made to the source tree that would meet their
needs and perhaps also improve the ease with which other users who
have to deal with legal deparements can use musl.

2. In-line vs out-of-line copyright/license info. The out-of-line form
we have now has some benefits, mainly in avoiding source file clutter,
avoiding diff hunks to update copyright years, etc. But it also has
disadvantages such as making it easy to forget to update and arguably
being hard to interpret. I think this is an area where it would be
useful to discuss pros and cons and whether there are in-between
solutions that get the best properties of both.

Rich

Re: musl licensing

[FRIGN]

On Wed, 16 Mar 2016 16:13:58 -0400
Rich Felker <dalias@libc.org> wrote:

Hey Rich,

> 1. Staying on topic. The topic at hand is not "relicensing" or
> anything crazy, just figuring out what's not sufficiently clear to
> Google's lawyers about our current licensing or documentation of
> copyright status, and whether there are "non-functional" (clarifying)
> changes that could be made to the source tree that would meet their
> needs and perhaps also improve the ease with which other users who
> have to deal with legal deparements can use musl.

I think the biggest concern on behalf of Google is the code licensed
under public domain. There needs to be a decision for that.

> 2. In-line vs out-of-line copyright/license info. The out-of-line form
> we have now has some benefits, mainly in avoiding source file clutter,
> avoiding diff hunks to update copyright years, etc. But it also has
> disadvantages such as making it easy to forget to update and arguably
> being hard to interpret. I think this is an area where it would be
> useful to discuss pros and cons and whether there are in-between
> solutions that get the best properties of both.

As I promoted in my previous mails, I favor an out-of-line
copyright/license info with a small one-line remark in each
source file. This actually makes it easy to update years (only necessary
in the COPYRIGHT file) and makes it easier for people to find out what
license code is under.

Cheers

FRIGN

-- 
FRIGN <dev@frign.de>

Re: musl licensing

[Rich Felker]

On Wed, Mar 16, 2016 at 09:19:43PM +0100, FRIGN wrote:
> On Wed, 16 Mar 2016 16:13:58 -0400
> Rich Felker <dalias@libc.org> wrote:
> 
> Hey Rich,
> 
> > 1. Staying on topic. The topic at hand is not "relicensing" or
> > anything crazy, just figuring out what's not sufficiently clear to
> > Google's lawyers about our current licensing or documentation of
> > copyright status, and whether there are "non-functional" (clarifying)
> > changes that could be made to the source tree that would meet their
> > needs and perhaps also improve the ease with which other users who
> > have to deal with legal deparements can use musl.
> 
> I think the biggest concern on behalf of Google is the code licensed
> under public domain. There needs to be a decision for that.

Yes, what I'm waiting for on this is whether a "conditional license"
("if this code is deemed to be covered by copyright, then we license
it as BSD0/CC0/whatever") will satisfy them. This makes no difference
in jurisdictions where public domain is recognized but may make them
happy.

I very much do not want to actually _claim_ copyright on these files,
because it's my position (and I believe also Google's position vs
Oracle) that pure facts of API interfaces without any additional
expressive content are not copyrightable.

> > 2. In-line vs out-of-line copyright/license info. The out-of-line form
> > we have now has some benefits, mainly in avoiding source file clutter,
> > avoiding diff hunks to update copyright years, etc. But it also has
> > disadvantages such as making it easy to forget to update and arguably
> > being hard to interpret. I think this is an area where it would be
> > useful to discuss pros and cons and whether there are in-between
> > solutions that get the best properties of both.
> 
> As I promoted in my previous mails, I favor an out-of-line
> copyright/license info with a small one-line remark in each
> source file. This actually makes it easy to update years (only necessary
> in the COPYRIGHT file) and makes it easier for people to find out what
> license code is under.

What about authorship/copyright holders per-file?

Rich

Re: musl licensing

[Jens Gustedt]

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

Am Mittwoch, den 16.03.2016, 16:34 -0400 schrieb Rich Felker:
> What about authorship/copyright holders per-file?

Just a thought. In some projects I use an automatic tool to keep
author information uptodate in each file by synching it with git. (And
also ironing the identation style and stuff like that.)

This must not necessarily be done a each commit, but perhaps once at
the end of year could suffice? Such updates could be clearly marked as
such, and so they wouldn't interact much with the real development.

Jens

-- 
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::




[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: musl licensing

[FRIGN]

On Wed, 16 Mar 2016 16:34:28 -0400
Rich Felker <dalias@libc.org> wrote:

Hey Rich,

> Yes, what I'm waiting for on this is whether a "conditional license"
> ("if this code is deemed to be covered by copyright, then we license
> it as BSD0/CC0/whatever") will satisfy them. This makes no difference
> in jurisdictions where public domain is recognized but may make them
> happy.

can you give me one single aspect in which BSD0 and Public Domain differ?

> What about authorship/copyright holders per-file?

I see no need for that and it's one hell to maintain. If you want to
find out exact authorship, "git blame" is your friend. It will give you
the history and everything else ("git log file", "git show", ...).
Trying to emulate that by hand is just tedious and defeats the purpose.

Cheers

FRIGN

-- 
FRIGN <dev@frign.de>

Re: musl licensing

[Rich Felker]

On Wed, Mar 16, 2016 at 10:15:27PM +0100, FRIGN wrote:
> On Wed, 16 Mar 2016 16:34:28 -0400
> Rich Felker <dalias@libc.org> wrote:
> 
> Hey Rich,
> 
> > Yes, what I'm waiting for on this is whether a "conditional license"
> > ("if this code is deemed to be covered by copyright, then we license
> > it as BSD0/CC0/whatever") will satisfy them. This makes no difference
> > in jurisdictions where public domain is recognized but may make them
> > happy.
> 
> can you give me one single aspect in which BSD0 and Public Domain differ?

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".

> > What about authorship/copyright holders per-file?
> 
> I see no need for that and it's one hell to maintain. If you want to
> find out exact authorship, "git blame" is your friend. It will give you
> the history and everything else ("git log file", "git show", ...).
> Trying to emulate that by hand is just tedious and defeats the purpose.

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.

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.

Rich

Re: musl licensing

[FRIGN]

On Wed, 16 Mar 2016 17:35:51 -0400
Rich Felker <dalias@libc.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@frign.de>

Re: musl licensing

[John Levine]

>I very much do not want to actually _claim_ copyright on these files,
>because it's my position (and I believe also Google's position vs
>Oracle) that pure facts of API interfaces without any additional
>expressive content are not copyrightable.

In the U.S., you are certainly right.  In other countries where the
rules are different and there are database rights that cover
collections of facts, who knows?

You might consider asserting copyright over whatever parts of the
material are copyrightable, if any, and then grant a CC0 license.
Whatever rights you may have had, the grant effectively puts the
material back in the P.D.

R's,
John

Re: musl licensing

[Christopher Lane]

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

On Wed, Mar 16, 2016 at 1:34 PM, Rich Felker <dalias@libc.org> wrote:

> On Wed, Mar 16, 2016 at 09:19:43PM +0100, FRIGN wrote:
> > On Wed, 16 Mar 2016 16:13:58 -0400
> > Rich Felker <dalias@libc.org> wrote:
> >
> > Hey Rich,
> >
> > > 1. Staying on topic. The topic at hand is not "relicensing" or
> > > anything crazy, just figuring out what's not sufficiently clear to
> > > Google's lawyers about our current licensing or documentation of
> > > copyright status, and whether there are "non-functional" (clarifying)
> > > changes that could be made to the source tree that would meet their
> > > needs and perhaps also improve the ease with which other users who
> > > have to deal with legal deparements can use musl.
> >
> > I think the biggest concern on behalf of Google is the code licensed
> > under public domain. There needs to be a decision for that.
>
> Yes, what I'm waiting for on this is whether a "conditional license"
> ("if this code is deemed to be covered by copyright, then we license
> it as BSD0/CC0/whatever") will satisfy them. This makes no difference
> in jurisdictions where public domain is recognized but may make them
> happy.
>
> I very much do not want to actually _claim_ copyright on these files,
> because it's my position (and I believe also Google's position vs
> Oracle) that pure facts of API interfaces without any additional
> expressive content are not copyrightable.
>

WRT conditional licensing along the lines of "this is public domain if you
think that's a thing, otherwise this is BSD0," that's legally ambiguous
enough that it doesn't actually help that much.  If you ("you" in the
collective musl project sense) are willing to license under BSD0 in some
set of circumstances, it's clearer if you just do that without the public
domain condition.

I agree that APIs aren't copyrightable, and I believe so do the majority of
software developers.  But unfortunately, neither your opinion, mine, or
Google's matters much when the courts have said otherwise.  That said, I
don't want you (or anyone else who is passionate about this) to
misrepresent your position on this.  I suggest you DO record your opinion
that the public headers/APIs are "public domain" and not copyrightable, but
please don't do it in the LICENSE file since it defeats the purpose of
providing a clear license.

Also, in case you're wondering who I am:
Hi, I'm Chris.  I work on the same team as Petr.  Nice to meet you :)


>
> > > 2. In-line vs out-of-line copyright/license info. The out-of-line form
> > > we have now has some benefits, mainly in avoiding source file clutter,
> > > avoiding diff hunks to update copyright years, etc. But it also has
> > > disadvantages such as making it easy to forget to update and arguably
> > > being hard to interpret. I think this is an area where it would be
> > > useful to discuss pros and cons and whether there are in-between
> > > solutions that get the best properties of both.
> >
> > As I promoted in my previous mails, I favor an out-of-line
> > copyright/license info with a small one-line remark in each
> > source file. This actually makes it easy to update years (only necessary
> > in the COPYRIGHT file) and makes it easier for people to find out what
> > license code is under.
>
> What about authorship/copyright holders per-file?


> Rich
>



-- 
kthxbai
:wq

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

Re: musl licensing

[Ed Maste]

On 16 March 2016 at 20:34, Rich Felker <dalias@libc.org> wrote:
>
> What about authorship/copyright holders per-file?

I have an interest in this as it applies to downstream consumers who
wish to use a portion of the software -- for example, I'd like to use
musl's memmem and strstr in FreeBSD's libc.

I've proposed copying the text from the top-level COPYRIGHT into the
individual files themselves. (In code review at
https://reviews.freebsd.org/D2601 if you're interested.) If there were
a reference to the standalone copyright/license file it would need to
be modified anyway. Thus, from my perspective it doesn't much matter
if the original has no statement, or a one-line reference to a
separate file.

Re: musl licensing

[Rich Felker]

On Thu, Mar 17, 2016 at 02:01:17AM +0000, Ed Maste wrote:
> On 16 March 2016 at 20:34, Rich Felker <dalias@libc.org> wrote:
> >
> > What about authorship/copyright holders per-file?
> 
> I have an interest in this as it applies to downstream consumers who
> wish to use a portion of the software -- for example, I'd like to use
> musl's memmem and strstr in FreeBSD's libc.
> 
> I've proposed copying the text from the top-level COPYRIGHT into the
> individual files themselves. (In code review at
> https://reviews.freebsd.org/D2601 if you're interested.) If there were
> a reference to the standalone copyright/license file it would need to
> be modified anyway. Thus, from my perspective it doesn't much matter
> if the original has no statement, or a one-line reference to a
> separate file.

What would be the minimal requirement for you not to need to modify
the files? Full license text? Or would something like having the
copyright holders named and "licensed under standard MIT license" or
similar (possibly with a reference of some sort) suffice?

I'm trying to gauge if we should try to make it so you don't need to
modify the files, or if that's not a practical goal while avoiding
massive comment-spam in source files.

Rich

Re: musl licensing

[Ed Maste]

On 16 March 2016 at 23:19, Rich Felker <dalias@libc.org> wrote:
>
> What would be the minimal requirement for you not to need to modify
> the files? Full license text? Or would something like having the
> copyright holders named and "licensed under standard MIT license" or
> similar (possibly with a reference of some sort) suffice?

I think it depends on context. For example, If we planned to import
musl into our contrib/ tree and build it as a standalone entity the
current form (with no individual file statements) would be just fine.

But in this case, where I hope to combine a few files into our
existing libc I'll want the license text in the file as it's
consistent with the rest of our libc, and it avoids adding a
MIT-LICENSE.txt, MUSL-LICENSE.txt or similar file to the tree.

> I'm trying to gauge if we should try to make it so you don't need to
> modify the files, or if that's not a practical goal while avoiding
> massive comment-spam in source files.

I don't think it's a practical goal to entirely avoid needing to
modify files; I had to do so for a minor header variations or some
such anyhow. From my perspective, my order of preference is full
authorship + license, authorship + license statement, status quo. I do
understand wanting to avoid the full license text though. Do other
potential downstream consumers of musl have a preference?

Re: musl licensing

[Rich Felker]

On Thu, Mar 17, 2016 at 02:49:55PM -0400, Ed Maste wrote:
> On 16 March 2016 at 23:19, Rich Felker <dalias@libc.org> wrote:
> >
> > What would be the minimal requirement for you not to need to modify
> > the files? Full license text? Or would something like having the
> > copyright holders named and "licensed under standard MIT license" or
> > similar (possibly with a reference of some sort) suffice?
> 
> I think it depends on context. For example, If we planned to import
> musl into our contrib/ tree and build it as a standalone entity the
> current form (with no individual file statements) would be just fine.
> 
> But in this case, where I hope to combine a few files into our
> existing libc I'll want the license text in the file as it's
> consistent with the rest of our libc, and it avoids adding a
> MIT-LICENSE.txt, MUSL-LICENSE.txt or similar file to the tree.

Indeed, I was thinking more along the lines of whether we're to the
point that standard licenses could be referenced by name/identifier
without an in-tree copy.

> > I'm trying to gauge if we should try to make it so you don't need to
> > modify the files, or if that's not a practical goal while avoiding
> > massive comment-spam in source files.
> 
> I don't think it's a practical goal to entirely avoid needing to
> modify files; I had to do so for a minor header variations or some
> such anyhow. From my perspective, my order of preference is full
> authorship + license, authorship + license statement, status quo. I do
> understand wanting to avoid the full license text though. Do other
> potential downstream consumers of musl have a preference?

I think our community tends to dislike files which are 20+ lines of
copyright/license comments followed by <10 lines of code. Whether
there are situations where the file size makes a practical difference,
I don't know. One observation: on a standard-size terminal it's likely
you wouldn't seen _any_ code on the first page with a full-license
comment header.

Rich

Re: musl licensing

[Wink Saville]

As a data point, in android the file copyright header
(https://android.googlesource.com/platform/bionic/+/master/benchmarks/math_benchmark.cpp)
is 13-15 lines long depending on how you want to count it:

/*
* Copyright (C) 2013 The Android Open Source Project
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/


On Thu, Mar 17, 2016 at 12:16 PM, Rich Felker <dalias@libc.org> wrote:
> On Thu, Mar 17, 2016 at 02:49:55PM -0400, Ed Maste wrote:
>> On 16 March 2016 at 23:19, Rich Felker <dalias@libc.org> wrote:
>> >
>> > What would be the minimal requirement for you not to need to modify
>> > the files? Full license text? Or would something like having the
>> > copyright holders named and "licensed under standard MIT license" or
>> > similar (possibly with a reference of some sort) suffice?
>>
>> I think it depends on context. For example, If we planned to import
>> musl into our contrib/ tree and build it as a standalone entity the
>> current form (with no individual file statements) would be just fine.
>>
>> But in this case, where I hope to combine a few files into our
>> existing libc I'll want the license text in the file as it's
>> consistent with the rest of our libc, and it avoids adding a
>> MIT-LICENSE.txt, MUSL-LICENSE.txt or similar file to the tree.
>
> Indeed, I was thinking more along the lines of whether we're to the
> point that standard licenses could be referenced by name/identifier
> without an in-tree copy.
>
>> > I'm trying to gauge if we should try to make it so you don't need to
>> > modify the files, or if that's not a practical goal while avoiding
>> > massive comment-spam in source files.
>>
>> I don't think it's a practical goal to entirely avoid needing to
>> modify files; I had to do so for a minor header variations or some
>> such anyhow. From my perspective, my order of preference is full
>> authorship + license, authorship + license statement, status quo. I do
>> understand wanting to avoid the full license text though. Do other
>> potential downstream consumers of musl have a preference?
>
> I think our community tends to dislike files which are 20+ lines of
> copyright/license comments followed by <10 lines of code. Whether
> there are situations where the file size makes a practical difference,
> I don't know. One observation: on a standard-size terminal it's likely
> you wouldn't seen _any_ code on the first page with a full-license
> comment header.
>
> Rich

Re: musl licensing

[Petr Hosek]

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

In Chromium and all related projects, which are licensed under the BSD
license, we use a much shorter header:

// Copyright 2016 The Chromium Authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.

On Thu, Mar 17, 2016 at 2:17 PM Wink Saville <wink@saville.com> wrote:

> As a data point, in android the file copyright header
> (
> https://android.googlesource.com/platform/bionic/+/master/benchmarks/math_benchmark.cpp
> )
> is 13-15 lines long depending on how you want to count it:
>
> /*
> * Copyright (C) 2013 The Android Open Source Project
> *
> * Licensed under the Apache License, Version 2.0 (the "License");
> * you may not use this file except in compliance with the License.
> * You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
>
>
> On Thu, Mar 17, 2016 at 12:16 PM, Rich Felker <dalias@libc.org> wrote:
> > On Thu, Mar 17, 2016 at 02:49:55PM -0400, Ed Maste wrote:
> >> On 16 March 2016 at 23:19, Rich Felker <dalias@libc.org> wrote:
> >> >
> >> > What would be the minimal requirement for you not to need to modify
> >> > the files? Full license text? Or would something like having the
> >> > copyright holders named and "licensed under standard MIT license" or
> >> > similar (possibly with a reference of some sort) suffice?
> >>
> >> I think it depends on context. For example, If we planned to import
> >> musl into our contrib/ tree and build it as a standalone entity the
> >> current form (with no individual file statements) would be just fine.
> >>
> >> But in this case, where I hope to combine a few files into our
> >> existing libc I'll want the license text in the file as it's
> >> consistent with the rest of our libc, and it avoids adding a
> >> MIT-LICENSE.txt, MUSL-LICENSE.txt or similar file to the tree.
> >
> > Indeed, I was thinking more along the lines of whether we're to the
> > point that standard licenses could be referenced by name/identifier
> > without an in-tree copy.
> >
> >> > I'm trying to gauge if we should try to make it so you don't need to
> >> > modify the files, or if that's not a practical goal while avoiding
> >> > massive comment-spam in source files.
> >>
> >> I don't think it's a practical goal to entirely avoid needing to
> >> modify files; I had to do so for a minor header variations or some
> >> such anyhow. From my perspective, my order of preference is full
> >> authorship + license, authorship + license statement, status quo. I do
> >> understand wanting to avoid the full license text though. Do other
> >> potential downstream consumers of musl have a preference?
> >
> > I think our community tends to dislike files which are 20+ lines of
> > copyright/license comments followed by <10 lines of code. Whether
> > there are situations where the file size makes a practical difference,
> > I don't know. One observation: on a standard-size terminal it's likely
> > you wouldn't seen _any_ code on the first page with a full-license
> > comment header.
> >
> > Rich
>

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

Re: musl licensing

[Ruediger Meier]

On Thursday 17 March 2016, Petr Hosek wrote:
> In Chromium and all related projects, which are licensed under the
> BSD license, we use a much shorter header:
>
> // Copyright 2016 The Chromium Authors. All rights reserved.
> // Use of this source code is governed by a BSD-style license that
> can be // found in the LICENSE file.

BTW is it really needed to update the copyright year regularly? Even 
though this is automated, it's annyoing for users and developers to 
have such changes in the git history.

What I really don't like when watching diffs is to see 1000 files differ 
because of the copyright year. One other file has a real diff. It also 
increases build time when switching between tags or bisecting.

cu,
Rudi

Re: musl licensing

[Anthony J. Bentley]

Ruediger Meier writes:
> On Thursday 17 March 2016, Petr Hosek wrote:
> > In Chromium and all related projects, which are licensed under the
> > BSD license, we use a much shorter header:
> >
> > // Copyright 2016 The Chromium Authors. All rights reserved.
> > // Use of this source code is governed by a BSD-style license that
> > can be // found in the LICENSE file.
> 
> BTW is it really needed to update the copyright year regularly? Even 
> though this is automated, it's annyoing for users and developers to 
> have such changes in the git history.
> 
> What I really don't like when watching diffs is to see 1000 files differ 
> because of the copyright year. One other file has a real diff. It also 
> increases build time when switching between tags or bisecting.

The only time copyright years need to be updated in a per-file copyright
statement is when the file has had copyrightable changes made. Updating
the year in a file that hasn't otherwise changed in that year is
spurious (and incorrect, really).

-- 
Anthony J. Bentley

Re: musl licensing

[Kurt H Maier]

On Thu, Mar 17, 2016 at 05:07:55PM -0600, Anthony J. Bentley wrote:
> 
> The only time copyright years need to be updated in a per-file copyright
> statement is when the file has had copyrightable changes made. Updating
> the year in a file that hasn't otherwise changed in that year is
> spurious (and incorrect, really).
> 

Post-Berne Convention there is no legal requirement to display years
anywhere.  It's just cargo-cult lawyerin'.

khm

Re: musl licensing

[Anthony J. Bentley]

Kurt H Maier writes:
> On Thu, Mar 17, 2016 at 05:07:55PM -0600, Anthony J. Bentley wrote:
> > 
> > The only time copyright years need to be updated in a per-file copyright
> > statement is when the file has had copyrightable changes made. Updating
> > the year in a file that hasn't otherwise changed in that year is
> > spurious (and incorrect, really).
> > 
> 
> Post-Berne Convention there is no legal requirement to display years
> anywhere.  It's just cargo-cult lawyerin'.

Post-Berne no copyright statement is needed at all. Marking license
terms, authors and dates in individual files is strictly a convenience
factor for those using or reading the code.

-- 
Anthony J. Bentley

Re: musl licensing

[Ruediger Meier]

On Friday 18 March 2016, Anthony J. Bentley wrote:
> Kurt H Maier writes:
> > On Thu, Mar 17, 2016 at 05:07:55PM -0600, Anthony J. Bentley wrote:
> > > The only time copyright years need to be updated in a per-file
> > > copyright statement is when the file has had copyrightable
> > > changes made. Updating the year in a file that hasn't otherwise
> > > changed in that year is spurious (and incorrect, really).
> >
> > Post-Berne Convention there is no legal requirement to display
> > years anywhere.  It's just cargo-cult lawyerin'.
>
> Post-Berne no copyright statement is needed at all. Marking license
> terms, authors and dates in individual files is strictly a
> convenience factor for those using or reading the code.

Convenience factor? It's simply annoying. The gnu people have devoloped 
a whole machinery to spam these non-sense commits all over any gnu 
project:

$ cd ~/src/coreutils/
$ wc -l `find -name "*copyrig*"`
    4 ./.x-update-copyright
  274 ./gnulib/build-aux/update-copyright
   66 ./gnulib/check-copyright
   19 ./gnulib/modules/update-copyright
   12 ./gnulib/modules/update-copyright-tests
  547 ./gnulib/tests/test-update-copyright.sh
  922 total

This is one of many many minor points why reading musl sources is much 
more fun than gnu sources. Please don't give up too many of these minor 
plus points.

cu,
Rudi

Re: musl licensing

[Kurt H Maier]

On Thu, Mar 17, 2016 at 05:31:48PM -0600, Anthony J. Bentley wrote:
> 
> Post-Berne no copyright statement is needed at all. Marking license
> terms, authors and dates in individual files is strictly a convenience
> factor for those using or reading the code.
> 

Yes.  However, musl has had more than one person express a desire for
per-file copyright notifications.  None of these people have expressed
interest in needlessly including a year.  With this information, we can
ask if 

/* Copyright the musl authors.  Available under a ___-style license, which
   can be found at http://git.musl-libc.org/cgit/musl/tree/COPYRIGHT */

would meet their needs.

Such a notice would minimize the amount of source-control noise, because
it would not need to be updated every year.  The license in question can
even be marked in a way that makes it easy for fossology et al. to
automatically classify data.  If you put the year in, no useful
information is added (that can't also be got from the source control
software) but the message will then require maintenance.

So, in this specific instance, I focused on the year alone as being
unnecessary, because the notification itself may (to some) be desireable
for other reasons.  I personally don't care if each file holds a
notification or not; I'll use musl either way.  But if we want to
satisfy the most people with the least maintenance load, it might be
worth considering.

khm

Re: musl licensing

[Rich Felker]

On Thu, Mar 17, 2016 at 11:30:38PM -0400, Kurt H Maier wrote:
> On Thu, Mar 17, 2016 at 05:31:48PM -0600, Anthony J. Bentley wrote:
> > 
> > Post-Berne no copyright statement is needed at all. Marking license
> > terms, authors and dates in individual files is strictly a convenience
> > factor for those using or reading the code.
> > 
> 
> Yes.  However, musl has had more than one person express a desire for
> per-file copyright notifications.  None of these people have expressed
> interest in needlessly including a year.  With this information, we can
> ask if 
> 
> /* Copyright the musl authors.  Available under a ___-style license, which
>    can be found at http://git.musl-libc.org/cgit/musl/tree/COPYRIGHT */
> 
> would meet their needs.

Generally I don't think people like (and I don't like) URL references
to licenses because there's no guarantee that they don't change or
linkrot. Referencing the copy in the top-level source tree COPYRIGHT
file avoids that but obviously doesn't meet the needs of someone
including it in another tree.

If Google's lawyers are happy without adding per-file notices (which I
haven't seen them asking for in any of the clarifying follow-up
emails; correct me if I'm wrong) then I think we should treat this as
a separate issue aside from trying to resolve the current license
concerns they have, and follow up on it later.

Rich

Re: musl licensing

[Christopher Lane]

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

On Mar 17, 2016 8:41 PM, "Rich Felker" <dalias@libc.org> wrote:
>
> On Thu, Mar 17, 2016 at 11:30:38PM -0400, Kurt H Maier wrote:
> > On Thu, Mar 17, 2016 at 05:31:48PM -0600, Anthony J. Bentley wrote:
> > >
> > > Post-Berne no copyright statement is needed at all. Marking license
> > > terms, authors and dates in individual files is strictly a convenience
> > > factor for those using or reading the code.
> > >
> >
> > Yes.  However, musl has had more than one person express a desire for
> > per-file copyright notifications.  None of these people have expressed
> > interest in needlessly including a year.  With this information, we can
> > ask if
> >
> > /* Copyright the musl authors.  Available under a ___-style license,
which
> >    can be found at http://git.musl-libc.org/cgit/musl/tree/COPYRIGHT */
> >
> > would meet their needs.
>
> Generally I don't think people like (and I don't like) URL references
> to licenses because there's no guarantee that they don't change or
> linkrot. Referencing the copy in the top-level source tree COPYRIGHT
> file avoids that but obviously doesn't meet the needs of someone
> including it in another tree.
>
> If Google's lawyers are happy without adding per-file notices (which I
> haven't seen them asking for in any of the clarifying follow-up
> emails; correct me if I'm wrong) then I think we should treat this as
> a separate issue aside from trying to resolve the current license
> concerns they have, and follow up on it later.
>
> Rich

I asked our lawyers about per-file headers. Yes, it's clearer if the files
have headers.  It's especially easier to copy on a per-file basis for
projects that need to do that.  But the feedback I got was that the text in
the COPYRIGHT file that says basically "anything without a header has the
MIT license above" is clear enough for us to use musl.  Having per-file
headers is not, IIUC a blocker for us.

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

Re: musl licensing

[Ed Maste]

On 17 March 2016 at 15:16, Rich Felker <dalias@libc.org> wrote:
>
> Indeed, I was thinking more along the lines of whether we're to the
> point that standard licenses could be referenced by name/identifier
> without an in-tree copy.

My reservation is that there are tools which scan source trees for
license statements, and they may not parse such a statement.

Also, generally speaking I think a phrase like "the MIT license" is
unambiguous and understood by everyone on this list, but that may not
be true a decade from now.

> I think our community tends to dislike files which are 20+ lines of
> copyright/license comments followed by <10 lines of code. Whether
> there are situations where the file size makes a practical difference,
> I don't know. One observation: on a standard-size terminal it's likely
> you wouldn't seen _any_ code on the first page with a full-license
> comment header.

I grew up in the BSD world so I'm used to it -- just jump down a page
after you open a source file :-)  I certainly understand the desire to
avoid it though.

From later in the thread,
> // Copyright 2016 The Chromium Authors. All rights reserved.
> // Use of this source code is governed by a BSD-style license that can be
> // found in the LICENSE file.

This seems to be a good compromise to me, even though it still needs
special treatment in my case of assembling software using portions of
code from different sources.

Re: musl licensing

[Luca Barbato]

On 17/03/16 20:16, Rich Felker wrote:
> I think our community tends to dislike files which are 20+ lines of
> copyright/license comments followed by <10 lines of code. Whether
> there are situations where the file size makes a practical difference,
> I don't know. One observation: on a standard-size terminal it's likely
> you wouldn't seen _any_ code on the first page with a full-license
> comment header.

Using something along the lines of http://spdx.org/licenses/ would be
acceptable?

I'm not 100% convinced about it myself but might be a good idea in the end.

> 
> Rich
> 

Re: musl licensing

[u-uy74]

On Thu, Mar 17, 2016 at 02:49:55PM -0400, Ed Maste wrote:
> From my perspective, my order of preference is full
> authorship + license, authorship + license statement, status quo. I do
> understand wanting to avoid the full license text though. Do other
> potential downstream consumers of musl have a preference?

(speaking for Dapty / Aetey)

The less legalese stuff in the source files the better.

A single authoritative license file for the whole package, covering all
the files is best.

Otherwise - am I assumed to actually have read and interpreted _every_
file to make sure I follow all the possible licenses and their variations??
(Isn't this the biggest lie of our time "I have read the license terms" ? :)

The authorship is different. You do not have to "agree" to it, so do
not _have_ to read it even if some licenses force you to duplicate
the authorship information at distribution.
Practically, while looking at the source, it is nice to to see in the
files who wrote which part of the code and when, even though this is
not a substitute for a modification log.

Rune

chromium with musl libc (was: [musl] musl licensing)

[Natanael Copa]

On Tue, 15 Mar 2016 14:59:24 -0700
Petr Hosek <phosek@chromium.org> wrote:

> We work on Chromium project at Google. Our team, as well as several
> other teams here at Google, would like to start using musl in various
> open-source projects. This includes shipping musl as a part of SDKs
> and toolchains.

This is very exciting!

Alpine Linux have built chromium against musl libc, but we had to patch
it a bit and i think it is currently broken.

I don't think the patches are good enough for upstream yet, but they
give an indication what needs fixing to make chromium build against
musl.

Patches are found here:
http://git.alpinelinux.org/cgit/aports/tree/community/chromium

Would be awesome if chromium would support musl libc officially.

-nc