Applications / .src / SN2610T-T87824 · published by ICANN 7 October 2026 · snapshot 2026-10-08

.src

CommunityActive

§ 1 — Meaning of the string Q118·Q120

The name refers to 'source' as in 'source code', the (human readable) instructions that can be compiled into computer software or hardware.

/sɔːs/

§ 2 — Mission and purpose Q133

The internet has changed how software is created: the free and open source community has created billions of lines of code in a distributed manner. There is obviously wide usage of domain names throughout the software supply chain because of that, which has been a major enabler but is also an unrecognised liability. This is because of a structural mismatch between the considerations for internet operations and information management. Internet operations deals with real-time consumption ('where do I find this particular machine on the internet'), while information management is using domain names as a recall mechanism over a prolonged period --- as much as decades.
Anywhere in the lifecycle of a software project developers may acquire a domain name and proceed to use that --- for publishing their source code, a blog with release announcements, (documentation) websites, mailing lists, issue trackers, et cetera. They use a variety of top level domains for this: .org, .io, .ai, .rs, .eu, .foundation, .app, and many more.
While any given project is under active development, this of course is very convenient: users reliably know how to find www.example.org, can clone the software from git.example.eu with confidence and trust reported vulnerabilities and emails with new releases or urgent security notifications from example.eu. The well-known domain name of the project helps users to establish trust in the provenance of related information.
This is also the issue: these *non-persistent* domain names are depended upon by the infrastructure ecosystem at large as a *trust signal*. Software distributions authoritatively point to these names, helpful postings on internet fora and social media nudge users towards the domain name in question, and manuals and documentation of other applications refer to them.
That means that once these domain names are abandoned, and a new owner silently picks them up, they can be used for impersonation and a variety of other nefarious purposes --- and only manual intervention by vigilant users, on a case by case basis and across the entire chain can prevent this.
Any software project domain name is therefore *one missed renewal* away from landing in the hands of actively hostile parties. Mistakes are easy to make. The attack surface is huge and hard to monitor: to an attacker a domain name for an unassuming low level library has significant economic value as part of a layered attack chain, whilst for downstream developers it is one of many dependencies and for the upstream developer it represents a never-ending cost. Domain names may not be that expensive, but certainly they are not free either --- and over time these costs do start to add up.
Once a domain name is in use, developers are 'stuck' with a significant responsibility for their uninterrupted upkeep: either they continue to foot the bill for each and every domain they were kind enough to register for their (regularly unpaid) contribution to the digital commons. Or they hand it over to someone sternly promising to take good care of it (but potentially does so with ulterior motives, e.g. see the 'XZ' attack). Or they leave it to whomever happens to circling around the renewal date of the domain.
dotsrc creates a safe landing ground for free and open source software projects made available via the internet, which doesn't suffer the same problem of short-lived identifiers. It provides a new future proof top level domain name that will not have any cost for upkeep for maintainers and developers of digital commons. Instead, the users and stakeholders directly bear the cost of the top level domain and all its registered domains as a whole through donations. In other words: a prepaid domain available as a public utility, with no financial friction for the contributors.

§ 3 — Commitments and safeguards Q164–Q188

More trustworthy, consumer risk, regulated sector, government reporting, harm, government function Q164–Q169	Yes to: more trustworthy (Q164), consumer risk if abused (Q165)
Voluntary Safeguard PICs Q170·Q171	• Registry Operators will include a provision in their Registry-Registrar Agreements that requires Registrars to include in their Registration Agreements a provision requiring registrants to comply with all applicable laws, including those that relate to privacy, data collection, consumer protection (including in relation to misleading and deceptive conduct), fair lending, debt collection, organic farming, disclosure of data, and financial disclosures. • Registry Operators will include a provision in their Registry-Registrar Agreements that requires registrars at the time of registration to notify registrants of the requirement to comply with all applicable laws. • Registry Operators will include a provision in their Registry-Registrar Agreements that requires Registrars to include in their Registration Agreements a provision requiring that registrants who collect and maintain sensitive health and financial data implement reasonable and appropriate security measures commensurate with the offering of those services, as defined by applicable law. • Registry Operators will proactively create a clear pathway for the creation of a working relationship with the relevant regulatory or industry self-regulatory bodies by publicizing a point of contact and inviting such bodies to establish a channel of communication, including for the purpose of facilitating the development of a strategy to mitigate the risks of fraudulent and other illegal activities. • Registry Operators will include a provision in their Registry-Registrar Agreements that requires Registrars to include in their Registration Agreements a provision requiring Registrants to provide administrative contact information, which must be kept up-to-date, for the notification of complaints or reports of registration abuse, as well as the contact details of the relevant regulatory, or industry self-regulatory, bodies in their main place of business. • Registry Operators will include a provision in their Registry-Registrar Agreements that requires Registrars to include in their Registration Agreements a provision requiring Registrants to report any material changes to the validity of the Registrants' authorizations, charters, licenses and/or other related credentials for participation in the sector associated with the Registry TLD string in order to ensure they continue to conform to appropriate regulations and licensing requirements and generally conduct their activities in the interests of the consumers they serve. • Registry Operators will develop and publish registration policies to minimize the risk of cyber bullying and/or harassment.
Registry Voluntary Commitments Q172·Q173	None · 5 do
Community TLD Q131·Q132	The FOSS community. Developers of and contributors to free and open source software, educators and downstream consumers of this software and other stakeholders. This includes software distro's, organisational/institutional users and security professionals
Code of Conduct exemption requested Q185·Q188	No

