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

[Mike Gerwitz]

On Fri, Apr 29, 2016 at 22:42:42 -0400, Richard Stallman wrote:
>   > > 5. Can you expand on how we would "ensure that licenses are applied
>   > > correctly"? Does this mean, e.g. preventing forks (a feature which has 
> been
>   > > suggested before) and/or private forks would not be possible if the 
> project
>   > > was using a GPLv2+ license?
>
> That seems like a combination of misunderstandings.  All free licenses
> permit distribution of forked versions, that is freedom 3.
>
> I am not sure what "ensure that licenses are applied correctly" means
> -- what _in our criteria_ does that refer to?

He was quoting me; I had corrected myself in a subsequent reply to him;
I forgot to note that in my message to you.  I rephrased as encouraging
users to apply license headers and copyright notices to source
files.  Since GitLab (and most other hosts) pretty much stop with
dropping a license file in the project root, it encourages bad practices
by failing to encourage proper licensing.

>   > Richard: See screenshots on the aforementioned URL.  I don't think these
>   > will suffice, but maybe you'll have useful suggestions for how they
>   > format it.
>
> It is hard for me to see those.

I'll describe it; this'll be a bit verbose.

Connor, please correct me if I say anything inaccurate.

When creating a project, GitLab does not recommend a license.

After the repository is created, the user is redirected to the web page
that serves as the index page for the repository.  So long as the
repository contains no files, this page body includes a heading "The
repository for this project is empty", followed by normal-sized text
stating: "[...] Otherwise, you can start with adding a README or a
LICENSE file to this project."  README and LICENSE are hyperlinks.

Clicking "LICENSE" redirects to a page with a text area and
dropdown.  The dropdown lists various licenses, the first few being "GNU
General Public License v3.0", "MIT License", and "Apache License
2.0".  (Connor: "MIT" should be "Expat", or "MIT Expat", since that what
it usually means; see [0].)  Selecting one prefills the text area with
the license text.

The end result after saving this page is a LICENSE file added to the
repository root with that text.  This is technically SaaSS, since it's
modifying your repository on your behalf; I'd be curious to know your
opinion on this given its limited scope.  (It'd also be nice if COPYING
were added for the GPL, instead of LICENSE, but that's a more minor
issue.)

If the repository _does_ contain files, then those files are listed in
the page body.  Above that file listing are buttons, not prominent: "Add
Changelog", "Add License", "Add Contribution guide"; they're hidden if
the respective file associated with the button already exists.

---

So, in my opinion, GitLab does not encourage adding a license enough: it
blends in with the rest of the content and is displayed with the same
regard as READMEs, Changelogs, and contribution guides.  Users will not
be encouraged to add a license any more than they will be encouraged to
add one of those, and users who don't care about licensing or understand
the implications may just see it as more annoying boilerplate for their
repository.

I think GitLab needs to state clearly---perhaps in a similar manner to
how they would show warning/error messages (but not necessarily that
exact style)---that the project doesn't have a license, and is
consequently non-free.  This would serve as a notice to the author, and
a warning to users.

I suggested in another thread that, when selecting a license, GitLab
also suggest headers for source files.  Or perhaps even detect (when
viewing a source file on the website) that a header is missing, and
offer the text there.

Another topic that came up with the issue of where to include "or later"
for the GPL; obviously, if the license list simply prefills the license
text, then that is not the place to do it---that permission needs to be
granted in the source files.  This could be suggested as I mentioned by
including header suggestions for source files, but I'm not sure if you
have other ideas.


[0]: https://www.gnu.org/licenses/license-list.html

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

signature.asc
Description: PGP signature