From Codebases to LLMs: Non-Inclusive Naming in Linux Foundation Repositories

2026-07-02

AI Summary

This study addresses the lack of empirical analysis on the long-term adoption of non-inclusive naming terminology in Linux Foundation projects and its implications for AI-assisted software development. The authors propose NISCAN, a multilingual static analysis framework grounded in the Inclusive Naming Initiative (INI) lexicon, to detect non-inclusive terms in source code and associated artifacts across 461 repositories and assess their residual presence in large language models (LLMs). For the first time at an ecosystem scale, the work quantifies the prevalence of non-inclusive naming, revealing a 47% reduction since 2020, yet 62.7% of repositories still contain Tier-1 non-inclusive identifiers—predominantly in documentation and comments. Notably, LLMs can regenerate deprecated terms from context, exposing latent ethical risks. The study further identifies key project characteristics influencing naming inclusivity.

Abstract

Since 2020, the Linux Foundation and the multi-organization Inclusive Naming Initiative (INI) have encouraged open-source projects to replace non-inclusive terms such as master/slave and whitelist/blacklist. Although these recommendations have been widely adopted, there is limited empirical evidence on their long-term adoption across Linux Foundation (LF) projects or their implications for AI-assisted software development. In this paper, we present NISCAN, a multilingual static-analysis framework that detects non-inclusive terminology across source code and related software artifacts using the INI vocabulary. Using NISCAN, we conduct the first ecosystem-scale study of inclusive naming across 461 Linux Foundation repositories. Our analysis shows that non-inclusive terminology has declined by approximately 47% since 2020, yet adoption remains incomplete: 62.7% of repositories still contain at least one Tier-1 non-inclusive identifier, while most remaining terminology resides outside source code in documentation, comments, configuration files, and other software artifacts. We further show that repository size, programming language, project functionality, and ecosystem are stronger predictors of term inclusiveness in LF repositories rather than foundation governance. To examine the implications for AI-assisted software development, we conduct a case study evaluating whether large language models (LLMs) can reconstruct legacy non-inclusive identifiers from surrounding program context. The results show that historical naming decisions remain embedded in model predictions even after identifiers have been renamed. Overall, our study findings provide the first ecosystem-scale assessment of inclusive naming adoption within the Linux Foundation and highlight the importance of addressing terminology residue to support responsible naming and ethically sourced code generation.

Problem

• inclusive naming
• non-inclusive terminology
• Linux Foundation
• AI-assisted software development
• large language models

Innovation

• inclusive naming
• static analysis
• large language models
• software artifacts
• terminology residue