§ 4 — All other published answers

Every other answer ICANN published for this application, in the order of the form. Contact details (Q17–Q24) are left to the ICANN record.

Q212Q4.2-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. If financial statements are provided by a Qualified Parent Entity (QPE), the CEO, President, CFO, and/or equivalent officer of the QPE must co-sign the certification document. The self-certification document must represent and warrant: SC4.2-1.1 - The applying entity and/or a QPE will fund the startup and long-term operation of all applied-for gTLD strings and (if applicable) currently operated gTLDs of a QPE. SC4.2-1.2 - The applying entity or QPE has at a minimum of US$50,000 plus 25% of the application base fee for each applied-for gTLD string in Cash and Cash Equivalents on the balance sheet of the provided financial statements, up to a maximum of US$300,000, designated to support the startup and operation of all of the applying entity’s applied-for gTLD strings. SC4.2-1.3 - The applying entity and/or its officers are bound by law in its jurisdiction to represent financial statements accurately and the applying entity is in good standing in that jurisdiction.

Q4.2-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. If financial statements are provided by a Qualified Parent Entity (QPE), the CEO, President, CFO, and/or equivalent officer of the QPE must co-sign the certification document. The self-certification document must represent and warrant: SC4.2-1.1 - The applying entity and/or a QPE will fund the startup and long-term operation of all applied-for gTLD strings and (if applicable) currently operated gTLDs of a QPE. SC4.2-1.2 - The applying entity or QPE has at a minimum of US$50,000 plus 25% of the application base fee for each applied-for gTLD string in Cash and Cash Equivalents on the balance sheet of the provided financial statements, up to a maximum of US$300,000, designated to support the startup and operation of all of the applying entity’s applied-for gTLD strings. SC4.2-1.3 - The applying entity and/or its officers are bound by law in its jurisdiction to represent financial statements accurately and the applying entity is in good standing in that jurisdiction.

Answered with a document. Attachments are not published by ICANN.

Q220Q5.1-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. The self-certification document must represent and warrant: SC5.1-1.1 - The applying entity will appropriately protect confidentiality of data and prevent unauthorized access to data and services. SC5.1-1.2 - The applying entity will maintain a mature, appropriately funded and staffed security program, following a recognized, modern security framework based on risk management (such as the ISO27000 series, COBIT, HITRUST CSF, legally required security frameworks, or equivalent). The security program must be in place prior to delegation, and exist through at least the period of the registry agreement. SC5.1-1.3 - The applying entity is aware of and has designed its systems and business to comply with the relevant privacy and security regulations for all countries in which it operates.

Q5.1-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. The self-certification document must represent and warrant: SC5.1-1.1 - The applying entity will appropriately protect confidentiality of data and prevent unauthorized access to data and services. SC5.1-1.2 - The applying entity will maintain a mature, appropriately funded and staffed security program, following a recognized, modern security framework based on risk management (such as the ISO27000 series, COBIT, HITRUST CSF, legally required security frameworks, or equivalent). The security program must be in place prior to delegation, and exist through at least the period of the registry agreement. SC5.1-1.3 - The applying entity is aware of and has designed its systems and business to comply with the relevant privacy and security regulations for all countries in which it operates.

