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

[Mike Gerwitz]

Hey, Michael:

(Sytse: I CC'd you in case you're interested in the discussion as it
relates to licensing to satisfy the B2 criterion.)

On Tue, Apr 26, 2016 at 22:45:59 +0200, Michel Le Bihan wrote:
> Should Gitlab receive B2?
> https://gitlab.com/gitlab-org/gitlab-ce/issues/15621

Thanks for pointing out this thread!  I'm responding in part there, but
the bulk of my reply is below to keep this discussion on-list, and
because I want the discussion on that thread to continue to focus
primarily on LibreJS.

To quote @haynes:

> I think the second point is already solved then. Gitlab now allows
> project licences and other licence file names.

The text for B2 is:[0]

> Does not encourage bad licensing practices (no license, unclear
> licensing, GPL N only).

So to pass this, GitLab must:

- Either require users to choose a license (e.g. Savannah[1]), or
  prominently encourage users to choose a license and indicate that a
  lack of license makes the software proprietary.  If GitLab required a
  license selection, one of the options could be "Proprietary (No
  License)" or "No License (Proprietary)"; that's just a suggestion
  though.

- Ensure those licenses are applied correctly.

- Not encourage the use of the GNU GPL version N without the "or later"
  clause.

In discussions with Richard Stallman, he rejected the term "project
license" because it doesn't indicate that license information needs to
be stated on the source files themselves.  This is important[2], because
the files might get separated from the project, and then all copyright
and licensing information might be lost.  It might also be difficult to
determine the license of a file that is part of a project with multiple
licenses.

The license header is also the only place to state "or (at your option)
any later version)".  It's important to note that putting a `COPYING' or
`LICENSE' file containing the text of the GPL is important to satisfy
the condition of providing the license, but that in itself is not
intended to license the source code itself: instead, the license appears
in the source file header, which in turn says you should have received a
copy of the license.

What he had suggested as a possible phrasing for the GitLab criterion
failure was:

  Fails to lead users to choose a free license for their code and
  fails to lead them to put that license on their source files.

How GitLab wants to do that is up to them, and I'd be curious---it'd be
a great example to set for others.  For example, it would be awesome if
GitLab actually checked to see if there was a copyright header on the
file and provided a warning if not.  But I don't think that's the
intent---perhaps, when the user selects GPLv3+ as their license, it also
provides the boilerplate header that they can use in their source
files as a helpful tip.  This, in turn, encourages proper license practices.

It's great that GPLv3 is at the top of the license list, but it should
really be "GNU General Public License version 3 or later".  If they
don't want "or later", then can choose "other"; listing one without "or
later" would be both confusing to users and would encourage its
selection.

I hope this provides some clarification.


[0]: https://www.gnu.org/software/repo-criteria.html
[1]: https://savannah.gnu.org/register/
[2]: https://www.gnu.org/licenses/gpl-howto.html

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

signature.asc
Description: PGP signature