I think we should just go into it and you don't need anything to do, I think we should just go into it and you don't need anything to do, I think we should just go into it and you don't need anything to do, I think we should just go into it.
Yeah, so hello, let's start. I'm afraid to have such a big audience. I'm actually sort of shavage licensing and compliance manager at the e-free software foundation. I will facilitate the panel about managing copyrights in free software projects.
Apologize for everyone who needed some kind of introduction will just dive quickly deep into a very detailed issue of copyright assignments and the developer certificate of origins.
We don't have much time, but I hope we can focus on really important details. Thanks for having this panel to the organizers and thanks for the panelists that you found time to join us.
I'd like to start with a short round of introductions, so like can you just tell a few words about yourselves? Would like to start?
Okay, hi everyone, so I'm Ludovic, I'm Co-Maintainer of Gall, which is an implementation of this game programming language and founder of Geeks, which is a package manager and this tool.
My name is Craig Topman, I'm the Copyright and Licensing Associate for the Free Software Foundation and one of my many duties is the copyright clerk, which handles the copyright assignments for the FSF and Genew.
Hello, my name is Andrea Coralla, I'm a new contributor for the genital chain, so GCCB News is well-lapped.
I must contribute to it, and I must maintain it, during my daily job, I must see if you will architect it.
Hi, my name is James Baltimore, I'm a Linux kernel maintainer, and back in 2005 when the DCA was first invented, my job was to evangelize it throughout the industry, so it became industry standard.
Hi, I'm Karen Sandler, I'm the executive director of Software Freedom Conservancy, I am also a lawyer and lecturer in law at Columbia Law School.
And I'm really excited to be here, I was going to say more, but we should keep the shirts, so we can talk about the stuff.
Yes, thanks a lot, I hope we can add a bit later, so I'd like to start with Andrea.
So you are an entertainer in a project that chose to accept copyright assignments, require assignments, so maybe you could tell you from your own practical perspective, how does it work, what are the questions that you get from contributors, what's the workload?
Yes, typically it works like that, say we receive a patch from a name which is not familiar to us, so one of the maintainers has to look in the copyright file to see if this contributor has assigned copyright.
If it's not the case and the patch is not trivial, then we ask the contributor if it likes to assign the copyright.
Typically it says yes, if it's a case we send him a questionnaire with a few questions to be filled, which I believe has to send to be sent back to usignet.org, whatever.
Then he gets in contact with FSF, he gets, I believe, two paper works to be signed, one is for him to send the copyright, the other of it is from the employer, if he has one.
When all this paper work is done, we get a feedback from FSF that the copyright file is okay, and then we can accept the patch.
So in terms of workload, that's essentially what we have to do.
I think general is speaking from my perspective, it works quite well, because in my experience the vast majority of people who discover how to send a patch for renewing max, they are willing to do the copyright paperwork.
What I find that perhaps is not optimal and we should work on it is that only the containers from the group perspective can access the copyright file.
So all the people that are maintaining subsystem in the max don't know who are official the people who are on copyright file.
And so for this we cannot delegate all of that. So there are only three people in the max project as to handle all this workload, which I think it's a bit suboptimal.
For the rest, I don't think it's a big problem, the patch typically has to be on all the processes finished, which is typically one to weeks, whatever, you tell me.
People are happy to send a copyright, that's my experience.
Okay, thanks a lot.
Could you pass the mic to Ludovic?
Because I wanted to also ask for a different perspective, so you're a maintainer or a commentator and projects that have assignments optional.
So maybe could you tell us more how this option works and why did you decide to step away from the assignment?
Right, so I'm a co-entainer of a guy and a guy historically always required copyright assignment for contributions.
This is a decision that was made in the early days of the project before and then we go on myself became co-mentainers, so we just followed that process.
And three years ago, I think we decided that copyright assignment was a barrier to entry.
It's not the only one we have other problems in the project that we, when it comes to accepting patches, etc., like any free software project.
But still, this was a barrier to entry and we felt like the cost-benefit ratio was becoming too low, too bad.
And so we thought maybe we could just keep everything in change for existing contributors, people committed to developing the project.
But allow newcomers to contribute without having to go through the copyright assignment process, which can take, you know, some time depending, you know, some time it can take quite a bit of time, sometimes less.
But still, a guy is a project where people can make easy contributions, so it's becoming quite large.
So some contributions typically come from people committed to work for a long time, but others can be made by people who might send just one patch to the project.
And we want to be able to accept those contributions without having this extra barrier, essentially.
And so what we chose was to allow contributors to choose what they're going to do.
So if someone committed, can say, well, I prefer to assign copyright to the FSF, and in that case that's what happening.
But others can say, well, no, I just want to fix this particular problem and get my patch applied, and that's it.
Okay, thanks a lot.
Could you pass the mic to Karen?
So your perspective is, I think, yet one more different perspective, because the SFC, you have your own assignment policy, but you also, as a lawyer, I assume you have a lot of thoughts about this process.
So how would you like to comment on these two approaches, or maybe given the illegal ramifications, you have some comments, what's your.
So for freedom, conservancy, copyright assignment is optional for remember projects, and then we take assignments for non-member projects.
And it's very easy, we have an online assignment form, and you can just go ahead and do that and that's very helpful.
I would want to say, like, you know, generally speaking, when you have a strong copyright license, having diversity held copyrights, has a real advantage.
And so when we do copyright assignments, we're aggregating those copyrights in single entities potentially.
When those entities are companies, that can be a real problem.
But even with nonprofits, when you aggregate those copyrights together, making sure that those nonprofits have good governance is a really critical piece of that.
And having some of the copyrights assigned, so you have a weight of aggregation means that you can do something with those copyright assignments.
You can take action, like we have done at software freedom, conservancy, and so making sure that you have those actions that they're done in principal ways and that they're, you know,
brings weight to that copyright left licensing that otherwise simply doesn't exist.
Just because you license your code under a copyright left license, doesn't mean that someone will actually do it.
They're supposed to make it the secret.
And making sure that there is enforcement out there is extremely important in having those copyright that copyright aggregation is a tool to be able to do that.
And so, you know, we at software freedom, conservancy, have used that aggregation and I think it's incredibly important in seeing the different ways in which different projects do it.
You know, I think is notable too.
I mean, I'm not sure what to add from a legal perspective really.
But you know, if people had questions, I would be happy, did you have anything specific about the legal or ramification?
Well, okay, so maybe let's leave it for now. I hope we can still have some time for questions, maybe you can add.
Yeah, okay, so could you pass Mike to James? So James, when we emailed about the panel, you described yourself as a DCO advocate, well known DCO advocate.
So I wanted to ask you as the strong proponent of DCOs.
What are the benefits of DCOs? And if there are any drawbacks, you can name maybe you could also tell us how DCOs works.
Yeah, sure, so the main different, well, to go back historically, the reason why the Linux kernel has a DCO is because we saw copyright assignment, which was then the preferred model of the FSF as a significant barrier to contribution.
One, and two, Linus Tuvels just was not prepared to run the admin required to do it, even though the OSDL is that then was would have helped him.
So we insisted that the OSDL design a new process that helps us. So the DCO is effectively a representation on behalf of a developer.
This is actually has legal force because it's a promise that a developer made that they, you know, they have the right to contribute or they know the person who wrote the code and he has the right to contribute and so on.
So it provides that legal framework, but all of this came out of the school lawsuit against Linux.
And the primary problem we had was that we needed to trace the origin of every patch in the tree.
So if you gave me a line of code, I would be able to say who effectively was the final sign off on that.
So if we have a problem with that code rather than getting sued over it, we can simply remove it.
And so there are two things that underpin the DCO. One is the representation, but the other is tracking through the source tree of exactly how that code got into Linux kernel, which allows us to do something about it if there's a problem.
And we believe thanks to evangelization throughout the industry that the strengths provided by DCO, particularly as Karen says, the distributed copyright ecosystem,
I equal to the strengths that you would get if you did just did ordinary copyright assignment.
When I first started this, that wasn't true because the DCO was largely an unknown process, but by making that process standard the industry, everybody knows how to do it, everybody knows what it is.
It's incumbent on company's contribution to the Linux kernel to find out what the DCO means to them, rather than us having to prove that we explained it to them, which is a great strength within the industry.
Okay, thanks.
I just wanted to add one other piece that I should have probably said, which is that the assignments are very, very helpful when you have when people die and their copyrights are inherited by their errors.
And we have had situations where we've had to do tricky kind of code relicence issues and having to go and find the the errors of the copyright holders and explain to them that we've got 15 minutes left by the way.
You know, other than, you know, explaining to them why they would want to agree to a relicencing and sometimes the people who are the surviving errors don't understand free software at all.
I do want to say that if you if you're not assigning your copyrights, please have a conversation with your loved ones who will inherit your copyrights to explain to them that you care a lot about software freedom that you care about the free licensing because we have had errors say my spouse care you know care I hear what you're saying that they cared about free software, but actually they cared about me more.
And if you pay me a huge amount of money I will relicence my code and what happened in one of those instances was that code, you know, turned out to be not that important it was written around and that person's contributions are no longer a part of the code base, which is really just so heartbreaking.
One point that Karen forgot there which is copyright assignment does not overcome something in the US called revocation.
So the airs may still be able to claim copyrights even if you've been assigned. So it's important if you want to do this not only to assign your copyrights in your lifetime, but you also have to will them to whoever you gave them to in your will so that it actually is binding after your death.
Yeah, well, these are these jurisdictions specific.
Yeah, specific, but it's an important point to bear in mind.
Okay, so I'd like to finish this first round by asking Craig, could you present the FSF's perspective on copyright assignments?
How does the purpose, how does it work?
Well, the purpose is for enforcement of the GPL for the GNU project and currently the optimal way of doing this is by the copyright holder.
This may change in the near future, but currently globally copyright is something that can be enforced this way.
Other advantages if we're going to have to rely on some of its works, the copyright holders and the person that can do that.
So, I'm on a blind, sorry.
Well, from let's say the bigger picture, so because that's the kind of procedure, but I think when we're talking about this, you said a lot about the world is kind of ideological perspective.
Why the FSF is doing this, so maybe we wanted to elaborate.
I did have more to say, but I just appealed times very limited, and I'm going to open it up for questions.
Okay.
All right, so I still have a question, a couple of questions, then we can maybe give it to the audience.
So I also wanted to ask Karen, especially like we just had the presentation about enforcing the GPLs by user, the Sebastian, and so from the perspective of this so called third party rights, third party enforcement, which is a way that you can go after the GPL violation.
How do you find assignments important given this third party rights enforcement?
Right, so those are two completely different ways of getting to the same result of having the company be compelled to produce their complete and corresponding source code.
But they're different legal mechanisms, and so within the free and open source software communities, we want to make sure we maintain all of our levers to be able to compel and compliance amongst companies.
And so I think, you know, as there, there have been court cases and various rulings and different jurisdictions relating to copyright licenses and the GPLs in particular.
So I think it's not quite as unsettled as maybe some people think, but at the same time, you know, different approaches will work differently in different jurisdictions.
So we really need to maintain all of our options available.
It's extremely important for these licenses to have meaning for them to be enforced and to have effect.
So making sure that we have copyright assignment with organizations and groups of people that will actually be able to take action is incredibly important.
And so copyright assignment making sure that we have good governance and organizations where we are aggregating copyrights and aggregating those copyrights to begin with means that we as a community have that power.
Having copyright assignment is a compliment to also being able to enforce using third party beneficiary rights and purchasers rights.
So I think we want to make sure we have every avenue and not limit ourselves to one.
So just from the kernel's point of view since we have no copyright assignment.
The kernel itself is a fiercely independent body of people, and part of the reason for not having assignment is they didn't really trust anybody else to act on their behalf.
And so the mechanism for enforcement within the kernel is that all individual copyright holders as Harold Velter famously did in the initial instance are still able to enforce their copyrights.
So this effectively gives us a community enforcement mechanism which we see as matching the values and philosophy of the kernel.
It's not to say that signing to a foundation is wrong.
It's just that if you're a fiercely independent community, you can use this as your sole mechanism.
I completely agree and that's why we also have the Linux kernel copyright aggregation project.
And so some Linux kernel developers have assigned their copyrights to suffer freedom conservancy.
And so that works very well in conjunction with also having individual developers doing their enforcement.
But we do see issues in terms of how successful that enforcement can be as individuals and so having aggregation also helps.
So both of both approaches within the Linux kernel which is fascinating.
So I think that the one of the important topics here is to protect project from violation claims, for example from the employers.
And so maybe Craig could you tell us more how copyrights assignment process in the FSF is designed to protect the project against employer claims.
So one of the mechanisms that we have is we require people that are employed to program to sign a have their employer sign a disclaimer,
basically saying that they have no interest in this and they won't do anything to affect it into the future.
This is important because both employers and universities can get really aggressive with lawsuits and making claim on their employees work.
I've come across employees who their employment contract stipulates that the employer not only controls what they do it work, but also controls what they do in their free time and on their own equipment.
That's pretty rare, but I've seen it more than once.
And that's a little alarming in my opinion if that was my employer.
But yeah, just a claim or so they won't turn around and say that this code belongs to them.
Okay, thanks and I still want to ask Andrea and Ludovic.
Again, from your perspective, your experience.
Have you ever experienced some kind of issues coming up after the either this highman or the this year was delivered?
Well, any basically legal problems or other issues?
No, we've never had any such experience.
The thing is, Guy and Geeks are two volunteer primarily volunteer driven projects.
So they're, I guess, the whole class of problems that we are less likely to have at this in the situation.
I mean, it's not Linux, it's not GCC, right?
It's pretty different. So our priority was really to priority.
Well, to make sure we can receive, you know, contributions from volunteers.
In that case, for example, the employer claims are less likely to be a thing, I guess.
Yeah, question for Gene. So with the DCO, let's say someone signs us on a work that used the DCO,
what is stopping that contributor from turning around and asserting a patent right on their contribution?
Well, the thing that stops a contributor asserting a patent they own on the contribution is the license.
So we rely on the patent properties of the license to do this.
Well, DCO is just a representation that you're contributing under the license.
If the license has no patent clauses, then obviously, patents are not bound by it.
And you need some other mechanism to do it.
It was designed to work with GPL2, which has an implied patent license.
So effectively, at least in the Linux kernel, everybody who signs off on a DCO is implicating patents
their own, but it's actually also a fact that not a lot of developers own patents.
So most of the patents we worry about are owned by third parties, and wouldn't be captured either by a contribution
signing a contribution agreement or by the DCO.
So, in effect, we actually have a very different mechanism called the open invention network
that actually provides a patent shield around the Linux kernel and helps us with a lot of patent problems
that you can't solve just with licensing and even contribution agreements or copyright assignments alone.
So, I think we have less than three minutes left, so maybe we can start asking.
I don't want to go one more.
Oh, I'll be clear.
Yeah, so I see a question here, maybe you can just start collecting them.
Two simple questions.
One, suggestions in academic work to be placed in open source.
And two, how do you handle a tainted contributors that you have to take out of the code,
because of legal status, blockades, whatever.
Well, I can take that.
And it's with both copyright assignments and the DCO you have to have record keeping.
This is answering your second question.
So, if somebody is a bad actor and they signed an agreement wrongly or they did a sign off by wrongly
and you actually have to remove their code.
In the DCO case, we have all the sign off by throughout the source code repository and the whole metadata
of the get tree.
So, I could identify every line that contributed to touched and it would be a decision of somebody
in the project, what we do about that line.
With copyright assignments, it's a slightly more manual process, because you've got the bad assignment.
You then have to map that back to all of their contributions.
But again, as long as you've got a strong source control system,
even in the copyright assignment project, you can do this slightly more manual.
But a script could do it for you, and you could again take out all of their code if you had to.
But the point about this is, bad actors in both systems were not caught by the fact,
just because they signed a copyright agreement, even though they're a bad actor,
even if there's some penniless person, you can't really see them.
You just have to remediate the problem, and the remediation is to take out the code in both cases.
So, in neither case, did the DCO system score better or worse than the copyright assignment system?
Anybody else want to?
Hi, I'm Mark Prudemov from the App Fair Project.
I run a project that does require copyright assignments or actually contribute to your license agreement.
There was some talk about the amount of friction that can add to the goto project and why they don't do it.
All we do is just have people edit a text file and add their username and add it as a full request to the geto repository.
Is that considered sufficient or do you need a lot more legal ceremony in order to be able to obtain copyright assignment?
So, I think that this is a little bit different from jurisdiction to jurisdiction, but it generally a copyright assignment has to be in writing.
And so, just editing a file to add your name.