Answered with a document. Attachments are not published by ICANN.

Q221Q5.2-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. The self-certification document must represent and warrant: SC5.2-1.1 - The applying entity will, no later than delegation of the Top Level Domain (TLD), establish a dedicated abuse point of contact responsible for addressing matters requiring expedited attention and providing a timely response to abuse complaints concerning any name registered in the TLD. SC5.2-1.2 - The applying entity will, no later than delegation of the TLD, establish, publish, and provide to ICANN the location of a mechanism for members of the public to submit reports of abuse in accordance with the current obligations of the Base RA and any Consensus Policies. SC5.2-1.3 - The applying entity has developed proposed measures for removal of orphan glue records for names removed from the zone when provided with evidence in written form that the glue is present in connection with malicious conduct (see Specification 6). SC5.2-1.4 - The applying entity has or will have at time of delegation, established policies for handling complaints regarding abuse. Such policies are to be maintained and posted publicly so that anyone can review the policies via the Internet and any other means deemed appropriate by the applying entity. The applying entity’s policies at a minimum should contain appropriate confirmation of the receipt of the abuse report, the process of review of the report, and actions that will be taken if the applying entity confirms the report is legitimate. SC5.2-1.5 - The applying entity understands that DNS Abuse is Phishing, Malware, Botnets, Pharming and Spam (when used to deliver other forms of DNS Abuse). The applying entity understands and is prepared to contribute to the mitigation or disruption of DNS Abuse in domains in the TLD zone. SC5.2-1.6 - The applying entity’s abuse response capabilities are resourced appropriately to ensure a timely and adequate investigation and response to reports of DNS Abuse. This includes capabilities to receive and evaluate evidence of DNS Abuse in reports, and to take action to stop or disrupt the DNS Abuse. SC5.2-1.7 - The applying entity is prepared to conduct periodic scans of its zone to identify if domains are being used to perpetrate DNS Abuse, and to maintain statistical reports of the scans, the findings, and actions taken.

Q5.2-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. The self-certification document must represent and warrant: SC5.2-1.1 - The applying entity will, no later than delegation of the Top Level Domain (TLD), establish a dedicated abuse point of contact responsible for addressing matters requiring expedited attention and providing a timely response to abuse complaints concerning any name registered in the TLD. SC5.2-1.2 - The applying entity will, no later than delegation of the TLD, establish, publish, and provide to ICANN the location of a mechanism for members of the public to submit reports of abuse in accordance with the current obligations of the Base RA and any Consensus Policies. SC5.2-1.3 - The applying entity has developed proposed measures for removal of orphan glue records for names removed from the zone when provided with evidence in written form that the glue is present in connection with malicious conduct (see Specification 6). SC5.2-1.4 - The applying entity has or will have at time of delegation, established policies for handling complaints regarding abuse. Such policies are to be maintained and posted publicly so that anyone can review the policies via the Internet and any other means deemed appropriate by the applying entity. The applying entity’s policies at a minimum should contain appropriate confirmation of the receipt of the abuse report, the process of review of the report, and actions that will be taken if the applying entity confirms the report is legitimate. SC5.2-1.5 - The applying entity understands that DNS Abuse is Phishing, Malware, Botnets, Pharming and Spam (when used to deliver other forms of DNS Abuse). The applying entity understands and is prepared to contribute to the mitigation or disruption of DNS Abuse in domains in the TLD zone. SC5.2-1.6 - The applying entity’s abuse response capabilities are resourced appropriately to ensure a timely and adequate investigation and response to reports of DNS Abuse. This includes capabilities to receive and evaluate evidence of DNS Abuse in reports, and to take action to stop or disrupt the DNS Abuse. SC5.2-1.7 - The applying entity is prepared to conduct periodic scans of its zone to identify if domains are being used to perpetrate DNS Abuse, and to maintain statistical reports of the scans, the findings, and actions taken.

Answered with a document. Attachments are not published by ICANN.

Q121As per Section 3(d) of Specification 11 of the Base Registry Agreement, a registry operator of a “generic string” may not impose eligibility criteria for registering names in the TLD that limit registrations exclusively to a single person or entity and/or that person’s or entity’s “Affiliates” (as defined in Section 2.9(c) of the Registry Agreement). “Generic String” means a string consisting of a word or term that denominates or describes a general class of goods, services, groups, organizations or things, as opposed to distinguishing a specific brand of goods, services, groups, organizations or things from those of others. Confirm that the applied-for string is not a “generic string” in which the applying entity intends to limit registrations exclusively to a single person or entity.

