License file is missing

[ericbmerritt]

While the source indicates that this is MIT licensed, without the license file its hard to tell at a glance. For companies with a legal department it could also be an issue of which files are open and which are not. If you add a license file that just removes all the confusion.

[amirmc]

Although a file has been added, I still feel I should add my 2cents (as a general comment for MirageOS libs).

There are three points here.

• Difficult to tell at a glance what the license is.
• Legal departments might not be able to tell which files are open and which are not.
• Adding a license file removes confusion.

I completely agree with the first point (and I think it's important). I disagree with the second two.

The source itself should be enough information for any legal dept to be able to tell whether a file is open or not. Adding a separate file doesn't change the due diligence that a legal professional would have to undertake.

In addition, the separate file doesn't necessarily remove confusion as now this repo has license info in a file and in the source files. Although these are consistent, there may be occasions for other libs where code is copied in under a different but compatible licence (admittedly, I think this would be rare -- and likely discouraged -- but the possibility exists). In that case, the LICENSE file would be misleading.

While I disagree with the second two points, I do agree that making the license info easier for developers to find out is a desirable goal. My approach to this would have been to mention the license info as one line in the README file and point people to the source -- e.g. "LICENSE: Source is released under the ISC license, but please see individual files for details." (or something in that vein).

[samoht]

@amirmc we usually mention the license either in the _oasis and/or opam file. In that case, the project didn't have an _oasis file and the field in the opam file was missing. So adding the file and the right metadata makes senses here. In other projects, the _oasis file usually contains the information so it's less important.

[amirmc]

The _oasis files (and opam files) are specific to OCaml projects so for someone browsing the repos who doesn’t know that, the first point still stands (not seeing at a glance what the license is).

For a case in point, see the other issue at https://github.com/mirage/ocaml-ipaddr/issues/50, which does have an _oasis file and the same request for a LICENSE file.

I (think I) understand where the desire for a license file is coming from and given the way it’s stated, it’s applicable to most of our repos. Hence, I wanted to comment here so that my thoughts are public.

On 2 Jun 2015, at 10:50, Thomas Gazagnaire notifications@github.com wrote:

@amirmcI we usually mention the license either in the _oasis and/or opam file. In that case, the project didn't have an _oasis file and the field in the opam file was missing. So adding the file and the right metadata makes senses here. In other projects, the _oasis file usually contains the information so it's less important.

— Reply to this email directly or view it on GitHub.

[samoht]

that makes sense. I'll try to add a line in the README where this is applicable.

[dbuenzli]

Le mardi, 2 juin 2015 à 10:47, Amir Chaudhry a écrit :

While I disagree with the second two points, I do agree that making the license info easier for developers to find out is a desirable goal. My approach to this would have been to mention the license info as one line in the README file and point people to the source -- e.g. "LICENSE: Source is released under the ISC license, but please see individual files for details." (or something in that vein).

FWIW what I do is to always mention the license kind at the end of the short description of my package which is replicated in various places: in the README, in the opam descr file and on the webpage of the project. The problem I have with global LICENSE files is that, as you mention, they are often misleading, I more than once saw projects specifying a license in a global LICENSE but failing to acknowledge that other files in the project were licensed differently.

Best,

Daniel