Re: FreeBSD Use Case for Short Identifiers


Warner Losh
 



On Fri, Apr 2, 2021 at 9:27 AM Sebastian <seabass-labrax@...> wrote:
Dear Warner,

I've read the policy draft you've written; clearly you have given this
lots of thought already. I'd like to offer my take on it:

Thanks for the feedback. I'll take a look at this.
 
The policy seems really similar to the REUSE standard [1] for licensing
notices, which combines the SPDX license list with a convention for
where and how to put these notices in the source tree. Given that your
draft policy has many of the same objectives as REUSE, you might want to
consider adopting the REUSE standard fully, as it would allow you to use
existing tools to check and add these notices. It also allows you to
generate SPDX documents automatically, if that is something you are
interested in.

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
the principles of the specification is to provide copyright and license
notices for *all* files, even if that license may be unenforceable. As
the BSD license has very few requirements, it shouldn't be hard for
distributors to comply with it anyway. Again, if all files (even the
trivial ones!) are supposed to have SPDX notices, it would be very easy
to spot the files missing them.

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
necessarily contracts as stated in section 2; I think that part one of
the short essay 'Free Software Matters: Enforcing the GPL' by Eben
Moglen [2] is particularly good at describing the essence of software
licenses.

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
separate document describing those policies. I sometimes find it
confusing when projects have multiple documents explaining the same
thing, and it also increases the risk of contradictions when one is
updated but not others.

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,
if you decided to choose that path, would be the perfect topic for a
joint press release - maybe something to discuss in the future :)

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,

Sebastian

[1]: https://reuse.software/
[2]: http://emoglen.law.columbia.edu/publications/lu-12.pdf





Join Spdx-legal@lists.spdx.org to automatically receive all group messages.