AI Policy Update Proposal

[mrego]

Servo’s Technical Steering Committee is looking for feedback regarding our policy for contributions made with generative AI. The current policy, adopted in June 2024, is documented in the Servo book (permalink).

Earlier this year, a member of the TSC requested permission to experiment with GitHub Copilot. We granted them permission to do that for a single feature as an experiment, so we can better understand and document their process, and potentially re-evaluate our AI policy.

After the experiment, we started discussing what to do about our AI policy, namely, should we keep our current policy or allow specific exceptions? A poll within the TSC showed that we were quite divided about what to do next, with similar votes in favour of each option.

Discussion in the TSC continued in an attempt to reach consensus, and we’re now proposing the following changes to our AI policy:

1. Update the AI policy to allow usage of some AI tools to make the project more inclusive and accessible (like using translation tools, tools to improve the language, etc.). These are not related to code contribution directly, but how folks participate in the project.

2. One year testing period that allows Servo maintainers that request it to experiment with GitHub Copilot, after that year and with the experience gained, we will revisit this topic. This testing period is subject to the guidelines below:

   • PRs created using Copilot should be tagged accordingly. This allows maintainers to pay closer attention when reviewing them.
   • Set suggestions matching public code setting to Blocked. This lowers the risk of copyright violations.
   • Use it only for things like auto-complete, small snippets and refactors; but not for full code generation.

While a majority of TSC members were in favour of these proposals, a significant minority were opposed, so we'd like to hear from our community, including (but not limited to) in this GitHub discussion and in this Zulip thread. These changes will go into effect no earlier than June 2025, subject to a review of your feedback.

We know AI is a controversial topic, so we'd like to remind everyone to keep this discussion as constructive and non-confrontational as possible, observing our code of conduct.

[ptrcnull]

Just to clarify, does "usage of some AI tools to make the project more inclusive and accessible" include documentation? ( one could argue translating documentation to other languages, or documenting some obscure parts of code counts as making Servo more accessible )

[ptrcnull]

The reason I'm asking is that generating semi-coherent documentation with LLMs is very low-effort for contributors, but it usually misses the point of documenting obscure code - including more context, decisions, things that are not obvious from code itself.

Translating documentation with "AI" translation tools has its issues as well, usually in the form of making the documentation complete garbage - when Microsoft tried that, they got "data processing with pigsty herd" or "eating a chalice of orange sauce".

[EchedelleLR]

Not to mention the current state of AWS documentation touched by AI...

[LunarEclipse363]

Hi, regarding non-code contributions, specifically documentation, I feel like AI tools are not appropriate for the job because of the way they tend to add plausible-sounding but wrong information into text they generate.

I would argue that it's much more important for documentation to be precise and correct than for it to be written in perfectly grammatically correct language.

Of course I imagine this is to be weighed against a reduction of workload for people writing the documentation, however I generally find it more productive to not find an answer to a question immediately than to get a wrong answer.

My personal experience with AI-generated answers from search engines has been that they often confidently present completely wrong answers, and it's less work to ignore them and look for answers from authoritative sources (i.e. documentation) from the start, than trusting the AI-generated answer and finding out it's wrong later.

In summary, I believe it's a bad idea to allow AI-generated text for use in documentation because it could result in making the one place that should have authoritative and reliable information lack those qualities.

[ptrcnull]

Another concern:

Set suggestions matching public code setting to Blocked. This lowers the risk of copyright violations.

Considering that it only lowers, but not eliminates the risk of copyright violations, is Servo equipped (financially, etc.) to handle a situation where a copyright violation occurs? Who covers the eventual cost of litigation if someone decides to sue - Servo, Igalia, or the contributor who added the copyrighted code to Servo?

[milleniumbug]

While Microsoft has declared previously that they will "pay any legal damages for customers using Copilot, Bing Chat, and other AI services as long as they use built-in guardrails", I think relying on this puts the project in legal dependency on Microsoft, which is extremely dangerous to have in an open source project.

[jschwe]

Servo is not a paying customer for Copilot, so this protection is not available in any case (at least that is how I understand it).

[emenel]

👎👎 this will only make the project less trustworthy, less robust, and less open. It will also make Servo far less sustainable in both technical/documentation and environmental impact. You will lose a lot of contributors and supporters, replacing them with dubious contributions.

[emenel]

how is that not constructive? they asked how we all see it, i provided an answer. i think this will hurt the project in the long run.

[mcclure]

If we are voluntary contributors to the project, then how we feel has a material impact on the project.

[emenel]

this is a good (and entertaining) overview of why LLM's and "ai" are bad for security and trustworthiness ...

