SPDX License Identifier Only and Full Copy?

Gedare Bloom gedare at rtems.org
Thu Feb 20 16:20:39 UTC 2020


On Thu, Feb 20, 2020 at 12:58 AM Thomas Doerfler
<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.

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!

> As you all know I am not a lawyer (and don't want to be), but my gut
> say's the extra lines in the top of each file are worth their storage.
> And anybody opening a RTEMS source file (even when it has been taken to
> a different project) should see what he has.
>
> ---------
>
> If you have different reasons to replace the header and just leave the
> identifier I a will go with it and it's fine for me. But my tendency
> is... leave it in.
>
> Kind regards,
>
> Thomas.
>
> Am 20.02.20 um 08:30 schrieb Sebastian Huber:
> > Hello,
> >
> > On 18/02/2020 16:58, Gedare Bloom wrote:
> >>>>> I suggest to use a master COPYING file and use file headers without
> >>>>> the
> >>>>> full license text.
> >>>>>
> >>>>> https://lists.rtems.org/pipermail/devel/2018-December/024198.html
> >>>> It would be nice to get some feedback here.
> >>>
> >>> I'm generally ok with just the spdx and copyright statements.
> >>>
> >> I'm also fine with the master COPYING, spdx-tag, and individual
> >> copyrights in files.
> >>
> >> I should make a note to take a pass over "my" files to relicense them.
> >> Does anyone have any script/tools for making that easy?
> >
> > I talked with Thomas and he is not in favour of a removal of the licence
> > text. Not everyone knows what an SPDX-Licence-Identifier is and that
> > this means the file is covered by the reference license. The
> > BSD-2-Clause license text is quite clear and not long. For us it is
> > important that it is very clear that our contributions are without
> > warranties and so on. This information should be also clear if files are
> > transferred out of the RTEMS context to other projects.
> >
>
> --
> --------------------------------------------
> 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/
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel


More information about the devel mailing list