We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Fiduciary License Agreement

00:00

Formal Metadata

Title
Fiduciary License Agreement
Subtitle
Lessons Learned
Title of Series
Number of Parts
199
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
The first version of the Fiduciary License Agreement was published by the FSFE in 2007 in order to offer something that was missing at that time — a well balanced copyright assignment for the FS community. Since then different FS projects have made use of it. Some to assign copyright to FSFE and others to assign it to different entities in order to take care of paperwork and copyright issues for the FS project. In this presentation we will look at the lessons learnt in the diverse history of the FLA and look ahead what is in line for the next version of the FLA. The Fiduciary License Agreement [FLA] is a very well balanced copyright assignment that is beneficial for both organisations that foster FS project and the contributors. Its main goals are to: - make sure the project stays Free Software; - make license maintenance easier for the Fiduciary (the entity); - retain as much freedom and power to the Beneficiaries (the contributors) over their own code as possible not to make the software non-Free. After a short introduction, we will look at how FSFE and other entities — from dedicated FS organisations to businesses and individuals — have made use of the FLA and which lessons were learnt in those 6 years. At the end of this session we will peek into the future of the FLA and discuss improvements aimed at the next revision.
Identical particlesHookingMereologySystem callQuantumUniverse (mathematics)Computer animation
CodeFreewareSoftwareSoftware developerCASE <Informatik>MathematicsRight angleRule of inferenceExclusive orBus (computing)Natural numberVideo gameFile formatParameter (computer programming)Analytic continuationOpen sourceWordDigital rights managementProteinState of matterFreezingCodeLecture/Conference
Polarization (waves)Software developerTerm (mathematics)Self-organizationCodeRight angleOscillationTouch typingArmDistanceEndliche ModelltheorieDataflowEnterprise architectureMultiplication signFreewarePhysical lawRevision controlPopulation densitySoftwareResultantVarianceCASE <Informatik>Plug-in (computing)AdditionCodeNoise (electronics)Software maintenanceWordSound effectComputer programGroup actionReading (process)Slide ruleBackupPhase transitionOffice suiteVideo gameChemical equationSelectivity (electronic)Alpha (investment)Arithmetic meanWritingIntegrated development environmentMereologyChaos (cosmogony)Computer animation
FreewareProcedural programmingCASE <Informatik>CodeSoftwareSoftware developerRule of inferenceBitMereologyRevision controlVotingNumberOpen setStandard deviationSoftware bugForcing (mathematics)Order (biology)System administratorCore dumpPatch (Unix)Form (programming)Chemical equationCuboidGroup actionWordArithmetic meanPhysical lawSubsetEnterprise architectureArmStability theorySet (mathematics)Open sourcePoint (geometry)Physical systemDistribution (mathematics)Overhead (computing)Figurate numberLibrary (computing)Structural loadBlock (periodic table)MassDynamical systemQuicksortFraction (mathematics)User interfaceDiffuser (automotive)Video gameComputer animation
SoftwareMultiplication signChemical equationWordExclusive orRight angleContent (media)Web pageInterpreter (computing)Self-organizationCASE <Informatik>Software developerOffice suiteCellular automatonArmPoint (geometry)Term (mathematics)Revision controlMereologySurfaceDigital rights managementVacuumSet (mathematics)AuthorizationPhysical systemMoment (mathematics)FreewareOrder (biology)QuicksortEvent horizonAxiom of choiceNatural numberDebuggerExpert systemLogicThread (computing)Group actionRadical (chemistry)Formal languageOpen sourceSign (mathematics)Lecture/Conference
XML
Transcript: English(auto-generated)
The truth is that I'm just embarrassed to try to pronounce your name. Are you a true kleptomaniac? Yeah, I'm a true kleptomaniac. It's easy to remember. Are you introducing yourself? I will introduce myself. I'm willing to, but... Oh, awesome, you're doing it then. Thank you.
And your talk's on the FOI lesson plan? Yeah. I'm going to go... Okay, so thanks for coming back. Our next speaker is the distinguished Matija Shukla, sometimes known as Hook.
And he's going to talk about the Fiduciary License Agreement, a very interesting and innovative contributor agreement that FSF Europe developed. And I will turn it over to him. Hello, my name is Matija Shukla, and I work for the Free Software Foundation Europe.
More specifically, I'm leading the legal team. I hope that the DJI jacket stays where it is. It's a bit flimsy. And I'm going to talk about the Fiduciary License Agreement. And we're going to start with a short introduction of what it actually is and what it does,
and continue with analyzing... Could you speak up? Speak up? Okay, sorry. So we're going to start with the talk. I'm going to start the talk with a short introduction of what the FLA actually does. And then continue using four use cases to show what the lessons are
that we learned in the past six, seven years that we've been using it. And later on, continue with where we want to take the FLA in the future. So starting off with what the FLA actually is.
And this is the Dev Room for the legal talks. So I think I can shorten it up very easily to say this is a copyright assignment that is written specifically with the communities, with the free software project
and free software communities in mind. So it's not written to benefit the legal entity who gains the copyright, but it's there to make sure the software stays free software. Even if, for example, if the entity would go batshit crazy someday later on.
So, of course, as any copyright assignment, it does have the benefit of gathering all the copyright into one place, which means it's a lot easier to manage the licensing. It's easy to re-license if you have to, so you want to update the license.
Although it does include a clause that says that it has to stay free software always, so the project is not able to just derail and become proprietary because the legal entity that got the copyright assignment went crazy.
It also provides some other rules that make sure that the fiduciary, which is the legal entity, continues with keeping it free software.
So, for example, some of the examples that we've already seen with FLA helping is if somebody stops contributing, you know how it is. You get a life, you get kids, you become unemployed or you become too employed, you get hit by a bus.
It complicates copyright managing a lot. If the person who wrote the code is not able to say yes or no to license change in their own work. So, for example, if you got stuck, if you wrote a piece of code in GPLv1,
got hit by a bus, and now not only does the project want to use GPLv2, but maybe use GPLv3 or whatever, and it's incompatible, they're not able to use your code anymore. So, for such reasons and also for helping with violations
because an entity with exclusive rights on the whole code base has a lot bigger leverage than just a single developer who got sued by usually a company or something. It does make sense to sign the FLA.
Yeah, it's any copyright assignment, but as I'm going to explain, the FLA does things in a way that makes sure that you're also protected from the entity, not just by the entity. So, how does the FLA work in a nutshell?
I'm going to explain it in plain words because this is a lightning talk, but for an overview, refer to this picture, and for legal subtitles, refer to, as usual, the tiny text hidden somewhere in the picture. So, in a nutshell, the beneficiary, that is how the document calls the awesome developer,
assigns full copyright to the fiduciary, which is the entity which makes sure that the copyright,
sorry, the fiduciary is the entity or it can also be an individual who holds ultimately the copyright from the whole project and is facilitating that copyright and making sure everything runs fine when it comes to copyright.
It's not necessarily the same organization that manages the everyday work of the project, but it's advisable if it is because they at least know the project a lot better and also know the developers themselves. Okay, so now the fiduciary has all the copyright,
but assigns basically a non-exclusive version of the same back to the developer. So, the end result is plus an additional license to, an additional non-exclusive license to make sure that the developer can really use their own work in any way they want.
So, the developer can then license their own work under any license they want to anybody they want. So, including if for some reason you need to as part of a proprietary project.
On the other hand, the fiduciary not only is allowed to only offer it under a free software license, but according to the document is also required to publish it as free software. So, as you can see there are some carefully selected checks and balances
that make sure that the project stays free software. And one of the biggest checks and balances comes already from the name of the document, the fiduciary licensing agreement, fiduciary meaning trust, which means that if the trust by the beneficiaries that they invest into the fiduciary is broken,
the FLA terminates automatically and all the rights flow back to the fiduciaries, so to the developers. And from the fiduciary, which means that the entity now has no copyright in the thing.
So, I'll continue with the four use cases and start with the smallest one, which is Aonic. Maybe you've heard of it, probably not. It's UML based SDK to write Python code.
So, from what I understand you actually use UML to program and Python codes automatically comes out. I haven't tested it yet. So, the project started in 2007 as a proprietary solution and in 2009 they assigned, all the developers assigned their copyright using the FLA to the FSFE
and released the code under the GPLv2. Nothing major happened since then in terms of legal stuff, but in 2014 when I got in touch again with the main developer and the maintainer of the project,
he said that they're starting again after, I don't know, a year or two of dormant phase and they're thinking of upgrading the license to something newer, maybe even to AGPL.
So, the next one is Bakula, which is a fairly bigger project with around 60 developers.
And with Bakula, the thing is that it started in 2000 as a proprietary enterprise ready backup solution and in 2002 they released the code under the GPLv2 and the documentation under the FDL. In 2006 they assigned all their copyrights using the FLA to FSFE
and we assigned them a random of understanding regarding licensing. But things started complicating around 2008 where the main developer and still current maintainer
started gathering copyright assignments from the developers themselves, which included also the right to release the code under a proprietary version. So, in terms of code, what happened is that now there was a community version,
which was a GPLv3, and a proprietary enterprise version, which included some additional plugins. In terms of legal stuff, it means that we suddenly had this one group of developers who assigned their copyright to FSFE
and another group of developers who assigned their copyright to Kern Sibbald and an overlap of the two, which obviously caused massive chaos. So, in 2013 we sat down and discussed it like adults
and because part of the code copyright flows kind of from the developers using the FLA directly to FSFE,
the other one flows from the developers using the copyright assignment to Kern Sibbald, but because Kern Sibbald signed the original FLA to the FSFE and the clause is included, that same code also flows from the copyright of the code, also flows using the current FLA with the FSFE back into the FSFE.
Because you have this first, we cannot stop the code being used in a proprietary environment because the developers have agreed with it, and as we saw in the second or third slide,
that's explicitly allowed with the FLA and makes sense. But what we did is we sat down and we discussed the whole issue and what we agreed upon is that all the features that are in the Enterprise edition
have to flow in due time back into the community version, so they have to pop up into the free software version in a few years. The same goes for patches, obviously, and they will start reporting how much they contributed to the free software version,
and there's also some checks and balances to make sure that if the code gets, of the Enterprise edition, gets under the copyright of FSFE in case Bakula Systems stops distributing the Enterprise version
or if they stop contributing to the free software version or the company goes belly up or whatever. There's also a trademark clause. We also get the trademark along with the code if the company goes belly up.
So that way we made a proprietary project, which was an open-core project later on, into something that still has some proprietary bits,
but ultimately all the proprietary bits are going to be open-source because there is an agreement about it, including damages. So it's not just something we signed because we don't have anything else to do.
The next case is KDE, and this is a really huge thing, not just because the project is humongous with developers from all over the world and a huge code base, but also because of the fact,
and the fact that the first version of KDE was released ten years before they joined the FLA. They had this huge number of contributors and this huge code base and documentation, obviously,
that requiring suddenly that everybody should sign the FLA would be a tremendous effort. They figured out that's not the way they want to go because it's too much work, and what they do is that they recommend, really worriedly recommend the developers to sign the FLA,
but don't force them to. Apparently it works really well for them. More and more developers, and most of the core developers have signed it. It's also different that they don't use the vanilla version of the FLA, but we work together with the KDE EV, which is the NGO that handles the community of KDE,
to modify the FLA to suit them a bit better, and also to change the fiduciary to point to KDE EV. As part of the modification is also the FERP, which is the Fiduciary Re-licensing Policy,
which is a separate document that says under which licenses, each kind of contribution must be licensed. So you have like, I don't know, it says if it's a library, it can be licensed under the LGPL V21 or BLA or something.
So you have like groups of contributions and groups of acceptable licenses for them. It also includes a procedure that the KDE EV has to take if they want to re-license a piece of code.
So even if a developer has assigned their copyright to KDE EV, they still have to follow those rules. And it's a very stable dock. It's in fact, it's so stable that you have to, the KDE EV, in order to change the re-licensing policy, has to have a vote with the same majority
as if they would change their own constitution. So another project that uses the FLA is a EU funded educational project that is about free software and open standards. The self-project started in 2000 something,
and it ended in 2009, and part of the consortium, part of the self-consortium is also FSFE, and since it stopped in 2009, there's nothing new to say about it. Sorry. Okay.
So what we learned from all this is that the FLA does in fact make projects' lives easier, and it's also, if you explain it well enough to the developers, it's well accepted by the developers, and they like to sign it if they understand it, which also means that we learned that it's very efficient,
that, I mean, legal text, even if they're nicely worded, like I think the FLA is, it's still, geeks are still going to try and find bugs in it. I mean, that's what we do. So what you have to do, you have to prepare for that, and the best thing is to do that is in person,
like have talks at conferences, have BOF sessions like the KDE people do, et cetera, so you can discuss in person what their fears are and figure out if there actually is a bug or there isn't.
So what we also learned is that it is an administrative overhead, but that's kind of to be expected when you're handling copyright of other people, right? It's also, as an example of KDE, the fiduciary licensing policy and having a patch policy
are a very good idea to have, and we're actually thinking of maybe incorporating that into the FLA as well, into the vanilla version. So what do we want to do with the FLA in the future? We want to make it more user-friendly, because honestly the form you have to fill out,
the user interface, is not very transparent. We want to make that one clearer, so you don't have to always explain to people what does each box mean. But I'm exaggerating that people understand it.
I want it to be clearer. The wording is really good, but we have found some minor modifications that we want to do, and although the text is already tried and tested in Germany,
and it was also written in mind to be legal in both continents, in civil as well as common law jurisdictions, when we are talking to huge projects like KDE, we figure out there could be some issues within India,
so we're also trying to make sure that it works in Asia as well. And we also want to tackle new problems that we didn't anticipate back then, like patents and trademarks, and basically whatever the community needs it, which also means that I'm open for questions and ideas.
Pam? What happens with respect to enforcement of the copyright? So I turn over my copyright to the fiduciary. Does the fiduciary have any obligation to go after fromdoers that might be offending my choices or open source licensing? I don't think the text actually has an explicit clause about that,
but it is implied at least that if you complain and say somebody is violating my copyright, or somebody sued me, and you own the copyright. First of all, if somebody sued the individual developer, and the exclusive rights are at some organization,
the first thing you do is just, hey, exclusive rights, go ask them, not me. I just have a license. The other thing is I think if the fiduciary would not go after this, and they wouldn't respond if it turns out badly,
it could be considered a breach of trust. So the FLA would just void, and you would get your copyright back. So I missed a logical step that I'd like to get clarification on the back of the situation. You said that you couldn't prevent the one guy who did most of the vacuous stuff
to proprietorize because he had all those copyright assignments. But there's an assumption there that it means that he must have collected copyright assignments from everyone who ever signed in an FLA for that to be true. Is that what happened? As what we understand is true.
So how did that happen politically? I'm curious. He missed everybody that ever signed an agreement with you to go sign an agreement with him? From what we understand, that's the case, yeah. But I agree, it's complicated. If that's not the case, we'll see what happens. But that's what the situation that we understand is at the moment.
The thing also is that when you mentioned the logical stuff, Kern is also the owner of Bakula Systems, which is the company that does the proprietary version, and is the company that already had employed most of the developers for Bakula in the past as well.
Mr. Zak? Yeah, so trying to prove your point that geeks try to, you know, nitpick on legal things. So I noticed that, and I just read the FLA. I agree with you, it's very well written. But there is a sense which is kind of weird.
In the event FSFE violates the principles of Twi software, so do you think that's kind of impossible? Yeah, that's the question we got a lot. But what are we going to do? I mean, that's always the question between natural and humanitarian sciences.
I mean, especially when we're talking about the world of is versus the world of should, which is the legal world. So yes, it is a vague term, but I think that if we're talking about free software,
we're talking about something that quite a few NGOs agree upon, and those NGOs are considered to be the interpreter of what free software is. But yes, it's not very explicit what it says. But then again, if it was very explicit, we'd have to update it every time a new thread came,
and then you can have like a really verbose text, and that's even easier to find. If you have a really verbose text, it's even easier to find loopholes in it, because it doesn't say explicitly that. I mean, if you have like a definition of five pages long,
it's kind of weird to say yes, but that was implied. So it was back there. I think the gentleman at the back was first. How does the FLA compare to the FSF copyright assignment? I haven't invested much time in the FSF copyright assignment,
but from what I understand, and Bradley correct me if I'm wrong, the FSF copyright assignment is intended for the GNU project and group project only, and what we're trying to do with the FLA is not gather copyright of other people, but we're actually making this document for also other organizations to use.
And especially if you have a foundation that already handles, manages that project, it makes a lot of sense to use it to assign your copyright to that foundation, not to FSF, EFSF, or anybody else.
Or to some NGO that is expert in handling copyright of free software projects. I might feel much more comfortable assigning my copyright to the Free Software Foundation,
or FSF E, because hopefully they would have a good idea about what keeping up to date with what free software might lead and tell, given sort of the nebulous language that's used to provide this legal tool inside it.
So what do you think about assigning copyright to some other NGO that uses free software, but maybe at the front end that's a tool that in the future could conflict with a free software deal? As I said, the FLA has some checks and balances in case the fiduciary, so the entity you assign your copyright to, starts violating the basic rights of free software.
So does that answer your question? It sounds like you're saying that it's dangerous to assign your copyright to an organization like that, because at that point there's more of a chance that the FLA might revert,
at which point it sounds like you would have to go back to the community and renegotiate, because the agreement had fallen apart, is that correct? Because if the FLA falls apart, it sounds like you need to renegotiate with people. Yeah, but at least with that person whose FLA terminated.
But I'd have to look into that. I think we're out of time, unfortunately. Thank you so much for the discussion. So if you want to stay, please, everybody move over to the left-hand side.