As per Section 3(d) of Specification 11 of the Base Registry Agreement, a registry operator of a “generic string” may not impose eligibility criteria for registering names in the TLD that limit registrations exclusively to a single person or entity and/or that person’s or entity’s “Affiliates” (as defined in Section 2.9(c) of the Registry Agreement). “Generic String” means a string consisting of a word or term that denominates or describes a general class of goods, services, groups, organizations or things, as opposed to distinguishing a specific brand of goods, services, groups, organizations or things from those of others. Confirm that the applied-for string is not a “generic string” in which the applying entity intends to limit registrations exclusively to a single person or entity.

true

Q134How would you categorize your community?

How would you categorize your community?

The free and open source community covers the spectrum of primarily ideologically driven developers and researchers (those that develop 'libre/free software' and for whom the benefits revolve around the so called 'four freedoms') and pragmatically driven developers and researchers (those that recognise an open source license is an effective means to share and collaborate). Distribution of FOSS licensed software happens mostly online these days, but got started before the internet with physical tapes, floppy disks, CDs and DVDs. The community still has lots of offline presence and social interaction, with community events that bring together anywhere between small groups of developers for targeted sprints to large community events like FOSDEM, KubeCon, FOSSASIA with several thousand of people.
Some people are financially compensated to contribute - through an employer, through grants or subsidies, or through paying customers. This of course does not preclude them from being ideologically aligned with the individuals and organisations that contribute their work in a volunteering/non-remunerate capacity, primarily driven by the desire to create a global digital commons and help push towards a more open society.

Q135What is the applying entity's connection to the community?

What is the applying entity's connection to the community?

As a philanthropy we are a significant grant maker within the digital commons space. We have been funding the third party development of many free and open source software applications since the nineties.
We have funded over 1 million hours of free and open source development in the past decade, globally. Our portfolio can be seen on https://nlnet.nl/project

Answered with a document. Attachments are not published by ICANN.

Q136How is the community organized? Are there one or multiple organizations ("organizing body") that represent or administer the community?

How is the community organized? Are there one or multiple organizations ("organizing body") that represent or administer the community?

The community is organised (or non-organised) in a fairly layered and complex manner. The organising principle is not some member-based organisation or institute as such but sharing a specific transitive form of licensing of copyrights that endows rights to users.
There are two key authorities in the field that define which licenses qualify: the Free Software Foundation (also maintainer of the GPL family of licenses) and the Open Source Initiative (OSI). Membership of neither is obligatory to be part of the community.
The primary manifestation of being part of the FOSS community is the publication of ones software under a recognised free and open source license on the one hand, and the downstream use of software or hardware created with those licenses on the other hand. People that are categorically unaware of free and open source licensing as well as the availability of reusable/editable source code of FOSS software they use, obviously are missing out on some benefits - but they can still contribute without knowing, by helping to promote open solutions from elsewhere in the community.

Q137Does the community have defined membership requirements, such as registration, licensing, or use of specific communication? Or, do community members self-identify as part of the community?

Does the community have defined membership requirements, such as registration, licensing, or use of specific communication? Or, do community members self-identify as part of the community?

As stated, both the creation and (indirect) consumption of software or hardware with a free and open source (FOSS) license automatically qualify people and organisations as part of the community.
There is no membership of any single legal or informal entity which is universally recognised as constituting 'the FOSS community' - though there are organisations around specific FOSS software which are a subset of the community.
Community members may explicitly identify themselves as members of the FOSS community, but that is not a requirement. For all intents and purposes people can be counted as such when they somehow benefit from the work done by the FOSS community. "Good citizenship" however assumes some level of awareness, and obviously has a reciprocal and/or evangelising component - helping to promote FOSS software or helping other users is also much appreciated and seen as a contribution to the commons.

Q138Where is the community located?

Where is the community located?

Globally dispersed, there is no central location.

Q139What is the estimated size of the community? This should take into account any regions listed in Question 138.

What is the estimated size of the community? This should take into account any regions listed in Question 138.

Billions of people (at least all 6 000 000 internet users) use FOSS software, and/or software and services with significant FOSS components (ranging from all smartphones to televisions, internet services, etc) to , but not everyone may realise they do.

