Rule to require JSdoc comment

[philsch]

Like described in the deprecated package https://eslint.org/docs/rules/require-jsdoc, it should be possible to require that a JSdoc is existing at all.

[gajus]

PR welcome. Simple first contribution.

[thsmi]

I've implemented an eslint compatible requireJSDoc rule in my fork.
The change set is 54445b6

The rule is re-engineered by running it against the ESLint Unit tests.

But before creating a pull request I need clarification on the following topic:

As this project does not uses any of the well known OSS licenses (Honestly it does not seem to me as a valid license at all) I do not know if it is permissible to include the copied unit test file. The rule file is reengineered, so it does not have any licensing issues.

Can you, as the maintainer, contact the eslint maintainer and ask for clarification? If they grant you the permission everything should be fine.

In case they cannot grant you the permission, the only way to include the unit test would be getting the permission of all the original authors to convert it from MIT license to the public domain or your homegrown license. Or including the Unittest file under the MIT License. Both is to my knowledge viable.

So how to proceed?

Should I create a pull request without the unit test file? Or contribute the unit test under MIT? Or wait until you clarified the situation with the eslint maintainer?

[brettz9]

package.json lists this package as BSD-3-Clause which it appears to me to be... And with eslint/eslint being under MIT, if that's the code you included, then it should be compatible in this direction (to include within eslint-plugin-jsdoc).

But, FWIW, if including eslint-plugin-jsdoc into an MIT project, the project could maintain MIT for the rest of its files, but would need to follow the separate and slightly stricter BSD-3-Clause terms for the eslint-plugin-jsdoc code.

[thsmi]

This raises a new question. Which is the actual license of this repository?

• Github shows a custom license as defined in https://github.com/gajus/eslint-plugin-jsdoc/blob/master/LICENSE
• NPM shows BDS as it is defined in the package.json

[brettz9]

It is the same text as https://opensource.org/licenses/BSD-3-Clause , with two exceptions (the second of which is puzzling here, but I presume is due to a copy-paste error from another repo):

1. "Gajus Kuizinas (http://gajus.com/)" replaces "the copyright holder" as would be normal or expected.
2. "IN NO EVENT SHALL ANUARY BE LIABLE" instead of "IN NO EVENT SHALL THE COPYRIGHT HOLDER BE LIABLE"

(FWIW, the local list is also bulleted instead of numbered.)

[thsmi]

@brettz9 thank you for the clarification and sorry for the confusion I created. I obviously got lost in the licenses jungle. I had for some reason in mind that the BSD license was a way longer text like the the GPL stuff. But it is still strange that github does not detect the license correctly.

As the code is BSD-3-Clause, the original question is still applies.
Is it OK to add the unit test file under a MIT license? If not the file needs to be relicensed to BSD, which needs at least the permission of the maintainer and/or the original authors. How to proceed?

[brettz9]

Where do you say Github did not detect it correctly? I reported such an issue once and they fixed it not too long later.

But it seems from the "License" link on the repo page, that while they did not mislabel the license, they didn't identify the license type either as they typically do and as described that they do at https://help.github.com/en/articles/licensing-a-repository#detecting-a-license . Apparently, as per that link:

To have your license detected, simplify your LICENSE file and note the complexity somewhere else, such as your repository's README file.

As far as your question, while it is up to @gajus , I think it is just an issue of including the MIT license with maybe a note in the README about that code being under the MIT license per the original license, though any modifications to it, and in the rest of the repo would be under the stricter BSD terms, and as neither license is viral like the GPL, they do not require the other linked code to comply with their terms. But the MIT license does insist on a copy of the license being kept with the code. As far as the original maintainers, you could ask them to dual-license it with BSD-3-Clause, but I think to save themselves work, they might just say you should just include the MIT license as it is compatible, and all we have to do is include a copy, and should probably indicate by some means to which code the license applies.

(I think it would be convenient actually if developers had an easy way to flag through npm, etc. that they were multi-licensing against all the open source licenses, not only for the sake of compatibility questions, but for the sake of their users not needing to host so many copies of a license; but as MIT is so common, in practice, there are not so many types used.)

(Btw, FWIW, if you're conscientious on this issue, you might also want to use something like https://www.npmjs.com/package/license-checker to ensure that the dependencies are actually compliant. But it can be complicated to determine whether a development dependency is actually compiled into your resulting code or whether it is just code that is used as a tool during development for say just test the depencency or such and is not actually bundled into your consumer code.)

[brettz9]

In short, the MIT file doesn't need to be relicensed for changes on top of it to be BSD, as MIT allows modifications and redistribution with the only condition that is in some small way perhaps incompatible with BSD being solely that the MIT license says you have to include a copy of itself--which presumably means not just a copy of BSD. :) (Even though BSD does basically have the same conditions with an added one--and the MIT license doesn't tend to prevent additional conditions from being added.)