Contributor License Agreements Ruin Most FOSS Projects

Summary

The video script discusses the nuances of open source and free software movements, emphasizing their differences despite shared goals. It delves into the complexities of permissive and copyleft licenses, and the role of Contributor License Agreements (CLAs) in project contributions. The script highlights various types of CLAs, from Fedora's to the KDE project's fiduciary licensing agreement, and the Developer Certificate of Origin, illustrating how some CLAs can be beneficial while others may infringe upon developer rights. It advises caution and understanding of CLA terms before signing, advocating for a balanced approach to open source contributions.

Takeaways

• 😀 Open source and free software movements have different ideologies and goals but share some overlap in their licensing principles.
• 🔄 Permissive licenses allow anyone, including companies, to take a project and make it proprietary, applying equally to all parties.
• 🔒 Copyleft licenses prevent additional restrictions from being added to the code, ensuring freedom for all users and developers.
• 📜 Contributor License Agreements (CLAs) are additional documents sometimes required for contributing to a project, varying greatly in their terms.
• ⚠️ CLAs are often viewed negatively due to cases where they undermine developer rights or supersede licenses with unfavorable terms.
• 📝 The terms of a CLA can range from restrictive and harmful to developers, to neutral or even beneficial in some cases.
• 📑 Examples of CLAs include the Fedora Project Contributor Agreement and the KDE Project's Fiduciary Licensing Agreement, each with different implications.
• 🛑 The Developer Certificate of Origin is considered an 'anti-CLA' as it does not grant additional rights and simply confirms the contributor's rights to the code.
• 🚫 Some CLAs, like the one from Discourse, can be harmful as they grant companies extensive rights to re-license and use contributions in any way they see fit.
• 🤔 It's crucial for contributors to read and understand CLAs, or seek guidance if they are unclear, as the terms can significantly impact their rights.
• ❗️ A negative reaction to the term 'CLA' is common due to misuse, but it's important to remember that not all CLAs are inherently bad and some can be neutral or positive.

Q & A

What is the main difference between open source and free software movements?

The main difference lies in their ideologies and goals. While both movements promote software that can be freely accessed and modified, open source focuses on practical software development and collaboration, whereas free software emphasizes user freedom and ethical issues.

How do permissive licenses affect both companies and individual developers?

Permissive licenses allow anyone, including companies, to take an open source project, make it proprietary, and claim it as their own. However, this also applies to individual developers, who can do the same with the project.

What is a Contributor License Agreement (CLA) and why is it sometimes viewed negatively?

A CLA is an additional document that contributors are often required to sign before they can contribute to a project. It is sometimes viewed negatively because it can be used to undermine developer rights, supersede the license, or impose other unwanted terms.

Can you provide an example of a CLA that is considered neutral or positive?

Yes, the Fedora Project Contributor Agreement and the KDE Project's Fiduciary Licensing Agreement are examples of CLAs that are considered neutral or positive because they do not take away rights from the original authors and are used for the protection of the project.

What is the Developer Certificate of Origin, and how does it differ from other CLAs?

The Developer Certificate of Origin is a simple document that states the contributor owns the code and it is licensed under an open source license. It does not grant additional rights to the project maintainers and is often considered an 'anti-CLA' because of its minimal requirements.

What are the implications of a CLA that allows for re-licensing of contributions?

A CLA that allows for re-licensing gives the project or company the right to change the license terms of the contributed code, which can be problematic as it may go against the original intent of the open source or free software movement.

Why is the FSF's copyright assignment considered a form of CLA?

The FSF's copyright assignment is considered a form of CLA because it requires contributors to assign their copyright to the FSF, giving the FSF the right to protect and manage the code, but it is trusted because of the FSF's commitment to free software.

What does the KDE fiduciary license agreement aim to address?

The KDE fiduciary license agreement addresses the issue of full copyright assignment by allowing contributors to assign economic rights to the KDE project while retaining moral rights, ensuring that the project cannot change the licensing terms without the author's consent.

What is the recommended approach when encountering a CLA for a project?

It is recommended to read the CLA document thoroughly and understand its terms. If unsure, seek advice from someone knowledgeable. If the CLA is unbalanced or overly restrictive, it might be best to avoid contributing to that project.

How does the discourse CLA differ from other CLAs mentioned in the script?

The discourse CLA is more restrictive and grants the company extensive rights, including the ability to re-license the contributions under any terms, which raises concerns about the project's commitment to open source or free software principles.

Outlines

00:00

📜 Understanding Open Source and Free Software Licenses

