Break

This is a time for you to get some refreshment and clear your mind a little in preparation for the next part of the workshop.

Workflow checklist

Overview

Teaching: 5 min
Exercises: 20 min
Questions

  • What will I do?

  • When will I do it?

  • How will I remember to?

Objectives

  • Be confident you’ll remember to implement the skills learned here today.

How to use this checklist

Checklist

Licensing [ ]

Documentation [ ]

Code [ ]

Dependencies [ ]

Tests [ ]

Repository [ ]

Publishing [ ]

Referencing [ ]

Collaboration [ ]

Rights and Licensing

Overview

Teaching: 10 min
Exercises: 10 min
Questions

  • What is licensing?

  • Do I need to license my work?

  • Who owns the rights to my work?

Objectives

  • Understand what parts of your university’s rights and licensing policy apply to you.

  • Know where to get help.

What is licensing?

When software is created it is automatically copyrighted. The owner of the copyright (the ‘rights holder’) can do things with it that other people can’t. A license lets people do things that they couldn’t otherwise do.

Normally, we can’t legally copy someone else’s intellectual property, for example. We normally can’t sell it. And we definitely can’t sell it and claim that we made it ourselves. These are examples of rights that we would infringe upon without an appropriate license. Most software licenses you’re familiar with will let you copy software, at least once to put it on your computer. Other licenses will let you make more copies, and distribute them – some will even let you sell the software or versions of it that you extend. Certain very ‘broad’ licenses waive all rights (i.e. you still have those rights but you’ve agreed that nothing people do will infringe them).

Do I really need to license stuff?

Yes. If you don’t, no one can do anything with your code or software. And, if you have collaborators, no one includes you.

What kind of licenses are there?

The major kinds of licenses we’re concerned about are open source licenses. These licenses embrace four freedoms:

  1. The freedom to use
  2. The freedom to modify
  3. The freedom to distribute
  4. The freedom to distribute modifications

You can get a good idea of which open source license is right for you by looking at https://choosealicense.com/.

Of course, you can choose any of a large number of different licenses (or write your own), but established licenses give people confidence to run and build on your software. The more custom a license is, the more people will worry about unintended effects.

Who decides what license to use?

The license must be decided by the rights holder. If you’re writing software on your own at home, this is almost certainly you. There may, however, be other considerations. While it’s not a strict hierarchy, the rough order to check is:

Finding out 10 min

Take ten minutes now to find out who is the rights holder for your current project. If you don’t have a current software/code-writing project, who would hold the rights if you did?

  1. If you have already written software, does it have dependencies that have copyleft licensing?
    • If not, it’s possible you may be forbidden from building on these works.
    • This is unlikely, but it can happen.
  2. Check your funding arrangement if you have one – it might say who is the rights holder for work you produce, or perhaps state which licenses you can use.
  3. Check your university policy.
    • This may be different for students.
    • and faculty .
  4. If none of these say anything relevant, then you are the rights holder and you can use any license you like. If you don’t care, use a public domain license like the unlicense.

Totally lost?

Take this time to send an email to your supervisor, librarian, administrator, or someone else who might be able to answer the question “who owns code/software that I write in my research?”

By now you should know who will be the rights holder for code and software you write. You should know how to ask them to let you choose an appropriate license for your code or software. If you run into difficulties, you should know where to get help.

New Lesson

Overview

Teaching: 10 min
Exercises: 20 min

The text of your lesson will go here. It can make use of markdown formatting, as well as the special callout zones in The Carpentries’ template.

Template

Why share?

Overview

Teaching: 0 min
Exercises: 30 min

Enumerating the benefits 5 min

In small groups, try to think of reasons people share code and software. Using the collaborative notes document, jot down any ideas you come up with, so that we have an overall list at the end.

Ideas

Some reasons that are commonly cited are:

  • Shared software can be built on by others
  • Shared code can be checked by others
  • Shared software can be maintained by others
  • Extensions to some software have to be shared due to copyleft licensing
  • It’s possible to audit and verify shared software
  • Sharing software helps you hold yourself to higher coding standards

Considering the concerns 5 min

In the same groups, try to think of reasons people might hesitate to share code or software. Again, use the collaborative notes document to jot down any ideas you come up with.

Ideas

Some reasons that are commonly cited are:

  • If I share my code, people will find mistakes in it, and that would be embarrassing
  • My software is badly built, or my code is messy, and it’s embarrassing
  • It takes time to learn how to share and do the sharing – time I don’t have
  • I don’t want to maintain my code or software, and I’d feel obliged to if I shared it
  • My software won’t be as impressive if people can see how it works
  • People could use adapt my software for purposes I don’t agree with
  • I worked hard on this code and I don’t want other people to benefit from my work

Your experiences 10 min

Now we have listed some benefits and concerns of sharing, go around your small group and have each group member identify two items that they have experience with. You can choose a benefit and a concern, or two benefits or even two concerns. For each one, share your experience of it with your colleagues. If you have time, add a brief note about your experience to the collaborative notes document, but the focus should be on sharing with your colleagues and listening to what they have to say.

Addressing concerns 10 min

We have a list of concerns that people in your workshops might have. It’s helpful to be able to provide some perspective on those concerns – we want to acknowledge that sharing can be frightening or difficult, but highlight that it is worth doing anyway!

Again, in your group, choose two of the concerns. If they are concerns you have or have had yourself, that’s ideal, but they could also be ones that you just find interesting. Go around the group, discussing each person’s concerns. Try to think of reasons why the concern should not hold you back from sharing your code and software. If you can’t think of anything, try asking the larger group or one of the workshop instructors or helpers.

Remember, it’s not wrong to have concerns! We believe that sharing data and code is important and that the benefits outweigh the concerns, and we’d like to help you understand why and give you any encouragement you need.

Key Points

  • People share code and software for many reasons

  • Shared software can be extended

  • Shared software can be evaluated

  • Bugs can be found and fixed