My opinions about licenses run more to seeing CC0 as the default for data with the use of CCBY only under careful consideration. People report a lot of fear about CC0 being used on their data, because people could do anything with it and they aren't required to cite. That's true, but the use of CC0 doesn't negate the behavioral standards of citation within the academic community. Both CC0 and CCBY are two of the most benign choices from the CC family, but attribution stacking and tracking can get cumbersome. At the end of the day it's often your choice to pick whatever you're comfortable with, I just like to make sure that people aren't excluding CC0 from serious consideration.
Also, to clarify some of my earlier comments, there's nothing wrong with having code/data it github and depositing specific versions in a formal repository. As you said, it makes collaboration much easier. I was just checking that a data repository deposit was in the pipeline. Elizabeth On Thu, May 26, 2016 at 2:44 AM, Matthias Nilsson <[email protected]> wrote: > Hi Elizabeth! > > Thank you very much for your answer! I've replied inline. > > E.W. <[email protected]> wrote on Wed [2016-May-25 11:43:04 -0500]: > > I've done some analysis on the licenses that are used by datasets > within > > DataCite records. As of December 2015 when I scraped the data in, > 59% of > > the records had a rights statement and 95% of those were in the > Creative > > commons family. Yanking more out of my slides, when looking at the CC > > uses: 62% CC-BY-NC; 36% CC-BY; 1% CC0; <1% other. These numbers are > > heavily biased towards specific repositories using stock licenses for > all > > their records and having a high volume of records, so these should > not be > > interpreted as data representing the self-deposit data world. > > CC has a nice wizard to select a license from, but CC0 or CCBY are > usually > > the ones we (the data repository team I work in) try to recommend to > > people for open data. I can provided unapologetically biased opinions > > about which to use, but I shall refrain unless prodded. > > I would be interested in hearing your opinions, especially since I > lean towards copyleft licenses, but maybe we should take that off the list? > > > There may be a domain repository that specializes in this kind of > data and > > they likely have some recommendations. As far as adding it goes, most > > repositories just have a declaration on the splash page for the > dataset, > > within the metadata, and sometimes a copy of the license as part of > the > > file set. > > But to focus more on the third item, please do consider formally > > depositing this into a data repository of some sort (versus just > having a > > public github repo). Zenodo has hooks to github and issues out > DataCite > > metadata when it generates the DOI. Figshare does this as well, but > > Zenodo has better editing capabilities for the metadata. I'm happy to > > brain dump about this more offline for the curious of if you're > confused > > as to how to use the elements (this is an open offer to anyone on > there > > wrangling with datacite metadata). > > > > As far as other considerations about the question of making things > public, > > it depends on the source and content of the data. > > 1) Is work on the content creation and edit of these data files > done? You > > don't want to potentially be changing content under people's feet if > they > > are working with the data. There are ways to version the data and I > can > > expand on this if it is an issue. > > The reason for the move to Git repositories is to facilitate > development and collaboration. As a bonus, it should also make it > simpler to handle versioning. For published models, I think there is > already a structure in place for submitting them to data repositories. > > > 2) Are there any data sensitivities? For example: Is this human > subject > > data? Could this potentially have a harmful impact on any subjects? > > Looks like these are just models, so likely not, but always consider > this. > > (Most of) the models have already been published in papers previously > and as I've understood things they contain no sensitive data. > > > 3) Are there any contractual or licensing sensitivities for making > this > > open? For example, are these data files derived from a source with > > restrictions on such derivatives? Any other contracts or IP issues > with > > tools used or the University in regards to licensing? University IP > > concerns are highly variable by local laws and policies, but > something to > > consider if they would want to have a stake in this. > > Good point! I am not aware of any issues, but I'll ask around. > > > Thanks again for taking your time to answer! > > Best regards, > Matthias >
_______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/listinfo/discuss
