Legal issues from a radical community angle
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 | 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 | 10.5446/32562 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 2014169 / 199
2
3
10
11
12
13
14
17
18
19
23
24
25
27
29
45
46
47
48
49
50
51
52
55
56
57
58
65
67
68
70
72
74
75
76
77
78
79
81
82
84
86
87
89
90
93
94
100
101
102
103
104
106
107
109
110
111
112
113
114
115
119
122
123
124
126
127
128
129
137
139
141
143
145
147
150
154
155
158
161
163
164
165
166
168
171
174
175
176
179
182
183
185
188
190
191
192
194
195
196
00:00
SoftwareProjective planeFreewareProcess (computing)Queue (abstract data type)File Transfer ProtocolFile archiverMultiplication signSoftware maintenanceLevel (video gaming)AreaLatent heatComputer fileInformationSoftware bugTheoryQuicksortBitGoodness of fitCategory of beingDifferent (Kate Ryan album)Point (geometry)Fundamental theorem of algebraProduct (business)Term (mathematics)Web 2.0Ocean currentServer (computing)Direction (geometry)Materialization (paranormal)Range (statistics)Declarative programmingEndliche ModelltheorieScaling (geometry)WhiteboardMultitier architectureDensity of statesDistribution (mathematics)AuthorizationData structureExploit (computer security)CryptographySelf-organizationFile formatArithmetic meanAdditionCompilerOpen sourceSoftware developerPhysical lawTrailNominal numberSingle-precision floating-point formatMomentumRow (database)Similarity (geometry)Wechselseitige InformationMetadataCodeElectronic mailing listDefault (computer science)Basis <Mathematik>Interpreter (computing)Virtual machineConstraint (mathematics)Hacker (term)Heat transferCommitment schemeComputer configurationCASE <Informatik>Data conversionLine (geometry)SummierbarkeitMereologyPrototypeKeyboard shortcutEmailIdentity managementDecision theoryVotingCharge carrierParameter (computer programming)Copyright infringementView (database)WikiOperating systemLink (knot theory)CirclePower (physics)Interior (topology)Exception handlingOperator (mathematics)Content (media)Right angleCompilation albumSet (mathematics)Wave packetForm (programming)Revision controlDependent and independent variablesWordBlock (periodic table)Public domainLimit (category theory)Spectrum (functional analysis)Inclusion mapGame controllerOntologyShared memorySound effectDirectory serviceCore dumpReal numberSinc functionChemical equationLocal ringInformation securityDiscrepancy theoryAnnihilator (ring theory)Internet forumPosition operatorArray data structureField (computer science)NumberMultimediaRadical (chemistry)UsabilityAnalogyNamespaceConsistencyDescriptive statisticsCheat <Computerspiel>Archaeological field surveyFitness functionSlide ruleThread (computing)INTEGRALGroup actionInstance (computer science)Client (computing)Natural languageTemplate (C++)Source codeAxiom of choiceModulare ProgrammierungWeb serviceEstimatorVideo gameCellular automatonLibrary (computing)2 (number)MassCanonical ensembleState of matterFocus (optics)Shape (magazine)Physical systemSoftware frameworkKernel (computing)AutocovarianceLattice (order)Digital electronicsUniformer RaumSpeech synthesisMultiplicationImage resolutionSystem administratorCopula (linguistics)Flow separationFunctional (mathematics)Component-based software engineeringGreatest elementClosed setResultantAlpha (investment)Pattern languageInverse elementComputer-aided designChainMathematicsForcing (mathematics)Event horizonLinearizationHypermediaBoss CorporationACIDAlgorithmParticle systemComputer-assisted translationSpywareCovering spaceInferenceFamilyProgram slicingMatching (graph theory)Incidence algebraStress (mechanics)Bit rateWebsiteRule of inferenceSpacetimePublic key certificateExtension (kinesiology)Medical imagingConcentricSurfaceInsertion lossKey (cryptography)ConvolutionSheaf (mathematics)Sign (mathematics)Musical ensembleExecution unitComputer virusType theoryLogical constant1 (number)Derivation (linguistics)Partition (number theory)GradientVideoconferencingOrder (biology)Volume (thermodynamics)Ring (mathematics)Machine visionOffice suiteArithmetic progressionWell-formed formulaEmbargoCombinational logicCuboidStandard deviationControl flowDigital Equipment CorporationSpring (hydrology)Software industryMoment (mathematics)Condition numberPhase transitionDivisorTwitterInversion (music)Pattern recognitionVarianceSubject indexingVertex (graph theory)Price indexSubsetGradient descentFrequencyService (economics)Computer architectureLecture/Conference
Transcript: English(auto-generated)
00:00
And I am really pleased to announce our next speaker, who is probably best known for being a Debian project leader, but has also got his fingers in many other plies which are really fascinating and have to do with interdependency of software and other sorts of very cool things.
00:23
But I think you really want to hear what Stefano Zagurale has to say about the community. Thanks Stefano. Good morning everyone. I've been a Debian project leader for three years, since last April.
00:40
So what I'm going to talk today is about some of my experiences in dealing with specifically legal issues, but as you know they also have quite a bit of policy implications. So it will be partly a kind of deductive talk in how we do things in Debian from a legal standpoint on different pillars of what is called inappropriate but still intellectual properties.
01:01
And on another direction of the talk I will share some lessons learned that might be useful in other communities, at least in communities which are in some sense related to Debian. So let's start with some fundamentals of Debian. I believe everyone in the room here knows what Debian is about, but just to recap some of the points which will be relevant for my talk today.
01:23
So Debian has existed for more than 20 years now. It's very well, very popular in terms of the technical product we make, the Debian operating systems. So we are kind of the current web server market lead, so the most popular operating system for web service on the web is Debian today.
01:43
We have a huge archive with something like 30,000 source packages, no 20,000 source packages and 30,000 binary packages today, 12 architectures. And what's interesting from the legal point of view as well is that we are the basis for more than a half of the existing distributions according to digital watch.
02:02
What's interesting for us today as well is the social contract, which is kind of an agreement between people making Debian and the outer Free Software ecosystem. In there you will find that Debian promises to remain always Free Software, and I will come back to that in a moment. You will find a culture of not hiding problems, which as I mentioned yesterday, initially was for mostly technical things,
02:25
but have evolved into a more radical culture of transparency in all aspects and decision making in Debian. And you will find some provision in how we deal with non-Free Software, which is still redistributable by our users. All this kind of ethical connotation of the project have been useful in making Debian a very popular project for volunteers.
02:46
So nowadays we have something like 1,000 official members of the Debian project, so people will get to decide where the project is going, people will get to decide who is the Debian project leader and vote in general, let's say a referendum within the project, and something like 5,000 other volunteers contributing in other ways, but not being committed to be members of the project.
03:07
We are often credited to be one of the largest, possibly the largest, Free Software project in terms of official members. So there are three fundamentals on how we do things legally in Debian which we want to discuss.
03:22
The first one is the DFSG, the Debian Free Software Guidance, which you are probably familiar with. What's interesting here is that essentially you cannot promise to be entirely Free Software unless you also define what you mean with Free Software. So the DFSG is actually the interpretation for Debian of what it means to be Free Software. So there are sort of guidelines which you apply to licenses of software, not to software itself,
03:46
or more specifically which you apply to the rights that you have when downloading some specific software. And in there you will find essentially, even if it's written rather differently, you will find the four freedoms they need to uphold for something to be considered free by Debian.
04:02
You will find some distribution-specific provisions, like what happens if you put unrelated software on a CD or on a DVD. Do they contaminate each other? So you have some technicalities to deal with that. Historically they've been the basis for the open source definition, which is essentially a more or less direct reformulation of the DFSG in a more general terms, not for distributions.
04:25
And what's interesting, they've been interpreted over the years by the Debian project as applying not only to software but to all sorts of content we have in the Debian archive. So this is very interesting for me, I'm very proud of it, because in a sense that makes Debian
04:41
an even more radical institution than the FSF when interpreting what rights do you have on non-software content. So recently we now have this free culture movement, so all the content you find in Debian is essentially free culture compatible. And this means that we face some kind of challenges when dealing with content which other distributions which only focus on software maybe do not fit.
05:06
What's important here, another point, Debian is de facto one of the three major bodies that people look up to when deciding if something is free. So if there is a new license published tomorrow, luckily the license proliferation problem has been slowly fading away.
05:23
But if a new license pops up tomorrow, people will essentially look up at the FSF to know what they think of the license itself, of the OSI, and likely they're also going to lock up. Is Debian saying that this license is free or not? So we are kind of a reputed body in the area.
05:41
Second point, which is the second fundamental of how we do things, is governance. So on paper, and in some sense also at the reputation level, Debian has a reputation of being very bureaucratic, very formal with a lot of decision making processes and so on and so forth. We have bodies, formal bodies, like the Debian project leader, the technical committee, like general solution.
06:02
And it looks like it's very bureaucratic, but in practice, on a day-to-day basis, we are almost an anarchic project. So we have a clear area of responsibilities, we have maintainers for individual packages, and those maintainers can do essentially whatever they want as long as they stay within some common agreement upon quality requirements for their packages.
06:24
So we have like hundreds of teams, we have thousands of maintainers for different parts of Debian, and they essentially are all autonomous. So they can decide on a lot of methods for their software in a very liberal and independent way. So third point, before moving to some specific lesson learned, is independence.
06:45
So I often claim that Debian is essentially very far away from risk of corporate controls. The reason why I claim that is that there is no single company babysitting Debian. So if you look at the competitors of Debian, other distributions out there, in almost
07:02
every case, you can pinpoint an individual company which is either fully sponsoring the development of the distribution, or at least it is financing completely the infrastructure of the distribution. So maybe there is a real community of volunteers working on the distribution, but if the infrastructure goes away from one day to another, well, that distribution will have a problem.
07:21
And again, this is not the case, so we have a lot of companies donating to us, we have a lot of volunteers donating to us, but they kind of balance it out. Formally, there are no employees of the Debian project, so they are not even dependent on the money we have to do their job. They might have employees that are interested in them contributing to Debian, but we have quite kind of a very diverse range of companies paying people to work on that.
07:44
So I think this is truly remarkable among, let's say, major or widespread distributions today, but it also adds drawbacks, especially in the kind of things we are going to discuss today. In particular, it means that we do not have direct access to typical corporate resources. For instance, we do not have Debian lawyers, we do not have IP boards that can review what's going in the distribution and what's not.
08:07
And all this kind of typical structure that you have in corporate projects, we do not have direct access to it, so we need to cover up on that front in another way.
08:21
What else? So this is how we essentially work with respect to outer corporations and the outer financial world. And in terms of assets, we do have money, we use money for buying machines, for sponsoring hackathons or sprints or whatever you want to call them. And those assets we have are essentially spread over several organizations.
08:42
So we have several so-called trusted organizations, which the Debian project trusts to hold money and other assets for the project. And they are kind of scattered around the world. So the one we use the most is in the US, is SPI, software in the public interest, which is actually being created for the need of Debian, but then has become a more like umbrella organization for other projects.
09:03
Another one we use quite a bit is FFIS in Germany, then there is Debian CH in Switzerland. And a recent addition is not yet a trusted organization, but is on track to become one, is Debian France, founded by Debian developers in France. So we have this kind of scattering to reduce essentially single point of failure risks.
09:23
So having assets spread over several organizations, we believe our assets are more reliable than if it were in a single entity. Okay, so this is the way we do things. So there are some consequences of all this.
09:41
So first of all, the consequences are not necessarily Debian specific. So you will find other communities out there which have similar traits. So I'm not going to claim in the lesson learned that I'm going to show you today, ported natively to other communities, but it is possible that similar communities have similar traits and similar consequences.
10:01
So the most direct I face myself is essentially the typical approach, top-down approach of saying to developers, you shall do this or you should not do this, simply don't work. Because they are not employees. So the usual incentive you can give to people do not work. So you cannot just say to someone, I'll double your salary if your salary is zero, right?
10:21
You cannot say to people, I'm going to fire you because that's not how it works in the volunteer community. So when you talk with the corporate work, they might have this kind of incentive, but simply do not work in that. It also means that you have limited access to legal advice, so we had to cover up in other ways in finding out how to deal with legal issues.
10:42
And it also means that we suffer of some sort of US centrism in how we interpret law. Because essentially, being Debian historical project born in the US, originally, even though today is a very worldwide community, and being that our principle, so the trust organization we use the most is software in the public interest,
11:03
we add more access to US specific resources such as interpretation of budget constraints or legal advice is mostly US specific. So we might need to evolve there a little bit. So let's see, considering all this, which is a kind of overview of the structure of Debian which is relevant for legal issues,
11:22
let's have a look at some specific legal concerns we have faced in the past. So it's organized along the three axes of the actual property. One is copyright, another one is patents, and another one is trademarks. So in terms of copyright, the concerns that the distribution has are quite different from the concerns that a company or a corporation might have.
11:45
So the main things you need to do in a distribution like Debian about copyright are 1. Keep Debian, Debian main archive, 100% free software. There is no legal obligation for us to do that, but this is a commitment we've made to this free software ecosystem.
12:01
So this is the point 1 of what we need to do in terms of copyright and Debian. Point 2 is to keep the Debian archive legally redistributed. So side by side to the Debian archive, main, we have packages we support but which are not free software, encountered and non-free, and even though we do not make any promise that those packages are free software,
12:21
in fact most of them aren't, if not they will be in main, we need to ensure that they are legally redistributable so that we can distribute them via our mirror network. And there is another concern that is typical for companies or corporations dealing with free software, which is copyright assignment and that is not of a particular interest for Debian.
12:41
So we do, at the present, we do not have interest in, you know, collecting copyright assignments even though we have something to think about offering the option to developers along the lines of the fiduciary license agreement that we have been discussing this from yesterday. So the first question is, how do you do review of copyright notice and of license notices in a project which is shaped as Debian is?
13:05
So the first lesson learned here is that you essentially don't do that in an analytic way. You cannot simply, you know, enable all developers to just have a say on reviewing copyright notices and copyright notices and license notices and just trust that everyone will do the right thing.
13:23
This is our experience. Why? Because essentially at this scale you will find someone who either does not care at all about this kind of stuff, so it will be kind of stopping your union. And essentially you will find out that for many actors the legal part of free software is just a burden.
13:41
They're not really into, you know, nitpicking at the license level. They find the software, they want you to make it useful for Debian users, and they just want to, you know, even take shortcuts with that available. So what we put in place is essentially a multi-tier review process for the software that gets into archive. So you might have heard about the FTP master team, you might have heard about the new queue in Debian,
14:01
and this is a kind of package qualification process for copyright notices in Debian archive. So it works this way, essentially you have an upstream software, you will have a Debian maintainer which finds the upstream software and decides to, you know, prepare a Debian package for it. And the first time this package prepared by a Debian maintainer will go through the Debian archive,
14:25
it gets essentially stopped in a staging area which is called the new queue, for the new package queue, and at that level we have a specific team of people in Debian that are people that do a review, a thorough review of all the copyright notices and all the license notices,
14:41
and check that Debian maintainer has properly noted down in a file called Debian copyright all the license and copyright information. And at the same time they check that the Debian copyright file is incomplete and they also check that the licenses are actually compatible with the Debian free software guidelines. So this happens only at the time of the first upload to the archive,
15:00
and subsequent uploads just go through directly to the archive. So why do we have this difference? It's essentially a trade-off. So in theory you might want to have multiple reviews at every single upload of the fact that the licenses are fine, that you didn't forget to add a specific license, but that would be a very high burden.
15:20
So there's a trade-off in which you say, okay, we do that in a new package, and then of course if you find bugs later on, you'll cope up with them. So this is working quite well for us. It can be used also for other kind of license and legal vetting. It's mainly used for copyright and licensing office, but it could be used for other stuff, and also for package quality checking
15:47
and for consistency of the namespace. Yes? Can you repeat the question? The question is how do we deal with the case where the maintainer decides to add extra dependencies?
16:02
So this is the granularity of source packages. So if there are dependencies, those dependencies are on other packages that may be part of the same source package or not. If they are part of other packages, well, the other packages are either already in the archive, so they already went through this process, or they will get in the archive later,
16:20
and they will go through this process as well. Yes? Can the maintainer ask for another review at some point in the future? That's a good question. I don't think we have a process for that. It surely can. The question is whether this kind of vetting team will have the time to do it. Because it's the original upstream package. Of course. You're absolutely right. So that happens when you change name.
16:42
So if you change name of the package, that will happen again by default. Yes? Just out of interest, is also part of that FTP master approval process or is there some kind of assessment about whether the software is actually useful to anyone? I perceive a mild troll in there.
17:02
No, no, no. That's a very good question. Do you have requirements like that or not? I can see why you might. There are actually no legal requirements on this. It's actually to keep the name space same. Because if the FTP master will deal with the names of the packages, so what will happen is that they can debate, well, cannot this package be part of this other package which is already in archive?
17:22
But that usually happens way before that. So before preparing a package, there's a process in which the maintainer must declare they're working on something. And at that level, if the name is incredibly silly or the package is too small or if it's already elsewhere, people will be essentially called up. So that happens before? Yes, exactly. Then I should really go on.
17:41
Otherwise, go ahead. I wanted to ask about SPDX and explain how that could be automated and stuff. Has Debbie looked into that? Yeah, I can do that in a bit. But it wasn't the first talk, so you've been oversleeping, I think.
18:01
Me too, it was the first talk for me as well. So I'm confused. Where does Debbie and legal fit into this part? Yeah, so that's the next slide. We did not plant the troll. I have it too. So the important part here, before we get back to SPDX and that,
18:20
is that essentially the STP master team is the fact of the team deciding which licenses are free or not free for that. So they are deciding the official interpretation of the Debian free software guidelines on behalf of the Debian project and they are trusted by the project to do that. So we try to document these kind of decisions, but as Fontana often points out, we are not that good at documenting them,
18:42
but we are trying to improve that. So there is a wiki which is essentially still quite empty, but the idea is to have the cross-referencing all licenses we have in the archive with the actual decision on their freeness or not. So we are trying to improve on that, but what is important to realize is that the STP master is the gatekeeper of license freedom in that.
19:02
So once you have all this, you kind of start asking yourself some questions. So when you have something as big as Debian, which is, in my opinion, very representative of the popular and representative free software out there, you might want to ask yourself, okay, so let's assume, it's unapothetical,
19:22
that Debian decides that you cannot link together OpenSSL and GPL licenses. Do we have in the archive software doing this and can we decide if that's the case by just looking at metadata? Or you can't have related questions. You might have, okay, what happens if with GPLs, which is from GPL2 to GPL3,
19:43
and how many GPLv3 incompatible licenses do we have in the archive? It was a question which was quite popular in free software circles in 2007. Or again, let's assume that some low-level library, say libberkeley-db, gets re-licensed to a GPL by someone. So what happens? How many packages in the Debian archive get automatically
20:02
re-licensed to a GPL due to this change? So you cannot decide that on a mere, you know, looking just at the package metadata, but you can help it to, you know, have a look at specific cases. So the idea there is that if we have all the Debian corporate information, and we have the dependencies, so we might look at packages that might link together
20:24
during the compilation process, software under different licenses, and we can use that set, a set of packages we need to inspect manually to realize whether we have some of these problems. The requirement to do that is that you need to have Debian copyright information in a machine-parseable form. So, unfortunately, the initial Debian copyright,
20:43
the initial format for the Debian copyright file was not machine-parseable, so we started moving to that in 2007. There was some yearly version on the Debian wiki of Acosta, and it has been summarized only starting from 2012, so we now have a Debian copyright format which is fully machine-parseable, and which looks like something I put on this slide.
21:03
So it's essentially a Debian typical RFC 2822 format in which you have some specific fields in which you can say, well, these files in this package are under this license, and this is the copyright author, and these other files are under a different format. And there are various interesting things in there.
21:21
So, essentially, you have globbing to match files, you have short licenses, okay, short license names, and you have the ability to add natural language text blocks in this file to add additional information on the license, or to include licenses which are unknown to the form.
21:43
If you want to have a real example, which is larger than the example I have, you can look at the LibreOffice Debian copyright file, which is already translated to this format. It's kind of big, as you might imagine from such a project. It's kind of something like 1,500 lines, and if you look in there, the largest part of the file is essentially verbatim inclusion
22:02
of licenses which are either unknown, meaning that they are not known to the ontology of licenses known to the format, or which are known but they are not considered popular enough in the Debian archive to be included in a directory which is user share common licenses where we include verbatim, all the licenses which are very popular in the Debian archive.
22:24
And everything else, about 2,000 lines, are globbing and matching files to specific copyright information. So it's still pretty manageable, even though at this scale it can be intimidating at first. So I think this is very interesting for Free Software in general,
22:40
because in Debian you have a lot of files, or Free Software source code files, which have been already reviewed at least by the Debian maintainers, and starting from the official declaration of the upstream authors about their copyright and their license. So it can still be, you know, incorrect information, but it has been reviewed at least by two parties
23:01
before entering the Debian archive and before reaching the users. So this is potentially a huge corpus of license and copyright notices reviewed by two tiers which is available for everyone to use. But to profit from it, you really need to have archive coverage and have all Debian copyright files in this format.
23:21
So this is just an idea to the kind of coverage for this format we have in the archive. It's still optional to use this format, right? Yes, it's still optional. So it's really hard to use the coverage a lot? Of course. We haven't yet, you know, mandated to Debian people to actually convert to this file, which has been some resistance. But even though it's not mandatory yet
23:41
for people in Debian to do that, it's gaining momentum. So in 2011, at the time of the squeeze there really is, only 20% of the packages in the archive were in this format. In the time of the Weezer release it was 42%, and now the snapshot of the seed distribution I took a couple of days ago, it's something like it's very close to 50%.
24:01
So it's gaining momentum. I think in the end it will be available in this format for everyone. But even if it's not complete yet, you can use it. Someone asked about SPDX, yes? This huge corpus that you have is available under which license? Ah, that's a good question.
24:21
That's a good question. So right now, it's not a corpus in the sense that this is aggregated anywhere. So right now there are just individual metadata under the same license of the package usually. Well, the Debian maintainer can declare a different license for the Debian information, but by default we don't do that. So by default it's usually an individual metadata
24:42
under the same license of the source file. But you're right, if you aggregate it somewhere, it should be exposed to something like the ODBL or something like that. I will be working on that, so I'll keep that in mind. Last thing about this, someone asked about SPDX. So I know about SPDX, the goals are kind of different. SPDX is mostly for companies and for people
25:02
who are having to do some bill of materials of the software they are shipping to users. While in my opinion, Debian Copper, the machine readable Debian Copper is more like a format for hackers. So it's an intentional format where you use globing to minimize the size of the license information while in SPDX you have an extensional form,
25:21
where for each file you need to specify what license is under. So essentially it gets so big in SPDX that you need to use software to deal with it, while Debian Copper in machine transfer is meant to be used by humans. It's also my understanding that SPDX is meant to be mostly machine readable. Well, you can read it with XML, but it's not particularly easy to understand,
25:41
while Debian Copper is meant to be both machine readable and human readable. That's absolutely the intent with SPDX, is to be both machine and human readable. You consider that today it's machine readable? Excuse me? You consider that today is machine readable? Sorry, is human readable SPDX? I mean, there's conversion tools to do that, but the project is, you know, that's under the umbrella of the project.
26:03
But the intent, I think the intent is not... I was the one who started the SPDX project, and I can tell you that was the original intent. It's not the case today, but that was the original intent. So we can agree on that? We have to talk about SHA-1 sums also later on. So there are some compatibility between the two.
26:23
So for instance, we have compatible license names. There are specific provision in the machine possible, Debian Copyright format to be compatible at the license name level with SPDX. And there are some prototype tools to do the mutual conversion between the two. Unfortunately, they're not here properly packaged yet, but they exist.
26:40
Back to Debian Legal. Is that actually a comment I forgot to make on this slide? Thanks, Karen. So Debian Legal mailing list is not the official Debian position licenses. It's just a forum where people who likes licenses and not always have a clue about them, discuss the things, okay? So it's essentially the Debian Legal community is not the community
27:01
that does the final say in what is free and what is not free for Debian. Thanks, Karen. Thank you. So what else? Second point, which is very popular in free software circles in the past years, it's about patents. So like every very big software assembly, Debian is a patent minefield.
27:25
Essentially every big collection of software is potentially a patent minefield. Because patents are so broad that you can actually patent everything. Maybe their patents are invalid, maybe they're not, but you can patent a lot of silly ideas that you can find in every single software if you look hard enough.
27:44
So as everyone else in the area, Debian did some risk assessment for patents in the bin archive. We've learned quite a few lessons from this. The first lesson we learned is that FUD and hysteria has basically won. So we are living in a world with respect to free software and patents
28:03
where people are really scared about the most common offenders. So the patents that make the headlines on the tech news networks. We are really scared about those. And we essentially ignore other areas that might be there in free software, very likely are, which could be very risky from a patent standpoint.
28:21
So essentially it seems to me that FUD and the people who are shouting the most have been able to set their agenda on how free software communities are dealing with patents. So this is the first lesson we have learned. I believe that this gives us something like a false sense of security because communities feel on safe ground if they stay away from the common offender.
28:42
But maybe they are in danger for other patents which are less known to the big public, but which can be a real danger for the community or for the companies involved with the community. So in the specific case of Debian, this is what has led to the Debian multimedia 4. I encourage you today to have a look again if you're using Debian multimedia,
29:01
if what you need is or is not in the Debian archive, because it's very likely that you do not need that fork anymore today. So this is the first lesson. So hysteria, people shouting the most, and FUD has really made a dent in our community. The second lesson we learned is that the typical requirement of
29:21
you should not speak about this in public simply doesn't work in our community. It's fundamentally against the ethos of free software communities that want to talk to each other, and usually their public nailing is to do so, so they will do that. So just saying you should not do this is not going to work. So we worked on this not alone.
29:42
As I mentioned, we were not lawyers, we were geeks. We have scarce access to legal resources, but we have been lucky enough, being a big project, to work with institutions like the Software Freedom Center on this kind of stuff. And we tried to create training material and do a usable material on patent matters and other matters like trademarks, which is very usable for other communities
30:02
and possibly which is not only US specific. As Tom Callaway mentioned yesterday, in Europe we like to live in this dream in which software patents are not a problem for Europe. That's actually not true. There are various sneaky ways to have patents on software in Europe as well, so the dangers are not only for our US friends,
30:21
there are real dangers also for people in Europe. So we discussed our needs, we discussed LC and produced at least a couple of documents which might be useful for other communities. The first one is the Community Distribution Patent Policy FAQ, which contains essentially training material on what patents are, what infringing a patent means,
30:40
how you can disprove that you're infringing a patent. And this is all general material on patents, specifically on software, but on patents also in other fields. This is very interesting. I think it's training material that everyone interested in the subject should read. And it also contains stuff which is specific to distribution, and distribution which are community-driven. For instance, it contains a review at the time of publishing
31:02
of how many lawsuits you have had around community infringing patents, and so on and so forth, and I encourage you to look at that. The second document we published is the Degen position on software patents, which is something that we hope can inspire other communities to take similar steps. And in there you will find as well teaching material,
31:22
you will find the claim against FUD on patents matter, and you find encouragement for communities like, you know, please refrain from discussing specific patents in public, because it's dangerous to you. I know it doesn't work, because in Degen it doesn't work, but at least we're trying to educate accuracy in our field and also in other fields.
31:42
We need a lot more. Yeah? Could you put a filter on all the WN Madenwels that automatically diverts the moderation of your eMessage continuing with patents? So the question is, can I filter the Degen mailing list so that if there is a patent in the subject or in the mailing, you get the reviews? No. No, no, it goes to moderation. It goes to moderation. So you can then email the guy and say,
32:00
look, are you really sure you want to do that? No, that won't fly in Degen. But it's potentially a proposal that we can think about. So similar to this, we have faced similar issues in trademarks. So as many other projects do in free software and old-style free software, we do own a number of trademarks.
32:21
In particular, in the case of Degen, we own a trademark on the Degen name, and we own a trademark on the Degen logo. We have been discussing this with communities since, like the first discussion about this, I think it dates like 15 years back or something. And the feeling I have every time I've discussed these matters with communities,
32:41
in a community like Degen, is that communities are visually against patents. At least the free software radical communities like Degen. Essentially, there is a feeling that we are doing this for software freedom, for enabling people to do whatever they want with our software. Why should we restrict on the basis of naming?
33:01
The analogy with censorship is something you will find very often in public threads between hackers on this subject, and it's something which is really hard to debate. As an example of this, if you look at the Degen free software guidelines, you will find a specific trademark position. It doesn't mention trademarks, but the intent is pretty clear.
33:23
The point is the integrity of the author's first code, and in there you'll find something like license may require derived works to carry a different name. It is required to force people to change the name of your software, if you do changes, for instance. But it's also noted that this is a compromise.
33:40
The Degen group encourages all authors not to restrict any find, source or binary, from being modified. Back in the days when the DFSG were drafted and approved, you see already this kind of tension. You see people that say, okay, we can accept if your software is trademarked, we can accept if you want to defend your name, your identity to change something,
34:01
but we notice that that's a compromise. This is something very symptomatic of the kind of culture that you find in pre-software communities against trademarks. I find it very hard to explain the risks of trademark infringement to communities like Degen. I myself believe that trademarks are very useful in communities like Degen,
34:21
and the arguments that I found worked more, they work better, are the arguments in which you show that trademark infringement can actually go against the community ethos. For instance, in Degen you can imagine having people trying to take Degen, fool it with proprietary software, spyware, and distribute it to others, calling it Degen. That's an argument that will make a dent,
34:42
that people will perceive as something which makes sense. I think that last year you gave a talk on licensing from the trenches, right? At the Mozilla cage. And I think this kind of stories you have in Mozilla is something that will talk quite a bit to Degen, except that we haven't yet seen them for our products, so people are not aware of the risk you have.
35:02
I mean, in the last two years it's become even more, so the only reason that we have any entry at all into the mobile phone market is the power of the Firefox trademark. That is the only leverage we have with carriers, and that is why there are now 14 countries and 17 carriers shipping phones which are running much freer operating systems,
35:25
maybe one day truly free operating systems, and that's what's carving a path, possibly for truly free operating systems to run on mobile phone hardware, right? This is an enormously good thing for the free software community, and the only reason it can happen is because we have the Firefox trademark, and therefore it seems odd to me
35:41
that people think that maintaining the Firefox trademark is a bad thing, and they are not interested in any software that bears it. You should come talk to my community as well. Yes, I have on several occasions. Yeah, I was just going to say, I've noticed this early against trademarks, notes of that, not nearly as much as you've had experience with,
36:00
and I find it a bit puzzling as an attorney because if you just, and I wonder if the key thing is a lack of understanding of the intent of trademark law and how it works because your good argument is the argument for trademark law regardless of who owns the trademark. I mean, that is cutting right to the intent,
36:20
which is really protecting the consumer, or in this case, the person receiving Debian. So I totally agree, and in fact, my point is that we need more training material, also trademarks. So I have some examples. Pam is speaking later about that. Yeah, exactly. I believe Pam will be. To comment on your last slide, when you say communities seem to be viscerally against trademarks,
36:41
one of the things, I wrote a paper a few years ago and I spent a fair amount of time looking at the Debian list. The old one, you mean? The old one, yes. But one of the things I found was people also viscerally reacted very strongly when they thought there was an infringement. So there actually, I saw both sides of it.
37:00
I saw the people who were very against enforcement trademarks, but I also saw people who didn't, I think they reacted on a very emotional level when they saw something that they thought was an offense to the Debian sensibilities, and they'd be like, oh my God, why are they using our trademark? And someone, sometimes the respondent said because they're allowed to because it's under our license. But it is, I like the word visceral
37:22
because I think it's true, but it's also true in those directions. But this could be its own talk and you've only got 10 minutes. Okay, so I'll wrap up here quickly. So this was an example of the old Debian trademark policy that Pam was discussing. And it's really not a trademark policy, something we have been using for almost 15 years,
37:42
and you find there a very vague sentence. So you have an example like, for example, if you make a CD of Debian, then you can tell that product Debian. But if you go down, you have restrictions like, to refer to all businesses, we insist that no one other than Debian uses Debian trademark in the name of the business, organization or domain name. And here, you might notice that there is no mention of a product at all.
38:02
So that's kind of weird, right? So I think it's true that there was not really a clear- Is that intentional or a mistake, do you think? I think it was a mistake. I wasn't around in 1998 when this has been created. I think it was a mistake due to another look of not only trade, how trademark works, but also what is its main point, right?
38:22
So I need to be quick now. So we changed that. So we've been working on a notion developed initially by Mako and Galt Pomerath. The idea is trademark freedom, and it's a new trademark policy based on a few principles. The first one is that we want to make trademarks as free as possible. And this is the region where you have some tension
38:41
between hackers and trademark lawyers. So essentially, we want to push the limits of how far can we go in giving freedom to people to use our marks without losing the right to our marks. And of course, it's not clear-cut, right? So there is also a different risk you take depending on how you move on that spectrum. So the second interesting principle for me
39:00
is that for free software community, you really want to have your mark to become as popular as possible, of course, within limits of not giving up your rights. Why? Because people are doing this to promote free software. Because they believe in the value of free software and it's their interest to have their marks as widely used as possible. A contentious case, which is very important for them,
39:21
is, for instance, giving the ability to other people, to third-party vendors, to make commercial merchandise using Degenmarks. Because for us, they're doing us a favor, popularizing Degenmarks. And this is clearly a point of tension in people that have been looking at trademarks from a different point of view. And also you find in there stuff like making it easy for people
39:43
like the Degen project leader or the responsible for the Degen assets to keep up with day-to-day trademark infringement, day-to-day trademark request and so on, license request and so on and so forth. And you find a new trademark policy here. It's been in effect since January last year.
40:00
I think it's a pretty decent policy and it's been using an inspiration for other communities. For instance, the core community looked into it, with interest. It's been referenced in some legal journal. It was, unfortunately, a paywall, so I can't look at the article anymore,
40:20
but I find it references a good example. And we definitely need more reference, trademark material, more educational material on what trademarks are about, and more template-like material that Queen Mary used to create trademark materials. So in that sense, I really would like to point out the related work by Pam. I think you will be talking about that this afternoon.
40:42
Oh, no, sorry. So that's the trademark modeling guidance. The idea is to provide actually template guidance you can use for actually if you want to create your trademark policy for a free software project. And that's the thing that's very useful and we need more in that direction. Another good example is the new Wikimedia trademark policy, which is more restrictive of what we have in Degen,
41:02
but is actually a very nice example of how to communicate the dos and don'ts. So it's very visual, I think it's very immediate to grasp, and it's a very nice way to communicate what the community think is fine and what the community think is not fine with respect to their goals. So that's it, essentially, from my talk.
41:20
I just have some concluding thoughts. So in a community like Degen, we have had this, like copyright issues, trademark issues, patent issues, but you have had much more. So I've been around for about 12 years in the Degen community. I've seen in the past US crypto exploitation issues at the time of the crypto wars. I've seen the MCA issues.
41:40
I've seen the problem of dealing with countries which are considered embargoed by the US. Can we accept their contribution in terms of code? Can we not? I've seen problem about inbound trademark policy. For instance, there is a kind of a mean for me. If you recompile something from source and that's something you are recompiling, it's a trademark on his name,
42:01
does recompilation invalidate nominative use? That depends. So that's a question that communities are going to really face and they don't have a clear answer, possibly because it does not exist, a clear answer in all cases. We have trademark laws. So we have trademarks. We have people saying, hey, in China or Malaysia or somewhere else,
42:21
people are trying to restore trademark which is similar to yours. Maybe it's not even true. We want to pay us the best amount of bucks to inhibit them to do so. And they are not legitimate records. We have quite a bit of trade-back trolls doing these kind of activities. We've been working on copyright assignment to nonprofits because when you have a community which is as old as Debian, 20 years, for instance, you will have people that will die.
42:41
So maybe they will want to assign a copyright to people that will take care of their code contribution after they passed away. Or maybe just because they want their copyright to be enforced, like they were saying before. And so on and so forth. So I think we really need a mutual dialogue between communities and free software lawyers
43:00
because we have to deal on a day-by-day basis with all this kind of stuff and they really impact the policy of your project. So my wish list in legal matters, just as a dream for you to maybe join, we really need more free software legal education material. We have some in the realm of copyright.
43:21
We have some in the realm of patents and trademarks. We need more because geeks tend to think, software geeks tend to think that they know quite a lot of legal issues and that's actually not the case. And the risk to take shortcuts which really harm the community by doing so. We need more community-oriented legal templates, like for the trademark one,
43:41
like for patents, like for copyright inbound policies and all this kind of stuff. We really need template materials that we can reuse, maybe possibly under legal advice because you cannot easily transfer templates from one case to another, but it's a starting point. We really need more fiscal sponsor organization and organization like the Software Freedom Law Center. The organization in which they try to work for communities pro bono
44:02
and try to have models in which it is sustainable when they make sustainability for the pro bono work, charging clients that are doing business work on free software and you really need more of this kind of institution, not only at the U.S. level. We need something like this also at European level. And finally, we need less laws that punish typical activities for communities.
44:25
For instance, it's really against the ethos of free software communities merely knowing about something, merely knowing about a patent or merely discussing in public about something. It's making the situation worse from a legal standpoint. That's really harming the communities and my dream is that we will see these kind of things going away.
44:42
We need less people spreading through 3D, including lawyers. Typically, we have an agenda for some corporation in corporate interest against free software and because, in fact, a 3D really works. So when people are seeing lawsuits which are working in some area, they start to think they can affect their work as well.
45:01
So it really works and it's really impacting the choices that communities do. And that's it. So if you have questions, I'm happy to take them. Yeah? One small remark on trademarks and then two questions. The short remark is that I think it's important to realize that you can use trademarks in an equal way or in a good way.
45:24
Like, for instance, in copyright, GPL uses copyright actually against copyright. Of course. You can do something similar to a trademark but you can use it for consumer protection, right? The question is, the FSF holds a list of three mirror slash Linux distributions.
45:44
JPN is not listed there and, honestly, their reasoning why JPN is not listed there seems to be quite weak to me. Is JPN doing something about that?
46:01
Any FSF board member in the area who wants to take the question? So that's really not a question for me, right? So that's my question for you. I mean, the question is, if JPN is taking this... Yes, we are working on this quite profitably with the FSF. We've been collaborating with them on this issue for the past two years, if not three.
46:20
So things are going forward. The answer to your question is yes, we are working on that and we are quite happy about the relationship but it takes time. Changing this kind of policy decision takes time. On trademarks, I want to comment on your comment. You are right. Trademarks can be used in bad faith but a lot of things that distributions are doing can be used in bad faith. We are recompiling the software you are using.
46:42
We can make mistakes or we can add vectors. In some sense, we are trusting the Debian project. So if we do trust the institution of the Debian project and the Debian project trusts some specific organization to all their assets including trademarks, well, this is the kind of trust you can count on.
47:01
In the human readable copyright data, have you thought about moving that to the software packages instead of having them assigned to the software projects and then maybe the work could be shared with other kind of Linux distributions? Right. So it is part of the software packages. So for every single package you install, you add the data and copyright locally.
47:21
Have we thought about sharing them with other institutions? I think it was upstream. Well, if we found discrepancy about our findings on copyright licenses and what upstream is claiming, by default, we fall back, we forward the information to upstream. That's part of the... But I mean, if Fedora might want to use the same data
47:42
to erode the two distributions... Right. So myself working, I've created a project called sources.debian.net and this year, which is exposing all Debian sources via web with some API to work on them. And I'm working on exporting all the machine possible Debian copyright information for others to use and there will be an API. So I'm personally working on that,
48:00
but there is not something that can be easily used yet. But I mean, it's all free software, right? So in theory, every other distribution can already download the Debian copyright and use it. Yeah.
48:22
Right, so I agree. I would not go as far as saying that the format which we develop for our needs, it's potentially a good format for upstreams as well. I believe there are other things like DOA, the description of a project. Maybe they include some copyright information. So they can use it. I'm not sure it could be a good format
48:42
for people other than that. Yes? You have about one minute left. And I have a question for Vichy. She's cheating. She's cheating. I've heard recently about people who are concerned about participants in communities like Debian
49:02
and being confused about whether people are representing their companies or representing their personal views and that that's having a deep impact on the governance of the project. Are you seeing that in Debian and how is that going? I don't think it's going to be a deep impact. I think I know what I'm referring to. I don't think it's having a deep impact. It's actually a multiple situation. Okay, but in fact, I want to know data about how much we have corporate interest in Debian.
49:22
I think the Debian model should be like the Linux model in which you have enough different companies contributing to the project to actually balance their interest. One thing I'm working on is a survey of Debian developers to ask them who they're working for or at least how much time they're spending doing Debian in their work time, in their free time and actually see if we can have some factual data
49:42
in how interests are balanced in Debian. So I have a good answer. My feeling right now is that no, it's not impacting a lot of governance, but it might be, and I want to have data on that. I would follow up with one point. There is a big difference between you and Linux, though, is that in Linux you've got a very small collection of people who are making a lot of the final decisions. In Debian, you've got a thousand or more package maintainers,
50:03
and if one of them has an agenda, they will make their decisions based on their agenda. I'm not saying it's happening, but there is a significant governance difference. You have also a very different granularity, though. So the scope of, the impact of decision in Debian is much smaller than in here. That's correct.
50:21
Okay. Well, thank you very much. Sorry. Thank you.