https://www.youtube.com/watch?v=ajGX7odA87k&t=11s

but also, there is a lot of writing, reporting, and discussion about how poor these tools are and the kind of technical (and other) debt you end up with if you rely on them. please feel free to search it out.

[ptrcnull]

The Servo contribution policy currently requires the commit author to sign off commits with the Developer Certificate of Origin (#32496), which includes:

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file

However, as far as I can tell, there's no way to ensure the snippet generated by Copilot was sourced from open-source repositories with licenses that are permissive enough to use without a copyright notice - does the TSC plan to change the policy to remove the DCO sign-off requirement?

[ptrcnull]

( I presume that the following section of DCO:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

does not apply here, as most jurisdictions do not consider "AI" generated work to be copyrightable by the person who wrote the prompt, etc. )

[auctumnus]

I am not a contributor myself but I'd like to chime in to note that Copilot can frequently be tricky in complex code, in ways that aren't clear, even in "small snippets and refactoring" - recently, in making a small implementation of Hindley-Milner, a relatively common algorithm which should have good enough coverage to be simple for an LLM to generate, it frequently output incorrect code, in ways I didn't necessarily understand. For a project with subtle correctness to worry about, I would highly recommend dissuading contributors from using Copilot.

It's not necessarily possible to prevent all Copilot use - LLM output is here with us forever now - but I think the current AI policy seems reasonable for Servo.

[awilfox]

I've been trying to contribute small fixes to Servo as I can, and bringing up Servo on systems and architectures that are "less popular" to ensure it is portable and can serve the widest number of people. Specifically, my interests are in platforms like Power, Arm, and MIPS.

I have a number of concerns about this policy:

1. My first is that changes made by AI can be subtly wrong in ways that even experts do not immediately realise (see David Chisnall's post for examples). Even before AI, there has been subtly wrong code that "worked" on x86_64 but was wrong and caused runtime errors on other platforms. Adding AI hallucinations could cause even more issues like this.

2. Specifically on documentation, as said in some of the other answers here, AI is not reliable in authoring documentation or even necessarily being able to make full sense of how code works to generate documentation. My secondary languages are French and Ukrainian, and machine translation can perform okay in French sometimes, but it is not good at all at Ukrainian. I am concerned that using machine translation could cause documentation that does not make sense or, in the worst case, could be actively harmful. This can be either by using the wrong terminology, or by writing language that is offensive - it could have learned translations from some of the malicious translations from Ubuntu and other projects, for example.

3. The environmental impact of using LLMs, including power, water, precious metals, and other resources is also concerning for reasons of climate impact and also impact on society at large.

4. The quote here:

   This allows maintainers to pay closer attention when reviewing them.

   suggests that this will cause Servo's maintainers to have to spend more time and energy reviewing these contributions, which may actually cause them to have negative value, as reasoning about the correctness of AI-generated code will result in more work than just having them write it themselves in the first place. I am concerned about maintainer burn-out, and about lengthening the time of other reviews or work to be completed as the maintainers will be bogged down by LLM-generated contributions.

Note that when you allow LLM contributions, you invite a number of people who want to use it to have something on their CV ("I contributed to Servo"). Others may be well-meaning but do not understand programming and therefore cannot reason about whether or not the change makes any sense. This can do a lot of harm to the project in many ways, and the current policy already makes these cases very clearly and concisely. For that reason I would support keeping the current policy instead of widening it.

[multiplealiases]

"ignore all criticisms; breach trust thermocline"

Technical reasons aside, I urge you to consider the implications (and there is no escaping it) of this policy update. A good chunk of people (many of which may have considered contributing, and some of which may be active contributors) are going to see this and consider Servo tainted. Merely entertaining AI these days is a statement, and that statement is "we don't care about quality, we don't care about contributors, all hail the slop machine".

It's bad optics.

[stephenmartindale]

Rescinding a prior anti-A.I. policy is an even stronger statement that merely "entertaining" it and, then, there's also this guideline in the new proposal:

Use it only for things like auto-complete, small snippets and refactors; but not for full code generation.

We already have conventional developer tools for all of those use-cases so explicitly limiting "A.I." use with this guideline must mean one of two alternatives:

1. Any use of "A.I." will be at most marginally better than using conventional developer tooling so the project is accepting bad optics for very little return.
2. Terms like "snippets" or "refactors" are not congruent with developer vernacular; this guideline is misleading.

These optics are far, far worse than "bad"!

[Be-ing]

106 👎 to literally just one 👍 on the original post

Merely opening this discussion has already been harmful.

[delan]

As a coauthor of the current policy, these proposals are a mistake, and I have consistently said they are a mistake. I can elaborate on this in longer form if people want, but I’m honestly really tired of this whole situation, and I hope I can spend that time contributing to Servo in other ways.

[Be-ing]

I’m honestly really tired of this whole situation

Isn't the purpose of having a written policy to avoid relitigating the same topic over and over? I don't see any rationale explaining some novel situation that warrants a reconsideration.

[olivia-fl]

The current policy is excellent, and I have already seen several other projects adopt similar policies that were explicitly inspired by servo. That you so much for your work on it.

[farooqkz]

An outsider here. I have some comments regarding using LLMs for code. Be warned. They are very radical!

I don't have experience with a Rust codebase of this size. But I have great concerns regarding AI/ML. Not because I see it as a hype. But because most good models are only in the hand of specific big techs. And they have full control over it. Relying and getting used to these models could make people lazy. And when they aren't available anymore, it could interfere in development.

If I was in your shoes and I had the resources, I would've deployed and used a model on my own infrastructure. If I had more resources and data, I might also have considered training a model specific only to the programming languages servo uses. This also might have other benefits. Such as feeding the entire codebase to the LLM. And then using it as an encyclopedia about the it. For a big codebase, it could be very useful for new contributors.

Edit: In my own projects, I've found DuckDuckGo's Llamma useful for code review for Typescript and Rust. You give it the code and ask it to find the mistakes. Then it finds like 10 mistakes. And usually 2-3 of them are valid. And you can see that yourself. As your mind is filled. You can also look back at your code after a while or ask someone else to review it. But human time is valuable. With LLM, you pay computation time and buy valuable human time and energy.

[mcclure]

Responding personally: If Servo begins allowing contributions for Copilot or other random code generators¹ I will halt my monetary contributions to Servo and also halt my code contributions to Servo.

I am not a major Servo contributor, but I would like to help Servo if I can. However, I will not contribute code on a project where you don't know if code you are interacting with or potentially having to fix was written by a human, or randomly generated. I will expend effort to create things, but I refuse to expend effort to clean up after a random-text-generator robot creating nonsense code. Meanwhile, I will not intentionally support an organization that considers AI morally acceptable.

I believe that "AI" is a cancer on human society and a poison to the human mind. I believe that its use will only make everything it touches worse. Moreover I believe that, due to inherent irrationality in capitalism— Capitalism will always seek to minimize labor costs, no matter what it has to sacrifice to do it, even if it means overall costs increase— I believe "AI" in all things is inevitable, unless every human who can see what is happening engages in total moral rejection of not just "AI" but any service or organization that even incidentally uses "AI". In some cases I'm not able to act out this moral view— software like Github, Firefox, or Google now integrate "AI", but I use them anyway, because they are a monopoly, or because their competitors also use "AI". I can't easily cut Github or Firefox out of my life. But my reasons for participating in Servo are primarily ideological. I really like Servo, but I don't need Servo; it would be very easy for me to stop paying attention to it altogether, because there is such a wealth of existing alternatives which are currently in a more complete state. Significant work is needed to get Servo to the point where it can replace the existing engines, and given those other engines do exist, nothing really is going to get you there except some kind of ideology. This makes a clear ideological basis more important for Servo than it is for other projects. You need to think about why you're doing what you're doing.

There is another thing. As I mentioned above Firefox has recently embraced "AI" in their feature set (they are trying to move everyone to a new tab layout which has an always-present "AI chatbot" widget in the bottom left corner); I and many other people are now looking for a Firefox alternative as a result. I frequently have people ask me what browser they should switch to if they don't want to support "AI". Since I can't really recommend a Firefox fork (no Firefox fork so far is planning to remove the AI-bot pane, they just disable it— and it's not even clear if Floorp and Waterfox will disable it), I usually recommend Servo as the current "no AI" candidate. I don't know if it's worked, but I've encouraged people that if they want an alternative to the existing browsers they should consider financially supporting Servo. (No, I didn't get confirmation from your project avoiding "AI" is your actual intent. I just hoped.) There is a market segment that wants "AI"-free tech and in a crowded market, rejection of "AI" could be a significant differentiator. However, I will obviously not be able to pitch Servo as the "no AI" alternative if Servo is partially developed using that same AI. Even if I wanted to try, it simply wouldn't be believable. If you take this step, you potentially give the "no AI" market segment up.

My statements above are about code. I believe code is a uniquely dangerous deployment site for "AI", because in programming, the most dangerous thing is code which is almost correct. The human brain has a significant tendency toward seeing what it expects to see and a person can sometimes look directly at something that's mostly correct but wrong without noticing it. However, creating this almost correct code is exactly what "AI" is best at. The purpose of the content generators people now call "AI" is to create something which can plausibly fool a human into believing they are looking at a real picture, real paragraph of text, or real computer program code. So Copilot might as well be designed to generate bugs a human cannot catch. Moreover, computer programs are chaotic systems where bad code in one place might break an invariant and cause bad behavior for the entire program. This means use of "AI" for code is much worse than other uses. But as far as those other uses go:

• If Servo used "AI" for its documentation, this probably wouldn't stop me from using Servo itself, though I'd probably (for the aforementioned moral reasons) stop donating to Servo or recommending it to others as a "no-AI" alternative to Chrome/Firefox. This said, I certainly wouldn't read that documentation (because why read something that might or might not be random nonsense, with no way to tell?), and would warn others away from it (because it might be misleading them).

• I do not personally believe that machine learning based translation necessarily poses the same problems as using babble-bot AI to generate code or factual text (documentation), because code and factual text can generally be thought of as having objective "right answers" whereas translation is relatively more subjective. It's noteworthy that translation, like text OCR and speech-to-text, is a use of machine learning that long predates the current "AI" ideology— these are uses of machine learning that make sense as a solution to a problem rather than as a quasi-religious social terraforming project. I do think machine translation gives worse results than, and should never be used as a replacement for, human translators, but I wouldn't make the strict statements I do above. However I would ask Servo try to avoid working with actively exploitative companies such as OpenAI when doing machine translation.

¹ I will not say "Artificial Intelligence", because it isn't

[dmoonfire]

While I haven't contributed code, I do contribute money (I will not contribute to AI-writtencode I'm aware of). Beyond that, I agree with all of this. In my day job, I spend so much time going through "looks right" code and finding flaws and inconsistencies with LLM-generated code.

My concern is:

Use it only for things like auto-complete, small snippets and refactors; but not for full code generation.

How do you put those guardrails in? How do you know someone is "only" using auto-complete or snippets? Even if it starts with "only", the boundaries start to grow "it isn't that large of a refactor, I'll use more of it" and then more and more. Also, refactoring has the potential of breaking code and "looks right" is much harder to find issues.

[Xiretza]

First of all, I appreciate that you decided to have an open and public discussion about this, I hope people's reactions won't make you regret taking that step.

I think the reasons for why this is a bad idea are already being discussed aplenty; I wanted to note something different: I think you should investigate and reflect upon the apparent stark difference in reception to this idea between the TSC members and the respondents in this post. Were TSC members:

• unaware of the arguments being presented here,
• not convinced of their validity/impact,
• or did they think that while valid, they were outweighed by some huge benefits that aren't being discussed here?

[ptrcnull]

I think the TSC minutes linked above by @delan shed some light on this:

sid: [...] I don't want to shut the door to AI. Shutting the door might hurt funding. Please open door to AI

gregory: Allowing maintainers is different from mandating community. Even if community is concerned about AI, why ban me from it.

[rgacogne]

Well, I had been sponsoring servo's development for a while but I just cancelled my sponsorship. Happy to start it back once the use of AI is no longer on the table.

[ptrcnull]

Also, for a bit of context that might not be obvious here: sid in the quoted minutes log is Sid Askary, a person from outside of Servo entirely, a Rust for Linux contributor, and a "Technical Director of Open-Source" at Futurewei Technologies.

It is unclear to me what his involvment in Servo is, as I cannot find any contributions - and while I myself don't have many as well, I also don't join TSC meetings to push them towards "AI".

[Lyude]

Hi: I'd like to object against this policy because there's no actual benefit that is mentioned here. Writing code is not the struggle of maintaining an application, and typing documentation is not the struggle of documenting things. For the former, the struggle is actually understanding how to solve a problem and come up with solutions for it, along with fixing subtle errors and logic issues - writing code is the easiest part. For the latter, accuracy is key and inaccurate documentation is substantially worse then no documentation.
So: what is the actual perceived benefit then? The usage of AI for generating code means you are getting a large block of code - possibly taken from other codebases, that you must now as a maintainer review for accuracy and hope you don't hit a subtle issue you missed. It is an extra layer of code review on top of the fact you're -already a maintainer having to review people's code all day-, you now have to review code from a contributor that randomly hallucinates things and cannot answer any questions as to why code was written a certain way. How does this save the maintainer time? And if you generate documentation with it, now you have to deal with potential fallout when contributors gets confused with your documentation and submit incorrect patches. You saved yourself typing in both cases, but quite literally that is possibly the least significant timesink of any of this. How much extra time have you actually spent babysitting the tools that were meant to help you?

And, I hate to say it: but I do agree this hurts the reputation of servo and willingness of people to contribute. As someone who has worked in FOSS for years frankly getting told I need to deal with AI generated code is still more then enough to make me take my time and effort somewhere else. I mention this because frankly, a lot of people here are going to get angry and give you the same point with far less respect - and I can certainly understand that. Not only do we want to stop this in projects like servo, people working in FOSS like myself want to make sure that AI absolutely does not become a norm in FOSS as it will make maintainer's lives everywhere so much more miserable.

Also: on the topic of funding, come on guys. If you want to get AI funding fine, I know how capitalism is. But there are more clever ways of doing this and waving the shiny AI keys in front of investors to get them to give money then actually honestly using the tools. Show some demo of using ChatGPT on the browser or something, be more creative then just going "yeah well who cares about maintaining a project anyway".

[LikeLakers2]

My opinion on AI has always been that it should only be used as a means to assist, not to replace.

For example, it could be given some documentation and suggest improvements (such as making something more concise), or perhaps it might be given a code problem and asked "Would there be any tools in std that might help?". However, I believe that should be the limit - and that anything further than that should be heavily vetted by the human who sent the request to the AI.

As a practical example, some friends and I recently used ChatGPT to help us with our storytelling. In particular, we had a city in our roleplay which was recently attacked - and we wanted to get ideas on how that might affect the city's future. We used ChatGPT for this, giving it a stripped-down version of the situation to work off of - but we were careful not to just take its ideas and suggestions wholesale. Instead, we took them as points of consideration, and invented our own answers.

Whether the Servo project allows or disallows AI, I don't care. What I do care about is, if it allows AI usage, it ensures that those contributing aren't simply copying an AI's output wholesale - and that any parts still contributed by an AI (which I believe should be minimal anyways) are marked appropriately for review. After all, AI models can be useful for many tasks, but they are not the end-all-be-all tool that some people wish they were.

[sdomi]

I'm strongly against. My 2 cents:

PRs created using Copilot should be tagged accordingly.

This is unenforceable, and in the long term will lead to either all PRs getting "closer attention when reviewing" (sic), or none at all. In one case this means increased work for maintainers for basically no gain, in the other case it means potentially buggy, not thought-through code getting through the review much more easily. In both cases, the code quality will suffer.

Set suggestions matching public code setting to Blocked. This lowers the risk of copyright violations.

you either violate the copyright or you don't. With the presently available LLMs trained on public data, this isn't a risk. This is a fact. The risk you're speaking of is getting found out doing so.

Use it only for things like auto-complete, small snippets and refactors; but not for full code generation.

Just like one of the previous points, this is unenforceable. "Small snippets and refactors" is so vague and up to interpretation that I don't even know what you exactly mean.

---

I also echo everyone else's concerns about using LLMs for documentation; If this leads to whole documents being autogenerated, you might as well not provide any docs IMHO.

[tomoverlund]

you either violate the copyright or you don't. With the presently available LLMs trained on public data, this isn't a risk. This is a fact.

No, such legal questions are a grey area, and will depend on individual cases and the courts that decide them. Are you, as a person, allowed to learn from public data, and apply your knowledge when writing new code? Yes, you are. But if you were to slavishly copy a big chunk of code, you'd likely be in violation. But then it's quite common to copy large snippets of code from places like StackOverflow, where they are explicitly posted to help people solve their problems.

I think the safest and best use of AI is in understanding an existing codebase and using it as an assistant, not an oracle. And projects that allow the use of AI in this manner will have more productive developers. Of course there is the problem of AI slop, but I don't think slop would get past code review.

But I myself have never actually used CoPilot or any other AI coding tool. In personal projects, the legal risk has deterred me. And if I do start using one, I will only do so using an open source model that I run locally.

[MikeTaylor]

My earlier comment here was (in retrospect quite rightly) marked as off-topic. I referred to e14n and said nothing else, so I was only contributing heat, not light. Let me try again:

We live in a world where there are a tiny number of browser engines, and one of those is owned by a megacorp that has not only dropped its old "Don't Be Evil" motto but seems to be actively plunging into the dark side with all possible haste. The only other browser engine of current significance is Mozilla's — and they are setting fire to their reputation in every possible way (ludicrous CEO compensation, sprint towards AI everywhere, pivoting towards advertising, generally not at all behaving as we would hope or expect from a non-profit.)

In that context, servo is desperately needed — but its whole value proposition is to be different from the current rapidly enshittifying browser engines. That's why the present proposal is so desperately disappointing. All the technical problems with the move towards AI have been outlined above, and do not need to be reiterated. What concerns me here is what it tells us about the project culturally. It has the distinct whiff of "all the cool kids are doing it, so we should, too". But all the cool kids are doing a ton of other things that are the exact opposite of cool. If servo does this, who will feel confident that they won't then start doing all the other things, too?

Be different. That's the value proposition.

[wusyong]

Hello, I'm a contributor and TSC member here. I tried to formulate my thoughts in the past few days, but it contained some discussion might be off-topic so I published to my blog instead: Why I voted for Servo's AI policy change despite I don't use those tools

I don't use any AI tools nowadays to commit code, but my main concern is potential of losing contributors. It's difficult to contribute and land the feature we wish to push already. I believe we will need to re-negotiate the policy change, but I hope we could discuss how to encourage the contribution and help the contributors in the long run.

[joepie91]

The feedback I really want to get is how do we proceed next. Because even with current policy, it will be extreme difficult to enforce.

Okay. What then, is the problem that needs solving here? Sure, it is difficult to enforce an "AI" ban - that's the nature of the technology, it deliberately deceives users. But this isn't really anything new from a governance perspective; societies have had scams with the same properties of deception for at least thousands of years, and yet people have acted against it successfully time after time, and pushed it towards the fringes. It has never been a perfect solution and it doesn't need to be, to be effective.

I don't think anybody in this thread is under any illusion that we can somehow reliably detect 100% of the "AI" contributions, but that is not the point. The point is to deny it legitimacy, to make it very clear that if you are trying to break this policy, you will receive no sympathy or support; and the policy serves as a tool to enforce this on a social level if someone does get caught breaking it. It works exactly the same way as every other community rule.

So, I don't see an issue with the policy as it currently stands (prior to this change proposal), it's a good policy and it's about the most enforceable thing we can realistically expect to have, within the constraints of the project's sphere of influence. So what, exactly, is there to 'proceed' with, besides rejecting this proposal? What, specifically, is the problem that further feedback is being sought for here?

[MikeTaylor]

I think this comment captures the issue perfectly. I regret that I have only one 👍 to give it.

[Be-ing]

I didn't intend to continue the conversation because I agree your points and that's why I didn't use any AI tool myself. Right now, I'm trying to revert the proposal as well.

Ah, thank you for clarifying. I did not understand this from your blog post. But now I understand the blog post as explaining your past action rather than your current opinion.

[Be-ing]

The feedback I really want to get is how do we proceed next. Because even with current policy, it will be extreme difficult to enforce.

This isn't a requirement because you already have a written policy published elsewhere, but you may want to consider adding a checkbox to the pull request template. For example, Kanidm's PR template has this:

- [ ] This PR contains no AI generated code

When I opened my first PR for Kanidm and saw that, it increased my respect for the project and my desire to continue contributing.

As @joepie91 elaborated, of course this can't prevent everyone from trying to violate the policy. But it is a very clear statement of expectations. It adds a social obstacle. If someone really wants to violate the policy, they have to explicitly choose to lie every time they open a PR.

Apparently there are such people that believe it's acceptable to lie and violate a project's policy while trying to contribute to it. If someone ever does obviously violate the policy, you can simply close the PR/issue and leave a comment with a link to the policy without having to get dragged down in a pointless discussion about the merits of their nonsense. If they do it again, you could ban them. Getting dragged into such pointless discussions is something that could burn out contributors. If you're not familiar with this kind of spam, here are some examples:
rust-lang/rust#126204
rust-lang/rfcs#3541
rust-lang/rfcs#3497
I doubt anyone would seriously argue that the contributors engaging in discussion responding to that spam was beneficial to the project.

[Be-ing]

The current policy contains these two sentences:

For now, we’re taking a cautious approach to these tools due to their effects — both unknown and observed — on project health and maintenance burden. This field is evolving quickly, so we are open to revising this policy at a later date, given proposals for particular tools that mitigate these effects.

I think a positive outcome of this discussion would be to simply remove those two sentences. That would shut the door on having to discuss it again in the future and go through this whole process again of contributors and donors leaving.

I also suggest adding a new paragraph along the lines of:

Impact on the web: The web crawlers that many AI tools run create an extraordinary burden on web infrastructure, especially the infrastructure of free and open source software projects. As a free and open source web technology project, we do not support use use of tools that have such a damaging impact on the web.

[joepie91]

In addition to my earlier comment, I want to highlight another thing regarding the 'funding' point; funding is never without strings, and the type of strings matters. If the hope is to gain funding from "AI"(-aligned) companies, then the string is going to be that you are expected to have first-class support for "AI" tools in Servo itself; just like what happened with the widespread funding of FOSS projects by cryptocurrency projects, where down the line those projects were suddenly expected to add cryptowallets and whatnot to retain their funding.

Seeking funding from such companies would most likely not just mean tolerating "AI"; it would result in Servo becoming an "AI browser".

[mcclure]

I can't tell how hypothetical this side discussion is, but—

I think it would be a mistake to chase money from AI firms, or at least to make changes in order to get money from AI firms. There probably is a lot of that money sloshing around right now, but (as I've personally seen happen with previous investment-driven tech fads) that money stream could disappear very suddenly and without warning, possibly as early as this year. Make "AI" part of Servo's character for cash and the money will flow only as long as the AI-industry expansion lasts… but the damage to your community will be permanent (and any bugs introduced by "AI"-generated garbage code could stick around in your codebase for a lot longer too).

[SimonSapin]

I believe this entire sub-thread is based solely on one comment by Sid Askary in the 2025-02 TSC synchronous meeting. I think it’s worth pointing out:

• These meetings are open to anyone
• Sid is not a TSC member nor can I find them in git shortlog
• That comment did not get any response in that meeting (according to minutes, I was not attending)
• The TSC has a private channel on servo.zulipchat.com. Much of the discussion around this policy and potential updates happened there
• I regularly read all of that channel. The idea that the current policy might possibly hurt project funding was never brought up there. So I don’t believe this was at all a motivation for the change proposal.

I think it’s bad that so much of those discussions happened in private. I think it’s easy for non-members to read too much into the public meeting minutes when that’s all that’s available. I think the private Zulip channel should either be retired, or reserved for a very narrow set of administrative topics. In particular, the async continuation of any topic discussed in the public sync meeting should definitely happen in public.

[webbeef]

It's obviously impossible to prevent people from using private discussion channels, so I'm not sure retiring the TSC channel would help much. Making it readable to all (maybe only after some time, a bit like some government records) could maybe work better.

In any case, the change needs to come from within the TSC.

[Be-ing]

These meetings are open to anyone
Sid is not a TSC member nor can I find them in git shortlog

Perhaps the meetings should not be called "TSC meetings"? Maybe "project meetings" or something general like that?

I think the private Zulip channel should either be retired, or reserved for a very narrow set of administrative topics.

Having been in such private Zulip channels before, there's an appropriate use of it. But the default should be to use the public channels unless there's some specific reason the discussion should be private. I've experienced discussions that started in private channels but I realized didn't need to be there, so I spoke up in the private channel and asked the participants to move the discussion to a public channel.

[mcclure]

@SimonSapin , thank you for clarifying that.

[kevinheavey]

btw the current formulation of the policy excludes anyone who relies on voice coding:

Contributions must not include content generated by large language models or other probabilistic tools

Voice coders, even those who are not using LLMs, are using speech recognition engines that are (of course) probabilistic tools

[awilfox]

I'm not trying to rule-lawyer here, but those contributions are not "generated" by those probabilistic tools - they are "input" by them. The contribution is still generated by the brain of the person who is driving the tool, not the tool itself.

This could have been phrased significantly better and I agree it is not great. But I do see the intent and I do not believe the intent is at all to disadvantage disabled contributors.

[delan]

thanks for the feedback. i think our policy should be amended to explicitly allow voice-to-text tools, even though they sometimes use similar underlying technology to LLM autocompletes and text generators, since they’re a clear win for a11y and most of the reasons for our policy don’t apply to them.

[SimonSapin]

In addition to being a clear a11y win, I’d consider (probabilistic) voice recognition to be in a different category from generative models: there a single correct answer to what the user meant to say, and when the tool makes a mistake they can immediately notice and fix it.

[delan]

some thoughts that are too long for a comment: https://www.azabani.com/2025/04/11/generative-ai-in-servo.html

there i cover (imo) how it happened, your feedback, what we should do next, and how the policy could be improved. thank you for your feedback everyone, it was very insightful and i hope it makes a difference.

[rabbithawk256]

I'm voting against this - from my experience, Copilot tends to produce pretty heuristic code; it works for now, but it's a bodge more than anything and it's incredibly painful to grow from. It's useful for menial tasks, sure, but I can't really figure out a way to say "Please only use LLM-generated code for repetitive tasks" and prove that you're not having crucial parts of the engine be LLM-written without enforcing a complete ban, unfortunately >_>

[rabbithawk256]

To addendum - I don't really feel like LLM code is a smart idea in something that could be as mission-critical as Servo - since there could be absolutely horrifying vulnerabilities in the code that get skipped for whatever reason (bad/missing auditing, quick patches, e.g.) that the LLM has produced

[acook]

There are few generative AI tools that are ethically trained, and even those which are not have limited reliability and a high human cost. The idea of "reducing" copyright infringement - because we all know it will it is just a matter of how well it can be obfuscated - is wild to me.

[charlot-shaw]

Non-Contributor, but long-time observer here.

I've been asked to work on a paper before, in a volunteer capacity, and I spent several days picking through the project, documenting all the little shortcomings, pieces that were subtly wrong. Later I found that the vast majority of the paper was directly copy-pasted out of an interaction with ChatGPT.

My issue then boils down to: "Why should I, as hypothetical developer reviewing PRs, put effort into understanding and correcting something that the contributor didn't even write?"

From a logistics point of view, having the person with the acquired skills and domain knowledge have to spend time on hallucinated code is a bad exchange. They are volunteering their time as programmers, not as editors to someone else's computer-assisted wish fulfillment.
It's worse still when you consider that the person submitting the PR has learned less about the system, so they aren't gaining knowledge to potentially become a reviewer in their own right.
The reciprocal bond of working towards a common goal is eroded; the expert has to wade through junk, and the student loses opportunities to learn.

So yeah, usage of plagiarism engines is a leak in the collective knowledge/effort pool.

[ghost]

I've become interested in the project recently, specifically in response to Firefox's degradation into an AI/ad engine. I am really quite despondent seeing Servo consider this change. AI, in its current form, appears to have no helpful application. We can see its effects everywhere in the coding ecosystem even now: nonsense code appearing in supposedly curated code, help fora corrupted by nonsense babble, etc. It isn't helpful or safe to use even in documentation, but in coding it's particularly dangerous. There is no amount of human "triple checking"-style assurance that will hold. The point of using AI/LLM is not to learn, or grow, but to emit things that look like functional solutions and "save time" by using them in place of curated work. These things are poison.

The current policy may be to some extent unenforceable, but the same could be said of OS licenses, and yet we still pursue them because they are technically and ideologically correct. I would be saddened to see Servo succumb to this particular fad, and would likely not be interested in seeking out ways to contribute moving forward.

[lf-]

As a maintainer of a large open source project not on GitHub (Lix), we've had substantial infrastructure incidents caused by LLM companies recklessly scraping our gerrit instance in spite of the robots.txt forbidding it. The people developing LLMs do not care one iota about consent, which is why they are shoving LLMs down everyone's throats against their will. This seems against the mission of Servo in an environment dominated by the exact corporate players building said LLMs and abusing their users' consent.

Also, LLM tools generate, chiefly, code which its purported authors very frequently don't understand in my personal experience, and which contains subtle bugs accordingly, or which often mismatch project conventions. The most limited resource in an open source project is very often maintainer bandwidth; it certainly is in our case, and permitting tools that make writing more code easy at the cost of bugs is a poor trade in open source where it's hard to always expect a contributor sticks around for stabilization. There's even more reason to want to get it right the first time in open source than closed source. Getting it right generally means less code and more assurance it's right, both the opposite of the output of LLMs

[Geobert]

I’ll stop my monthly donation if that goes on. genAI is a disgrace

[alanwsmith]

I'm not going to be able to add to the reasons folks have against this move, but I'm with them. From both a practical and moral viewpoint I stand against the use/inclusion of AI.

[vriesk]

All I can say is that if you ever do this, I believe your project and your TSC deserves to be forked-out into oblivion.

Because the sole reason the Servo project makes sense to exist is to make things objectively better to the existing numerous alternatives. Code excellence per se due to superb tooling and review practices, and also freedom from the "AI" being shoved into our throats by literally everybody else, would be two such reasons for me at least. With this, you will lose both.

[skyfaller]

I have a recurring donation that I will cancel if Servo accepts AI slop into its code or documentation. I also will no longer promote Servo. If you can't hold the line against AI grift, we can't expect you to resist the next grifter fad like NFTs or whatever. It's a fatal sign for your judgement and governance.

[mrego]

Thanks everyone for your feedback here and in other places.

Servo TSC would like to share that we have decided to not go forward with this proposal and we'll keep the AI policy as is.

In the future, if we want to do any change to this policy the discussions will happen in public channels to get early feedback about them.

Thanks again.

[xvello]

@mrego this is good news! Will minutes from this TSC discussion be released, in the interest of transparency?