Contributor License Agreements Ruin Most FOSS Projects
Summary
TLDRThe 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
๐ 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.
๐ก๏ธ 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.
โ๏ธ 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.
Mindmap
Keywords
๐กOpen Source
๐กFree Software
๐กPermissive License
๐กCopyleft License
๐กContributor License Agreement (CLA)
๐กFiduciary Licensing Agreement (FLA)
๐กDeveloper Certificate of Origin (DCO)
๐กRe-licensing
๐กCopyright Assignment
๐กDiscourse CLA
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
Browse More Related Video
There Is So Much Here..
Welcome + Opening Remarks - Austin Parker, OTel Community Day Event Chair
The Vulnerability History Project: Revealing the Past to Build a Better Future for Software Security
WinRAR And The Infinite 40-Day Trial
The mind behind Linux | Linus Torvalds | TED
Generating scan reports with Trivy
5.0 / 5 (0 votes)