Unusual location for license defeats wwhrd and other tools

Question

Unusual location for license defeats wwhrd and other tools

ijc opened this issue 7 years ago · comments

The Apache license for this project is in LICENSE.code, which means that wwhrd (and I suppose any other tool using go-license) cannot find it and so reports an unknown license (which is a failure). I've added an exception to my project but thought it worth raising since I don't like exceptions.

How would we feel about renaming LICENSE.code to just LICENSE (and leaving LICENSE.docs alone of course)? My argument for giving the code the "privileged" position is that automated tooling is going to primarily be interested in code (e.g. vendoring) while docs are not typically vendored or subject to automatic inclusion in quite the same way. Even more LICENSE.docs specifically only covers README.md and CONTRIBUTING.md which really aren't going to be vendored I think.

I can make the PR if we think this is a good idea.

As an alternative a symlink LICENSE → LICENSE.code would work too (I guess, I've not actually tried it)

There is an issue on go-license at ryanuber/go-license#16 but its from 2015 so I figured I would start here first.

Vincent Batts · Answer 1 · Fri Apr 27 2018 02:21:09 GMT+0800 (China Standard Time)

that seems like a fine idea

…

On 04/26/2018 11:37 AM, Ian Campbell wrote: The Apache license for this project is in |LICENSE.code|, which means that wwhrd <https://github.com/frapposelli/wwhrd> (and I suppose any other tool using go-license <https://github.com/ryanuber/go-license>) cannot find it and so reports an unknown license (which is a failure). I've added an exception to my project but thought it worth raising since I don't like exceptions. How would we feel about renaming |LICENSE.code| to just |LICENSE| (and leaving |LICENSE.docs| alone of course)? My argument for giving the code the "privileged" position is that automated tooling is going to primarily be interested in code (e.g. vendoring) while docs are not typically vendored or subject to automatic inclusion in quite the same way. Even more |LICENSE.docs| specifically only covers |README.md| and |CONTRIBUTING.md| which really aren't going to be vendored I think. I can make the PR if we think this is a good idea. As an alternative a symlink |LICENSE| → |LICENSE.code| would work too (I guess, I've not actually tried it) There is an issue on |go-license| at ryanuber/go-license#16 <ryanuber/go-license#16> but its from 2015 so I figured I would start here first. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#37>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEF6fBwC-CQAX4giiDPj5AIcakeQhyAks5tsemsgaJpZM4Tlc4R>.

Derek McGowan · Answer 2 · Fri Apr 27 2018 03:52:15 GMT+0800 (China Standard Time)

Not sure why some of these projects even have a license.docs file, perhaps inherited from the Docker registry. There are no docs but if just renaming License.code works then SGTM

W. Trevor King · Answer 3 · Fri Apr 27 2018 04:04:09 GMT+0800 (China Standard Time)

Not sure why some of these projects even have a license.docs file…

I'd added LICENSE.docs in #12 to catch up with a README reference which landed in 36db198. If the Git history hasn't been truncated, @stevvooe and I are the only README authors. I'm happy reclicensing my contributions there under Apache-2.0 if that helps with the licensing (my README contributions may be too minimal to be copyrightable anyway).

CONTRIBUTING.md, on the other hand, is straight from docker/opensource (as described in 79405cf, #7), so if you want it relicensed under the Apache-2.0, you'll need to check there to see who owns the copyright. Alternatively, you could probably source an Apache-2.0 CONTRIBUTING.md directly from somewhere else (e.g. here) or write your own.

Just renaming LICENSE.code sounds simple enough and allows us to punt on getting an Apache-2.0 CONTRIBUTING.md.