post idea: Licenses

[sckott]

Do we want to do a blog post on licenses? For software and data? Most readers may not make software, but they use it, and licenses important to understand for papers and data, which most readers will put out there...

[emhart]

Whoa. you must have read my mind. I was going to e-mail everyone about a blog post I had about licenses. Basically it was a cautionary tale that has happened on another project I've been working on. The gist is that the NSF funded a software project for about 10 years. No licenses were ever agreed upon and when the soft money dried up the lead developer took all the code and close sourced it and started selling the software for profit. I wanted to write about it emphasizing the importance of having a good license policy from the start. So I'd be happy to contribute.

[karthik]

Nice @sckott Would be good to do a round up of existing posts. There are some really good ones by SSI, possibly at SWC and various other non open science initiatives. Can also ask Neil Chue Hong to maybe do this as a guest post since he's best informed.

[sckott]

That'd be a great story to include @emhart -

Sure, maybe ask Neil, but if he waffles about it, and says something like "sure, some day", then just do it ourselves?

[karthik]

Sounds good. I was just asked to write a post for them (about non ropensci stuff) so this would be a good time to ask.

[sckott]

ok, let us know what happens

[cboettig]

:+1:

[sckott]

from chat with ben marwick today, he mentioned a discussion about license in archeology (his field), here's the link https://lists.okfn.org/pipermail/open-archaeology/2014-July/thread.html

[karthik]

Dropped Neil a note. Will update soon.

[sckott]

Ben Marwick told me about one of Victoria's papers which I didn't know about http://academiccommons.columbia.edu/download/fedora_content/download/ac:140154/CONTENT/04720221.pdf

[karthik]

Just heard back from Neil. He's happy to do it. He asked about target audience. I'd like to tell him: Aimed at researchers who are just entering the world of research software (in whatever capacity, ie. writing code or software packages in any scientific computing lang; think Simon Goring) but not geared towards someone as advanced as say a research software engineer or at the other end, as basic as lay person scientist who doesn't write any code. Sound good?

[cboettig]

sounds good.

On Wed, Aug 27, 2014 at 10:54 AM, Karthik Ram notifications@github.com wrote:

Just heard back from Neil. He's happy to do it. He asked about target audience. I'd like to tell him: Aimed at researchers who are just entering the world of research software (in whatever capacity, ie. writing code or software packages in any scientific computing lang; think Simon Goring) but not geared towards someone as advanced as say a research software engineer or at the other end, as basic as lay person scientist who doesn't write any code. Sound good?

— Reply to this email directly or view it on GitHub https://github.com/ropensci/roweb/issues/67#issuecomment-53613419.

Carl Boettiger UC Santa Cruz http://carlboettiger.info/

[sckott]

great, sounds good

[sckott]

@karthik @cboettig should we try to do this ourselves?

[cboettig]

Good question. There's a lot of this stuff out there already, though there might be value in making our perspective a bit more clear.

I sometimes think that the space of open source licenses is rather oversimplified by the way it is presented in what I sometimes see in SWC etc (e.g. that all licenses are either BSD-like or GPL-like), that go like this http://www.astrobetter.com/the-whys-and-hows-of-licensing-scientific-code/

NESCENT has tended to recommend this PLOS article, which is at least a little more concrete and less black & white:

“A Quick Guide to Software Licensing for the Scientist-Programmer.” PLoS Computational Biology 8 (7) (July 26): e1002598. doi:10.1371/journal.pcbi.1002598.

The more I learn the less I feel I actually know or understand about licenses. the whole CC0 bid to OSI fell down due to patent concerns rather than license copyright issues. Licensing complex content as in R packages that have data and documentation; re-licensing (dynamic vs static binaries, packages with mixed license dependencies, distribution laws on software that includes open source encryption algorithms, etc). While I value the spirit of permissive licenses immensely, I feel that posts on the topic that have simply said "let me guide you through the complexity of all these different open source licenses -- you want BSD" haven't been much help in navigating these issues.

I would be curious to here @npch 's take here (he got my attention at WSSSPE with an offhand comment that, for instance, the MIT license may be too vague to work as a license in many jurisdictions, e.g. the UK)...

[sckott]

@ropensci/owners does somebody want to take this on? if not, we can close

[karthik]

Let's leave it open for now.

[npch]

My viewpoint on this is "I wish that licensing was easier to understand".

However as Carl points out, the issue is that under the surface there are so many things that might or might not be barriers persist, due to a combination of differing legal systems, a lack of test cases, and a lot of FUD (fear, uncertainty and doubt).

I actually quite like the astronomy article you point to, though I think it could argue the "why permissive" with a little more evidence.

I generally use go through the following steps with people:

1. Always license your code, otherwise other people can't use it [though be wary of patents]
2. Broadly speaking, there are three types of license: commercial (closed), permissive and copyleft
3. If you're going to use a permissive or copyleft license, use an OSI-approved one as it means it's had more legal eyes over it
4. The reasons you might want to choose a particular type of license, broadly:
   • Commercial licenses let you control the code absolutely, and charge a fee for use
   • Permissive licenses let the largest number of people build on your code, and make it easy to collaborate with other researchers and industry
   • Copyleft licenses make it easier to keep derivatives of your code open

The issue that @cbottig noted I had raised as a remark is that one sub-clause in the MIT license cannot be applied in England and Wales because it disclaims liability for something that you cannot disclaim liability for under English & Welsh Law. Therefore it's unclear how a judge would choose to strike out the clause - which might mean the whole liability clause disappears.

A great resource for those who are interested in these things is: https://tldrlegal.com/

[mbjones]

Just as a side note: In DataONE we chose the Apache 2 license (over BSD) for all of our new code because of the patent grants there, which are especially important for multi-authored code which originates from Universities that can at times be aggressive pursuing patents. Although all of our contributors have joint copyright, the disposition of joint patent rights is far less clear. I agree that this is much more complex than most people want to grapple with.

Nevertheless, with academic software (say, R code that scientists want to share), some simple guidelines would still be useful to get people started, maybe with some pointers to more exhaustive treatments. It might be as simple as recommending that people 1) choose a license from the big 3 (Apache2, BSD, GPL), and 2) get written approval from their universities as it is probably needed. Then give pointers to the rest of the license complexity. I point scientists to the JISC guide for data licensing all the time: http://discovery.ac.uk/files/pdf/Licensing_Open_Data_A_Practical_Guide.pdf