Steve, what do you think of these proposed improvements?
Proposed rewrite for /ids:
WHY use SPDX IDs?
Sure, you've done what's necessary already by putting a full license
statement in your repository. But you make code reuse even easier by
adding this info tersely to every file, so others can determine easily
which licenses apply to a file. You'll reduce license clutter in
source code comments, eliminate error-prone parsing of license headers,
and decrease confusion by using the SPDX License List.
Proposed rewrite For ids/why:
SPDX IDs make code reuse easier.
Putting your license notice a top-level LICENSE.txt file is the bare
minimum needed to properly license your code. You'll make it easier for
those to reuse your code with a simple 'cp FILE /new/project' if you add
an SPDX ID to every file in your repository. An SPDX ID is located
within each source code or documentation file, and follows that file
into downstream projects, making license identification easier.
> On Thu, Apr 12, 2018 at 08:14:30PM -0700, Bradley M. Kuhn wrote:
> > I suggest modifying the tutorial at https://spdx.org/ids to address
> > the issue head-on, with perhaps a explanation on why you would carry
> > license information in individual files at all. The *only* reason
> > it's useful to do so is in case the file gets separated from its
> > larger work.
W. Trevor King wrote at 21:33 (PDT) on Thursday:
> This point is already addressed in [1] with:
> SPDX IDs make code reuse easier.
>
> If your project only has license info in a top-level LICENSE.txt
> file, it's harder for others to reuse your code.
This is not on the main page, which leaves it in TL;DR for most readers (if
the goal here is to make the "ids" page make the case on its own). Also,
the existing text overstates the issue and actually gives the opposite
impression -- that somehow there is a licensing problem if you don't do
file-by-file licensing inventory.
I redrafted below two proposals above to give the idea of what I'm talking
about.
The key issue is that when this kind of advice is given, it's important to
be clear this useful improved labeling, and *not* that there is a licensing
problem if you don't do it. Too much of the rhetoric around licensing
labeling gives that wrong impression, so it's really useful to mitigate that
wrong impression where we can. Overstating the issue only serves to make
SPDX look pedantic and alarmist.
--
Bradley M. Kuhn
Pls. support of the charity where I work, Software Freedom Conservancy:
https://sfconservancy.org/supporter/
_______________________________________________
Spdx-tech mailing list
[email protected]
https://lists.spdx.org/mailman/listinfo/spdx-tech