Q140What portion of the community do any organizing bodies represent or administer to?

What portion of the community do any organizing bodies represent or administer to?

FSF has about 5000 associate members globally. The Open Source Initiative has 24000 (paying) members. There are many more relevant organisations in this space, such as Apache, Eclipse, OW2, Gnome, KDE, LF, SFC, SPI, Commons Conservancy, CCT, OpenBSD, etc.

Q141Do the organizing bodies demonstrate active and consistent efforts to engage and connect with the identified community and its members?

Do the organizing bodies demonstrate active and consistent efforts to engage and connect with the identified community and its members?

There is a near endless stream of advocacy and outreach about a variety of FOSS related topics. However, it seems off-topic at this moment to dive into this - the question is clearly not that relevant for this particular application.

Q142What is the role of the applying entity in the engagement efforts listed in Question 141?

What is the role of the applying entity in the engagement efforts listed in Question 141?

There is no explicit role in terms of engagement, although we liaise with many FOSS organisations in a variety of ways. NLnet sometimes funds some of the advocacy entities (and has for instance helped pay for the development of the GPLv3 family of licenses), but typically we fund developers directly to work on concrete coding efforts.
Our funding is exclusively dedicated to Free and Open Source Software, and with over 1 000 000 hours of funded effort across > 1500 projects in the last decade there is a significant organic engagement at the level of developers.

Q143Are community members aware of the identified community and each other?

Are community members aware of the identified community and each other?

