LICENSE?

[redchair123]

Is it really MIT if you reserve all rights?

[thlorenz]

Right here :) https://github.com/thlorenz/valuepack-core/blob/master/LICENSE This is a proper MIT license don't worry.

[redchair123]

@thlorenz i've never seen "all rights reserved" in an MIT license for a project before.

http://opensource.org/licenses/MIT, the one most people use, doesn't have the clause. However, according to https://fedoraproject.org/wiki/Licensing:MIT?rd=Licensing/MIT people have attached that clause in a few ways.

I would advise using the URL form for the license in package.json (because npm defaults to opensource.org corpus), which should be something like

"licenses": [
 { "type": "MIT"
 , "url": "https://github.com/thlorenz/valuepack-core/blob/master/LICENSE"
 }
]

[thlorenz]

Good points, however if you look at npm itself for instance, it's license has a rights reserved clause as well.

So I think all is good on that front -- I'm not an expert, but am assuming to reserve all rights first and then grant exceptions via permissions is the proper way to do this.

Adding licensing instructions to the package.json is a good idea, although not legally required (including LICENSE file is enough).

So I'll include this in my package.json template, so all future projects wil have this and will add it to existing packages I'm updating over time, unless you want to fix it for all my packages (I'll accept PRs :) ).

[redchair123]

(including LICENSE file is enough)

Let me first say that it's good that you remembered to include it. Most people (and by most I mean > 80%) forget.

I didn't mean to suggest that you had to include them in package.json. But if you are going to do it, do it right :)

You already had "license": "MIT" (which is why https://npmjs.org/package/valuepack-core has a link in the license field), but the generated link points to the opensource.org version ( http://opensource.org/licenses/MIT), which does not have the all rights reserved clause.

if you look at npm itself for instance

That uses something that is clearly not vanilla MIT (explicitly says "MIT +no-false-attribs License"), which is not a problem so long as that is made clear in package.json. I think going either way (linking directly to the license in package.json OR omitting it entirely) is acceptable.

(I realize I'm niggling, but I am, after all, a niggler :)

On Mon, Jun 10, 2013 at 9:33 AM, Thorsten Lorenz notifications@github.comwrote:

Good points, however if you look at npm itself for instance, it's licensehttps://github.com/isaacs/npm/blob/master/LICENSEhas a rights reserved clause as well.

So I think all is good on that front -- I'm not an expert, but am assuming to reserve all rights first and then grant exceptions via permissions is the proper way to do this.

Adding licensing instructions to the package.json is a good idea, although not legally required (including LICENSE file is enough).

However I'll include this in my package.json template, so all future projects wil have this and will add it to existing packages I'm updating over time, unless you want to fix it for all my packages (I'll accept PRs :) ).

— Reply to this email directly or view it on GitHubhttps://github.com/thlorenz/valuepack-core/issues/1#issuecomment-19198555 .

[thlorenz]

Point taken, and as I said, I'll fix this every time I touch a package and will change my template to fix it for all future packages. But, again, if you wanna help beyond niggling, I'll take PRs :+1:

[redchair123]

@thlorenz I'm working on a more comprehensive tool for that purpose:

Originally I wrote a quick bash script to check repos: https://gist.github.com/Niggler/5426452

Then someone took it and made something really awesome: https://github.com/dschep/license-checker

[thlorenz]

Nice! However that won't fix the package.json issue,but it'll see improvement I promise :)

[redchair123]

actually your case exposed a real problem (where the license doesn't match the package.json version), which is good (it's better to consider this now rather than later :)