Good morning everyone, our first speaker today is Margaret Tucker, she's a public policy manager
at GitHub and is passionate about getting developers opinions on policy making when it comes
to open source software. In her talk today, she'll be discussing with us the challenges
of policy making, copyright issues, etc. when it comes to goat collaboration platforms such
as GitHub, please welcome Margaret Tucker. Thank you. All right, well, I will be honest,
I'm a bit of a technical guinea pig when it comes to the AV, so bear with me. Okay, it's great.
All right, so kind of a long title here, but generally this QR code refers to a paper,
I'll talk about the paper at the end. It's relevant, but this is a bit of a different talk.
So hi, my name is Margaret Tucker and I'm a policy manager at GitHub. GitHub has a developer policy
team, which means that we represent the interests of developers, policy makers,
and I will say most of my work is explaining what is a developer, what is co-collaboration,
what is open source, and I'm going to assume I don't need to explain any of that to you all.
So instead, I'm going to kind of walk through how code the developer community and the norms
and nuances of open source have influenced our approach to content moderation on GitHub.
So yeah, let's get started.
So first, a really important component to note that code is different from other content.
So typically, when we're interfacing up policy makers who are attempting to legislate,
also, is there any way, is there any way we can turn off the other micro-missie?
Bit echoey.
Hello? Okay. It's still pretty echoey, I'm sorry, but yeah,
typically when we're talking to policy makers who are attempting to legislate on issues pertaining
to online platforms, what they're thinking about is the big platforms, you know, it's meta,
it's talk, it's all of those. And so when we try to explain what our platform is,
who our users are, everything like that, what's really important is we identify that code,
software code, shared on our platform is distinctly different from other user-generated content.
And it's functional purpose creates unique considerations for platform moderation.
I'm going to walk through these and then we'll get into some more information about how the
free and open source developer community have influence art approach. So first, I'll talk about the
content on the platform and then I'll talk about the community that uses it. So yeah, these three
interesting kind of elements of content are copyright, dual use, and the network effects have
taken down. So we'll walk through all three of those. All right, so first off, code has different
copyright concerns, especially when it comes to the free and open source community. So first off,
the functional purpose of code is distinctly different from other content. Just as there's,
you know, only so many ways to fry an A, there's only so many ways to instruct a computer to do
something. And so there's a lot of independent duplication that arises on, you know,
code collaboration platforms and just in open source development. And because of that functional
nature, there's a lot of independent duplication. And that means that the typical approaches
of copyright just don't make sense. And so this is something that we kind of come up with a lot
of what one piece is that also the, you know, the norms and nuances of the open source
community and you need that people share their code under permissive licenses. And that means that,
you know, the kind of, oh, this is mining, you can't use it norms of copyright, do not apply
when it comes to open source. And so this is kind of come to a head in a couple of instances. So
again, when policymakers are thinking about platforms, they're not typically thinking about
code collaboration platforms. And that often comes up in copyright. So for example,
trying to set up upload filtering these types of practices has come up quite a bit.
And so a one-case study that the EU copyright directive, or all of you familiar with this debate
was in 2018, I'll give you a quick spiel. So the EU copyright directive, when it was initially
proposed, it contained language that was concerning for open source development. The, you know,
potential of requiring upload filtering for code would just be unworkable for so many reasons.
As we talked about independent duplication, you know, the norms of sharing and remixing.
And also there was a bit of a value gap. So, you know, the argument that we need to
introduce upload filtering for copyright violation just didn't make sense on platforms where
there wasn't monetization, where there just, there wasn't any reason for this to happen.
And frankly, you know, I think it wasn't a purposeful, it wasn't a purposeful exclusion.
And so we were able to work with, you know, other stakeholder, civil society, the open source
community, and activate developers to advocate for an exemption specifically for code collaboration
platforms. So that's, you know, example of some of the copyright concerns that we experience.
Another big one is dual use. So, as I said, you know, the functional nature of code creates
just a lot of different considerations. And one of those is dual use. So, you know,
basically technologies that could be used for a lot of positive purposes could also have some
negative ones. There's, you know, a certain degree of neutrality when it comes to technology,
a printer could print something really offensive, you know, code could do bad things and good things.
And so, we kind of tow this line quite a bit, and it's something that our content moderation policies
are considering quite bad. So, a big one, although, is our approach to security research.
So, in 2021, we tried to overhaul our policies related to security research.
And in doing so, we, on GitHub, we will launch a 30 day notice in comment period when we have
substantive changes to our site policies. And in this instance, we opened the notice in comment period
because we were trying to create more clarification that we explicitly allow dual use security
research on the platform. Now, you know, this is, this is malware, this is exploits, this is,
you know, people sharing code that could be used for nefarious purposes, but is could also
be used for legitimate research. And so, in doing so, we, we kind of, I would say, it's not completely
oh, all of this is allowed. So, one, you know, anything that is being used in active attacks,
that is not allowed. Also, we encourage security researchers to label their code. So, people don't
accidentally download something that could have negative impacts on their computers.
And another component is that we have a robust appeals and reinstatement process. And so,
we will oftentimes work with maintainers who may have code that seems like it was offending,
we take it down, we work with them to make it clear that it's meant for legitimate research.
So, there's kind of this, this important process because, you know, code is, it's useful. And so,
we don't want to, we want to keep as much up as possible within, you know, the bounds of the law
and what's, you know, safer other users. One that's, it's pretty recent. We introduced this update
in, I think April of 2024 was our approach to, to deepfake. So, we updated our policies on synthetic
media to explicitly disallow the use of deepfake tools for the creation of non-consensual
intimate imagery and disinformation. So, again, it's kind of towing the line because we do want
to get have to be a place that can share these technologies. It's important for this research to
happen out in the open. So, everyone can see it. So, people can develop detecting tools,
so people can study it. So, all of that legitimate research is really important to our platform.
And so, that's why, again, we had this kind of balance of saying, look, we support legitimate
research. But that said, if your project is fine-tuned, explicitly, you know, encouraging,
using this, you know, tool to create deepfakes, create disinformation, and that's disallowed.
And so, again, we had a 30-day notice in comment period. We introduced the policy. We got feedback,
clarifying some things. And so, that's been put into place. And it's been, I would say we were right
along the line with, you know, a lot of policy makers have been expressing concern with this. And
it's important to show that you're taking action while also explaining why it is valuable to have,
you know, research shared on your platform. Even if it could potentially be used for a negative
purposes. This one isn't noted, but another big piece is, you know, circumvention tools,
copyright. And a lot of things that could be used as circumvent copyright can also be used for
really beneficial purposes. So, accessibility, archiving, journalistic purposes. So, that's another
really important one. All right. So, next off. So, moderation of
moderating code requires careful deliberation of the context and network effects. So,
code is functional. Code that is shared openly is often widely used downstream, lots of downstream
dependencies. And that means that, you know, when a platform like get have takes down code,
we have their expectations. Like, I'm sure all of you have expectations in how our platform
should behave towards developers. And so, we definitely, you know, try to have a careful
deliberation of what a take down code potentially means to the community if it's, you know, something
is widely used. And so, this, this, an interesting example. So, YouTube DL, any of you familiar with
the YouTube DL take down kind of a hollow blue. So, but it was an important hollow blue. I'll say that.
So, YouTube DL, I believe it was 2021. That might be incorrect. But so, the YouTube DL was
widely used a video downloading tool. I think I had used it before. I even came to get,
it's really well-known. And so, YouTube DL, basically, we had taken it down and response to a
copyright report from the RI AA, the Recording Industry Association of America, I believe.
And the reason we took it down immediately is because it alleged circumvention. And so, safe harbor
liability protections on platforms do not protect circumvention tools. So, we took that immediately.
But it was a project that was very valuable and widely used. And because of that, there was quite
a bit of community outcry. And so, we were able to work with the electronic frontier foundation
and, you know, some other civil society groups who were able to explain why this tool was not
actually in violation of technological prevention measures. And so, yeah, this is an interesting
one. So, after YouTube DL, we overhauled our review process. We added an engineer to our team.
And so, circumvention claims are subject to both legal and technical review. I will say this
case continues to be active. It's a bit complicated. And so, you know, we hope that things land
in a positive place for developers. It also led to us establishing a developer defense fund to
give money for developers who are dealing with legal cases. But yeah, it's one of those things where,
you know, you want to, you know, have your platform work within the bounds of the law, but that
also means that these, you know, useful items of code can be taken down and have mass and network
effect. So, again, we try to have a balance. All right. So, I'll get into the more
fostered-me pieces of the talk. So, as I might have mentioned before, we, we know that our
community has expectations for us and expectations about how we conduct or in governor platform.
And so, moderating the developer community specific requires a lot of nuance. So, some elements
of the developer community and open source norms. So, we, you know, both open source or site policies
have an open 30 day notice in comment period. We, you know, try to keep everything as, as transparent
as possible. We have a transparency center. It's also as repository. We try to give away as much
information as possible. And so, that's a big piece. It's trying to embody the values of the open source
community and the way that we conduct things and be as open and transparent as possible. Another
big component is platform moderation beyond take downs. And I think this is a piece where we really
diverge from other user-generated content platforms. I'll say, you know, I've used platforms like
Instagram and if something's taken down that's usually it, the, you know, appeals and reinstatement
processes is not as robust as ours. But, you know, as mentioned, because code is functional code
can be widely used across, you know, different downstream dependencies. We've developed a pretty broad
suite of different moderation actions that we can take. So, you know, for something that may be
content that is within our terms of service and acceptable use policies, but may say have a
adult content or something like that. We encourage people to clearly label it. We can apply
interstitials, which, you know, give sort of a pop-up that gives more information about a project
before people use it. We also can, you know, for projects, we can, we can de-index them. We can,
you know, do things that kind of change the visibility or add friction to access without taking
down code that may be unused. Also, there's have been some instances where maintainers or just
users violate our platform are, you know, acceptable use policies, terms of use. And we also have
approaches that can, you know, restrict the maintainers use of the platform while still keeping code
it was widely available as possible. So, there's a lot of different approaches. Something to note
that I'm not sure if the people are aware of, but we, we cannot edit lines of code. There's a
wide, you know, it's both technically and I would say ethically, in, in feasible for our platform.
And so that means that, you know, because we can't edit the code itself, we do have to have a
lot of interaction with developers, you know, kind of work through, you know, the appeals process
with maintainers. But yes, so it's, it's an important thing that have that kind of, you know,
I would say robust and, you know, varied approach depending on the offense or try to keep as much
code up as possible. And yes, so finally, something that is really essential on a platform like
GitHub is community content moderation. Our platform would be nothing without the efforts of volunteer
maintainers working on their projects. And so the element of encouraging community content
moderation is a really important piece. So, we both provide tools for maintainers to, you know,
have, you know, moderate contributions in their projects, set expectations, you're lots of different things.
Actually, here, let me go back a second. So, on the community content moderation piece,
I will say that GitHub has noticed a pretty massive influx of spam on our platform. And so something
we're kind of working towards is thinking about what maintainer tools we need to build out. So,
once we move into the kind of Q&A portion, I open your thoughts and I'll also provide information on
how you can get into contact with us. All right, next up. So, this is a very recent case study,
the XC, back door incident. It's a pretty fascinating one. How many of you are familiar with XC?
Okay, everyone, great. So, I'll keep the background brief. But XC is a pretty, I think that I really
hope that we have as much of a reflection of it as we did from after solar winds, because just because
this was stopped before it happened, it could have been much worse. And frankly, a lot of the issues
that it has raised, I think, are, you know, something that we really need to address within the
community, especially on the side of industry. So, yeah, XC was an interesting case. So, it was a
several years sophisticated social engineering approach to installing a back door. So, over the
course of, I think, three years, say, both a user and a couple of sock puppet accounts kind of
gained control and became a combinator of a widely used project, XC utils. And the back door was
discovered by, I think, an engineer completing, you know, routine maintenance. And it was something
where, you know, typically, GitHub does not try to immediately take down a project. But we weren't
able to get in touch with the maintainers. We didn't know who was involved. And so, this was an
instance where we did use the, I would say, like, last resort approach of taking down a project.
And then, as things became more clear, we were able to get in touch with the, the real maintainer,
not the bad one. And so, we were able to get in touch with them. We gave, you know, them, the
choice and how they wanted to approach bringing it back up. And this one, you know, I think that there's
a lot of things that we need to learn from XC. So one that I think is a topic of conversation
that's gaining a lot more traction is open source of sustainability and art dependence and, you know,
volunteer maintainers. This is a project that was so widely used, but yet it was being maintained
by one maintainer. This is, you know, it just happens too often. And so, some things that get
have specifically is doing to approach open source sustainability and, and, you know, supporting
maintainers. So we have the get-have sponsors program. We recently announced the creation of the
get-have open source sustainability fund. And then we've also supported the, I think, the sovereign
tech fund through Germany's, like, their creation of funds and within the US, I'm forgetting the
name of the agency, but there's also one within the US. So anyway, we, we were trying to, you know,
I would say be the change and also take responsibility because, you know, the balance of responsibility
when it comes to open source sustainability really should lead on players with the most resources.
And, yeah, so I think, you know, there's, there's a lot of other takeaways from from XC,
another piece is, you know, discussing maintainer burnout, being able to offload projects effectively.
And, yeah, so I think it's, it's hopefully something that just because it was averted won't be
forgotten. And then we can really learn from it and move forward positively.
All right, so I'm getting to that end of my talk. I'll be frank, I've, I've gone very quickly,
but I hope that means that we can, you know, have some interesting time for conversation.
But I'll, I'll kind of touch on some new frontiers and new issues that we're facing for content
moderation. So a big one is, you know, AI, I'm sure you guys are all sick of hearing about it,
everything's AI. And, and, and I am too, but it is something that is, you know, it's really transforming
what it means to be a software developer. It's transforming, you know, the, the moderation approaches
that we have to take because AI can also be, you know, like a, a means to have, you know, like
mass, like spam campaigns and things like that. And so I think we're, it's definitely something
we're experiencing. And so a good habit is interesting because we are both a provider of AI
developer tools. And we're a platform that can be used to host models. And so the, the deep
big policy, I would say is one of our first sort of moderation stances that has been specifically
about AI. But it's definitely something that we're, you know, kind of participating in dialogue
about, um, we recently participated in a partnership on AI workshop about the value chain of AI tools,
um, and you know, who should take responsibility for what? Because it's, it's a lot of different
players, the supply chain there. Um, but yes, so another big thing, um, so the, the question of what
does AI need for software development is kind of existential because arguably, you know, AI is
already making it a lot easier to build software. Um, and that means that there are going to be a
lot more software developers in the future. And so think about a world, get, get, get how I think we
have a 150 million developers in our platform. Um, we have a stated goal that we want one billion
on get have by 2030. So we'll see how that plays out. But I'm very curious to see what the, you know,
the AI revolution means, um, for, um, you know, developers. And so I think a concern is, you know,
how will we scale moderation as our platform becomes larger, more global. And I think it's just a
broader question for the open source community, um, you know, right now because, you know, we, we have
volunteer maintainers because we have community content moderation. We've been able to scale, um,
but it is of challenge. And I think that, you know, while our platform is more resource, we, we,
we definitely, you know, it's, it's something that will be, you know, broadly a challenge for the open source
community. And so I think it's definitely a dialogue. We need to have. All right. So, um, next step,
I'll, I'll, I'll say this, there's a lot of ways that you can get in touch with us. Um, and we really
do me, we're, we're a developer policy team, our focuses on the interests of developers. And so there's
quite a few ways if you want to, um, you know, be collaborative of us. If you want to, um, share your thoughts,
highlight, you know, important, um, you know, pieces of legislation that you're noticing and wanting
to know what we're doing about it. Um, there's quite a few different ways you can collaborate.
So, um, first off on our site policy, so how we govern the platform itself. Um, as I mentioned,
we do have this 30 day notice and comment period versus the Santa site policy changes. Um,
those changes are announced on our blog posts. Um, and so that is something that you can participate in.
But that's that you can always comment on our site policies. And um, I am one of the maintainers
for our site policy repo. And I do read every issue and pull requests that goes into there. And
a lot of people just notice typos and, you know, offer like, you know, opportunities for clarification.
So, there's a lot of different ways to engage. It does, you know, like, I definitely think it's
something if, if you're curious about how we govern our platform. That's an interesting place to go.
Um, we also have a developer policy repo. Um, I would really like to, you know, use that more in our team.
So, encouraging all of you, if you have thoughts, if you have ideas, research to share any
cool projects related to developer policy, um, you can open an issue in our repo. Um, and finally,
you can email us at policy at gethave.com. All right. So, man, I've spread through that. Um,
but hopefully, if any of you have questions, then we can get into that. Um, this QR code is, um, for a
paper, I co-authored with members of our trust and safety and legal team at gethave. It's, you know,
more, I would say a more research and policymaker focus, you know, explanation of how we approach
a moderation of a developer platform. Um, so yeah, encourage you to read it if you're interested.
And, um, yeah, thank you. And I would love to have questions. So, if anyone, you know, has,
has questions, I would appreciate that. So, maybe, thank you.
Um, my question is, one of the big topics at our team, and we are actually curious, what is
your opinion on the lifetime of a, of a branch in the get.
My opinion on the lifetime of a branch and get, um, I don't know if I have necessarily a great answer
to that. Um, I'll be frank, I am not a software developer. My background, the open source
community is from GIS. So, um, I will say, I definitely think that the, the, the question of
open source sustainability, how we maintain things continually and also offload them. Very important,
but yeah, I, I'm sorry. I don't have a really specific answer for that. But thank you.
The working, um, this working. Oh, I'm amazing. Thanks. Uh, first, thanks for your talk. Um,
my questions mostly towards automation, within your review or moderation process, especially since
I used to be a security researcher. GitHub was big on providing IOCs, but also finding malicious
packages and everything. So, how much automation do you actually use? Because you mostly talked
about your team adding one engineer that sounds kind of concerning for me if there's one engineer
in this team. How much do you actually invest in automating finding malicious code, finding
code that should just not be on the website and how do you report on it? Then how could we
as researchers find that better? Yeah, that's a great question. So, I'll also, um, the, the
engineer added to our team was added to our, um, our policy team. And so, he was once an engineer,
or once a lawyer, then became an engineer. And so, he specifically for our, um, like a technological
circumvention review. So, a little bit separate. Um, I, I believe that we do use a bit of proactive
moderation when it comes to security. And so, we have a pretty advanced security lab that both
looks into vulnerabilities in open source itself and then also on GitHub. Um, so, I do understand
that we use proactive moderation for that. Otherwise, um, I believe that, um, um, C. Sam and, um,
like terrorist content are other things that we do, um, proactive moderation for, um, but yeah.
So, it's definitely something that we, we resource quite a bit. Um, our security team is,
I would say, like, pretty, it's a massive focus. Like, both GitHub, Microsoft, like, security
is, I would say, like one of our top priorities.
Um, I would like to thank you for the talk. And for the work you do, as I'm a
entertainer, I sometimes reported spam to the platform. It was really quickly handled. So,
sometimes I find non-sensical commits or comments in discussions. And I find that this account
is active for the past weekend. Post it to 100 triples. So, it's really, uh, easy to see once you see
it once. But my question was, uh, about the point, uh, you wanted a billion developers on GitHub
in a really short time frame. The statistics I saw over the past years say that there is 20 to 30
million developers in the world. So, how do you scale to a billion? Does it include spam and AI
or? You, so we have 20 to 30 million? Yeah. I'm not sure about that. So, we do have 150 million
users in the platform, um, estimated. Um, yeah. So, I, I, I, I, I think that this scaling question is a
lot about, you know, what, you know, AI tools and natural language prompts can do for creating software.
And so, that's, that's, I think that's the, the big thing of the scaling is just making it
so much easier to, um, you know, like, lifting the barriers. Um, though I will say, like, I do,
it was necessarily a question. But as of maintainer, like, I, I just want to say, like, we are
very aware of the spam issue. And it's something that we're working to resolve, or, you know,
not necessarily resolve the deal with. Um, so, again, like, that that asking for feedback,
like, we're really open to ideas, um, on, on that topic specifically, because it's something that
we have noticed a pretty massive influx in and are, are working to resolve. So, anyway, thank
you for your work.
I can hear you. I can repeat your question.
Okay. So, um, there were two questions. The first one was on code as speech and what we do to
reflect human rights principles. So, I'll address that, and then I'll do the AI one. Um, so yeah,
it's a great question. Um, so we both, um, I would say, forgetting the specific principles. But we,
we're in line with both, you know, UN Human Rights principles, so the Santa Clara principles.
And so that is something that informs her approach. Um, code has been defined as speech by legal
precedent. And so that, that is just, you know, a component of it. Though code is speech,
code is also, it's a unique thing. So, I think that is, you know, like a different approach.
And so, yeah, definitely something that, um, you know, we try to take as, you know, I would say,
open, um, of an approach as possible, transparent about our moderation actions. Um,
another big piece of, with GitHub is that we are, what we believe is the largest US platform,
globally available, including in China, which, you know, definitely creates a lot of concerns for,
you know, being able to be as globally available as possible, but also working within different
legal jurisdictions. So, a lot of complicated things there. Um, and then your second question was about AI,
and you know, honestly, I think that's something that we really need to do more on.
And so, we have been looking at how other model marketplaces are approaching AI tools.
So, at the moment, we haven't issued any explicit guidelines, but we did something that we're discussing,
um, not just so you don't to compete with hugging face or whatever, but just, you know, be clear on
what's most useful. Um, but that said, I definitely think that open source is, you know, an excellent
approach for being as, you know, transparent as possible. And so, I, I think that just sharing your,
your code on GitHub if it's an AI tool is really helpful.
Um, and
uh, yeah. Thanks for the talk. And, um, took two questions.
questions. One is, what do I do if I recognize that code, which is made by my company
appears in an open source project, another question which is slightly related to this
dimension, this repose, where we can submit issues. So is this the place to do that? Because
these are some kind of, you know, issues, what we don't really want to share, the exact details
about, and these are public repose. So how do we solve this?
Yeah, thank you for your question. So one thing we do encourage is that people reach out
to maintainers directly. A lot of these disputes can be resolved without a platform getting
involved. So I think that's the first point. You know, I don't know this specific case,
what, you know, the licensing, all of that, I don't know this situation, but I would say
in general, you know, interacting with people directly and explaining things is the best approach.
And yeah, I don't know, what was the second part of your question? Oh, how to get in contact
with this? Yeah, so definitely, I would say the developer policy repo is, you know,
if you have an idea about, you know, more of the public policy world. So it can really
be anything, it's not a very active repo, and I'll be honest, I read everything. So if any
of you want to get in touch with our team, like it is very much like we do read it, the policy
I could have email. That is a good thing for a specific questions and queries, though,
if you have a trust and safety concern, I think it's probably best to, you know, do that
through our platform itself. And yeah, in the site policy repo is specifically about governing
our sites or platform policies. Thank you. Any last questions? All right. Well, thank you so
much. You've been a great audience, and I really appreciate your engagement. And yeah,
yeah, keep in touch with us. We're here at Boston because we want to meet developers and
share, you know, how we govern our platform with you. So anyway, thank you.