From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B71CA385043A; Mon, 30 May 2022 16:24:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B71CA385043A From: "richard.purdie at linuxfoundation dot org" To: glibc-bugs@sourceware.org Subject: [Bug libc/28007] Add SPDX license identifiers Date: Mon, 30 May 2022 16:24:06 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: richard.purdie at linuxfoundation dot org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2022 16:24:06 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28007 --- Comment #12 from richard.purdie at linuxfoundation dot org --- (In reply to Florian Weimer from comment #11) > (In reply to richard.purdie from comment #8) > Based on that, I don't think you actually need per-file SPDX identifiers. > One file with all the identifiers that to pertain to any code in glibc > should be sufficient for analysis tooling to pick them up. >=20 > I think this would avoid the future maintenance burden. We can also clari= fy > that we (as the project maintainers) believe that the SPDX identifiers ar= e a > convenient approximation to the actual licensing state of glibc for use w= ith > SPDX tools, but may not be completely accurate. We did deal with a project where every source file was licensed with GPL-2 except for one file that was GPL-3.0. We could prove programmatically which output binaries had that GPL-3.0 file and which did not. We are being asked similar questions about the glibc output binaries now it is under multiple licenses. We (as in Ycoto Project) can make our best guesses about what license files= are under but it would be nice to share that information with others in the upstream rather that everyone making guesses. We're being asked to accept it within Yocto Project so that multiple users don't maintain it themselves. I'd hope the burden on developers isn't high, in general licenses tend to be more straight forward now and more consistent within projects. I'd hope it actually encourages that over time. FWIW I can also speak as a maintainer of projects which have adopted them a= nd I find it does simplify things a lot from my perspective. --=20 You are receiving this mail because: You are on the CC list for the bug.=