[OT] Opinions about licensing approach for permissive/weak-copyleft projects

[Adriaan de Groot]

Hi Filipe,

On Tuesday, 17 November 2020 19:27:32 CET Filipe Saraiva wrote:
> The reviewer proposes an approach for software licensing. In summary,
> s/he believes that if the project is using exclusively permissive or
> weak copyleft licenses, there is no need to put a license for the entire
> project.

I'm having a lot of trouble figuring out what the actual proposal *is*. It may 
be getting lost in paraphrases (I commend you on being very careful and 
paraphrasing when asking about papers that are under review).

One question to ask is "how can we tell if a project is using exclusively 
permissive or weak copyleft licenses?" Actually, we could take a step back and 
ask what the relationship is between "project uses a license" and "license 
applies to a software product published by project". A single project may 
produce more than one software product (see KDE, for instance).

OK, but suppose we know that the software product is intended to be licensed 
under (permissive or weak-copyleft) license L.

> On his/her words: "You don't need to specify a package-level license.
> What you can do is put a "default" license to your package which would
> mean that in the absence of a license in a file, that file would be
> under this license. This allows not having to specify the license in all
> files (although that is the recommended way of doing things). Note that
> this default license should be permissive or weak copyleft."

This is confusing: a "package-level license" to me sounds like something that 
is not at file-level. And then a "default" license is .. a license that is not 
at file level.

So I read this as "you don't need an overall license for the product, just put 
an overall license on the product!" Combined with the assertion in your first 
paragraph that you don't need an overall license on the product, now I'm 
*doubly* confused.


Given the "This allows .." note, though, I'm going to think that the intended 
use is:

- don't tag each and every file with license L
- do put license L somewhere

This sounds exactly what .. everyone has been doing since the '90s? A top-
level COPYING file and then little or no notice in the files themselves. I 
think Andreas Cord-Landwehr has already spoken to that: that's exactly what we 
(as KDE) are trying to **stop** doing. The REUSE.software folks (as pointed 
out by CoLa) have a good write-up why.

Also, what's special about permissive or weak-copyleft that makes this a good 
idea for them, but not others?


> I understand that his/her suggestions make sense (this would allow novel
> tools to improve license visualization, like that color bar that GitHub
> uses for programming languages could be used),  but I also wonder
> whether this would make sense in practice (this would require that all
> source code files are properly licensed).

And this explanation turns it around completely again, to tagging each-and-
every-file. I'm now either triply- or quadruply- (depending on whether 
confusion is linear or quadratic) confused.

The guiding principle for license-tagging right now is:
- assume the file is the atomic level of software distribution
- license each file
- put the license information **in** the file if possible
- make the license information machine-readable

Deriving package-level license information or aggregated license information 
from files tagged well is .. well, not simple, but doable, as CoLa's tooling 
has shown.

Oh, and as far as REUSE.software and/or Debian licensing tools go, a dep5 file 
with

Files: *
License: CC0-1.0
Copyright: no

is the kind of "default license" that is being suggested, and I think that 
that's a **bad** idea for the individual contributor, who now has a blanket 
that they don't control and have not explicitly accepted, covering their code. 
Informed consent is, IMO, hard to demonstrate with that kind of blanket.

[ade]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20201120/6a8bd8e5/attachment.sig>