Application Details
Last published on: 7 October 2026 at 15:26 UTC
Application Responses
Section: Applying Entity Information
This question set collects information regarding the legal entity that would enter into a Registry Agreement with ICANN upon successful completion of all relevant application processes. The information collected is intended to be used for background screening.
Provide the full legal name of the applying entity as it appears on the official registration documents. Do not use abbreviations.
Stichting NLnet
Provide the long form (no acronyms) of the legal entity form/business structure of the applying entity as it appears on the official registration documents. If the original script of the legal entity form/business structure is not English, ONLY provide its official English translation. No additional information should be provided as this will be used for the automatic population of the Registry Agreement.
Foundation
The jurisdiction indicates the location in which the business of the applying entity is registered for legal and financial purposes. This is either 1) a country name, or a 2) state/territory name, depending on where the applying entity is registered. No additional information should be provided as this will be used for the automatic population of the Base Registry Agreement. Examples include "Delaware", "Germany", etc.
the Netherlands
Provide the website URL of the applying entity, if available.
https://nlnet.nl
1. Choose Yes or No. 2. Use the definition of Affiliate from the Base Registry Agreement (see https://www.icann.org/en/registry-agreements/base-agreement).
false
Choose Yes or No.
false
31
Provide the primary business phone number without including the country code.
208884252
Provide the primary business email address of the applying entity.
icann@nlnet.nl
Enter the street address (no PO Box).
Science Park 400
Enter the city, village, municipality, etc.
Amsterdam
Enter the state, province, department, territory, prefecture, oblast, etc., if applicable.
Zuid-Holland
1. Enter the postal code, if applicable. 2. If a postal code does not exist, type “Not Applicable”.
1098 XH
NL
Section: Applying Entity Background and Organization
This question set collects information related to the individuals who will have access to TAMS, manage the application, and receive inquiries.
Bob Goudriaan, Bob Goudriaan
Bob Goudriaan
Section: Self-Certification
Provide a single document for Self-Certification question Q4.2-1. The document must include only the SC4.2-1.1, SC4.2-1.2, or SC4.2-1.3 statements. Do not modify any of the Self-Certification statements.
1. Provide a single document for Self-Certification question Q4.2-1. 2. The document must include only the SC4.2-1.1 through SC4.2-1.3 statements. 3. Do not modify any of the Self-Certification statements. 4. If the applying entity cannot Self-Certify the SC4.2-1.1 through SC4.2-1.3 statements, provide a document that explains why the applying entity cannot Self-Certify the SC4.2-1.1 through SC4.2-1.3 statements.
Section: Security Policy and Planning
Provide a single document for Self-Certification question AGB Q220, Q5.1-1. The document must include only the SC5.1-1.1 through SC5.1-1.3 statements. Do not modify any of the Self-Certification statements. If the applicant cannot Self-Certify SC5.1-1.1 through SC5.1-1.3 statements, provide a document that explains why the entity cannot Self-Certify the SC5.1-1.1 through SC5.1-1.3 statements.
1. Provide a single document for Self-Certification question Q5.1-1. 2. The document must include only the SC5.1-1.1 through SC5.1-1.3 statements. 3. Do not modify any of the Self-Certification statements. 4. If the applying entity cannot Self-Certify the SC5.1-1.1 through SC5.1-1.3 statements, provide a document that explains why the applying entity cannot Self-Certify the SC5.1-1.1 through SC5.1.1-3 statements.
Section: DNS Abuse
Provide a single document for Self-Certification question AGB Q221, Q5.2-1. The document must include only the SC5.2-1.1 through SC5.2-1.7 statements. Do not modify any of the Self-Certification statements. If the applicant cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements, provide a document that explains why the applying entity cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements.
1. Provide a single document for Self-Certification question Q5.2-1. 2. The document must include only the SC5.2-1.1 through SC5.2-1.7 statements. 3. Do not modify any of the Self-Certification statements. 4. If the applying entity cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements, provide a document that explains why the applying entity cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements.
Section: Primary String
This question set collects basic information regarding the string that is being applied for (for example, a-label, meaning, script). If the applying entity opts to designate a replacement string, it must answer the same set of questions for the replacement string from the AGB Question Set 5 on.
src
Provide the meaning, or restatement of the string in English, that is, a description of the literal meaning of the string in the opinion of the applying entity. If there is no literal meaning in English (for example, a brand name or a proper noun without a translation) simply state "No English Translation"
The name refers to 'source' as in 'source code', the (human readable) instructions that can be compiled into computer software or hardware.
Provide a representation of the string according to the International Phonetic Alphabet.
/sɔːs/
Confirm the statement using a checkbox.
true
1. Describe the mission and purpose of the applied-for gTLD, including the intended registrants and users, and the related activities that have been or will be carried out to achieve this purpose. 1a. If applying for a variant of an existing gTLD, please also describe the mission and purpose of the existing gTLD, including the intended registrants and users, and the related activities that have been or will be carried out to achieve this purpose. 2. Explain how this purpose is sustainable over time.
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.
Section: Community
This question set collects information specific to Community gTLDs. However, question 133 (Mission & Purpose) must be answered by all applying entities.
General
Yes
1. Provide the name of the community that the applying entity is committing to serve. 2. Describe the distinct aspects of the community.
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
Enter a category that best describes your community. Some examples of community categories could include, but are not limited to: activity-based and volunteer groups, online or social media groups, religious or political groups, diasporic communities, linguistic communities, celebrity or sports team supporters.
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.
Organization
Describe and provide evidence of the relationship between the applying entity and the identified 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
Describe and provide evidence related to the community organization, any relevant organizing bodies, and any relevant leaders within 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.
1. Describe any formal membership process, if there is one. 2. If there is no formal membership process, provide evidence related to how an individual can join the identified community (i.e., “self-identify” as a community member).
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.
Provide the primary location of the community.
Globally dispersed, there is no central location.
1. Provide the estimated size of the community. The size should be in number format (e.g., “1,000,000 members”). 2. If the community is divided by group, region, sector, etc., this should include estimated size for each group.
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.
Provide the estimated size of the community that is administered or represented by each relevant organizing body in the identified community.
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.
Engagement
1. Provide evidence of any documented practices of community efforts to date 2. The applying entity should provide documentation of the following practices, which should have occurred within the two years leading up to application submission: a) Offering support; b) Sharing information; c) Responding to specific community needs; d) Fostering and strengthening relationships within the community.
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.
1. Describe whether the applying entity has a role in any of the activities listed in Question 141. 2. If the applying entity does play a role, provide evidence of the applying entity’s role. If the applying entity does not play a role, describe why this is the case.
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.
Awareness
1. Provide evidence that demonstrates that community members are aware of the identified community and the different member groups or segments within the identified community. 2. The applying entity should provide documentation of the following practices, which should have occurred within the two years leading up to application submission: a) Surveys conducted; b) Records of activities involving a diversity of community groups, segments, or members.
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.
1. Provide evidence of community members’ awareness of the applying entity and its intent to apply for a community gTLD. 2. If there is no such evidence, explain why not.
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.
Established Presence
Provide evidence of the established presence of the community prior to the opening of the application submission period.
No
1. Provide evidence that demonstrates that individuals and groups outside of the community show an awareness of the identified community. 2. The applying entity should provide documentation of the following practices, which should have occurred within the two years leading up to application submission: a) Media or other public information regarding the community and its activities or members; b) Discussion of the community in various fora, whether online or in person; c) Evidence of partnerships or collaborations with groups outside of the identified community; d) Evidence of the chartering or organization of the community prior to the opening of the application submission window; e) Evidence of contributions (for example, cultural or scientific) to a larger society or population;
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.
Longevity
1. Provide evidence of the longevity of the community. 2. The applying entity should provide documentation of the following practices which should have occurred within the two years leading up to application submission: a) Evidence of recurring or scheduled activities that demonstrate continuity over time; b) Documented records of past activities that demonstrate a long-standing tradition or practice; c) Records of discussions emphasizing the community’s enduring presence or its cultural significance.
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.
Nexus
Explain how the applied-for string matches the name of the community or is a well-known alternative name (whether long or short form) of the 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.
1. Explain how the applied-for string clearly relates to or represents the community 2. Explain whether the applied-for string has any other significant meaning beyond identifying the community or community members described in the application. The applying entity may wish to provide pertinent information regarding any particular geography, region, or themes that may be alluded to by the string, of which the community may or may not be a part.
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.
Community Registration Policy
Select from Radio Buttons - Yes/No. Notes: 1. Community Registration Policies are conditions that community gTLD registry operators impose upon registrants within their gTLDs. 2. If you select “Yes” to this question, the applying entity is required to pay the conditional Registry Commitments Evaluation fee, and Community Registration Policies that are approved by ICANN will be scored in the CPE (if the applying entity elects to participate) and included in Specification 12 of the applicable Base RA. 3. If you select “No,” then the application cannot proceed as a community application.
Yes
1. Draft the Community Registration Policy as proposed contract language. Policies that are approved by ICANN will be included in Specification 12 of the applicable Registry Agreement and will be subject to enforcement by ICANN Contractual Compliance. See Appendix 4 Base Registry Agreement, Specification 12 for drafting approach. Consider the usage of defined terms and the definitions of such terms in the 2026 Round Base RA. 2. Enter a single proposed Community Registration Policy with respect to registrant eligibility in each response field. Up to 10 Community Registration Policies can be submitted. 3. Follow this format to propose what the Registry Operator must do and/or must not do: a) “Registry Operator shall___”; and/or b) “Registry Operator shall not___”. 4. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars ,: a) "Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or b) "Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”. 5. Follow this format to propose any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements: a) "Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring ___"; and/or b) "Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting ___". 6. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Community Registration Policy. For example: a) Registry Operator shall develop and implement a registration eligibility policy and publish this policy on its website no later than the date on which the TLD is delegated in the DNS. b) Registry Operator shall review the registration policy described in (a) at least once per year, and publish the results of such review (including any updates to the registration policy) on its website within thirty (30) days following the anniversary of the Effective Date. 7. If the Community Registration Policy is limited in time, duration, scope, or any other factors, specify the applicable limitations. For example, if a registrant eligibility restriction is time-limited, the applying entity must state if the restriction will apply for the lifetime of the gTLD, only during a specified period, or for some other defined period (such as, Registry Operator shall, for a period of x days from the Effective Date, ___). 8. See Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria for evaluation criteria that ICANN will apply for evaluating each proposed Community Registration Policy.
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.
Please see full instructions in AGB Q151.1.
Registry Operator will include the following provisions in its Registry-Registrar Agreement: The requested .src name must correspond to the name of an actual free and open source project name (e.g. nix.lgc.src) or the FOSS relevant part of their existing domain name (so garage.deuxfleurs.fr may become garage.lgc.src). Where needed or clearer, for instance in case of domain hacks (e.g. jit.si) or to avoid name collisions the current TLD label may be included (jitsi.lgc.src). If a company as rights holder and Registrant chooses to retain part of a trademarked company name in the project name submitted to .src (e.g. it registers collaboraoffice.lgc.src) it explicityly gives permission for the dotsrc Registry Operator and all its downstream consumers to use this name in conjunction with any versions of the software officially published via .src for perpetuity. Alternatively, moving forward, a new name may be chosen under .src that avoids ambiguity. This holds in particular for companies that share their complete name with their projects. In those cases it is recommended to switch the FOSS effort to the .src LTM proposition. For names using other scripts than ASCII, either a transcribed or preferably a translated version of the project name may be used for registering with .src. In all scenario's where new names are chosen, it is suggested to avoid collisions and confusion with any other FOSS projects, with other TLDs, and with brands. In their own interest projects should avoid confusion with other existing FOSS efforts, should these have chosen the same string in different TLDs. Projects may check the 'Whitelist' for possible base name collisions, and anticipate when registering their .src domain. If there are multiple FOSS projects with the same base name, for instance within different (programming) language ecosystems, it is wise to anticipate this and use a prefix or contact the dotsrc registry for advice. In case of challenges by third parties, the Registrant, Registrar and Registry Operator will collaborate in finding a good resolution that doesn't endanger the continuity of the global software supply chain. If the existing domain was or is also used for proprietary software, or is a personal or business domain used for other purposes, the content published on the new .src domain should be different from the original domain and be sanitized until only the actual eligible FOSS proposition remains. All registration are automatically valid for a period of 10 years, or the maximum allowed by ICANN - whichever is the highest.
Please see full instructions in AGB Q151.1.
Registry Operator will include the following provision in its Registry-Registrar Agreement: It is the responsibility of the Registrar to evaluate and monitor the eligibility of the prospective Registrant. As a service to speed up evaluation in a number of reasonably 'easy' cases, the dotsrc Registry Operator will publish - on a best-effort basis - a (non-exhaustive) machine-readable list of existing domain names in other TLDs associated with real-world relevant FOSS components present in the software supply chain, which could therefore be potentially eligible for a Legacy Mode registration ("Whitelist"). This machine-readable list will be created by processing machine-readable metadata from the software present in a number of relevant public data sources within the free and open source community - notably various software distributions and package management systems, app/extension/plugin stores, language packaging ecosystems and the Linux System Definition. The list is non-exhaustive and presence on the Whitelist is thus not a requirement, nor does absence from the list mean a specific free and open source project is not relevant or admissible - there are plenty of ways in which important software in active use would not end up not being listed. A key reason being technical incompatibility of the most likely source: some distributions do not offer any way to automatically ingest their data in a reliable manner. And inversely, some domains on the whitelist might be there for historical reasons and do not actually pass scrutiny at the moment. Even if their FOSS project website is not on the Whitelist, a prospective Registrant interested in .src Legacy Mode may initiate the registration procedure as long as it believes it qualifies. In this case the project will need to present the Registrar with suitable evidence of the free and open source nature of the effort, giving insight into code provenance and real-world relevance of the software. It will also present at least three independent users that give an attestation of their use of the software. The Registrar is responsible for upholding the registration criteria towards individual Registrants, verifying eligibility prior to activation and after that periodically. In parallel, the dotsrc Registry Provider will work with the free and open source community to add reliable additional sources to the Whitelist. The dotsrc registry will actively track software added to these sources, and will publish a revised Whitelist at least on a monthly basis (or more often if possible). Domains mentioned in the metadata within at least the following software distributions: - Adélie Linux - AIX Open Source Packages - AIX Toolbox - AlmaLinux - Alpine Linux - ALT Linux p11 - ALT Sisyphus - Amazon Linux - AOSC - Apertis - Arch Linux - ArchPOWER - Artix - BackBox - Baulk - Calculate - Carbs Linux - CentOS - Chimera Linux - Chocolatey - ConanCenter - CPAN - CRAN - crates.io - CRUX - Cygwin - Deb Multimedia - Debian - deepin - Devuan - distri - ELRepo - Endless OS - EPEL - EuroLinux - Exherbo - F-Droid - Fedora - FreeBSD Ports - Gentoo (+ GURU, Pentoo + Science overlay) - GNU Elpa - GNU Guix - Hackage - HaikuPorts - Homebrew - HP-UX 11.31 - IBM i - IzzyOnDroid - Kali Linux - KaOS - KDE neon - LiGurOS - LuaRocks - MacPorts - Mageia - Manjaro - MELPA - MSYS2 - MX Linux - nixpkgs - Npackd - opam - OpenBSD Ports - openEuler - OpenIndiana packages - openmamba - OpenMandriva - OpenPKG - openSUSE - Open VSX - OpenWrt - PackMan - pacstall - Parabola - Pardus - Parrot - PCLinuxOS - Pisi Linux - pkgsrc - PLD Linux - postmarketOS - PTXdist - PureOS - PyPI - Raspbian - ReactOS rapps - RebornOS - Rocky Linux - Rosa - RubyGems - SageMath - Salix - Side Linux - Siduction - Slackware - Stackage - stal/IX - T2 SDE - Tails - Termux - Terra - Tin Can Linux - Trisquel - UBI - Ubuntu - Vcpkg - Void Linux The contents of Open Invention Network's Linux System Definition: https://openinventionnetwork.com/linux-system
Please see full instructions in AGB Q151.1.
Registry Operator will include the following provision in its Registry-Registrar Agreement: The lack of trustworthiness of historical and predictability of future domain name renewal is in fact the raison d'être of dotsrc, meaning a check on existing domain names is neither fool-proof nor long term sustainable. If the Registrar becomes aware that a prospective Registrant is not a legitimate representative of the FOSS effort in question prior to initial registration (for instance because it is a known dropcatcher or large scale domain reseller), it will refuse the new .src registration and notify the Registry Operator. The applicant who is denied registration will receive written notification within 24 hours, and is given another 72 hours to provide additional information to clear. Registrar will also promptly report the attempt of misrepresentation to the Registry Operator, providing any necessary details to prevent the refused applicant from attempting to register elsewhere. Detailed information will not be published openly, but will be shared with any future Registrar The Registry Operator will place domain names involved with failed registration attempts on a second and third list of domain names: one with domain names that require additional scrutiny prior to acceptance as suitable evidence of an existing legacy domain in another TLD to be used for Legacy Mode ("Greylist"), and another list with domain names that may not be used as evidence for registration for acquiring a .src domain name ("Blacklist") - for instance because the domain name has previously been transferred to a Registrant that is known not to be eligible. The holder of a domain name on either of these lists that wishes to challenge inclusion, has access to a community-led appeals process. The price for this appeals process is set at a maximum of 2000 euro. Should the applicant win their case, this cost is assumed by the .src Registry Operator and the name is removed from the list. Otherwise, the name will be removed from the list after ten years.
Please see full instructions in AGB Q151.1.
Registry Operator will include a provision in its Registry-Registrar Agreement that requires Registrars to include the following provision in their Registration Agreements: Prior to final activation of the .src domain name, Registrant shall sign a succession agreement with a not-for-profit steward entity formally approved by the dotsrc Registry Operator. Multiple such stewards may be appointed, in that case the Registrant can choose a specific steward or delegate the choice to the dotsrc Registry Operator. Having such a succession agreement in place is mandatory for any .src domain(s), as well as for the original legacy domain(s) used to qualify for registration under .src. This succession agreement is only activated in case of pending abandonment of the original legacy domain name. In addition to committing to a succession procedure, the agreement makes it a binding requirement for the Registrant to immediately inform the Registry Operator of any relevant transfer locks, UDRP proceedings, judicial measures or ICANN requirements that would conflict with future escrow. In the event a succession is triggered, Registrant gives permission to the Registrar to share whatever technical information is available and needed by the prospective steward to continue operation without service interruption - include encrypted escrow of key material used for DNSSEC. This will be shared as part of the transfer. If a Registrant is about to fail (or has chosen not) to renew the domain name used to qualify for their registration into .src Legacy Mode, Registrar will notify the Registry Operator no later than one weeks before taking the domain name offline/entering the quarantine period. At that point there is an imminent risk of general availability of the original domain name to cease, and users may be in urgent need of a reliable fallback. Registrar will at the same time inform Registrant about the pending activation of the agreed succession procedure, and that a timely renewal of the original qualifying domain name will abort the procedure. When the threshold of 48 hours before entering quarantine is reached, another email will be sent to the domain holder that the domain names will potentially be transferred to the agreed not-for-profit steward the next working day. When the threshold of 24 hours prior to deactivation is reached, concrete preparations for a possible transfer are initiated and executed - unless the steward organisation after evaluation believes that the domain name is not (or no longer) relevant enough to assume the cost of maintaining the legacy domain. It that case, the .src legacy domain and whatever content can be rescued might be transitioned to Long Term Mode with a technical redirect. Since future ownership may no longer be linked to the orginal FOSS effort, the original name shall be added to the "Greylist" with a machine-readable note flagging that the domain was intentionally abandoned previously. A 'no questions asked' appeal process shall be available through the Registrar: if the abandonment turns out to be non-intended and the Registrant in fact wants to keep operating the domain names itself in Legacy Mode, the steward will allow for a retransfer of the domain name within the quarantine period as soon as possible - of course taking into account the presence of any transfer lock. A domain used as proof to obtain a .src domain name may not be put up for sale or carry a "_for-sale" DNS leaf node name (RFC 10023), this is counted as pending abandonment.
Please see full instructions in AGB Q151.1.
Registry Operator will include the following provisions in its Registry-Registrar Agreement that requires Registrars to include in their Registration Agreements the following provision: Registrant agrees that the Registrar or the Registry Operator may trigger the succession agreement in case: - the Registrant is an organisation that is about to dissolve, or is about to change hands in a manner that poses a clear threat to the public interest. - the Registrant intends to sell the qualifying domain - the Registrant is placed on a mandatory sanction list - the Registrant is convicted of fraudulent or criminal behaviour - in case of a natural person, the Registrant dies or is otherwise no longer capable of holding the responsibility for the .src domain name in question moving forward
Please see full instructions in AGB Q151.1.
Registry Operator will include the following provisions in its Registry-Registrar Agreement that requires Registrars to include in their Registration Agreements the following provision: Each registration shall have an identifiable and accountable natural person or legal entity as the Registered Name Holder, together with an identified (human) administrative contact authorised to act on its behalf. Registrant confirms that the activity taking place on the registered .src domain will remain under human control and be subject to human accountability without compromise. If circumstances change and these provisions no longer hold, Registrant should pro-actively notify the Registry Operator to see if any action needs to be taken.
Please see full instructions in AGB Q151.1.
Registry Operator will include the following provision in its Registry-Registrar Agreement: If the Registrar is confronted with what it considers sufficient proof that an active .src Registrant is in fact not (or no longer) a legitimate representative of the FOSS effort in question, it shall trigger the following emergency procedure: - The Registrar will immediately notify the dotsrc Registry Operator, and provide any proof it has alongside any other available information about the domain to the Registry Operator on a best effort basis - including any copies (of any version) it may hold of the zone file. The Registrar will refrain from informing the Registrant. - This early notification will allow the Registry Operator (and whomever the Registry Operator deems necessary to involve in the public interest) to undertake an expedited risk and damage assessment concerning the domain in question. As part of the risk and damage assessment, the Registry Operator shall be allowed to share relevant information (with the noted exception of personally identifiable information) about the registered domain and its history with third party experts. - Unless instructed otherwise by the Registry Operator, the Registrar will pre-emptively put a registry lock in place for the domain in question - if there is not such a lock in place already. If the initial investigation is preliminarily concluded (with whatever outcome), Registrant will be informed of the established facts and given the opportunity for redress and correction of mistakes and misunderstandings. Based on the final facts and information provided by the Registrant, the Registry Operator will conclude its research or (in complex cases) appoint an independent committee to further investigate the matter. At the earliest possible opportunity, either the Registry lock will be removed (false negative) or it is concluded there has been invalid representation. If valid representation presents itself during the procedure, control is handed over to this person or entity. If not, the Registrar will follow the succession agreement and assign control of the .src domain name involved to a designated steward organisation appointed by the dotsrc Registry Operator. A notification is published in the transparency log of dotsrc to inform the community. In case the mandate is restored as a result of either, or in case of a procedural mistake or a mistake in processing, service shall be promptly restored - ultimately within 24 hours.
Please see full instructions in AGB Q151.1.
Registry Operator will include the following provisions in its Registry-Registrar Agreement: There is no fee charged for .src registrations by the Registry Operator. Registrars are also suggested to voluntarily waive fees for their services as a concrete contribution to the public benefit. In case this isn't possible, they may charge Registrants a reasonable fee for verification of domains under .src and specific services rendered. By design, every .src Registrants already is an existing customer of the Registrar they want to register their .src domain with - which should help to keep these costs low. A Registrar must be transparent about its fee structure for validation, DNS hosting, and publish these rates on its website. Prior to entering into any legally binding commitment or renewing a contract the Registrar must always share written out information with the Registrants pertaining to the (freely available) Long Term mode, and complementary DNS hosting and to other free services within the .src infrastructure as provided by the Registry Operator and any partner organisations.
Please see full instructions in AGB Q151.1.
Registry Operator will include the following provision in its Registry-Registrar Agreement: Once an open license is given, software and documentation cannot be unpublished. This is one of the great strengths of free and open source software from the user side. .src domain names are intended as persistent identifiers to such software and documentation that can be used over a very long period of time. When registering a .src Legacy Mode domain name, the Registry Operator and its partners are explicitly handed the perpetual right by the Registrant to continue to publish any historical records using that chosen name and any variant as part of the identifier under .src domains - as long as these are clearly identifiable as such, including a timeline, and that users are made aware of the (last known) canonical location of the project and its online resources. Should there be legally binding reasons not to publish specific content, dotsrc will still be allowed to use the applicable names to provide metadata for historical and research purposes.
1. Draft the Community Registration Policy as proposed contract language. Policies that are approved by ICANN will be included in Specification 12 of the applicable Base Registry Agreement and will be subject to enforcement by ICANN Contractual Compliance. See Appendix 4 Base Registry Agreement, Specification 12 for drafting approach. Consider the usage of defined terms and the definitions of such terms in the 2026 Round Base RA. 2. Enter a single proposed Community Registration Policy with respect to name selection criteria or rules for the applied-for string in each response field. Up to 10 Community Registration Policies can be submitted. 3. These criteria or rules should align with the community objectives of the applied-for gTLD string. 4. Follow this format to propose what the Registry Operator must do and/or must not do: a) “Registry Operator shall___”; and/or b) “Registry Operator shall not___”. 5. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars: a) ""Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or b) ""Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”. 6. Follow this format to propose any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements: a) ""Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring___""; and/or b) ""Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting ___"". 7. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Community Registration Policy. For example: a) Registry Operator shall develop and implement a name selection rule and publish it on its website no later than the date on which the TLD is delegated in the DNS. b) Registry Operator shall review the name selection rule described in (a) at least once per year, and publish the results of such review (including any updates to the rule) on its website within thirty (30) days following the anniversary of the Effective Date. 8. If the Community Registration Policy is limited in time, duration, scope, or any other factors, specify the applicable limitations. For example, if a name selection rule is time-limited, the applying entity must state if the rule will apply for the lifetime of the gTLD, only during a specified period, or for some other defined period (such as, Registry Operator shall, for a period of x days from the Effective Date, ___). 9. See Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria for evaluation criteria that ICANN will apply for evaluating each proposed Community Registration Policy.
There is no further CRP.
1. Draft the Community Registration Policy as proposed contract language. Policies that are approved by ICANN will be included in Specification 12 of the applicable Registry Agreement and will be subject to enforcement by ICANN Contractual Compliance. See Appendix 4 Base Registry Agreement, Specification 12 for drafting approach. Consider the usage of defined terms and the definitions of such terms in the 2026 Round Base RA. 2. Enter a single proposed Community Registration Policy in each response field. Up to 10 Community Registration Policies can be submitted. 3. Follow the format to propose what the Registry Operator must do and/or must not do: a) “Registry Operator shall___”; and/or b) “Registry Operator shall not___”. 4. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars: a) ""Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or b) ""Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”. 5. Follow this format to propose any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements: a) ""Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring___""; and/or b) ""Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting___"". 6. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Community Registration Policy. For example: a) Registry Operator shall develop and implement a Community Registration policy and publish this policy on its website no later than the date on which the TLD is delegated in the DNS. b) Registry Operator shall review the Community Registration Policy described in (a) at least once per year, and publish the results of such review (including any updates to the registration policy) on its website within thirty (30) days following the anniversary of the Effective Date. 7. If the Community Registration Policy is limited in time, duration, scope, or any other factors, specify the applicable limitations. For example, if a commitment is time-limited, the applying entity must state if the rule will apply for the lifetime of the gTLD, only during a specified period, or for some other defined period (such as, Registry Operator shall, for a period of x days from the Effective Date, ___). 8. See Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria for evaluation criteria that ICANN will apply for evaluating each proposed Community Registration Policy.
Registry Operator will include the following provisions in its Registry-Registrar Agreement: As part of a not-for-profit, public utility .src is a top level domain name that is unlike others, serving a technologically capable and opinionated community with a long term persistent naming system. This also deserves a due, open process which was not possible during the applications process. The dotsrc Registry Operator will develop and implement the final Community Registration policy with the help of a public consultation, and publish this policy on its website no later than the date on which the TLD is delegated in the DNS. The dotsrc Registry Operator will review the Community Registration Policy described in (a) at least once per year, and publish the results of such review (including any updates to the registration policy) on our website within thirty (30) days following the anniversary of the Effective Date. The dotsrc Registry Operator understands that any material changes will need to be approved by ICANN.
1. If you are proposing any limitation to a proposed Community Registration Policy in Questions 151-153, please provide a rationale in this response field. Please see Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria. 2. If you are not proposing any limitation to a proposed Community Registration Policy in Questions 151-153, please type ""Not Applicable"" in this response field.
The design goal of .src is to make sure (on behalf of society) that free and open source software and its documentation remain available in the very long term in a disruption-tolerant manner, shielded from outside interference, neglect, pressure from specific interests or other unpredictable and undesirable behaviour. It comes paired with free hosting infrastructure to be used in conjunction with the domain name in question, with a confined set of core services that make it scalable and fully reproducible. However, it also caters for legacy use cases where existing infrastructure is the most convenient. It missing is to make itself as redundant as possible. As the first hybrid registry of its kind, we are breaking new ground and new insights will appear rapidly as we gain practical experience with how people want to use our infrastructure. Therefore the rules that must apply are preliminary, and subject to change as the result of broader consultation and stakeholder input. If a proposed RVC is added or modified before the applicable Registry Agreement is executed, we will use the Application Change Request process for this.
1. Provide an explanation of how the proposed Community Registration Policies meet the Registry Commitments Evaluation criteria 4 and 5 using the considerations in the Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria. 2. Consider whether the proposed Community Registration Policy could be argued to be duplicative of a requirement under applicable law, ICANN agreements, or ICANN Consensus Policies or Temporary Policies. There may be circumstances in which a Community Registration Policy that would duplicate requirements under applicable consensus policy or law could be approved at ICANN’s sole discretion. If not duplicative, please explain why you believe the Community Registration Policy is not duplicative. If yes, please specify such a requirement and explain why you believe duplication in the Base RA is necessary. 3. Consider whether the proposed Community Registration Policy could be argued to be contrary to a requirement under applicable law, ICANN agreements, or ICANN Consensus Policies or Temporary Policies. ICANN will not approve any Community Registration Policies that are found to be contrary to applicable laws, ICANN agreements and policies. Please share your views on this issue in the answer to this question. 4. Consider whether the proposed Community Registration Policy could be argued to be incompatible with ICANN’s Bylaws. ICANN will not approve any Community Registration Policies that are found to be incompatible with the ICANN Bylaws. See background at the ICANN Board resolution 2024.06.08.08-2024.06.08.10. Please share your views on this issue in the answer to this question. 5. Consider whether the proposed Community Registration Policy requires the operation of an additional Registry Service. The applying entity shall engage its selected RSP to discuss the implementation of such an additional Registry Service, which must be evaluated through the RSP Program and approved by ICANN.
.src deals with the digital commons, which involves an open-ended community: anyone that feels compatibility with the ideals of the free and open source community can join more or less instantly. Free and open source software is used throughout society and in particular within critical infrastructure, and the availability of the software supply chain is non-negotiable. As a TLD it is not a 'flash' short-term commercial proposition, but a 'steady' long term pro bono proposition where the availability of the DNS and the published content (software, documentation) at a systemic level matter. In terms of brands and TLDs, we want to avoid confusion and hassle - as a free, pro bono infrastructure we don't want to be in court any more than absolutely necessary. Projects should want to avoid name collisions anyway. Only in cases where the project is older than the brand, will we defend the public interest by serving the continuity of already known FOSS projects. Because the usage within our infrastructure is typically restricted to a very limited use case, the risk of abuse will be significantly more limited than any other TLD. We will work with the wide FOSS community and with ICANN to fine-tune and remove any duplicative requirements.
Community Endorsement
Please provide evidence of support for the applying entity’s application by attaching written endorsements from the organizing bodies relevant to the identified community (related to Question 136).
Please find endorsement letters from the CEO of Free Software Foundation and the Director of Policy and Standards Open Source Initiative and OSI Europe Foundation. While we have discussed our bid with quite a few other people we did not seek any further entity endorsement, in order to reduce the risk of adversarial bids - the risk of leaking via a public mailing list, notes or other could not guarantee confidentiality. Since 1982 to this day we have worked with many organisations in the field, as our track record shows.
Provide an explanation of why opposition may or may not be relevant or how the applying entity intends to address or resolve the opposition, if applicable.
There is no such expectation. We are not treading on anyone's territory or reducing the options space, but are instead enlarging it with a pro bono offering - working from a clear liability of the current software supply chain. Those that share our analysis will join, those that do not can safely ignore.
Section: Safeguard Identification
This question set collects information related to determining whether certain Safeguard Public Interest Commitments (Safeguard PICs) are required for the applied-for gTLD string. See Section 7.8.2.3 Safeguard PICs. Answers to these questions will inform assessment by ICANN on whether and which Safeguard PICs must be incorporated in the applicable Registry Agreement (RA) if the string proceeds to delegation. The answers themselves will not automatically make such a determination.
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
Yes
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
Yes
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. I-2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. I-2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
Select Yes or No. Notes: 1. ICANN will evaluate whether an applied-for gTLD string requires one or more Safeguard Public Interest Commitments (Safeguard PICs) to be included in the Base RA). 2. In addition to the Mandatory Public Interest Commitments (PICs) that must be included in each Base RA, a subset of Base RAs must include Safeguard PICs based on ICANN’s Safeguard Assessment. See Section 7.8.2.3 Safeguard PICs. 3. Applying entities for TLDs that are not found to require Safeguard PICs can elect to add them to the applicable Base RAs voluntarily to, for example, further their business objectives, help address issues or concerns that are raised or could be raised with respect to their applications, or avoid the need for the evaluation and implementation of customized Registry Voluntary Commitment (RVC). See Section 7.8.3 Registry Voluntary Commitments (RVCs).
Yes
Choose the applicable Safeguard PICs from the provided list (more than one option can be selected).
• 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.
Section: Registry Voluntary Commitments (RVCs)
This question set collects information related to any Registry Voluntary Commitments (RVCs) that the applying entity is submitting. The decision to submit an RVC is typically voluntary, except for those recognized by ICANN to resolve an objection or to address GAC Consensus Advice. See Section 7.8.3 Registry Voluntary Commitments for more information.
1. Select Yes or No. 2. In addition to Safeguard Public Interest Commitments (PICs), an applying entity will be permitted to propose one or more Registry Voluntary Commitments (RVCs) to provide additional safeguards with regard to the registry operator’s operation of an applied-for gTLD string. See Section 7.8.3 Registry Voluntary Commitments (RVCs). 3. RVCs are separate from Community Registration Policies. See Section 7.8.3 Registry Voluntary Commitments (RVCs) and Section 7.8.4 Community Registration Policies for more information. If you are applying for a Community gTLD, please submit the Community Registration Policies by answering Questions 150-155. However, if you propose to include additional Registry Voluntary Commitments in the RA beyond the Community Registration Policies, you may answer "yes" and proceed to answer the following questions. 4. You are encouraged to consider whether there are other means, separate from including commitment(s) in the Base RA, that could be used to further your business objectives or help resolve any anticipated or actual issue(s) raised regarding the applied-for gTLD string or application. See Section 7.8.3 Registry Voluntary Commitments (RVCs). Notes: If you select “yes” to this question, you are required to pay the conditional Registry Commitments Evaluation fee, and commitments that are approved by ICANN will be included in Specification 11 of the applicable Base RA as specific voluntary public interest commitments as contractual obligations.
No
Section: Brand & Code of Conduct Exemptions
This question set collects information related to whether the applied-for gTLD string is a .Brand (see Section 7.3) or if the applying entity is seeking a Code of Conduct exemption (see Section 7.4).
Select Yes or No
No
This serves as an indication of intent to apply for an exemption to Specification 9 and that the applying entity is NOT requesting to be designated a .Brand TLD, pursuant to Specification 13.
No
Section: Additional Information and Supporting Materials
This question set collects any additional information that the applying entity would like to provide, including any supporting materials.
1. An applying entity may use this response field to submit any additional, optional information or documentation that the applying entity believes enhances understanding of its application or may be of interest to the general public. This could include, but is not limited to, the applying entity’s: a) Individual registry policies; b) Separate agreement with a third-party to fulfill certain commitments; c) Terms of use; d) Additional Community Registration Policies not intended for RA inclusion; e) Other materials that clarify the applying entity’s mission, values, or intended use of the gTLD. Notes: 1. This question is optional and for informational purposes only. 2. The information provided here will not be evaluated as part of the application, or be contractually binding on the applying entity. 3. All submissions to this question will be posted for the public to review and comment.
We apologise for missing out on the Applicant Support Program, for which we would have qualified - and which clearly would have been beneficial to us during the preparation of our proposal. The time window for applying for this programme closed too early for us and thus participation was unfortunately outside our possibilities. As a public utility for the free and open source community that is paid for by the demand side through donations rather than by the supply side through registration feeds, .src falls somewhat outside of the mainstream TLD design. Because there is a concrete need for addressing the identified issue with the As will hopefully rapidly evolve
Section: Bona Fide Intent and Prohibited Communications
This question set contains attestations related to the applying entity’s acknowledgment of bona fide intent and prohibited communications.
Confirm the statement using the checkbox.
true
Confirm the statement using the checkbox.
true