* musl licensing @ 2016-03-15 21:59 Petr Hosek 2016-03-15 22:17 ` croco ` (6 more replies) 0 siblings, 7 replies; 78+ messages in thread From: Petr Hosek @ 2016-03-15 21:59 UTC (permalink / raw) To: musl; +Cc: kulakowski 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-15 21:59 musl licensing Petr Hosek @ 2016-03-15 22:17 ` croco 2016-03-16 16:32 ` Alexander Cherepanov 2016-03-15 22:20 ` Kurt H Maier ` (5 subsequent siblings) 6 siblings, 1 reply; 78+ messages in thread From: croco @ 2016-03-15 22:17 UTC (permalink / raw) To: musl; +Cc: kulakowski 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-15 22:17 ` croco @ 2016-03-16 16:32 ` Alexander Cherepanov 2016-03-16 22:50 ` Petr Hosek 0 siblings, 1 reply; 78+ messages in thread From: Alexander Cherepanov @ 2016-03-16 16:32 UTC (permalink / raw) To: musl; +Cc: kulakowski, Petr Hosek 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-16 16:32 ` Alexander Cherepanov @ 2016-03-16 22:50 ` Petr Hosek 2016-03-16 22:55 ` Josiah Worcester ` (2 more replies) 0 siblings, 3 replies; 78+ messages in thread From: Petr Hosek @ 2016-03-16 22:50 UTC (permalink / raw) To: musl; +Cc: kulakowski [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-16 22:50 ` Petr Hosek @ 2016-03-16 22:55 ` Josiah Worcester 2016-03-16 23:46 ` Rich Felker 2016-03-17 1:26 ` Alexander Cherepanov 2 siblings, 0 replies; 78+ messages in thread From: Josiah Worcester @ 2016-03-16 22:55 UTC (permalink / raw) To: musl; +Cc: kulakowski [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-16 22:50 ` Petr Hosek 2016-03-16 22:55 ` Josiah Worcester @ 2016-03-16 23:46 ` Rich Felker 2016-03-17 2:06 ` Christopher Lane 2016-03-17 1:26 ` Alexander Cherepanov 2 siblings, 1 reply; 78+ messages in thread From: Rich Felker @ 2016-03-16 23:46 UTC (permalink / raw) To: Petr Hosek; +Cc: musl, kulakowski 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-16 23:46 ` Rich Felker @ 2016-03-17 2:06 ` Christopher Lane 2016-03-17 3:04 ` Rich Felker 2016-03-17 8:17 ` u-uy74 0 siblings, 2 replies; 78+ messages in thread From: Christopher Lane @ 2016-03-17 2:06 UTC (permalink / raw) To: musl; +Cc: Petr Hosek, kulakowski [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-17 2:06 ` Christopher Lane @ 2016-03-17 3:04 ` Rich Felker 2016-03-17 8:17 ` u-uy74 1 sibling, 0 replies; 78+ messages in thread From: Rich Felker @ 2016-03-17 3:04 UTC (permalink / raw) To: Christopher Lane; +Cc: musl, Petr Hosek, kulakowski 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-17 2:06 ` Christopher Lane 2016-03-17 3:04 ` Rich Felker @ 2016-03-17 8:17 ` u-uy74 2016-03-17 15:14 ` Christopher Lane 1 sibling, 1 reply; 78+ messages in thread From: u-uy74 @ 2016-03-17 8:17 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-17 8:17 ` u-uy74 @ 2016-03-17 15:14 ` Christopher Lane 2016-03-17 15:28 ` FRIGN ` (2 more replies) 0 siblings, 3 replies; 78+ messages in thread From: Christopher Lane @ 2016-03-17 15:14 UTC (permalink / raw) To: musl [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-17 15:14 ` Christopher Lane @ 2016-03-17 15:28 ` FRIGN 2016-03-17 15:49 ` Hugues Bruant 2016-03-17 16:01 ` Rich Felker 2016-03-18 8:31 ` u-uy74 2 siblings, 1 reply; 78+ messages in thread From: FRIGN @ 2016-03-17 15:28 UTC (permalink / raw) To: musl 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> ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-17 15:28 ` FRIGN @ 2016-03-17 15:49 ` Hugues Bruant 2016-03-17 15:57 ` Rich Felker 0 siblings, 1 reply; 78+ messages in thread From: Hugues Bruant @ 2016-03-17 15:49 UTC (permalink / raw) To: musl [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-17 15:49 ` Hugues Bruant @ 2016-03-17 15:57 ` Rich Felker 0 siblings, 0 replies; 78+ messages in thread From: Rich Felker @ 2016-03-17 15:57 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-17 15:14 ` Christopher Lane 2016-03-17 15:28 ` FRIGN @ 2016-03-17 16:01 ` Rich Felker 2016-03-17 23:32 ` Christopher Lane 2016-03-18 8:31 ` u-uy74 2 siblings, 1 reply; 78+ messages in thread From: Rich Felker @ 2016-03-17 16:01 UTC (permalink / raw) To: Christopher Lane; +Cc: musl 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-17 16:01 ` Rich Felker @ 2016-03-17 23:32 ` Christopher Lane 2016-03-18 4:21 ` Rich Felker 0 siblings, 1 reply; 78+ messages in thread From: Christopher Lane @ 2016-03-17 23:32 UTC (permalink / raw) To: Rich Felker; +Cc: musl [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-17 23:32 ` Christopher Lane @ 2016-03-18 4:21 ` Rich Felker 2016-03-18 4:47 ` Christopher Lane 2016-03-18 18:16 ` Christopher Lane 0 siblings, 2 replies; 78+ messages in thread From: Rich Felker @ 2016-03-18 4:21 UTC (permalink / raw) To: Christopher Lane; +Cc: musl 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-18 4:21 ` Rich Felker @ 2016-03-18 4:47 ` Christopher Lane 2016-03-18 18:07 ` Rich Felker 2016-03-18 18:16 ` Christopher Lane 1 sibling, 1 reply; 78+ messages in thread From: Christopher Lane @ 2016-03-18 4:47 UTC (permalink / raw) To: Rich Felker; +Cc: musl [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-18 4:47 ` Christopher Lane @ 2016-03-18 18:07 ` Rich Felker 0 siblings, 0 replies; 78+ messages in thread From: Rich Felker @ 2016-03-18 18:07 UTC (permalink / raw) To: Christopher Lane; +Cc: musl 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-18 4:21 ` Rich Felker 2016-03-18 4:47 ` Christopher Lane @ 2016-03-18 18:16 ` Christopher Lane 2016-03-18 19:12 ` Rich Felker 1 sibling, 1 reply; 78+ messages in thread From: Christopher Lane @ 2016-03-18 18:16 UTC (permalink / raw) To: Rich Felker; +Cc: musl [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-18 18:16 ` Christopher Lane @ 2016-03-18 19:12 ` Rich Felker 2016-03-18 19:47 ` George Kulakowski 0 siblings, 1 reply; 78+ messages in thread From: Rich Felker @ 2016-03-18 19:12 UTC (permalink / raw) To: Christopher Lane; +Cc: musl [-- 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-18 19:12 ` Rich Felker @ 2016-03-18 19:47 ` George Kulakowski 2016-03-19 4:35 ` Rich Felker 0 siblings, 1 reply; 78+ messages in thread From: George Kulakowski @ 2016-03-18 19:47 UTC (permalink / raw) To: musl, Christopher Lane [-- 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-18 19:47 ` George Kulakowski @ 2016-03-19 4:35 ` Rich Felker 2016-03-21 22:46 ` Christopher Lane 0 siblings, 1 reply; 78+ messages in thread From: Rich Felker @ 2016-03-19 4:35 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-19 4:35 ` Rich Felker @ 2016-03-21 22:46 ` Christopher Lane 2016-03-23 2:32 ` Rich Felker 0 siblings, 1 reply; 78+ messages in thread From: Christopher Lane @ 2016-03-21 22:46 UTC (permalink / raw) To: musl [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-21 22:46 ` Christopher Lane @ 2016-03-23 2:32 ` Rich Felker 2016-03-23 20:35 ` Christopher Lane 0 siblings, 1 reply; 78+ messages in thread From: Rich Felker @ 2016-03-23 2:32 UTC (permalink / raw) To: Christopher Lane; +Cc: musl 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-23 2:32 ` Rich Felker @ 2016-03-23 20:35 ` Christopher Lane 2016-03-23 22:53 ` Rob Landley 2016-03-29 17:21 ` Christopher Lane 0 siblings, 2 replies; 78+ messages in thread From: Christopher Lane @ 2016-03-23 20:35 UTC (permalink / raw) To: Rich Felker; +Cc: musl [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-23 20:35 ` Christopher Lane @ 2016-03-23 22:53 ` Rob Landley 2016-03-29 17:18 ` Christopher Lane 2016-03-29 17:21 ` Christopher Lane 1 sibling, 1 reply; 78+ messages in thread From: Rob Landley @ 2016-03-23 22:53 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-23 22:53 ` Rob Landley @ 2016-03-29 17:18 ` Christopher Lane 0 siblings, 0 replies; 78+ messages in thread From: Christopher Lane @ 2016-03-29 17:18 UTC (permalink / raw) To: musl [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-23 20:35 ` Christopher Lane 2016-03-23 22:53 ` Rob Landley @ 2016-03-29 17:21 ` Christopher Lane 2016-03-29 20:03 ` Rich Felker 2016-03-30 6:56 ` u-uy74 1 sibling, 2 replies; 78+ messages in thread From: Christopher Lane @ 2016-03-29 17:21 UTC (permalink / raw) To: Rich Felker; +Cc: musl [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-29 17:21 ` Christopher Lane @ 2016-03-29 20:03 ` Rich Felker 2016-03-29 20:21 ` Christopher Lane 2016-03-30 6:56 ` u-uy74 1 sibling, 1 reply; 78+ messages in thread From: Rich Felker @ 2016-03-29 20:03 UTC (permalink / raw) To: Christopher Lane; +Cc: musl 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-29 20:03 ` Rich Felker @ 2016-03-29 20:21 ` Christopher Lane 0 siblings, 0 replies; 78+ messages in thread From: Christopher Lane @ 2016-03-29 20:21 UTC (permalink / raw) To: Rich Felker; +Cc: musl [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-29 17:21 ` Christopher Lane 2016-03-29 20:03 ` Rich Felker @ 2016-03-30 6:56 ` u-uy74 2016-03-30 14:11 ` Christopher Lane 1 sibling, 1 reply; 78+ messages in thread From: u-uy74 @ 2016-03-30 6:56 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-30 6:56 ` u-uy74 @ 2016-03-30 14:11 ` Christopher Lane 2016-03-30 14:43 ` u-uy74 0 siblings, 1 reply; 78+ messages in thread From: Christopher Lane @ 2016-03-30 14:11 UTC (permalink / raw) To: musl [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-30 14:11 ` Christopher Lane @ 2016-03-30 14:43 ` u-uy74 0 siblings, 0 replies; 78+ messages in thread From: u-uy74 @ 2016-03-30 14:43 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-17 15:14 ` Christopher Lane 2016-03-17 15:28 ` FRIGN 2016-03-17 16:01 ` Rich Felker @ 2016-03-18 8:31 ` u-uy74 2 siblings, 0 replies; 78+ messages in thread From: u-uy74 @ 2016-03-18 8:31 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-16 22:50 ` Petr Hosek 2016-03-16 22:55 ` Josiah Worcester 2016-03-16 23:46 ` Rich Felker @ 2016-03-17 1:26 ` Alexander Cherepanov 2016-03-17 2:20 ` Christopher Lane 2 siblings, 1 reply; 78+ messages in thread From: Alexander Cherepanov @ 2016-03-17 1:26 UTC (permalink / raw) To: musl; +Cc: kulakowski, Petr Hosek 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-17 1:26 ` Alexander Cherepanov @ 2016-03-17 2:20 ` Christopher Lane 0 siblings, 0 replies; 78+ messages in thread From: Christopher Lane @ 2016-03-17 2:20 UTC (permalink / raw) To: musl; +Cc: kulakowski, Petr Hosek [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-15 21:59 musl licensing Petr Hosek 2016-03-15 22:17 ` croco @ 2016-03-15 22:20 ` Kurt H Maier 2016-03-15 22:20 ` Josiah Worcester ` (4 subsequent siblings) 6 siblings, 0 replies; 78+ messages in thread From: Kurt H Maier @ 2016-03-15 22:20 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-15 21:59 musl licensing Petr Hosek 2016-03-15 22:17 ` croco 2016-03-15 22:20 ` Kurt H Maier @ 2016-03-15 22:20 ` Josiah Worcester 2016-03-15 22:41 ` Rich Felker ` (3 subsequent siblings) 6 siblings, 0 replies; 78+ messages in thread From: Josiah Worcester @ 2016-03-15 22:20 UTC (permalink / raw) To: musl; +Cc: kulakowski, phosek [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-15 21:59 musl licensing Petr Hosek ` (2 preceding siblings ...) 2016-03-15 22:20 ` Josiah Worcester @ 2016-03-15 22:41 ` Rich Felker 2016-03-15 22:49 ` Shiz ` (3 more replies) 2016-03-16 10:22 ` FRIGN ` (2 subsequent siblings) 6 siblings, 4 replies; 78+ messages in thread From: Rich Felker @ 2016-03-15 22:41 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-15 22:41 ` Rich Felker @ 2016-03-15 22:49 ` Shiz 2016-03-16 4:54 ` Isaac Dunham ` (2 subsequent siblings) 3 siblings, 0 replies; 78+ messages in thread From: Shiz @ 2016-03-15 22:49 UTC (permalink / raw) To: musl [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-15 22:41 ` Rich Felker 2016-03-15 22:49 ` Shiz @ 2016-03-16 4:54 ` Isaac Dunham 2016-03-16 8:00 ` u-uy74 2016-03-16 10:31 ` Szabolcs Nagy 3 siblings, 0 replies; 78+ messages in thread From: Isaac Dunham @ 2016-03-16 4:54 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-15 22:41 ` Rich Felker 2016-03-15 22:49 ` Shiz 2016-03-16 4:54 ` Isaac Dunham @ 2016-03-16 8:00 ` u-uy74 2016-03-16 10:31 ` Szabolcs Nagy 3 siblings, 0 replies; 78+ messages in thread From: u-uy74 @ 2016-03-16 8:00 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-15 22:41 ` Rich Felker ` (2 preceding siblings ...) 2016-03-16 8:00 ` u-uy74 @ 2016-03-16 10:31 ` Szabolcs Nagy 2016-03-16 10:55 ` FRIGN 3 siblings, 1 reply; 78+ messages in thread From: Szabolcs Nagy @ 2016-03-16 10:31 UTC (permalink / raw) To: musl * 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-16 10:31 ` Szabolcs Nagy @ 2016-03-16 10:55 ` FRIGN 2016-03-16 12:34 ` Szabolcs Nagy 0 siblings, 1 reply; 78+ messages in thread From: FRIGN @ 2016-03-16 10:55 UTC (permalink / raw) To: musl 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> ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-16 10:55 ` FRIGN @ 2016-03-16 12:34 ` Szabolcs Nagy 2016-03-16 12:46 ` Anthony J. Bentley 2016-03-16 14:01 ` FRIGN 0 siblings, 2 replies; 78+ messages in thread From: Szabolcs Nagy @ 2016-03-16 12:34 UTC (permalink / raw) To: musl * 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-16 12:34 ` Szabolcs Nagy @ 2016-03-16 12:46 ` Anthony J. Bentley 2016-03-16 13:49 ` u-uy74 2016-03-16 14:01 ` FRIGN 1 sibling, 1 reply; 78+ messages in thread From: Anthony J. Bentley @ 2016-03-16 12:46 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-16 12:46 ` Anthony J. Bentley @ 2016-03-16 13:49 ` u-uy74 2016-03-16 14:07 ` FRIGN 0 siblings, 1 reply; 78+ messages in thread From: u-uy74 @ 2016-03-16 13:49 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-16 13:49 ` u-uy74 @ 2016-03-16 14:07 ` FRIGN 0 siblings, 0 replies; 78+ messages in thread From: FRIGN @ 2016-03-16 14:07 UTC (permalink / raw) To: musl 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> ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-16 12:34 ` Szabolcs Nagy 2016-03-16 12:46 ` Anthony J. Bentley @ 2016-03-16 14:01 ` FRIGN 2016-03-16 14:47 ` Szabolcs Nagy 1 sibling, 1 reply; 78+ messages in thread From: FRIGN @ 2016-03-16 14:01 UTC (permalink / raw) To: musl 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> ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-16 14:01 ` FRIGN @ 2016-03-16 14:47 ` Szabolcs Nagy 0 siblings, 0 replies; 78+ messages in thread From: Szabolcs Nagy @ 2016-03-16 14:47 UTC (permalink / raw) To: musl * 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). ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-15 21:59 musl licensing Petr Hosek ` (3 preceding siblings ...) 2016-03-15 22:41 ` Rich Felker @ 2016-03-16 10:22 ` FRIGN 2016-03-16 20:13 ` Rich Felker 2016-03-18 12:35 ` chromium with musl libc (was: [musl] musl licensing) Natanael Copa 6 siblings, 0 replies; 78+ messages in thread From: FRIGN @ 2016-03-16 10:22 UTC (permalink / raw) To: musl; +Cc: phosek 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> ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-15 21:59 musl licensing Petr Hosek ` (4 preceding siblings ...) 2016-03-16 10:22 ` FRIGN @ 2016-03-16 20:13 ` Rich Felker 2016-03-16 20:19 ` FRIGN 2016-03-18 12:35 ` chromium with musl libc (was: [musl] musl licensing) Natanael Copa 6 siblings, 1 reply; 78+ messages in thread From: Rich Felker @ 2016-03-16 20:13 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-16 20:13 ` Rich Felker @ 2016-03-16 20:19 ` FRIGN 2016-03-16 20:34 ` Rich Felker 0 siblings, 1 reply; 78+ messages in thread From: FRIGN @ 2016-03-16 20:19 UTC (permalink / raw) To: musl 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> ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-16 20:19 ` FRIGN @ 2016-03-16 20:34 ` Rich Felker 2016-03-16 21:11 ` Jens Gustedt ` (4 more replies) 0 siblings, 5 replies; 78+ messages in thread From: Rich Felker @ 2016-03-16 20:34 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-16 20:34 ` Rich Felker @ 2016-03-16 21:11 ` Jens Gustedt 2016-03-16 21:15 ` FRIGN ` (3 subsequent siblings) 4 siblings, 0 replies; 78+ messages in thread From: Jens Gustedt @ 2016-03-16 21:11 UTC (permalink / raw) To: musl [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-16 20:34 ` Rich Felker 2016-03-16 21:11 ` Jens Gustedt @ 2016-03-16 21:15 ` FRIGN 2016-03-16 21:35 ` Rich Felker 2016-03-16 21:34 ` John Levine ` (2 subsequent siblings) 4 siblings, 1 reply; 78+ messages in thread From: FRIGN @ 2016-03-16 21:15 UTC (permalink / raw) To: musl 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> ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-16 21:15 ` FRIGN @ 2016-03-16 21:35 ` Rich Felker 2016-03-16 21:50 ` FRIGN 0 siblings, 1 reply; 78+ messages in thread From: Rich Felker @ 2016-03-16 21:35 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-16 21:35 ` Rich Felker @ 2016-03-16 21:50 ` FRIGN 0 siblings, 0 replies; 78+ messages in thread From: FRIGN @ 2016-03-16 21:50 UTC (permalink / raw) To: musl 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> ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-16 20:34 ` Rich Felker 2016-03-16 21:11 ` Jens Gustedt 2016-03-16 21:15 ` FRIGN @ 2016-03-16 21:34 ` John Levine 2016-03-16 21:38 ` Christopher Lane 2016-03-17 2:01 ` Ed Maste 4 siblings, 0 replies; 78+ messages in thread From: John Levine @ 2016-03-16 21:34 UTC (permalink / raw) To: musl >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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-16 20:34 ` Rich Felker ` (2 preceding siblings ...) 2016-03-16 21:34 ` John Levine @ 2016-03-16 21:38 ` Christopher Lane 2016-03-17 2:01 ` Ed Maste 4 siblings, 0 replies; 78+ messages in thread From: Christopher Lane @ 2016-03-16 21:38 UTC (permalink / raw) To: musl [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-16 20:34 ` Rich Felker ` (3 preceding siblings ...) 2016-03-16 21:38 ` Christopher Lane @ 2016-03-17 2:01 ` Ed Maste 2016-03-17 3:19 ` Rich Felker 4 siblings, 1 reply; 78+ messages in thread From: Ed Maste @ 2016-03-17 2:01 UTC (permalink / raw) To: musl 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-17 2:01 ` Ed Maste @ 2016-03-17 3:19 ` Rich Felker 2016-03-17 18:49 ` Ed Maste 0 siblings, 1 reply; 78+ messages in thread From: Rich Felker @ 2016-03-17 3:19 UTC (permalink / raw) To: Ed Maste; +Cc: musl 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-17 3:19 ` Rich Felker @ 2016-03-17 18:49 ` Ed Maste 2016-03-17 19:16 ` Rich Felker 2016-03-18 8:01 ` u-uy74 0 siblings, 2 replies; 78+ messages in thread From: Ed Maste @ 2016-03-17 18:49 UTC (permalink / raw) To: musl 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? ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-17 18:49 ` Ed Maste @ 2016-03-17 19:16 ` Rich Felker 2016-03-17 21:16 ` Wink Saville ` (2 more replies) 2016-03-18 8:01 ` u-uy74 1 sibling, 3 replies; 78+ messages in thread From: Rich Felker @ 2016-03-17 19:16 UTC (permalink / raw) To: Ed Maste; +Cc: musl 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-17 19:16 ` Rich Felker @ 2016-03-17 21:16 ` Wink Saville 2016-03-17 21:25 ` Petr Hosek 2016-03-17 21:42 ` Ed Maste 2016-03-17 23:37 ` Luca Barbato 2 siblings, 1 reply; 78+ messages in thread From: Wink Saville @ 2016-03-17 21:16 UTC (permalink / raw) To: musl; +Cc: Ed Maste 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-17 21:16 ` Wink Saville @ 2016-03-17 21:25 ` Petr Hosek 2016-03-17 22:56 ` Ruediger Meier 0 siblings, 1 reply; 78+ messages in thread From: Petr Hosek @ 2016-03-17 21:25 UTC (permalink / raw) To: musl [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-17 21:25 ` Petr Hosek @ 2016-03-17 22:56 ` Ruediger Meier 2016-03-17 23:07 ` Anthony J. Bentley 0 siblings, 1 reply; 78+ messages in thread From: Ruediger Meier @ 2016-03-17 22:56 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-17 22:56 ` Ruediger Meier @ 2016-03-17 23:07 ` Anthony J. Bentley 2016-03-17 23:19 ` Kurt H Maier 0 siblings, 1 reply; 78+ messages in thread From: Anthony J. Bentley @ 2016-03-17 23:07 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-17 23:07 ` Anthony J. Bentley @ 2016-03-17 23:19 ` Kurt H Maier 2016-03-17 23:31 ` Anthony J. Bentley 0 siblings, 1 reply; 78+ messages in thread From: Kurt H Maier @ 2016-03-17 23:19 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-17 23:19 ` Kurt H Maier @ 2016-03-17 23:31 ` Anthony J. Bentley 2016-03-17 23:46 ` Ruediger Meier 2016-03-18 3:30 ` Kurt H Maier 0 siblings, 2 replies; 78+ messages in thread From: Anthony J. Bentley @ 2016-03-17 23:31 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-17 23:31 ` Anthony J. Bentley @ 2016-03-17 23:46 ` Ruediger Meier 2016-03-18 3:30 ` Kurt H Maier 1 sibling, 0 replies; 78+ messages in thread From: Ruediger Meier @ 2016-03-17 23:46 UTC (permalink / raw) To: musl; +Cc: Anthony J. Bentley 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-17 23:31 ` Anthony J. Bentley 2016-03-17 23:46 ` Ruediger Meier @ 2016-03-18 3:30 ` Kurt H Maier 2016-03-18 3:41 ` Rich Felker 1 sibling, 1 reply; 78+ messages in thread From: Kurt H Maier @ 2016-03-18 3:30 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-18 3:30 ` Kurt H Maier @ 2016-03-18 3:41 ` Rich Felker 2016-03-18 3:55 ` Christopher Lane 0 siblings, 1 reply; 78+ messages in thread From: Rich Felker @ 2016-03-18 3:41 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-18 3:41 ` Rich Felker @ 2016-03-18 3:55 ` Christopher Lane 0 siblings, 0 replies; 78+ messages in thread From: Christopher Lane @ 2016-03-18 3:55 UTC (permalink / raw) To: musl [-- 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 --] ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-17 19:16 ` Rich Felker 2016-03-17 21:16 ` Wink Saville @ 2016-03-17 21:42 ` Ed Maste 2016-03-17 23:37 ` Luca Barbato 2 siblings, 0 replies; 78+ messages in thread From: Ed Maste @ 2016-03-17 21:42 UTC (permalink / raw) To: musl 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-17 19:16 ` Rich Felker 2016-03-17 21:16 ` Wink Saville 2016-03-17 21:42 ` Ed Maste @ 2016-03-17 23:37 ` Luca Barbato 2 siblings, 0 replies; 78+ messages in thread From: Luca Barbato @ 2016-03-17 23:37 UTC (permalink / raw) To: musl 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 > ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: musl licensing 2016-03-17 18:49 ` Ed Maste 2016-03-17 19:16 ` Rich Felker @ 2016-03-18 8:01 ` u-uy74 1 sibling, 0 replies; 78+ messages in thread From: u-uy74 @ 2016-03-18 8:01 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* chromium with musl libc (was: [musl] musl licensing) 2016-03-15 21:59 musl licensing Petr Hosek ` (5 preceding siblings ...) 2016-03-16 20:13 ` Rich Felker @ 2016-03-18 12:35 ` Natanael Copa 6 siblings, 0 replies; 78+ messages in thread From: Natanael Copa @ 2016-03-18 12:35 UTC (permalink / raw) To: Petr Hosek; +Cc: musl, kulakowski 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
end of thread, other threads:[~2016-03-30 14:43 UTC | newest] Thread overview: 78+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-03-15 21:59 musl licensing Petr Hosek 2016-03-15 22:17 ` croco 2016-03-16 16:32 ` Alexander Cherepanov 2016-03-16 22:50 ` Petr Hosek 2016-03-16 22:55 ` Josiah Worcester 2016-03-16 23:46 ` Rich Felker 2016-03-17 2:06 ` Christopher Lane 2016-03-17 3:04 ` Rich Felker 2016-03-17 8:17 ` u-uy74 2016-03-17 15:14 ` Christopher Lane 2016-03-17 15:28 ` FRIGN 2016-03-17 15:49 ` Hugues Bruant 2016-03-17 15:57 ` Rich Felker 2016-03-17 16:01 ` Rich Felker 2016-03-17 23:32 ` Christopher Lane 2016-03-18 4:21 ` Rich Felker 2016-03-18 4:47 ` Christopher Lane 2016-03-18 18:07 ` Rich Felker 2016-03-18 18:16 ` Christopher Lane 2016-03-18 19:12 ` Rich Felker 2016-03-18 19:47 ` George Kulakowski 2016-03-19 4:35 ` Rich Felker 2016-03-21 22:46 ` Christopher Lane 2016-03-23 2:32 ` Rich Felker 2016-03-23 20:35 ` Christopher Lane 2016-03-23 22:53 ` Rob Landley 2016-03-29 17:18 ` Christopher Lane 2016-03-29 17:21 ` Christopher Lane 2016-03-29 20:03 ` Rich Felker 2016-03-29 20:21 ` Christopher Lane 2016-03-30 6:56 ` u-uy74 2016-03-30 14:11 ` Christopher Lane 2016-03-30 14:43 ` u-uy74 2016-03-18 8:31 ` u-uy74 2016-03-17 1:26 ` Alexander Cherepanov 2016-03-17 2:20 ` Christopher Lane 2016-03-15 22:20 ` Kurt H Maier 2016-03-15 22:20 ` Josiah Worcester 2016-03-15 22:41 ` Rich Felker 2016-03-15 22:49 ` Shiz 2016-03-16 4:54 ` Isaac Dunham 2016-03-16 8:00 ` u-uy74 2016-03-16 10:31 ` Szabolcs Nagy 2016-03-16 10:55 ` FRIGN 2016-03-16 12:34 ` Szabolcs Nagy 2016-03-16 12:46 ` Anthony J. Bentley 2016-03-16 13:49 ` u-uy74 2016-03-16 14:07 ` FRIGN 2016-03-16 14:01 ` FRIGN 2016-03-16 14:47 ` Szabolcs Nagy 2016-03-16 10:22 ` FRIGN 2016-03-16 20:13 ` Rich Felker 2016-03-16 20:19 ` FRIGN 2016-03-16 20:34 ` Rich Felker 2016-03-16 21:11 ` Jens Gustedt 2016-03-16 21:15 ` FRIGN 2016-03-16 21:35 ` Rich Felker 2016-03-16 21:50 ` FRIGN 2016-03-16 21:34 ` John Levine 2016-03-16 21:38 ` Christopher Lane 2016-03-17 2:01 ` Ed Maste 2016-03-17 3:19 ` Rich Felker 2016-03-17 18:49 ` Ed Maste 2016-03-17 19:16 ` Rich Felker 2016-03-17 21:16 ` Wink Saville 2016-03-17 21:25 ` Petr Hosek 2016-03-17 22:56 ` Ruediger Meier 2016-03-17 23:07 ` Anthony J. Bentley 2016-03-17 23:19 ` Kurt H Maier 2016-03-17 23:31 ` Anthony J. Bentley 2016-03-17 23:46 ` Ruediger Meier 2016-03-18 3:30 ` Kurt H Maier 2016-03-18 3:41 ` Rich Felker 2016-03-18 3:55 ` Christopher Lane 2016-03-17 21:42 ` Ed Maste 2016-03-17 23:37 ` Luca Barbato 2016-03-18 8:01 ` u-uy74 2016-03-18 12:35 ` chromium with musl libc (was: [musl] musl licensing) Natanael Copa
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).