search

okfn / opendatacommons

Legacy Open Data Commons website. Moved to https://github.com/okfn/opendatacommons.org
MIT License
6 stars 6 forks source link

Fix sec 4.2 of ODC_BY to make clear it is not ShareAlike #3

Open marctjones opened 6 years ago

marctjones commented 6 years ago

Per conversation at https://discuss.okfn.org/t/is-odc-by-a-sharealike-licence/6417/10

Sec 4.2 of the ODC_BY license can be misleading and read to mean that ODC_BY is a ShareAlike license despite the clear intent that it be a Attribution license in the spirit of CC-BY. Fix the wording so that sec 4.2 only applies to the Database, and make it clear that 4.2(a) is a notice requirement not a licensing grant per the pull request #2

pnorman commented 6 years ago

I suggest closing this as out of scope of the website. The license stewardship process needs more than just GitHub, and a comment here does not have the visibility.

Is it even decided that ODC will be publishing an ODC BY 1.1 in the near future?

rufuspollock commented 6 years ago

@pnorman i agree that we should go through a proper review process. To be clear this was simply a clarification rather than a change with any substance but a fuller review than we had would still be useful.

@marctjones i still think having the PR / diff is very useful. Maybe you could post the diff here for now. See also discussion in the PR #6

marctjones commented 6 years ago

@rufuspollock Here is a diff of for my suggested patch for ODC BY.

234,236c234,235
< 4.2 Notices. If You Publicly Convey this Database, any Derivative
< Database, or the Database as part of a Collective Database, then You
< must: 
---
> 4.2 Notices. If You Publicly Convey this Database, including as part of a
> Derivative Database or as part of a Collective Database, then You must: 
238c237
<   a. Do so only under the terms of this License;
---
>   a. Indicate the Database is licensed under the terms of this License;
428c427
< terms of this License.
\ No newline at end of file
---
> terms of this License.
marctjones commented 6 years ago

@pnorman / @rufuspollock I agree. I would be inclined to say any textual change should go through a review process. Even small typos I would be inclined to send to the advisory council for review. You do not want to get into a situation some day where a pull request was put in to "fix" a typo for a lack of a comma, when in fact that comma changes the whole meaning of the sentence and was not a typo at all.

It might seem silly and overdoing it when fixing obvious mistakes, but sometimes what is obviously "obvious" becomes debatable.

marctjones commented 6 years ago

@rufuspollock I am curious if you know what the review process would be or is this something the advisory council would have to set up. I know the GPLv3 process was a whole production. I do not believe FSF has a review process procedure lying around so has to construct it each time they update a license. Which considering the infrequency of that task, seems fair.

rufuspollock commented 6 years ago

@marctjones GPLv3 was massive change. This is simpler so i think it can go to the AC and get a quick look from a relevant legal expert.

pnorman commented 6 years ago

@rufuspollock Here is a diff of for my suggested patch for ODC BY.

Can you explain the change in a non-technical way? Most people can't read diff files, and I can't read that particular diff formatting.