This paragraph delves into the distinctions between open source and free software movements, acknowledging their differences while recognizing the respect due to their supporters. It discusses the permissive and copyleft licenses, which apply to all parties and can be used by companies to make proprietary versions of projects. The paragraph introduces Contributor License Agreements (CLAs), explaining their variable nature and their role in supplementing project licenses when necessary. It provides examples of CLAs from Fedora and KDE, highlighting their different approaches and implications for contributors' rights.

05:01

🛡️ The Role and Implications of Contributor License Agreements (CLAs)

The second paragraph explores the concept of CLAs in more depth, contrasting the negative perception of some CLAs with the positive or neutral impact of others. It explains how CLAs like the Fedora Project Contributor Agreement and the KDE Fiduciary Licensing Agreement operate, focusing on their terms and the rights they grant to projects. The paragraph also touches on the Developer Certificate of Origin used in the Linux kernel, describing it as a lightweight 'anti-CLA' that ensures contributors have the right to submit their code. The discussion emphasizes the importance of understanding the terms of any CLA and the potential risks of signing away too many rights, as seen in the Discourse CLA example.

10:04

⚖️ Evaluating CLAs and Their Impact on Open Source Projects

In the final paragraph, the script addresses the controversy surrounding CLAs, particularly those like the Discourse CLA that grant extensive rights to the company, potentially undermining the principles of open source and free software. It argues that while some CLAs can be beneficial or neutral, others may be detrimental to the spirit of open source contributions. The paragraph encourages contributors to read and understand CLAs, seek clarification when needed, and consider the trustworthiness of the project and its management. It concludes with a call to action for viewers to share their experiences with CLAs and their thoughts on the topic.

Keywords

💡Open Source

Open Source refers to a software development approach where the source code is made available to the public with the right to use, modify, and distribute it. In the video, the term is used to discuss one of the two main movements in software licensing, emphasizing the collaborative nature of development where anyone can contribute to and benefit from the code. The video contrasts open source with free software, highlighting their differences in ideology and goals.

💡Free Software

Free Software is a term coined by the Free Software Foundation (FSF), which focuses on the freedom of the user to run, study, share, and modify the software. Unlike open source, which can be more focused on practical collaboration, free software is more about the ethical and liberty aspects of software use. The video discusses the philosophical differences between free software and open source, noting that while they have different goals, they share some common ground.

💡Permissive License

A permissive license is a type of software license that allows for modification and redistribution of the software, even for commercial purposes, without requiring the derivative works to be open source. The video explains that while a permissive license can be used by companies to make proprietary versions of a project, it applies equally to everyone, including individuals who can also take advantage of the open source code.

💡Copyleft License

Copyleft is a general method for making a program (or other work) free, and requiring all modified and extended versions of the program to be free as well. The video mentions copyleft licenses as a way to prevent others from adding additional restrictions to the code, ensuring that derivative works remain free and open source.

💡Contributor License Agreement (CLA)

A Contributor License Agreement (CLA) is a legal contract between an individual or corporation and a project or company, specifying the terms under which intellectual property rights are granted to the project. The video discusses CLAs as additional documents that contributors may be required to sign before they can contribute to a project, noting that the terms of a CLA can vary widely, from very restrictive to very permissive.

💡Fiduciary Licensing Agreement (FLA)

The Fiduciary Licensing Agreement, as mentioned in the video, is a type of CLA used by the KDE project. It is designed to protect the rights of the contributors while allowing the project to legally defend the software. The video explains that unlike a full copyright assignment, an FLA assigns economic rights to the project, allowing it to act on behalf of the contributors without taking ownership of the code.

💡Developer Certificate of Origin (DCO)

The Developer Certificate of Origin (DCO) is a lightweight and simple document that serves as a CLA. The video describes it as an 'anti-CLA' because it does not grant additional rights to the project maintainers. Instead, it serves as a record stating that the contributor has the right to submit the code and that it is appropriately licensed under an open source license.

💡Re-licensing

Re-licensing refers to the act of changing the license under which a piece of software is distributed. The video discusses the implications of CLAs that allow for re-licensing, which can be a contentious issue in the open source community. It points out that some CLAs, like the one used by Discourse, give the project maintainers the right to re-license the code under different terms, which can be seen as a threat to the original open source or free software ethos.

💡Copyright Assignment

Copyright Assignment is the process by which the rights of a copyright are transferred from one owner to another. The video mentions that the FSF's approach to copyright assignment is a form of CLA, where contributors assign their copyright to the FSF, which can then protect the code in court. This is contrasted with other CLAs that might allow a project to change the licensing terms of the code.

💡Discourse CLA

The Discourse CLA is highlighted in the video as an example of a CLA that is seen negatively by the open source community. It is described as granting extensive rights to the company, including the ability to re-license the code under different terms, which can be against the principles of open source and free software. The video suggests that such a CLA might disqualify a project from being considered truly open source or free software.

Highlights

