Re: FreeBSD Use Case for Short Identifiers
Warner Losh
On Fri, Apr 2, 2021 at 9:27 AM Sebastian <seabass-labrax@...> wrote: Dear Warner, Thanks for the feedback. I'll take a look at this. The policy seems really similar to the REUSE standard [1] for licensing I did have one question about REUSE. At one point it says: "To implement this method, each plain text file that can contain comments MUST contain comments at the top of the file (comment header) that declare that file’s Copyright and Licensing Information." and a little later: "The SPDX-License-Identifier tag MUST be followed by a valid SPDX License Expression describing the licensing of the file (example: SPDX-License-Identifier: GPL-3.0-or-later OR Apache-2.0). If separate sections of the file are licensed differently, a different SPDX-License-Identifier tag MUST be included for each section." These seem to contradict a little since you need to associate the copyright with the license, I'd think. Not sure how big a deal it is, but it was confusing to me. In particular, section 2.4 would become unnecessary with REUSE. One of True. It's a substantial burden to get to that point before adopting the rest of the system. That said, it is a good long-term goal and one that we can enforce in the pre-commit checks. At the moment, we have ~25k of the ~95k files in our tree with SPDX tags. It will be quite some time before we get everything marked. In the meantime, we'd hoped to use the short form to nip in the bud the number of variants that pop up as people cut and paste and then tweak things. Copyright notices, however, are much better represented. We have ~6k Makefiles w/o marking, and maybe a few thousand more that are mostly (but not entirely) tests or other files that don't go into the build or whose format cannot tolerate comments. Part of this effort, long term, is to clean all that up, but it can't have it gating the other stuff. Our 'Beer-ware' licensed files may fall into the unenforceable category... Finally, I also have a few minor suggestions. Copyright licenses aren't As a non-legal person, avoiding 'contract' and using 'document' is likely better since this policy is designed for clarity and anything that gets in the way of that clarity isn't so good. I've chatted with several corporate lawyers over the years who have a different analysis than Dr. Moglen. It's likely better to avoid the issue since I'm not a legal professional and should stay out of any such fights. Personally, I would remove sections 3 and 4 entirely and link to a Sections 3 & 4 are supposed to be 'what to do' while 1&2 are 'how to do it'. They are currently in 3 different docs, all of which are slightly different in ways that are more annoying than practically bad... I worry that having these things relegated to another document would exacerbate the issue with things being out of sync. Finally, it occurs to me that full adoption of SPDX license identifiers, Ah, that's above my pay grade :) I'll keep that in mind and chat with our PR folks about it, though. Warner Best wishes, |
|