diff --git a/modules/licenses/copyright.md b/modules/licenses/copyright.md index 2ff9787f..d064456d 100644 --- a/modules/licenses/copyright.md +++ b/modules/licenses/copyright.md @@ -4,7 +4,7 @@ type: reading order: 2 --- -## Copyright and software +## Copyright and software (2 minutes) Creative works, like books, paintings and music, but also scientific articles and software, are covered by copyright. Copyright is a legal construct that gives the owner of the copyright on a work the exclusive right to reproduce, modify, publicly perform and distribute the work. As a result, anyone who is not the copyright holder needs to have permission from the copyright holder to also be able to do so. diff --git a/modules/licenses/ex_choose_a_license.md b/modules/licenses/ex_choose_a_license.md index 424cbc35..2df14680 100644 --- a/modules/licenses/ex_choose_a_license.md +++ b/modules/licenses/ex_choose_a_license.md @@ -1,10 +1,10 @@ --- title: Choose a license type: exercise -order: 7 +order: 6 --- -## Exercise 3: Choose a license for or using your policy (10 minutes) +## Exercise 2: Choose a license for or using your policy (10 minutes) One of the concerns typically addressed in a software policy is licensing of software developed at the institution. Policies can choose a single license, or offer a range of options. diff --git a/modules/licenses/ex_finding_the_license.md b/modules/licenses/ex_finding_the_license.md new file mode 100644 index 00000000..1e847291 --- /dev/null +++ b/modules/licenses/ex_finding_the_license.md @@ -0,0 +1,25 @@ +--- +title: Finding the license +type: exercise +order: 3 +--- + +## Exercise 1: Find the license for a software package (10 minutes) + +Imagine that a researcher comes to you and asks whether they can use a particular software package that they found online. One aspect to consider would be its license, if there is one. + +Pick a software package from the following list, and try to find out whether it has a license and if so which. The idea is to cover the list together, so let's not all start at the top! + +- Kernel Tuner +- nodal-dg +- OpenFOAM +- MATLAB +- COPASI +- Glotaran +- LinkAhead + +A few hints: + +- The researcher only gave you the name. You'll have to find the code on the Internet first. +- Licenses are not always advertised on a code's website. Try looking somewhere more technical if you can't find it in the documentation. + diff --git a/modules/licenses/ex_have_licensing_policy.md b/modules/licenses/ex_have_licensing_policy.md deleted file mode 100644 index 7a1dfbf0..00000000 --- a/modules/licenses/ex_have_licensing_policy.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: Your policy -type: exercise -order: 4 ---- - -## Exercise 1: Does your university have a software licensing policy? - -Try and find out whether your university has a software (licensing) policy. If you can find it, compare it with the ones from [TU Delft](https://zenodo.org/record/4629662), [ASTRON](https://zenodo.org/records/7307162) and [the Netherlands eScience Center](https://www.esciencecenter.nl/wp-content/uploads/2020/05/nlesc_ip_policy_2017.pdf). What elements are commonly found? Which differences do you see, and what is their respective motivation? - diff --git a/modules/licenses/ex_licenses_in_use.md b/modules/licenses/ex_licenses_in_use.md deleted file mode 100644 index 8b586444..00000000 --- a/modules/licenses/ex_licenses_in_use.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: Licenses in use -type: exercise -order: 5 ---- - -## Exercise 2: What licenses do researchers at your university use? - -Search on [GitHub](https://github.com/) or other software repositories for software created by researchers at your university. What licenses do they use? Do they adhere to a policy (if there is one?) - diff --git a/modules/licenses/how_to_share.md b/modules/licenses/how_to_share.md new file mode 100644 index 00000000..51314768 --- /dev/null +++ b/modules/licenses/how_to_share.md @@ -0,0 +1,44 @@ +--- +title: How to share software +type: reading +order: 5 +--- + +## How to share software (6 minutes) + +Sharing software is done these days by making it available through the Internet, via e.g. GitHub or Zenodo. As we have seen however, that's not all you need to do. Because of copyright law, the software also needs a license. Sharing scientific software is sometimes simple from a legal perspective, but it can also be quite complicated. This section explains the main issues to take into account, which are ownership of the copyright, constraints imposed by dependencies, and choosing a license. + +### Ownership + +A copyright license must be given by the owner(s) of the copyright being licensed. This means that the first step to licensing a program is to find those owners. In most countries, including The Netherlands, any work you do as part of your tasks as an employee of an organisation belongs to your employer, not to you. After all, they're paying you to do the work. This means that the copyright on any software written by a university employee is owned by the university. + +If the software to be shared is written entirely by one person, with no copy-pasting of code from others, and no help from people outside of the organisation, then the copyright is therefore owned by your organisation, and it can decide how to license the code. + +Science is often done collaboratively though, and that makes things a bit more complicated. Funding for research is often given to consortia comprising multiple organisations that will collaboratively execute the research project. Such a consortium is governed by a Consortium Agreement (CA), which almost always has an Intellectual Property paragraph. Unfortunately, the standard text in the templates used for those documents rarely mentions software, as it mainly addresses patents and trade secrets. It does however usually say that each party gets to own the things they make, and that the partners can use it for the purpose of executing the research, but not beyond that. (Note that there is always some negotiation regarding the text, so you should check any specific CAs that apply, and not rely on this general description.) + +Funding may also come with terms covering ownership. eScience Center grants for example come with a stipulation that both parties co-own the software even if it is written completely by one of the partners. + +So, if your researcher works on the software together with a researcher from a different organisation, then both organisations need to agree to license their respective copyrights, ideally under the same license to avoid complicating things. + +For long-lived scientific software that isn't Open Source already, it can sometimes be very difficult to determine ownership. It may not always be clear who wrote which part of the code (especially if no version control software was used), who they worked for when they did so, and which contracts were in place that governed their activities. Ideally, the copyright owners would have been carefully tracked over the life of the software, with copyright statements in the README documenting the owners. That is unfortunately very rare however. If it is not possible to determine the owners of the copyright, then the software cannot be licensed. + +### Dependencies + +Owners may not be completely free to decide how to license their software. Aside from any constraints imposed by funders, *dependencies* play a role. Dependencies are externally developed, separate software packages that are needed for the software to work. Having such dependencies is very common, and dependencies typically have their own dependencies, so that any complete computer program consists of a whole collection of software packages, usually written by different people. These days at least for Open Source software, the complete program is rarely distributed as a whole. Instead, the owners of the individual components each put their components online, and a special tool is used to collect all the required bits and combine them together on the computer of the user, who can then use the software. + +As described in the section on licensing, strong copyleft licenses place constraints on how the combined software can be licensed. As a result, you cannot use them in a non-Open Source program. This does not mean that you have to make your software Open Source if has a copyleft dependency, but *if* you distribute it, then that must be done under the same license, and/or a more permissive one that does not conflict with it. + +As you can see, dependencies with strong copyleft licenses can make life a bit more complicated. On the other hand, as long as no proprietary software is involved not much can go wrong. In case there are proprietary dependencies (including ones without a license, or "academic use only" or somesuch), there is a larger issue. If the software cannot work without the dependency, and the proprietary license does not allow redistribution, there we can still open source the software, but others won't be able to run it unless they can somehow get a copy of the proprietary dependency. And if you choose a strong copyleft license for your code, then you'll have to add a special exception for your users to be able to use it with the proprietary dependency. + +So it is really proprietary software that complicates things legally, and that's aside from the lack of Open Science transparency. On the other hand, some proprietary software package is sometimes the only solution, and so proprietary dependencies cannot always be avoided. If that's the case, you'll have to look at the specific terms for that package and try to find a solution. + +Weak copyleft licenses are less of an issue, because they do not reach beyond the licensed package itself. They can become an issue if your researcher has copy-pasted code from them into their own program (which is bad practice, but unfortunately fairly common still), or created a modified version. In that case the same weak copyleft license applies to (parts of) their code or the modified software, thus restricting the available license choices. + +### Choosing a license + +In almost all cases, scientific software should be licensed under a common, standard Open Source license. Open Source enables scientific collaboration and makes the work available to the society that paid for its creation, and not using a standard license creates enough legal risk that most potential users will not be willing to touch the software unless they really have to. + +Whether to use a permissive, weak, or strong copyleft license is up to the copyright owner. If your organisation has a policy on software, then it may well say something about which licenses can be used, so be sure to check that. The authors of the software may also have an opinion, or develop one if you explain the different kinds of licenses to them. A tool like [ChooseALicense](https://www.choosealicense.com) may help here. + +Note that Creative Commons licenses should not be used for software. They were created specifically to be able to apply the concept of Open Source to everything that is *not* software, and aren't suitable to the specific properties of software. So use CC for data and other works, and an Open Source license for software. + diff --git a/modules/licenses/index.md b/modules/licenses/index.md index b7a6a73e..212ac4b4 100644 --- a/modules/licenses/index.md +++ b/modules/licenses/index.md @@ -3,7 +3,7 @@ title: Software licenses category: Reusability order: 25 author: eScience Center -abstract: What are software licenses, copyright and open-source, how are they related and why is it important to think about? +abstract: What are software licenses, copyright and open-source, how are they related and why is it important to think about? thumbnail: "thumbnail-licenses.png" visibility: visible --- diff --git a/modules/licenses/info.md b/modules/licenses/info.md index f34a6c5b..0929e7f4 100644 --- a/modules/licenses/info.md +++ b/modules/licenses/info.md @@ -7,6 +7,7 @@ order: 0 Obtain the skills and knowledge necessary to address the following questions: - What is a software license? What is copyright? -- What are the different kinds of software license? -- Why is it important to provide a license with research software? -- How do I support researchers in choosing the right license for their software? +- How to legally use software made by others in your organisation? +- How to license software created by your organisation? +- How to license contributions to external Open Source projects? + diff --git a/modules/licenses/licenses.md b/modules/licenses/licenses.md index d15296ef..d67f10ce 100644 --- a/modules/licenses/licenses.md +++ b/modules/licenses/licenses.md @@ -1,10 +1,10 @@ --- title: Software licenses type: reading -order: 6 +order: 4 --- -## Software licenses +## Software licenses (8 minutes) Software licenses are legal statements that give permission to use, modify and/or distribute software. By copyright law, only the copyright owner(s) can give this permission, so the license must be granted by those owners. diff --git a/modules/licenses/media/Kleine_Dinge.jpg b/modules/licenses/media/Kleine_Dinge.jpg new file mode 100644 index 00000000..bd870dc0 Binary files /dev/null and b/modules/licenses/media/Kleine_Dinge.jpg differ diff --git a/modules/licenses/media/Stephanie_Morales_Sharing.jpg b/modules/licenses/media/Stephanie_Morales_Sharing.jpg new file mode 100644 index 00000000..395d5b5b Binary files /dev/null and b/modules/licenses/media/Stephanie_Morales_Sharing.jpg differ diff --git a/modules/licenses/media/Zytgloggeturm_Bern.jpg b/modules/licenses/media/Zytgloggeturm_Bern.jpg new file mode 100644 index 00000000..2adc8014 Binary files /dev/null and b/modules/licenses/media/Zytgloggeturm_Bern.jpg differ diff --git a/modules/licenses/slides.md b/modules/licenses/slides.md index 0f5771ed..03408928 100644 --- a/modules/licenses/slides.md +++ b/modules/licenses/slides.md @@ -15,12 +15,48 @@ order: 1 +## Common questions + +- Can I use this software I found online? +- Can I share my software with others? +- Can I contribute to someone else's software? + + +Note: + +There are three different things researchers do with software that are affected by licensing: using someone else's software, sharing your own software, and contributing to someone else's software (or having others contribute to yours). + +You're probably most likely to get questions on the second topic, because the first is so commonly done that people either know the answer or don't know that it's even an issue, while the third one is still pretty rare in practice. + +Software is covered by copyright, and that's the main legal context in which we'll look at these questions here. + +=== + + + +
+ ## About copyright -- Berne convention +- Berne convention on copyright - Owned by author or employer? - Can be licensed +
+ +
+ + + +
+ +
+ +Photo by JoachimKohler-HB - Own work, CC BY-SA 4.0, Link + +
+ + Note: @@ -37,18 +73,92 @@ The owner of the copyright on a work can give permission to others to do things ## Using others' software +- Two ways of using software - You need a license -- Open Source makes that easy +- Licenses sometimes implicit, or home-made +- Open Source is better and safer - Different Open Source licenses available Note: -To use software that was made by someone else, you need to (at least) get a copy of it, and that requires permission from the copyright owner, i.e. a license. If the software has an Open Source license, then you have permission to get a copy and run it for any purpose, including commercially, and/or use it in your own software. There will be some conditions attached, which depend on the particular license used. +There are two ways of using someone else's software: running it, and incorporating it into your own program. Both are covered by copyright, because you need to download and because you're making a derivative work. + +So you need copyright permission, which is to say a license. In science, these are sometimes implied, by a researcher publishing the code without an explicit license, or home-made, which is not recommended because a non-expert will overlook many of the details of copyright law. -There are a handful of Open Source licenses available, with different terms. Those differences are especially important when you use a package or library in your own software. There are websites available that explain all the standard Open Source licenses in ordinary language, so that you can easily decide whether you can use a certain software package. You don't need to be (or have) a lawyer to use Open Source software. +It's better if the software has an Open Source license, because these are professionally written and have standard, well-known meanings. We will go into that a bit more later. There are websites available that explain all the standard Open Source licenses in ordinary language, so that you can easily decide whether you can use a certain software package. You don't need to be (or have) a lawyer to use Open Source software. +=== + + + +
+ +## Why share software? + +- Reproducibility +- Increasing impact +- Academic freedom of employees +- Saving by collaborating +- Public funding + +
+ +
+ +
+ +
+Photo by Stephanie Morales on Unsplash +
+ + +Note: + +Scientific software is sometimes shared, but also sometimes kept to themselves by the researchers making it. Here are some reasons that sharing scientific software is important: + +- Software is a scientific method, and it must be shared for the science to be reproducible. +- Sharing software will bring users of the methods and citations to papers about it +- Researchers frequently change jobs, moving from university to university. Without permission from their previous employers, they would have to start rebuilding their software from scratch every time they move to a new university, which would be very inefficient. +- Many of the most pressing problems that scientist work on involve complex, multifaceted systems that can only be properly studied in collaboration. Where software is involved, which is to say almost everywhere in academic research, researchers need to be able to exchange software and collaborate on its development, including across projects. +- The software was most likely funded with public money, and should therefore be available to the public, just like papers are published Open Access. + +=== + + + +
+ +## How to share software + +- Put it online +- Add a license + 1. Who owns the software? + 2. Dependencies? + 3. Kinds of licenses + +
+ +
+ +
+ +
+Photo by Stephanie Morales on Unsplash +
+ + +Note: + +To share software effectively, you need to give it a license, preferably an Open Source one. + +To do that, you need to be the owner of the copyright, or at least be able to act on behalf of the owners. This may be very simple but it can also be very complex. More on the next slide. + +The next thing to consider is whether other software has been used in the software you've made (that's almost always the case) and how those so-called dependencies are licensed, as this may constrain your choice. + +Finally, different Open Source licenses specify different terms and conditions for use, and you need to decide what you want there. + === @@ -57,55 +167,112 @@ There are a handful of Open Source licenses available, with different terms. Tho - Work for hire - Consortium agreements -- University policy +- Funding constraints Note: -In most countries, including The Netherlands, any work you do as part of your tasks as an employee of an organisation belongs to your employer, not to you. After all, they're paying you to do the work. This means that the copyright on any software written by a university employee is owned by to the university. And that means that anyone not working at that university (which may include said employee in the future!) needs permission from the owner to work with the code. +In most countries, including The Netherlands, any work you do as part of your tasks as an employee of an organisation belongs to your employer, not to you. After all, they're paying you to do the work. This means that the copyright on any software written by a university employee is owned by the university. -Some limited permission is often granted in the Consortium Agreements typically governing scientific project(s), but these are only valid within the project. To make the software available outside of the project it was developed in, broader permissions must be given. Some universities have a policy on how and under which conditions this can be done; details can typically be had from the library or legal department. +Science is often done in consortia, which are typically governed by a Consortium Agreement. Those often have a section on Intellectual Property that applies. Sadly those sections often don't mention copyright, but they do usually state that each partner gets to own the things they've made. That means that if your researcher has worked together on the software with researcher at one of the partners, that there are two owners that need to decide on licensing together. +Funding may also come with restrictions or stipulations regarding ownership. For example, eScience Center grants come with a rule that says that both parties co-own the software, even if it was written by one of them, and that it will be published under the Apache License unless otherwise agreed. === -## Why license your software? +## Kinds of licenses + + + + + + + + + + + + + + + + + + + + +
Free and Open SourceProprietary
CopyleftPermissive
StrongWeak
GPL1 AGPL2LGPL3 MPL4BSD5 MIT6 ApacheResearch only, No copying, No modification
+
+ 1GPL: GNU General Public License 2AGPL: Affero General Public License 3LGPL: GNU Lesser General Public License 4MPL: Mozilla Public License 5BSD: Berkeley Software Distribution 6MIT: Massachusetts Institute of Technology +
-- Public funding -- Academic freedom of employees -- Save work by collaborating -- Increase impact + +Note: + +Software licenses can be classified into different categories, which is helpful to get a quick idea for what kind of license you are dealing with. First, there are Open Source and non-Open Source licenses. Open Source licenses allow you to use the software, share it, change it, and share your changes. Proprietary software licenses do not allow one or more of these things. Note that this is not about being commercial, you can actually sell copies of Open Source programs, although you're not very likely to find buyers. + +Copyleft licenses say that if you modify the licensed software or incorporate it into your own, that that new software package must then be licensed under the same license. A permissive license allows licensing the new work under any license. As a result, copyleft software needs to remain open source, while permissively licensed software can be made proprietary. + +Within the copyleft licenses we can distinguish strong copyleft, which covers both modified versions and use in other programs, from weak copyleft, which only limits modification. So a weak copyleft license keeps the licensed software package itself Open Source, but can be used as a part of proprietary software, while a strong copyleft license keeps the software from being used in (but not with) proprietary software (it is a bit vague legally where the limit is). + +Finally, the Affero GPL is designed for use with software that is designed to be installed on a server and accessed remotely, for example through a web browser. A normal copyleft license does not require the server owner to give a copy of the software running on the server to the users, while the AGPL does. + +=== + + + +## Choosing a license + +- Use a standard Open Source license +- Check your policy (if applicable) +- Use a tool Note: -If a scientist working at a university, in the course of doing their job, creates software, then that software is owned by the university. By default then, it can only be used by that university and its employees. This is an undesirable situation for several reasons. +The next step is to choose a license. If at all possible, use a standard Open Source license, because it will make everyone's lives much easier. Do not use Creative Commons licenses, as they're not designed for use with software. -- First, the software was most likely funded with public money, and should therefore be available to the public, just like papers are published Open Access. -- Second, researchers frequently change jobs, moving from university to university. Without permission from their previous employers, they would have to start rebuilding their software from scratch every time they move to a new university, which would be very inefficient. -- Third, many of the most pressing problems that scientist work on involve complex, multifaceted systems that can only be properly studied in collaboration. Where software is involved, which is to say almost everywhere in academic research, researchers need to be able to exchange software and collaborate on its development, including across projects. -- Finally, doing so will allow them to achieve better results, and continue to build on those results, thus achieving higher impact. +Next, check if your organisation has a policy that covers software licenses. Those are still a bit rare, but they're being worked on in many places so it's likely that you'll have one at some point. Check whether it specifies a particular license, or maybe a range of acceptable ones. +Finally, there are some nice tools available that make it easier to select an Open Source license. We'll have a look at that in the exercise. === -## Open Sourcing scientific software +
+ +## Contributing to software -- Free, Open Source Software -- Technology Transfer +- Under the license +- Contributor License Agreements + - Who are you dealing with? + - Transfer or license? + +
+ +
+ +
+ +
+Photo by Mark König on Unsplash +
Note: -Free, Open Source Software (or FOSS, as it's sometimes abbreviated) is software that you are free to 0) use for any purpose, 1) modify to suit your needs, 2) share with others, and 3) share with changes you made, so you can work on it together. That's actually the Free Software definition, but Open Source really just says the same thing in more words, which is why they're usually mentioned together. These are exactly the permissions scientists need to be able to do science together using the software. +The most common way of contributing to an open source project is to do it under the license associated with the project. That means that you keep the copyright on your addition or modification, and license it under the same license as the existing code. This is the norm for small projects run by volunteers (or scientists). This case is similar to sharing your own code under a given license. + +Larger, more professionally run Open Source projects sometimes require a Contributor License Agreement. This is a contract that states what the recipient of your improvement can do with it. These are not standardised, so the contents vary. -Open Source licenses also allow commercial use, which means that they are a very effective means of technology transfer. Since the license terms are the same for everyone, there are no issues with state aid regulations, nor does a market-rate value for the software need to be determined. The standard Open Source licenses are now well understood and trusted by commercial parties, removing the need for complex negotiations on the exact terms. Of course, no payment will be received either. Given that commercial sale of academic software is very rare, it seems that the benefits obtained from the academic collaboration enabled by Open Source far outweigh the potential income loss due to not commercially licensing the software. And note that it is still perfectly possible to launch a spin-off or start-up that offers commercial services related to the software, including support and continued development. +When evaluating these, it's good to look at who you're dealing with. A commercial entity, like Google, or a governance organisation like the Apache Foundation. The latter non-profit offers support for Open Source projects, including making sure that everything is properly licensed. Google is of course a commercial entity. +Some CLAs require you to transfer ownership of the copyright on your contribution to someone else, which can be a good idea if that sole copyright holder can be trusted, for example because it makes it easier to upgrade the license. It may also allow them to turn your work proprietary however. In other cases, you're just giving explicit permission to distribute your contribution as Open Source software, which seems more just. +In general with CLAs, you should be careful with commercial entities (state aid!), and it's in any case probably wise to get your legal department involved. === diff --git a/modules/licenses/university_policy.md b/modules/licenses/university_policy.md index 1da95b94..0a552dda 100644 --- a/modules/licenses/university_policy.md +++ b/modules/licenses/university_policy.md @@ -1,10 +1,10 @@ --- title: Software policies type: reading -order: 3 +order: 7 --- -## University software policies +## University software policies (2 minutes) Universities employ researchers, who often create and use software in the course of doing research. That means that they create and use copyrighted works, activities governed by copyright law. Works created by employees as part of their work are normally owned by their employer. This is the default legally in many places, and is almost always stated in the employment contract as well. So, the university owns the software created by its employees, and because the employees also act on behalf of their employer, is responsible for any violations of copyright by their employees.