Open source and free software are fundamentally different movements with different goals but some overlap.

Permissive licenses allow companies to make proprietary versions of open source projects, but this applies to everyone.

Copyleft licenses prevent adding additional restrictions to the code, applying to developers and users alike.

Contributor License Agreements (CLAs) are additional documents sometimes required for project contributions.

CLAs are often viewed negatively due to attempts to supersede licenses or strip developer rights.

The terms of a CLA determine its impact, with some being benign or even beneficial, while others are harmful.

Examples of CLAs include the Fedora Project Individual Contributor License Agreement and the KDE project's fiduciary licensing agreement.

The Fedora Project Contributor Agreement does not assign copyright but provides a license to use contributed code.

The KDE fiduciary license agreement assigns economic rights to the project while retaining moral rights for the author.

The Developer Certificate of Origin is a simple CLA that confirms the right to use and contribute the code.

Discourse's CLA is controversial for granting the company extensive rights, including the ability to re-license contributions.

Unbalanced rights in a CLA, such as the ability for a company to re-license but not the contributor, can be problematic.

CLAs like the one used by Discourse can lead to debates about whether a project is truly open source or free software.

It's important to read and understand CLA terms, seeking clarification if necessary, especially from reputable projects.

Some CLAs, like the Developer Certificate of Origin, are considered neutral or even positive and fill gaps in contribution rights.

CLAs are not inherently bad, but they are often misused, and it's crucial to understand their implications for contributions.

The video encourages viewers to reflect on their experiences with CLAs and to engage in the discussion about their use.

Transcripts

Say what you will about the differences in ideologies behind open source and free software

They are very very different movements

But I can completely respect supporters of both of these movements because

Even though they are very different movements with very different goals. They do have some overlap, but still fundamentally different

Licenses under both of these banners apply equally to all parties involved

Yes, a permissive license allows a company to come along, yoink the project, make it proprietary and make it theirs

But that applies to everybody. You can do the exact same thing. And yes

A copy left license stops people adding additional restrictions to the code

But that applies to everyone the developers and also you

However, sometimes the terms of the license are not good enough for certain projects

So in comes would refer to as a contributor license agreement

Often just referred to as its acronym

C-L-A

Now oftentimes when the term CLA is used it is used in a very negative light and I understand why

Because oftentimes you hear about them. They are a very negative document that are trying to destroy developer rights

They're trying to supersede the license and do other things which

Frankly should not be there in a free software or an open-source project

But like many things out there a CLA is

Only as bad as the terms of the document

There are cases where CLA are not as bad. There are cases where CLA are good

And then there are cases where they absolutely suck and you should run the other way

But in short a CLA is an additional document that often you're required to sign not always

There are some very key exceptions before you're allowed to contribute to the project

So here are a couple of examples prior to 2011 all Fedora contributors were required to sign the Fedora project

Individual contributor license agreement

This was then superseded by the Fedora project contributor agreement with the earlier document being based on Apache's

Individual contributor license agreement. As of 2008 the KDE project makes use of the fiduciary licensing agreement made by the FSFE

Now this is one of those cases where it is optional

Most people have not signed it. There are a lot of people that have

But you do not have to sign this document now

Arguably things like the FSF's copyright assignment are a form of CLA and most was made as kind of a

anti-cLA

Depending on who you ask the developer certificate of origin from the Linux foundation used in the Linux kernel is

Also a kind of CLA but when people use the term

Contributor license agreement CLA what they are often referring to are things like what discourse has

Where you are basically signing away all of your developer rights

Now all of these documents are very very very different. There is no one set thing

This is a CLA. Let's take for example the Fedora project contributor agreement

This document does not assign your copyright to the Fedora project

What it does is provides them with a license to make use of your code

It does not allow them to re-license the code outside of the terms of the license you already have so if you have code

that is licensed under a

GPL license it can be licensed under the terms of the GPL license if it's MIT

That is a more permissive license and it can be re-licensed in a more permissive way

But it doesn't give them any additional rights unless we are talking about unlicensed code in the case of code

That does not have a license

They can provide a default license and this license can be changed in short

You're saying I wrote this code you're allowed to use the code and you have to follow the terms of my license

And if I don't provide a license then you can license the code in a way you see fit

Let's go and look at the KDE fiduciary license agreement now

This one might seem intimidating because it is four pages long

one of those pages is just your information and

The first page and most the second page is just definitions

So the FSFE made this document to deal with the issues with full copyright assignment

So with the FSF for example, you assign your copyright to the FSF

Basically, they own your code now and this in the case the FSF is done for a good reason

If they need to go and protect that code in court if they own the code

This is much easier to do and generally you're going to trust the FSF is going to try to keep that code as free