Yes, there is a sense of collective purpose, of global collaboration and mutual solidarity within the FOSS community. It would be difficult to produce billions of lines of code collectively without such an understanding and appreciation of an informal global community.
There is a significant collective inter-dependency on each other: FOSS is really a Gesamtkunstwerk, as a modern functional software stack requires many different components to work together. However, people might not know each other across programming language ecosystems, application domains, etc.
There are many events (e.g. https://foss.events) which some events like FOSDEM drawing > 10000 visitors from around the world annually.

Q144Are community members aware of the applying entity and its intention to apply for a community gTLD?

Are community members aware of the applying entity and its intention to apply for a community gTLD?

As one of the largest FOSS funders and decades of history, community members are typically reasonably well aware of our existence - to the extent that is reasonable for an organisation of our size (most inhabitants of the planet won't be able to tell you what ICANN does, and that is a much larger organisation in terms of footprint). You will find the NLnet logo in many repositories and on the very websites we'd like to put under .src.
With regards of our intention to apply for a community gTLD: we have talked to a select few trusted community members to probe their interest, but overall we considered it wise to maintain confidentiality - we did not want to arouse market powers that could potentially step in and compete (for whatever reason). There is a financial threshold but this is not per se high enough to deter predatory behaviour and hogging the scarce resource that is the global DNS namespace. The application is our gift to the community.

Q145Was there an established presence of the identified community prior to the opening of the application submission period?

Was there an established presence of the identified community prior to the opening of the application submission period?

No

Q146Are individuals and groups outside of the identified community aware of the existence of the identified community?

Are individuals and groups outside of the identified community aware of the existence of the identified community?

Yes and no. The FOSS community is very inclusive and thus rather expansive: nearly every modern device, service or appliance we use contains FOSS software (including that of the largest vendors).
People that are made aware of the digital commons and how open licenses work tend to recognise the contribution to the public benefit - and often instantly feel part of the community. So in the broad sense of the word community, there wouldn't be that many people _outside_ of the FOSS community - perhaps only those that completely shun all electronic devices.

Q147Are the pursuits of the identified community enduring and sustainable?

Are the pursuits of the identified community enduring and sustainable?

Yes. FOSS has been around since the eighties, and continues to grow in size and economic relevance. It is meanwhile pervasively present (>97% of all software and services contain FOSS components), and widely supported by the developer community, academia, public sector and industry.
The licenses by definition allow users self-determination - unlike a company that can drop a product or service without any recourse, in the case of FOSS users can pick up or take over development at any time, to accommodate specific needs. This constant evolutionary pressure and potential viability of every copy makes the ecosystem as a whole extremely robust and long-lived.

Q148Does the string match the name of the identified community?

Does the string match the name of the identified community?

No. The FOSS community is not monolithic and actually doesn't even carry a name either. We can't even agree on 'libre', 'free', 'open source', 'FOSS' or 'FLOSS'. Nor does the name refer to any sort of subset of that community or any group known to us. It does refer to what binds the community: the source code that is shared.

Q149Will the general public instinctively think of the community when thinking of the applied-for string?

Will the general public instinctively think of the community when thinking of the applied-for string?

Perhaps over time, to the extent that people who know about source code will hopefully associate .src with the universal location of the source of all software. A significant part of the population of course will never know the finer details of how software is created and maintained, which is fine - that part of the audience is served by distro's, app stores and service providers, and will only indirectly benefit from .src (through said distro's, app stores and service providers).
The goal is to facilitate the FOSS community in delivering robust software, and making it easily discoverable. The source code is the raw material on which FOSS developers collaborate, and as a convention in software repositories one will often find a folder "src" that contains the source code files. As per the same convention, the top level of the repository holds basic information such as a README file, a folder or file with LICENSE information, and technical requirements. The src folder keep all the code together, like .src will.
We are not aware of any geography, region or theme that would have a specific interest in this string.
The source code obviously is the concrete manifestion of the empowerment given by the FOSS licensing - it allows one to study the way the software works, to build it and to modify it.

Q150Are you proposing to include one or more Community Registration Policies in the Registry Agreement (RA) that are unique to the applying entity's applied-for community gTLD?

Are you proposing to include one or more Community Registration Policies in the Registry Agreement (RA) that are unique to the applying entity's applied-for community gTLD?

Yes

Q151.1Please state a specific Community Registration Policy with respect to registration eligibility for community members.

Please state a specific Community Registration Policy with respect to registration eligibility for community members.

Registry Operator will include the following provisions in its Registry-Registrar Agreement:
Only the authorised governing entity, maintainer or legitimate representative of a qualifying Free and Open Source Software project can become a Registrant within .src. To qualify as FOSS means the software needs to be licensed under a license formally recognised by one of two organisations: Free Software Foundation or the Open Source Initiative. The mere presence of a FOSS license does not suffice: projects should comply with copyright law and properly deal with code provenance, preferably following best practices such as the REUSE Software guidelines.
The .src infrastructure may not be used for distributing proprietary software, for that any other domains name can and should be used.
There are two modes of entry into .src: Legacy Mode and Long Term Mode.
Long Term Mode (LTM) offers strong forward-facing guarantees in terms of availability and sustainability, by removing complexity and vastly simplifying the governance. LTM provides access to stable tertiary (and quaternary, quinary etc) level names to free and open source projects, underneath secondary (tertiary, quaternary, etc) level labels determined by the dotsrc Registry Operator. These secondary (etc) level labels may for instance be used to differentiate between similarly named efforts in different programming languages ("imap.crate.src" versus "image.hackage.src"), between early stage projects and more mature/community vetted efforts ("incubating.src"), or between predominantly human written code and AI-generated code ("genai.src". This allows to share rich machine-processible information with consumers in a way humans can still easily understand. .src LTM domain names are (always) linked to a restricted set of turnkey infrastructure services offered pro bono by dotsrc as a public utility. The basic services offered are static site hosting and distributed versioning systems for collaborative software development - neither of which necessitate giving access to DNS records. Processing of LTM names is therefore handled directly within the dotsrc infrastructure.
In Legacy Mode, the Registrant remains responsible for running its own nameservers and managing the availability of the content to be found underneath the domain name, in the same way it is already responsible for the already active domain(s). Legacy mode requires technical infrastructure and skill at the side of the Registrant. It also means the dotsrc infrastructure is not able to give guarantees in terms of long term availability of any actual content found at those domain names, leaving as its major benefit a persistent, free and technically redundant domain name.
In other words: .src domains in Legacy Mode primarily act as a technical fallback to existing domains in other TLDs currently already dealing with the development and publication of free and open source software. LTM behaves as a "batteries included" service.
Registrars exclusively deal with Legacy Mode, and moreover shall only do so in support of existing customers that already have an active domain related to free and open source software which needs to already be depended upon by the FOSS community to qualify. In Legacy Mode, domains are followed by .lgc.src or legacy.src. This naming scheme signals to prospective users the more limited guarantees that Legacy Mode offers. If the services provided by LTM suffice, projects can always switch from Legacy Mode to LTM.

Q151.2If there is an additional proposed policy, please state the specific Community Registration Policy with respect to registration eligibility for community members.