Project Ownership & Project Enforcement: The Rules, They Are A-Changing
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 39 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 3.0 Unported: 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 | 10.5446/67213 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSS Backstage 202232 / 39
2
9
11
15
26
30
36
37
00:00
Source codeMereologyPresentation of a groupLecture/ConferenceMeeting/Interview
00:27
Computer programOpen sourcePhysical lawPersonal area networkSmith chartRule of inferenceSoftware repositoryFunction (mathematics)Physical systemDistribution (mathematics)CodeSoftware maintenanceSimilarity (geometry)CodeSoftwareBuildingLevel (video gaming)Perturbation theoryPhysical lawBitExpected valueFunctional (mathematics)Interpreter (computing)ChainMereologyPhysical systemProjective planeSubsetTerm (mathematics)NumberQuicksortRevision controlArrow of timeComputer fontHypermediaProcess (computing)Distribution (mathematics)Software repositoryOcean currentSet (mathematics)Open setDistributed computingOpen sourceEndliche ModelltheorieDifferent (Kate Ryan album)AuthorizationMultiplication signFreewareRight angleSoftware developer1 (number)PhysicsSoftware maintenanceCASE <Informatik>OutlierCloud computingComputer animation
08:28
Software maintenanceSimilarity (geometry)Computer programVirtual realityOpen sourcePhysical lawPersonal area networkSingle-precision floating-point formatRange (statistics)Data structureSound effectElectric currentTheoryDesign by contractControl flowGroup actionState of matterCodeOrder (biology)CodeMathematicsSoftware testingDecision theoryState of matterBitPrice indexSphereTheoryPhysical systemProjective planeResultantSubsetTerm (mathematics)CASE <Informatik>Musical ensemblePoint (geometry)Open sourceView (database)Endliche ModelltheorieDifferent (Kate Ryan album)AuthorizationCommitment schemeMultiplication signRight angleTwitterDesign by contractSoftware developer2 (number)Computer animation
16:29
TheoryControl flowGroup actionCodeState of matterOrder (biology)Computer programOpen setVirtual realityPhysical lawPersonal area networkSoftwareDesign by contractCodeOrder (biology)Self-organizationProduct (business)State of matterBitGroup actionConformal mapMereologyTheoryProjective planeResultantTerm (mathematics)NumberQuicksortGoodness of fitCASE <Informatik>PressureDirection (geometry)Open sourceEndliche ModelltheorieDifferent (Kate Ryan album)AuthorizationMultiplication signRight angleTwitterDesign by contractInternet der DingeSoftwareConservation lawArithmetic meanPoint (geometry)Source codeComputer animation
24:30
Order (biology)Vector potentialGroup actionProjective planeResultantRight angleMechanism designInformation technology consultingLecture/ConferenceMeeting/Interview
26:09
MathematicsElectronic mailing listPublic key certificateSoftware developerSelf-organizationOSI modelEndliche ModelltheorieLecture/ConferenceMeeting/Interview
26:45
CodeFunctional (mathematics)Projective planeTerm (mathematics)QuicksortEvent horizonCommitment schemeLecture/Conference
27:39
Open setOpen sourceCASE <Informatik>Lecture/ConferenceMeeting/InterviewComputer animation
Transcript: English(auto-generated)
00:04
Thank you, so we've now entered the part of the conference where the lawyers come in. I hope that doesn't draw you away. I'm a lawyer based in the United States and I think our next presenter is also a lawyer, so
00:21
hopefully we can keep you engaged on legal topics. So I'm going to talk about two issues that are sort of hot right now in the open source legal world. You may or may not have encountered these in your practice, wanted to just make you aware of them, kind of give you a background of what they're about and
00:42
where I think they're going. So I'm going to start off with a little bit of kind of history of free and open source software as it relates to legal questions. So I think if you've been working in this a long time and open source has a free and open source software has a long history, the
01:01
initial stages of that sort of software. It was a very small community of developers. The distribution model was pretty limited both in the number of people that were involved and in the way that distribution was done. I mean you actually had to use physical media to distribute software to other
01:21
people. So it tended to be a small chain of people giving code to one another, of course under a FOSS license, but not a very sophisticated chain of distribution. Of course it is now gigantic as represented by the left side
01:41
here. There are hundreds of thousands if not millions of developers all of whom are transmitting code, code contributions through repos which are getting reproduced as forks which are feeding back to the repos. It's getting
02:00
distributed through containers. There may be many different projects assembled together into a software build and all of this stuff is being transmitted back and forth between any number of different parties each with a software license associated with it. So I didn't put a software license on each of those
02:21
arrows because there's way too many of them to present here, but each of those have got some sort of software licenses associated with it. So now I want to talk a little bit about the function of software licenses. I think most of you are probably familiar in general with what the licenses are about and the
02:42
rights and freedoms that they're supposed to give to the recipient of the code. But there's really kind of two ways to look at a license. The first way is the way which most of us lawyers look at these licenses are. They are either a legal permission or a legal agreement from the author or the
03:04
creator of the software to the person who receives it. So that's sort of the legal way of looking at it. There's another way of looking at licenses which is they are just an outline of generally understood expected behaviors. So in the
03:22
early days of open source, free and open source, when the sort of small distribution model using physical medium existed, the second one of those functions was much more important. So there were not people going around
03:42
saying I'm calling my lawyer, you're not following the license. It was a small community. Generally everybody kind of knew how they were expected to behave. They weren't looking at the license to see how it should be interpreted or how it might be used against them. It was just sort of as the Free
04:01
Software Foundation has said about the GPL, there's a constitution of behavior and expectations of how that behavior will operate. So the legal interpretation was sort of downgraded in favor of the setting of expectations. Now that has changed a little bit. So I wouldn't say that the
04:23
expectation of behavior part of a license is gone. But the legal interpretation of licenses has become much more important and there's been much more focus on that. And the people who have been talking about OSPOs today have mentioned that. The legal people are starting
04:42
to look at things to understand what the law requires when you get code under a license. This is in part because the system of distribution has become so complex and there are so many different participants in the community that you have a greater risk of having
05:03
outliers. So people who don't follow the generally understood expectations that the license sets forth. The people who violate the license, who don't abide by the terms of the license or what the license says they ought to do. So we've got a little bit more of an
05:22
elevation of the legal aspects of these licenses. Of course, that means there's more lawyers involved in this process. Now that affects contribution policies in interesting ways. So I think most of you that have been working in open source know that open source projects
05:42
often have contribution policies. And contribution policies are ones that have been set up to deal with basically two things. First, what happens when you have a user of the software who doesn't follow the license? The contribution policy may be set up to
06:03
address that. It also sometimes addresses the problem that has occasionally been encountered, which is what happens if you actually have to change the license on the project? Now, sometimes that happens for good because there's a new version of a
06:22
license or that you detect a problem with the old license. And as Malcolm Boehm talked about yesterday, sometimes that happens for the bad. The open source license turns into a not really open source license. In each case, the question is, is the
06:43
disaggregation of the ownership of the IP of the code useful or harmful? Now, there are three basic models that are used for projects to allocate the IP rights in the code that's
07:03
deposited in the project. And I think some of you may be familiar with all of these three. They're certainly the subject of current debate right now. But they're basically this. One's called CAA, a copyright assignment agreement. And that's where the project says to anybody that's making a
07:20
contribution, we want you to give us ownership of the copyrights in the code that you want us to accept. So the project itself will own the IP in the contribution. And the IP ownership in that project is aggregated in that one
07:42
maintainer or that one project lead. Then there's the CLA, contributor license agreement. This is one that's fairly common in a lot of the projects that have been talked about here today. In that case, the contributor gives a license to the project of some scope so that
08:03
they maintain ownership of the IP that they created, and they give permission to the project to make use of those IP rights. So in that case, you've got a disaggregation of the IP rights. Each of the contributors retain their IP
08:21
rights. The project gets access to those rights, but the ownership it retains with the creators or the contributors. There's also something called license in equals license out. It's somewhat similar to CLA in that the project says to the contributors, we use a license
08:43
for this project when we distribute it out. We expect you, when you make a contribution, to use the exact same license when you give it to us. So the license into us equals the exact same license that goes out. Now that's somewhat similar to the CLA model, but it can be
09:02
quite different depending on the terms of the CLA versus the license out. So in this case also, you have disaggregation of IP rights. The contributors still own the IP rights and their contributions. The project itself only has rights to use those IP rights. Now, there are
09:24
some pluses and minuses for aggregated versus disaggregated ownership. If there's a single owner of all the IP, then that single owner is the one entity that's allowed to make decisions to enforce the license, to sue people who don't follow the license. It
09:41
also gives them permission to change the license if they see fit. If they decide for whatever reason it's time to change the license, they have all the IP rights and they own them and they can make that decision unilaterally on their own. If you disaggregate the ownership, those two questions become a little bit more complicated. To enforce the license, you have all
10:04
these different IP owners, all the contributors, each have pieces of ownership in that code and any one of them theoretically can go and enforce the license against somebody who's not following it. It's the same with the change of the license. Theoretically, you
10:23
have to get the permission of every one of those contributors to make a change of the license. Now, that could be good or that could be bad depending on your perspective on whether you think changing the license is a good or a bad idea. Same with enforcing the license against people who don't
10:42
follow it. These are the trends that we're currently seeing in this sphere. The Copyright Assignment Agreement is one that is becoming increasingly unpopular. In fact, the one place that has had a long-standing policy that you had to
11:01
assign your copyrights to them, the GNU project within the past year has said, we're not always going to require you to assign to us. That's a little bit of an indication that they understand that that model is becoming less attractive to a lot of developers. The
11:20
Contributor License Agreement is still very prevalent and many people still use it. Although there have been some people that have raised questions about whether it's a good idea to use that model. I have it as a little bit of a down here, not completely down, just because there is some subset of developer
11:40
advocates who say that's not the best model to use. License in versus license out is the one that's becoming much more popular. Many advocates are saying that's really the best model to accept contribution because it's completely reciprocal. The project gets rights, the same rights in the author's
12:03
code that the users get from the project itself. There's no difference in the rights to the project and from the project. If those trends continue, I think you're going to see much more dominant use of the
12:22
license in, license out model for projects in the future. I think CLA, Contributor License Agreement, will continue to survive, mostly because a lot of projects still use it and a lot of people trust the projects that they will not misuse the rights that they've been granted by the authors to do things
12:43
like change to a bad license or things like that. Copyright assignment agreements, I think, are going to become less and less popular over time. That's mainly because you've seen some examples of projects that have done things that the contributors have not
13:03
liked, which Malcolm talked about last week. People are now saying, I don't think it makes a whole lot of sense for me to give up my rights to my IP if that's a potential thing to happen. Now, assuming that current trends, this is what's going to happen,
13:23
that's a big assumption. There can be things that can happen that can change these assumptions in the way that people act. I'll talk a little bit about that next. Now I'm going to talk a tad about FOSS licensing legal theory. This is something that we, open source lawyers, have been debating for 20 years
13:43
very vigorously. Probably not a lot of you have heard about this before, but I wanted to introduce it to you, hopefully not in a way that's too complicated. There's two theories on how FOSS licenses work in the legal world. One is that it's called a
14:00
quote-unquote bare license, which essentially says anybody who wrote code gives a one-way permission to anybody who gets the code to use their IP rights. The second theory here is called contract theory. That's a more traditional model in the legal
14:23
world, which is it's a two-way agreement. The author gives a right to the user, and the user gives some commitments back to the author.
14:42
Now, for most people, that's not all that important, but it's becoming something that's going to be a test case here pretty soon in the United States. Now, the majority view of most open source lawyers is that it's a bare license
15:00
theory, so it's a copyright permission that goes one way to the user. The contract theory generally is not adhered to by a lot of lawyers. There is a case in France where this theory was actually validated, so that's one little difference between a lot of the other countries. There's also another theory that says actually
15:22
both of these ways of looking at open source licenses could work. You could use either of these theories if you ever went to court and tried to enforce a license. That has never come up, but it may in some point in the future. Now, why this legal theory matters,
15:41
and not just because it's an esoteric debate point amongst lawyers, it matters because depending on the theory that you use here, you may have different results. The biggest potential result here is who gets to go and enforce license noncompliance. Under the bare
16:01
license theory, it's only the authors of the code and nobody else. Under the contract theory, there's potentially other people, including recipients of code that is nonconformant. There's a case on that, which I'll talk about here in a minute, where that theory is going to get tested. Also, depending on the theory
16:22
in which you're using here, you may be in a different court. In the United States, we have two different systems of courts, the state and the federal courts. Under a bare license theory, you have to go to the federal courts. Under the contract theory, you can go to either state or federal court. That may make a difference in terms of the results
16:41
that you get, depending on the theory that you use when you're interpreting these licenses. There's also some other differences that occur here based on these theories. What sort of money may be awarded as a result of the violation? What sort of order the court may issue as a result of the
17:00
violation against the violator? There may be different defenses available to the license violator, depending on the theory that is used to enforce the license. These are interesting questions that currently really haven't come up in any of the enforcement actions that have occurred in the past, but at some point, they
17:22
may become important. Let me talk a little bit about enforcement trends. I think probably a lot of you know that in the early 2000s, there was a trend of license enforcement, primarily here in Germany and in the United States. GPLviolators.org
17:41
was an organization that first kind of pioneered suing license violators here in Germany, had a lot of success, again, in the early 2000s or maybe the 2010s. Then that was mirrored by some actions by the Software Freedom Conservancy in the United States. Again, they were going out and finding entities that were
18:03
distributing GPL code without providing the source, and they said that's a violation of the license. We're going to sue you. They got a lot of good results as a result of doing that. Now, what has happened since then as there have been some enforcement actions that have raised some questions about
18:22
the way in which you go about license enforcement? The two big cases here, both out of Germany. One involves an individual I think a lot of you have probably heard of, Patrick McCarty, who was sort of famous for going around and suing people in Germany and asking for increasing amounts of money. He had
18:41
a relatively bad setback in a case against Genia Tech. There was also another case that was filed against VMware. In both of these cases, both in Germany, some questions were raised by the courts about how do you establish that you're enough of an author that you can come to court and
19:02
say to the court, please enforce this license. If you have a disaggregated theory about who owns the IP, these sort of questions are going to potentially be raised when you try and enforce a license, and you may actually not be able to get a result from a court if they say
19:21
to you, you do not have the right author in here enforcing the license, or you do not have enough authors in here coming in to enforce the license. So these are raising some questions about enforcement theory, at least in Germany and potentially in other countries as well. Now, the most
19:40
interesting case that's current is the one that was filed last year in California, where the Software Freedom Conservancy sued Vizio for GPL violation. They said, I bought a Vizio TV. It didn't have the source code. There is easily established that there is GPL
20:01
code in there. That's a violation of the GPL, and I'm going to sue you. That was done in state court under a contract theory. So this is really kind of the first time we've seen somebody come in and say, first of all, we're going to try and enforce the GPL as a contract, and number two,
20:22
we're not going to even involve an author of the code in this lawsuit. We are going to sue as a person who bought the code or received the code as part of a product, and we have a right to that, and we have a right to sue as a result of that. I think that's the first time anybody has ever,
20:41
as a user, sued somebody for a GPL violation or a violation of a FOSS license. Now what does this mean, or some final thoughts here? I think a lot of these questions you may see come up if you're maintaining a project, at least on the contribution policy
21:01
stuff. You also see, it may seem, some debates about how enforcement ought to work in the future. What happens, for example, what happens if the contribution policy trends are going in the opposite direction of the enforcement trends? So if the contribution policy trend is,
21:22
we should disaggregate as much as possible the ownership of the IP in this project, but the enforcement trends say, if the ownership is too disaggregated, you may not be able to get the right people in court to enforce a license, you're creating a potential problem
21:41
here. So the contribution policies and the enforcement policies may be at cross-purposes. Does that mean that projects may go back to something like a copyright assignment agreement? I'm not sure they will, but if we have a case where it becomes clear that that's the best model if you want to enforce, you may see people start
22:01
reconsidering that. The other thing is, if you don't have authors as the person going out and enforcing the license, does that open the door for new problems? Now the case in California that I discussed, it's done by the Software Freedom Conservancy, a
22:21
very well-known open source advocacy organization that I think a lot of people trust to go out and find license violations and try and get them corrected, but if anybody is allowed to sue, any user is allowed to sue when they find a license violation, are
22:43
you going to have people you would rather not have sue going about and doing that? Of course, the worst example I can think of is you've got the lawyer who's looking to make money off of a lawsuit saying, hey, I bought this whatever IoT device or I bought this
23:02
consumer product. I was able to analyze the code on it and determine there was some GPL in there. I want to sue the company for a GPL violation and I'm not going to try and ask them to get in conformance with the GPL. I'm just going to ask for a lot of money for that violation.
23:22
Also, are there better ways to encourage compliance other than enforcement? This has been a long ongoing debate both by lawyers and community members about whether it makes sense to go out and sue people for license violations. Are there other ways to encourage them
23:41
to do the right thing and comply with the license? I think a lot of that has been going on for a long time. There are other knobs that you can turn to get people to comply with licenses, including pressure campaigns, public shaming, refusal to, say, cooperate with their
24:02
own contributions or their engagements the open source community. That has been going on for a long time. If there are trends in enforcement that determine that that's not the best way to get things done, you may see more of an emphasis on that in the future. So, that's about all I've got on this
24:22
topic. We're about at time, so are there, if there's any questions, I open the floor to it. I was wondering if, in your judgment, do these potential enforcement problems merit actually adjusting either the licenses or the contributor license agreements?
24:42
In order to give somebody a clearer standing. I wouldn't do it right now, because I'd want to see the results of some of what people have been doing. I think that you will find that if there is a result that comes out of some of the enforcement actions
25:02
that people ultimately decide was bad or is harmful, people will start relooking at their outbound license or their CLA or whatever mechanism they use to receive contributions and say, hey, let's turn the knobs on this to make sure we're not facilitating
25:22
bad behavior. So, yeah, that could happen. Consult with your lawyer. Then you end up having to re-license existing projects. Potentially, yeah. That would be a problem with the LELO mode, right? Although I will say that the re-licensing problem is much more
25:43
of an issue with copy left than it is with permissively licensed code, because if you've got a permissively licensed CLA and a permissively licensed outbound license, it's not a huge deal to change the license in that circumstance, unless your CLA says
26:01
something like, I will never change the license ever, which I'm not aware of a lot that do that. Some of them do say, I will only change to OSD-approved licenses, and then you have a dependency on an external organization, or OSI-approved licenses, I mean. Well, then you hurry to the OSI license approval list with your
26:20
new license and say, please approve this immediately. Okay, any further questions? Yep. How do you see the DCO, the developer certificate of origin, is that just a technicality of the inbound equals outbound
26:40
model, or is that an own contribution policy flavor? Yeah, so I didn't discuss DCO, and in fact, license in equals license out usually says plus DCO. The DCO is much more designed to be a commitment by the contributor to say, this is my
27:00
code. So that's not really an enforcement question in terms of enforcement of the actual project code. It's much more of a, well, here's something that we could do in the event that there were a malicious contributor. And actually, the DCO is much more designed to say, if I'm
27:22
committing this code to you and I work for a company that owns the IP, then I'm going to make sure that I'm allowed to give the company's IP to you. I think that's mostly the function of the DCO, so it's not really, I think, relevant to these sort of issues.
27:40
OK, there are no further questions. In that case, thank you very much. Thank you.