Added BSD 3-clause license, and updated Readme with license terms

greenelab / library-access

Collecting data on whether library access to scholarly literature

Other

5 stars 3 forks source link

Added BSD 3-clause license, and updated Readme with license terms #5

Closed jglev closed 6 years ago

jglev commented 7 years ago

This follows the discussion at #3. I based the updates to the Readme on the wording in the Manubot repo. that @dhimmel referenced in that discussion.

A few questions:

I wasn't sure how your lab typically handles the BSD <copyright holder> template field. Do you use a CONTRIBUTORS file, list contributors directly in the LICENSE file, or something else?
I added a few additional file patterns that I anticipate us using, again taking Manubot as a starting point. Does that look acceptable to you?
We could also say "everything is BSD 3, except these file patterns," or "everything is CC0, except these file patterns;" in this PR, I've just listed file patterns separately, trusting that we'll update the respective lists as we add data and code. Do you have a preference between those approaches?

dhimmel commented 7 years ago

Also glad to see that you made the PR from a new branch not your master!

jglev commented 6 years ago

Thanks, @dhimmel! I've implemented your suggestions (excepting a file glob suggestion, to which I posted a response question above) in a series of new commits.

One additional question: The Lab's onboarding documentation mentions hard-breaking text at 80 characters. Is that meant to include markdown, as well?

dhimmel commented 6 years ago

The Lab's onboarding documentation mentions hard-breaking text at 80 characters. Is that meant to include markdown, as well?

We can use the 80 character limit for python (intentional exceptions like long URLs are acceptable).

However, for markdown let's use one sentence per line as explained here:

Within a paragraph in markdown, single newlines are interpreted as whitespace (same as a space). A paragraph's source does not need to contain newlines. However, "one paragraph per line" makes the git diff less precise, leading to less granular review commenting, and makes conflicts more likely. Therefore, we recommend using semantic linefeeds — newlines between sentences. We have found that "one sentence per line" is preferable to "word wrap" or "one paragraph per line".

jglev commented 6 years ago

Done, as of 28801d8 : )