SPDX License Identifier Only and Full Copy?

Fri Feb 21 14:06:59 UTC 2020

On Fri, Feb 21, 2020 at 2:31 AM Thomas Doerfler <
thomas.doerfler at embedded-brains.de> wrote:

> Hello,
>
> I think the GPL and the BSD licenses had a different approach from the
> start:
> - GPL always came with a separate "COPYING" file (and the GPL sources
> pointed to it)
> - BSD always/most of the times was included in the headers
>
> Lokking at how the linux kernel team handles this therefore only has a
> limited weight. So I tend to keep the BSD license text in the source
> code files.
>
> Keep in mind: We want to make sure the license topic is properly handled
> and clear. What is the harm to be conservative here and spend some extra
> lines of header in the files?
>
> Kind regards,
> Thomas.
>
> Am 21.02.20 um 02:15 schrieb Chris Johns:
> >
> >
> > On 21/2/20 12:11 pm, Joel Sherrill wrote:
> >>
> >>
> >> On Thu, Feb 20, 2020, 3:49 PM Chris Johns <chrisj at rtems.org
> >> <mailto:chrisj at rtems.org>> wrote:
> >>
> >>     On 21/2/20 3:20 am, Gedare Bloom wrote:
> >>     > On Thu, Feb 20, 2020 at 12:58 AM Thomas Doerfler
> >>     > <thomas.doerfler at embedded-brains.de
> >>     <mailto:thomas.doerfler at embedded-brains.de>> wrote:
> >>     >>
> >>     >> Hello,
> >>     >>
> >>     >> I just want to speak up here. I talked with Sebastian today and
> I really
> >>     >> tend to keep the license text in each file.
> >>     >>
> >>     >> Rational:
> >>     >>
> >>     >> - With the BSD license, anyone can pick any file from the RTEMS
> repo and
> >>     >> use/modify it in any project (and this is fine). The original
> authors
> >>     >> (and their copyright) are listed in the file, but the only
> pointer to
> >>     >> the legal part is the "SPDX identifier". I am not sure whether
> this is a
> >>     >> legally binding "tag" and whether this tag is clear to any user.
> >>     >>
> >>     >> - Strictly seen, it is not even forbidden to remove the "SPDX
> >>     >> identifier", because it is not part of the BSD-2-clause-license,
> it's
> >>     >> just a pointer to it. In the end we might result in code
> drifting around
> >>     >> without license information, which we all do not want to see.
> >>     >>
> >>     > This is a valid point. I also have no desire to be a lawyer.
> >>     >
> >>     > My intuition here is that, even without any licensing information
> at
> >>     > all in individual files, one can still apply a single license to
> an
> >>     > entire repository, e.g., BSD or GPL. For historical reasons, and
> >>     > similar arguments as you've made, BSD-style licenses have tended
> to be
> >>     > copy-pasted to individual files to make them easier to excerpt. We
> >>     > don't have license uniformity, so we do need to individually
> specify
> >>     > which license(s) apply to each file.
> >>
> >>     This makes sense. The simplified BSD license states ...
> >>
> >>      1. Redistributions of source code must retain the above copyright
> >>         notice, this list of conditions and the following disclaimer.
> >>
> >>     I do not see how we can centralise this and have the "above
> copyright" work?
> >>     Also the SPDX site here ...
> >>
> >>      https://spdx.org/ids-how
> >>
> >>     ... under the heading "Standard license headers" states ...
> >>
> >>      When a license defines a recommended notice to attach to files
> >>      under that license (sometimes called a "standard header"), the SPDX
> >>      project recommends that the standard header be included in the
> files,
> >>      in addition to an SPDX ID.
> >>
> >>     My reading of this means we should include the license in the
> source.
> >>
> >>     We need to consider compliance and machine auditing of the source.
> The SPDX tag
> >>     is important. Maybe ...
> >>
> >>     /*
> >>      * SPDX tag suff
> >>      */
> >>     /*
> >>      * Copyright stuff
> >>      *
> >>      * 2-Clause BSD license
> >>      */
> >>
> >>     > Linux follows a similar philosophy as Sebastian suggests. I think
> we
> >>     > can also follow Linux in this regards.
> >>     > https://www.kernel.org/doc/html/latest/process/license-rules.html
> >>     >
> >>     > I would suggest we follow their approach to self-document the
> licenses
> >>     > centrally. I suspect the risk of someone using code without
> adhering
> >>     > to the license is no greater. Probably they have a higher risk
> >>     > exposure than we do!
> >>
> >>     I agree with the comments in the Linux license rules text about
> license text in
> >>     files making it harder to check for compliance.
> >>
> >>
> >> Following Linux is probably a safe approach. I assume there was
> significant
> >> legal review of their policy.
> >
> > Does the Linux kernel rules apply to the 2 clause BSD license we have?
>

I am surprised no one thought to look at FreeBSD for similar advice. :)

https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/pref-license.html

The example there has SPDX and license in the same comment block. Repeating
the text of the license in each file apparently.

The GPL is too long to repeat in a file. The best you could do is a state
like "under GPLv2
seen at XXX".

I think we should following the FreeBSD guidance. Whether the license or
Doxygen @file
is first is a different issue. I personally like the @file first. They
aren't usually very long and
the license is visible when you open the file.  If someone can find another
project's example
including both, that would be nice to see.

Seeing the license when I open a file tells me nothing about the file and
then I have to
page down to see the comment. Perhaps I'm just old and telling you to get
off my lawn
though. :)

--joel

> >
> > Chris
> >
>
> --
> --------------------------------------------
> embedded brains GmbH
> Thomas Doerfler
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: Thomas.Doerfler at embedded-brains.de
> Phone: +49-89-18 94 741-12
> Fax:   +49-89-18 94 741-09
> PGP: Public key available on request.
> For our privacy statement, see
> https://embedded-brains.de/en/data-privacy-statement/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200221/5401c3d7/attachment.html>