Re: [Repo-criteria-discuss] B2 for Gitlab?

[Mike Gerwitz]

On Sun, May 01, 2016 at 18:46:47 +0200, Sytse 'Sid' Sijbrandij wrote:
> Personally I think that just a license file in the project can be
> sufficient if you use version control that keeps the files together
> and discoverable.

It's easy for a source file to become separated from others: files may
be copied to another project, for example, or may simply be separated on
a filesystem or website.  If that file does not have its own copyright
and license header, then it's origin and license will be incorrectly
assumed to be that of the project that received it; if there is no
containing project, then it's in a state of licensing limbo: effectively
proprietary unless its origin can be discerned (works are proprietary by
default unless rights are granted back by the author, so the absence of
such a notice means all rights are reserved).

A project might incorporate code from another into a single source file;
in this case, the license of the file must clearly state dual licensing,
unless they can be relicensed (e.g. Expat -> GPL).

Further, simply placing a license in the root of a project doesn't
implicitly license a project: what if I had a LICENSE file saying one
thing, and two other licenses for other types of works, with no
indication as to what licensed applied to what?  That's not valid
licensing; nor is a random LICENSE file without any information as to
what files it applies to.

There's a community convention of a single LICENSE file, but without an
explicit grant of rights on particular works, there's potential legal
gray area.  It doesn't always make sense, even, for the license in the
LICENSE file to be applied to everything in the project: what about
documents, images, data, etc?  These need their own licenses.

One can specifically say in another file (e.g. README) that the source
files are licensed under license X, but this doesn't solve the problem I
stated earlier---if files from another project are incorporated.  What
if a license in a file is absent, or disagrees with the project's
umbrella license statement?  It leads to confusion.

The rights granted might also be more than what is in the LICENSE file;
GPLv3+, for example, is not a license: GPLv3 is, and the "+" comes from
an "or (at your option) any later version" grant that is stated
elsewhere (usually the source file).

If the copyright and license are clearly stated in the source files to
which they apply, then there is no ambiguity, and there is no risk of
separation (unless someone separates portions of the file, in which case
he/she would be responsible for ensuring proper licensing).

This is what we mean by unclear licensing practices.

-- 
Mike Gerwitz
Free Software Hacker | GNU Maintainer & Volunteer
https://mikegerwitz.com
FSF Member #5804 | GPG Key ID: 0x8EE30EAB

signature.asc
Description: PGP signature