software and isn't going to re-license it in a way that is now

Completely against the terms

Many other organizations you probably wouldn't trust with that

But this comes with an issue if the FSF is ever taken over and they decide, okay

We're just gonna go proprietary now. We don't actually care about free software anymore

They own all of the code and they can do whatever they want with it

They can re-license it they can do anything because they own the copyright

This document is made to deal with that

So instead of doing a full copyright assignment

What you are doing is assigning the economic rights over that code to the KDE project

Whilst retaining the moral rights of the code the rights to be identified as the author

So they can go and operate legally on your behalf if they ever need to go to court to go and fight some

Copyright troll or something like that. They can easily go and do so but you still own the code

This also means because you are still the author

They can't go evil down the line and then re-license all of the code

Also, it is an optional document

So if for whatever reason you don't like the terms of it you don't have to sign this one now as for the developer

Certificate of origin as I said, this is so light. This is so simple. This is the entire document

It hasn't half loaded. There isn't a longer version of it. This is everything. It is so basic

It is often described as the anti-CLA because it doesn't provide any additional rights

basically all it is saying is

You own the code and it has a suitable open source license and to the best of your knowledge

It is based upon works that you have the right to see you have the right to use

So it's a fork of some open-source project under a compatible license

It's not based on leaked code from a code base

You shouldn't be seeing you're allowed to use the code and the contribution is being provided by you or on

behalf of somebody else who wants the code to be contributed that's all

No additional rights. It is basically just saying we have the right to use the code

You have the right to use the code

We agree on this. It's pretty much to say if somebody does contribute code that

Maybe wasn't allowed to be in there. Maybe they intentionally did so. It is a very easy way to say

Okay, you agree to these terms don't do this again

And if it is malicious get out of here now in the past few years

whilst there has been some disagreement about the Fedora projects contributor agreement about whether it's doing too much whether the

Automatic licensing of unlicensed code should really be done whether that really makes sense

for the most part all of these documents are

considered at least

neutral if not positive even the case of the FSF's copyright assignment

specifically because it's being done with the FSF if you're doing a copyright assignment to say

Microsoft you might have a very different opinion and

That's where things like the discourse CLA come in because the discourse CLA is

Why people have an instant negative reaction to when they hear the term CLA?

If you ever see this phrasing right here you grant to the company this being a discourse in this case a non-exclusive

Irrevocable worldwide royalty-free

Sublicensible

Re-licensible, that's the big one transferable license under all of your relevant

intellectual property rights to use copy prepared derivative works of

Distribute and publicly perform and display the contributions on any licensing terms including without limitation a

open-source licenses like the GNU GPL v2 and be

Proprietary or commercial licenses except for the license is granted here in you reserve all right title and interest in and to the contributions

This right here is the big problem

Re-licensible because what you are saying here is I

Don't actually care about the terms of the license

If the company does not like the license and they want to go and change it to something that's more suitable

Maybe they want to go from GPL v2 to MIT maybe a proprietary license

You have given them the right to do so the problem with a CLA in this case is the unbalanced rights

You can't go and re-license

But they can when you see cases as extreme as this I think it is fair to argue that the project you're looking at

Might not even be an open-source project anymore. I definitely don't think it's a free software project, but

There's at least an argument to be had about whether or not something like this

Really still qualifies as either of those categories

And I think as a general rule because there are documents like the discourse CLA

It makes sense to immediately have a negative reaction when you hear the term

But as we saw from things like the fedora project the KDE project even in some cases the FSF or the Linux kernel

CLA isn't always an inherently bad concept

They just often get very very misused when you see something like discourse. I would honestly recommend

Running the other way. I don't consider this a free software or open-source project

If you have the ability to re-license my code now some people might disagree

Some people might be fine with it

But what is very important is if you see a document like this

Read the document and try to understand it if you don't understand it

Try to find someone else who knows what is being said someone who's hopefully broken it down if it's a good project

They're gonna provide an FAQ for example fedora does exactly that if they don't provide an FAQ

If they don't explain what all this means

Honestly, I would trust them even less. I am not here to defend CLA

Most of them suck. This is just a fact

But sometimes you might run across something like the developer's certificate of origin and it just doesn't really matter

It's completely okay. It's gonna be pretty rare, but maybe it happens. Anyway, if you

Learn something today

Let me know

Down below. Have you signed a CLA?

Would you ever sign a CLA and would you be okay with some of the ones we've seen here where they don't really provide any

Additional rights is just more like filling in some of the gaps

I would love to know so if you liked the video go like the video

And if you really liked the video and you want to become one of these amazing people over here

Check out the Patreon, SubscribeStar and LiberaPay linked in the description down below

That's gonna be it for me and

CL away

I don't know what to do with the outro sometimes