Open Science is all too often equated with accessibility, but this is a mistake. A vital part of open science is not about access, but rather about use. For others to be able to use your project, you will have to give them permission you do this. You do that with a license. Without a license, your project is copyrighted, and others will not be able to build on it. But even if you want to give your project an open license, there are hundreds, even thousands of licenses out there, and it can be difficult to choose!
So, here is a very rough guide:
If you want an open license, and you have a creative project that is not functional (so, it is not software or code), you can choose one of the Creative Commons licenses. Within these licenses you can opt for specific flavors: do you want to allow commercial use of your project? Do you want others to reshape your project and make a derivative, or is this not allowed? Do you want derivatives to be shared with the same Creative Commons license? Or simply: when you use this project, you must attribute me.
If you have a software project, you can choose between a license that is ‘copyleft’, and a more permissive license. Copyleft is a term coined because it is the opposite of copyright: it not only allows access and use of your project, but it requires anyone building on the project to share their product with the same license, in a pay-it-forward kind of system.
Permissive licenses are the least restrictive about what a user should or should not do with your project: the MIT license, the BSD license, and Apache are examples of this.
So, that is what open license are. Here is what Open licenses are NOT:
They do not mean that you will be forgotten. Far from it: your work will be shared, and in sharing it, you will be attributed. When your work is shared, so is your name and recognition.
Open licenses also do not forbid you from monetizing your project. If you want to make money off of your project, you can; there are many ways in which that is possible even if you do not ‘sell rights’ to the project. An Open License in principle does not stand in the way of commercial gain.
Full disclosure: GitHub, and similar websites like GitLab and BitBucket, shine when used in combination with version control software such as Git. But GitHub can be used without Git, and you can benefit from the infrastructure within GitHub that facilitates collaboration and sharing. We recommend it!
A project on GitHub is called a repository, or a ‘repo’ for short. In a GitHub repo, both invited and uninvited guests can engage with your project, and collaborate: they can discuss ideas or make suggestions in issues, they can even copy the project to their own profile, where they are boss, make requisite changes, and propose to you that you integrate these changes.
If you do not want anyone to be able to see your project yet, GitHub allows private repos, where you can collaborate only with those you explicitly invite. But, for what it is worth, we recommend sharing early. It invites collaboration, and it sets the stage for a project to be shared completely and easily when it is done. A project that is shared throughout its lifecycle will be cleaner, less likely to contain clutter, and subject to a few more critical eyes that may just catch a gleeming error in your methods before you call Nature!
GitHubs infrastructure is much broader than a discussion platform: primarily, it allows you to show your work. GitHub showcases README files, making it easier for anyone to get started in understanding your work. Even if you do not use version control software, GitHub will do it for you, and track your history. Finally, a new release of your projects takes nothing more than a few button clicks, and GitHub has a superhighway to archiving your project on Zenodo, where you can store your project for posterity.
Archiving is more than sharing. It is a way to ensure that there is a permanent place for your project, AND to ensure it can always be found there. Zenodo is an archive – that means that everything that ends up in Zenodo will stay there forever. Fortunately, Zenodo has a sandbox environment where you can play with it without knowing your dummy projects will be archived for good.
A GitHub repo can be connected to Zenodo, which makes archiving it a breeze: releasing the project in GitHub will trigger the archive, and an updated version will end up as an updated version on your archived project. Zenodo issues a Digital Object Identifier, a DOI, which will persistently link to your project, even if the Zenodo archive will change locations on the web. In this example project, you can also see the license, and a version history: it is immediately clear if a project has been updated, but older versions remain accessible.