{"applicationHumanReadableId":"SN2610T-T87824","applicationDetails":{"applicationHumanReadableId":"SN2610T-T87824","applicationType":"New gTLD","primaryString":{"aLabel":"src","uLabel":""},"tldVariants":[],"originalTldVariants":[],"tldTypes":["Community"],"priorityNumber":-1,"applicationStatus":"Active","processingStage":"Pre-Evaluation Processing","hasClarifyingQuestions":false,"hasChangeRequests":false,"hasObjections":false,"lastPublishedAt":"2026-10-07T15:26:05.519Z"},"questionAndResponses":{"applicationHumanReadableId":"SN2610T-T87824","sections":[{"displayOrder":1,"sectionId":"1","sectionTitle":"Applying Entity Information","sectionInstructions":"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.","questions":[{"displayOrder":1,"questionText":"AGB Q1. Full Legal Name","instructions":"Provide the full legal name of the applying entity as it appears on the official registration documents. Do not use abbreviations.","responseText":"Stichting NLnet","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":3,"questionText":"AGB Q3. Legal Entity Form/Business Structure","instructions":"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.","responseText":"Foundation","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":4,"questionText":"AGB Q4. Jurisdiction","instructions":"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.","responseText":"the Netherlands","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":10,"questionText":"AGB Q10. Website URL","instructions":"Provide the website URL of the applying entity, if available.","responseText":"https://nlnet.nl","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":11,"questionText":"AGB Q11. Is the applying entity an existing registry operator, ICANN accredited registrar, or an Affiliate of either?","instructions":"1. Choose Yes or No. \n2. Use the definition of Affiliate from the Base Registry Agreement (see  https://www.icann.org/en/registry-agreements/base-agreement).","responseText":"false","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":13,"questionText":"AGB Q13. Is the applying entity a back-end registry service provider (RSP), an ICANN-approved data escrow agent, an emergency back-end registry operator, a Uniform Rapid Suspension (URS) service provider, an ICANN dispute resolution service provider, a Privacy or Proxy Service Provider, or a Reseller?","instructions":"Choose Yes or No.","responseText":"false","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":17,"questionText":"AGB Q17. Phone Country Code","instructions":"","responseText":"31","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":18,"questionText":"AGB Q18. Primary Business Phone","instructions":"Provide the primary business phone number without including the country code.","responseText":"208884252","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":19,"questionText":"AGB Q19. Primary Business Email Address","instructions":"Provide the primary business email address of the applying entity.","responseText":"icann@nlnet.nl","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":20,"questionText":"AGB Q20. Address Line 1","instructions":"Enter the street address (no PO Box).","responseText":"Science Park 400","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":22,"questionText":"AGB Q22. Locality","instructions":"Enter the city, village, municipality, etc.","responseText":"Amsterdam","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":23,"questionText":"AGB Q23. State/Province/Region","instructions":"Enter the state, province, department, territory, prefecture, oblast, etc., if applicable.","responseText":"Zuid-Holland","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":24,"questionText":"AGB Q24. Postal Code","instructions":"1. Enter the postal code, if applicable.\n2. If a postal code does not exist, type “Not Applicable”. ","responseText":"1098 XH","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":25,"questionText":"AGB Q25. Country Code of Location","instructions":"","responseText":"NL","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":2,"sectionId":"1","sectionTitle":"Applying Entity Background and Organization","sectionInstructions":"This question set collects information related to the individuals who will have access to TAMS, manage the application, and receive inquiries.","questions":[{"displayOrder":1,"questionText":"AGB 104. List all directors of the applying entity.","instructions":"","responseText":"Bob Goudriaan, Bob Goudriaan","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":2,"questionText":"AGB 105. List all officers & partners of the applying entity.","instructions":"","responseText":"Bob Goudriaan","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":4,"sectionId":"16","sectionTitle":"Self-Certification","sectionInstructions":"Provide a single document for Self-Certification question Q4.2-1.\r\nThe document must include only the SC4.2-1.1, SC4.2-1.2, or SC4.2-1.3 statements.\r\nDo not modify any of the Self-Certification statements.","questions":[{"displayOrder":1,"questionText":"AGB Q212. 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.","instructions":"1. Provide a single document for Self-Certification question Q4.2-1.\n2. The document must include only the SC4.2-1.1 through SC4.2-1.3 statements.\n3. Do not modify any of the Self-Certification statements.\n4. 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.","responseText":"","hasResponseDocuments":true,"hasCr":false,"hasCq":false}]},{"displayOrder":6,"sectionId":"18","sectionTitle":"Security Policy and Planning","sectionInstructions":"Provide a single document for Self-Certification question AGB Q220, Q5.1-1.\r\nThe document must include only the SC5.1-1.1 through SC5.1-1.3 statements.\r\nDo not modify any of the Self-Certification statements.\r\nIf 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.","questions":[{"displayOrder":1,"questionText":"AGB Q220. 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:\nSC5.1-1.1 - The applying entity will appropriately protect confidentiality of data and prevent unauthorized access to data and services.\nSC5.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.\nSC5.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.","instructions":"1. Provide a single document for Self-Certification question Q5.1-1.\n2. The document must include only the SC5.1-1.1 through SC5.1-1.3 statements.\n3. Do not modify any of the Self-Certification statements.\n4. 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.","responseText":"","hasResponseDocuments":true,"hasCr":false,"hasCq":false}]},{"displayOrder":7,"sectionId":"19","sectionTitle":"DNS Abuse","sectionInstructions":"Provide a single document for Self-Certification question AGB Q221, Q5.2-1.\r\nThe document must include only the SC5.2-1.1 through SC5.2-1.7 statements.\r\nDo not modify any of the Self-Certification statements.\r\nIf 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.","questions":[{"displayOrder":1,"questionText":"AGB Q221. 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:\nSC5.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.\nSC5.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.\nSC5.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).\nSC5.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.\nSC5.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.\nSC5.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.\nSC5.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.","instructions":"1. Provide a single document for Self-Certification question Q5.2-1.\n2. The document must include only the SC5.2-1.1 through SC5.2-1.7 statements.\n3. Do not modify any of the Self-Certification statements.\n4. 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.","responseText":"","hasResponseDocuments":true,"hasCr":false,"hasCq":false}]},{"displayOrder":8,"sectionId":"16","sectionTitle":"Primary String","sectionInstructions":"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.","questions":[{"displayOrder":4,"questionText":"AGB Q118. What is the meaning/definition of the applied-for gTLD string?","instructions":"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\"","responseText":"The name refers to 'source' as in 'source code', the (human readable) instructions that can be compiled into computer software or hardware.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":6,"questionText":"AGB Q120.  Phonetic Representation","instructions":"Provide a representation of the string according to the International Phonetic Alphabet.","responseText":"/sɔːs/","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":7,"questionText":"AGB Q121. 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.","instructions":"Confirm the statement using a checkbox.","responseText":"true","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":8,"questionText":"AGB Q133. What is the mission and purpose of the applied-for gTLD?","instructions":"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.\n\n1a. 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.\n\n2. Explain how this purpose is sustainable over time.","responseText":"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.\n\nAnywhere 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.\n\nWhile 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.\n\nThis 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. \n\nThat 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.\n\nAny 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.\n\nOnce 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.\n\ndotsrc 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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":1,"questionText":"AGB Q116. Applied-for Primary String (ASCII Label)","instructions":"","responseText":"src","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":10,"sectionId":"5","sectionTitle":"Community","sectionInstructions":"This question set collects information specific to Community gTLDs. However, question 133 (Mission & Purpose) must be answered by all applying entities.","subsections":[{"displayOrder":1,"subsectionTitle":"General","questions":[{"displayOrder":2,"questionText":"AGB Q132. What community will the applied-for string serve?","instructions":"1. Provide the name of the community that the applying entity is committing to serve. \r\n2. Describe the distinct aspects of the community.","responseText":"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","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":3,"questionText":"AGB Q134. How would you categorize your community?","instructions":"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.","responseText":"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.\n\nSome 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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":1,"questionText":"AGB Q131. Is this application for a community TLD?","instructions":"","responseText":"Yes","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":2,"subsectionTitle":"Organization","questions":[{"displayOrder":3,"questionText":"AGB Q135. What is the applying entity's connection to the community?","instructions":"Describe and provide evidence of the relationship between the applying entity and the identified community.","responseText":"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.\n\nWe 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","hasResponseDocuments":true,"hasCr":false,"hasCq":false},{"displayOrder":4,"questionText":"AGB Q136. How is the community organized? Are there one or multiple organizations (\"organizing body\") that represent or administer the community?","instructions":"Describe and provide evidence related to the community organization, any relevant organizing bodies, and any relevant leaders within the community.","responseText":"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.\n\nThere 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.\n\n 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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":5,"questionText":"AGB Q137. 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? ","instructions":"1. Describe any formal membership process, if there is one.\r\n2. 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).","responseText":"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. \n\nThere 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.\n\nCommunity 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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":6,"questionText":"AGB Q138. Where is the community located?","instructions":"Provide the primary location of the community.","responseText":"Globally dispersed, there is no central location.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":7,"questionText":"AGB Q139. What is the estimated size of the community? This should take into account any regions listed in Question 138.","instructions":"1. Provide the estimated size of the community. The size should be in number format (e.g., “1,000,000 members”).\r\n2. If the community is divided by group, region, sector, etc., this should include estimated size for each group.","responseText":"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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":8,"questionText":"AGB Q140. What portion of the community do any organizing bodies represent or administer to?","instructions":"Provide the estimated size of the community that is administered or represented by each relevant organizing body in the identified community.","responseText":"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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":3,"subsectionTitle":"Engagement","questions":[{"displayOrder":9,"questionText":"AGB Q141. Do the organizing bodies demonstrate active and consistent efforts to engage and connect with the identified community and its members?","instructions":"1. Provide evidence of any documented practices of community efforts to date\r\n2. The applying entity should provide documentation of the following practices, which should have occurred within the two years leading up to application submission: \r\na) Offering support; \r\nb) Sharing information; \r\nc) Responding to specific community needs;\r\nd) Fostering and strengthening relationships within the community.","responseText":"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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":10,"questionText":"AGB Q142. What is the role of the applying entity in the engagement efforts listed in Question 141?","instructions":"1. Describe whether the applying entity has a role in any of the activities listed in Question 141.\r\n2. 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.","responseText":"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.\n\nOur 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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":4,"subsectionTitle":"Awareness","questions":[{"displayOrder":11,"questionText":"AGB Q143. Are community members aware of the identified community and each other?","instructions":"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. \r\n2. The applying entity should provide documentation of the following practices, which should have occurred within the two years leading up to application submission:\r\na) Surveys conducted;\r\nb) Records of activities involving a diversity of community groups, segments, or members.","responseText":"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.\n\nThere 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.\n\nThere are many events (e.g. https://foss.events) which some events like FOSDEM drawing > 10000 visitors from around the world annually.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":12,"questionText":"AGB Q144. Are community members aware of the applying entity and its intention to apply for a community gTLD?","instructions":"1. Provide evidence of community members’ awareness of the applying entity and its intent to apply for a community gTLD. \r\n2. If there is no such evidence, explain why not.","responseText":"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.\n\nWith 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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":5,"subsectionTitle":"Established Presence","questions":[{"displayOrder":13,"questionText":"AGB Q145. Was there an established presence of the identified community prior to the opening of the application submission period?","instructions":"Provide evidence of the established presence of the community prior to the opening of the application submission period.","responseText":"No","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":14,"questionText":"AGB Q146. Are individuals and groups outside of the identified community aware of the existence of the identified community?","instructions":"1. Provide evidence that demonstrates that individuals and groups outside of the community show an awareness of the identified community. \r\n2. The applying entity should provide documentation of the following practices, which should have occurred within the two years leading up to application submission:\r\na) Media or other public information regarding the community and its activities or members; \r\nb) Discussion of the community in various fora, whether online or in person; \r\nc) Evidence of partnerships or collaborations with groups outside of the identified community;\r\nd) Evidence of the chartering or organization of the community prior to the opening of the application submission window;\r\ne) Evidence of contributions (for example, cultural or scientific) to a larger society or population;","responseText":"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).\n\nPeople 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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":6,"subsectionTitle":"Longevity","questions":[{"displayOrder":15,"questionText":"AGB Q147. Are the pursuits of the identified community enduring and sustainable?","instructions":"1. Provide evidence of the longevity of the community. \r\n2. The applying entity should provide documentation of the following practices which should have occurred within the two years leading up to application submission:\r\na) Evidence of recurring or scheduled activities that demonstrate continuity over time;\r\nb) Documented records of past activities that demonstrate a long-standing tradition or practice;\r\nc) Records of discussions emphasizing the community’s enduring presence or its cultural significance.","responseText":"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.\n\nThe 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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":7,"subsectionTitle":"Nexus","questions":[{"displayOrder":16,"questionText":"AGB Q148. Does the string match the name of the identified community?","instructions":"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.","responseText":"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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":17,"questionText":"AGB Q149. Will the general public instinctively think of the community when thinking of the applied-for string?","instructions":"1. Explain how the applied-for string clearly relates to or represents the community \r\n2. 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.","responseText":"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).\n\nThe 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.\n\nWe are not aware of any geography, region or theme that would have a specific interest in this string.\n\nThe 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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":8,"subsectionTitle":"Community Registration Policy","questions":[{"displayOrder":18,"questionText":"AGB Q150. 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?","instructions":"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.","responseText":"Yes","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":19,"questionText":"AGB Q151.1. Please state a specific Community Registration Policy with respect to registration eligibility for community members.","instructions":"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.\n\n2. 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.\n\n3. Follow this format to propose what the Registry Operator must do and/or must not do:\na) “Registry Operator shall___”; and/or\nb) “Registry Operator shall not___”.\n\n4. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars ,:\na) \"Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or\nb) \"Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”.\n\n5. Follow this format to propose  any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements:\na) \"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\nb) \"Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting ___\".\n\n6. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Community Registration Policy. For example:\na) 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.\nb) 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.\n\n7. 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, ___).\n\n8. 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.","responseText":"Registry Operator will include the following provisions in its Registry-Registrar Agreement:\n\nOnly 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.\n\nThe .src infrastructure may not be used for distributing proprietary software, for that any other domains name can and should be used.\n\nThere are two modes of entry into .src: Legacy Mode and Long Term Mode.\n\nLong 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.\n\nIn 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.\n\nIn 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.\n\nRegistrars 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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":19,"questionText":"AGB Q151.2. If there is an additional proposed policy, please state the specific Community Registration Policy with respect to registration eligibility for community members.","instructions":"Please see full instructions in AGB Q151.1.","responseText":"Registry Operator will include the following provisions in its Registry-Registrar Agreement:\n\nThe 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).\n\nIf 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.\n\nAlternatively, 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.\n\nFor 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.\n\nIn 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. \n\nIn 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.\n\nIf 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.\n\nAll registration are automatically valid for a period of 10 years, or the maximum allowed by ICANN - whichever is the highest.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":19,"questionText":"AGB Q151.3. If there is an additional proposed policy, please state the specific Community Registration Policy with respect to registration eligibility for community members.","instructions":"Please see full instructions in AGB Q151.1.","responseText":"Registry Operator will include the following provision in its Registry-Registrar Agreement:\n\nIt 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.\n\nThe 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.\n\nEven 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.\n\nIn 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).\n\nDomains mentioned in the metadata within at least the following software distributions:\n\n-\tAdélie Linux\n-\tAIX Open Source Packages\n-\tAIX Toolbox\n-\tAlmaLinux\n-\tAlpine Linux\n-\tALT Linux p11\n-\tALT Sisyphus\n-\tAmazon Linux\n-\tAOSC\n-\tApertis\n-\tArch Linux\n-\tArchPOWER\n-\tArtix\n-\tBackBox\n-\tBaulk\n-\tCalculate\n-\tCarbs Linux\n-\tCentOS\n-\tChimera Linux\n-\tChocolatey\n-\tConanCenter\n-\tCPAN\n-\tCRAN\n-\tcrates.io\n-\tCRUX\n-\tCygwin\n-\tDeb Multimedia\n-\tDebian\n-\tdeepin\n-\tDevuan\n-\tdistri\n-\tELRepo\n-\tEndless OS\n-\tEPEL\n-\tEuroLinux\n-\tExherbo\n-\tF-Droid\n-\tFedora\n-\tFreeBSD Ports\n-\tGentoo (+ GURU, Pentoo + Science overlay)\n-\tGNU Elpa\n-\tGNU Guix\n-\tHackage\n-\tHaikuPorts\n-\tHomebrew\n-\tHP-UX 11.31\n-\tIBM i\n-\tIzzyOnDroid\n-\tKali Linux\n-\tKaOS\n-\tKDE neon\n-\tLiGurOS\n-\tLuaRocks\n-\tMacPorts\n-\tMageia\n-\tManjaro\n-\tMELPA\n-\tMSYS2\n-\tMX Linux\n-\tnixpkgs\n-\tNpackd\n-\topam\n-\tOpenBSD Ports\n-\topenEuler\n-\tOpenIndiana packages\n-\topenmamba\n-\tOpenMandriva\n-\tOpenPKG\n-\topenSUSE\n-\tOpen VSX\n-\tOpenWrt\n-\tPackMan\n-\tpacstall\n-\tParabola\n-\tPardus\n-\tParrot\n-\tPCLinuxOS\n-\tPisi Linux\n-\tpkgsrc\n-\tPLD Linux\n-\tpostmarketOS\n-\tPTXdist\n-\tPureOS\n-\tPyPI\n-\tRaspbian\n-\tReactOS rapps\n-\tRebornOS\n-\tRocky Linux\n-\tRosa\n-\tRubyGems\n-\tSageMath\n-\tSalix\n-\tSide Linux\n-\tSiduction\n-\tSlackware\n-\tStackage\n-\tstal/IX\n-\tT2 SDE\n-\tTails\n-\tTermux\n-\tTerra\n-\tTin Can Linux\n-\tTrisquel\n-\tUBI\n-\tUbuntu\n-\tVcpkg\n-\tVoid Linux\n\nThe contents of Open Invention Network's Linux System Definition:\n\nhttps://openinventionnetwork.com/linux-system","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":19,"questionText":"AGB Q151.4. If there is an additional proposed policy, please state the specific Community Registration Policy with respect to registration eligibility for community members.","instructions":"Please see full instructions in AGB Q151.1.","responseText":"Registry Operator will include the following provision in its Registry-Registrar Agreement:\n\nThe 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.\n\nRegistrar 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\n\nThe 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.\n\nThe 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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":19,"questionText":"AGB Q151.5. If there is an additional proposed policy, please state the specific Community Registration Policy with respect to registration eligibility for community members.","instructions":"Please see full instructions in AGB Q151.1.","responseText":"Registry Operator will include a provision in its Registry-Registrar Agreement that requires Registrars to include the following provision in their Registration Agreements:\n\nPrior 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.\n\nThis 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.\n\nIf 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.\n\nRegistrar 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.\n\nWhen 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.\n\nIt 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.\n\nA '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.\n\nA 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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":19,"questionText":"AGB Q151.6. If there is an additional proposed policy, please state the specific Community Registration Policy with respect to registration eligibility for community members.","instructions":"Please see full instructions in AGB Q151.1.","responseText":"Registry Operator will include the following provisions in its Registry-Registrar Agreement that requires Registrars to include in their Registration Agreements the following provision:\n\nRegistrant agrees that the Registrar or the Registry Operator may trigger the succession agreement in case:\n\n- 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.\n- the Registrant intends to sell the qualifying domain \n- the Registrant is placed on a mandatory sanction list\n- the Registrant is convicted of fraudulent or criminal behaviour\n- 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\n","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":19,"questionText":"AGB Q151.7. If there is an additional proposed policy, please state the specific Community Registration Policy with respect to registration eligibility for community members.","instructions":"Please see full instructions in AGB Q151.1.","responseText":"Registry Operator will include the following provisions in its Registry-Registrar Agreement that requires Registrars to include in their Registration Agreements the following provision:\n\nEach 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.\n\nIf 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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":19,"questionText":"AGB Q151.8. If there is an additional proposed policy, please state the specific Community Registration Policy with respect to registration eligibility for community members.","instructions":"Please see full instructions in AGB Q151.1.","responseText":"\nRegistry Operator will include the following provision in its Registry-Registrar Agreement:\n\nIf 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:\n\n- 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.\n\n- 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.\n\n- 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.\n\nIf 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.\n\nAt 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.\n\n 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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":19,"questionText":"AGB Q151.9. If there is an additional proposed policy, please state the specific Community Registration Policy with respect to registration eligibility for community members.","instructions":"Please see full instructions in AGB Q151.1.","responseText":"Registry Operator will include the following provisions in its Registry-Registrar Agreement:\n\nThere 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.\n\nIn 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.\n\nA Registrar must be transparent about its fee structure for validation, DNS hosting, and publish these rates on its website. \n\nPrior 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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":19,"questionText":"AGB Q151.10. If there is an additional proposed policy, please state the specific Community Registration Policy with respect to registration eligibility for community members.","instructions":"Please see full instructions in AGB Q151.1.","responseText":"Registry Operator will include the following provision in its Registry-Registrar Agreement:\n\nOnce 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.\n\nWhen 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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":20,"questionText":"AGB Q152.1. State a specific Community Registration Policy with respect to name selection criteria or rules for the applied-for string.","instructions":"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.\n\n2. 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. \n\n3. These criteria or rules should align with the community objectives of the applied-for gTLD string.\n\n4. Follow this format to propose what the Registry Operator must do and/or must not do:\na) “Registry Operator shall___”; and/or\nb) “Registry Operator shall not___”.\n\n5. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars:\na) \"\"Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or\nb) \"\"Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”.\n\n6. Follow this format to propose any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements:\na) \"\"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\nb) \"\"Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting ___\"\".\n\n7. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Community Registration Policy. For example:\na) 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.\nb) 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.\n\n8. 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, ___).\n\n9. 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.","responseText":"There is no further CRP.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":21,"questionText":"AGB Q153.1. State a specific Community Registration Policy with respect to an additional commitment besides registration eligibility for community members and naming selection criteria or rules for the applied-for string.","instructions":"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.\n\n2. Enter a single proposed Community Registration Policy in each response field. Up to 10 Community Registration Policies can be submitted.  \n\n3. Follow the format to propose what the Registry Operator must do and/or must not do:\na) “Registry Operator shall___”; and/or\nb) “Registry Operator shall not___”.\n\n4. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars:\na) \"\"Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or\nb) \"\"Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”.\n\n5. Follow this format to propose any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements:\na) \"\"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\nb) \"\"Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting___\"\".\n\n6. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Community Registration Policy. For example:\na) 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.\nb) 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.\n\n7. 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, ___).\n\n8. 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.","responseText":"Registry Operator will include the following provisions in its Registry-Registrar Agreement:\n\nAs 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. \n\nThe 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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":22,"questionText":"AGB Q154. Explain the rationale for any limitations to the Community Registration Policy proposed by the applying entity in Questions 151-153.","instructions":"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.\n2. 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.","responseText":"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. \n\nIt 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.\n\nAs 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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":23,"questionText":"AGB Q155. Explain how the proposed Community Registration Policies of the applying entity meets the Registry Commitments Evaluation criteria 4 and 5?","instructions":"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.\n2. 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.\n3. 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.\n4. 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.\n5. 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.","responseText":".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.\n\nFree 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.\n\nIn 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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":9,"subsectionTitle":"Community Endorsement","questions":[{"displayOrder":24,"questionText":"AGB Q156. From where does the applying entity have the support to run the applied-for string on behalf of the identified community?","instructions":"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).","responseText":"Please find endorsement letters from the CEO of Free Software Foundation and the Director of Policy and Standards\nOpen Source Initiative and OSI Europe Foundation.\n\nWhile 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.","hasResponseDocuments":true,"hasCr":false,"hasCq":false},{"displayOrder":25,"questionText":"AGB Q157. Is there any opposition to the applying entity, application, or applied-for string that the applying entity is aware of? If yes, please explain.","instructions":"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.","responseText":"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.","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]}]},{"displayOrder":13,"sectionId":"2","sectionTitle":"Safeguard Identification","sectionInstructions":"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.","questions":[{"displayOrder":1,"questionText":"AGB Q164. Will people see a domain name as more trustworthy because it is registered in your TLD?\r\nThink about how people around the world will understand the TLD string(s) in the application, including literal and informal meanings in different languages and regions.","instructions":"1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts:\r\na. Literally as described in the application\r\nb. Literally in any other language in which the string is a recognized word or phrase.\r\nc. Informally in any language or regional variant, where alternative meanings exist.\r\n2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.","responseText":"Yes","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":2,"questionText":"AGB Q165. Is it likely that consumers will face significant risks if domain names in the TLD(s) in the application are abused?\r\nThink about how people around the world will understand the TLD string(s) in the application, including literal and informal meanings in different languages and regions.","instructions":"1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts:\r\na. Literally as described in the application\r\nb. Literally in any other language in which the string is a recognized word or phrase.\r\nc. Informally in any language or regional variant, where alternative meanings exist.\r\n2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.","responseText":"Yes","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":3,"questionText":"AGB Q166. Would people generally think that this TLD will be used by entities that require strict licensing or accreditation to do business?\r\nThink about how the TLD string(s) in the application will be understood around the world, including both literal and informal meanings in different languages and regions.","instructions":"1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts:\r\na. Literally as described in the application\r\nb. Literally in any other language in which the string is a recognized word or phrase.\r\nc. Informally in any language or regional variant, where alternative meanings exist.\r\n2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.","responseText":"No","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":4,"questionText":"AGB Q167. Would most people think that (domains in) the TLD(s) in the application are used for activities that require regular government reporting, inspections, and oversight in various countries?\r\nThink about how the TLD string(s) in the application will be understood around the world, including both literal and informal meanings in different languages and regions.","instructions":"1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts:\r\na. Literally as described in the application\r\nb. Literally in any other language in which the string is a recognized word or phrase.\r\nc. Informally in any language or regional variant, where alternative meanings exist.\r\n2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.","responseText":"No","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":5,"questionText":"AGB Q168. Could people reasonably believe that (domains in) your TLD will cause or lead to harassment, harm, aggression, complaints, criticism, distress, or embarrassment?\r\nThink about how the TLD string(s) in the application will be understood globally, including different languages and cultures.","instructions":"1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts:\r\na. Literally as described in the application\r\nb. Literally in any other language in which the string is a recognized word or phrase.\r\nc. Informally in any language or regional variant, where alternative meanings exist.\r\nI-2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.","responseText":"No","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":6,"questionText":"AGB Q169. Would most people think that the TLD is used for something usually done by governments?\r\nThink about how the TLD string(s) in the application will be understood globally, including different languages and cultures.","instructions":"1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts:\na. Literally as described in the application\nb. Literally in any other language in which the string is a recognized word or phrase.\nc. Informally in any language or regional variant, where alternative meanings exist.\nI-2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.","responseText":"No","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":7,"questionText":"AGB Q170. Are you proposing to include one or more of the Safeguard Public Interest Commitments (Safeguard PICs) in the Registry Agreement (RA) voluntarily regardless of ICANN’s Safeguard Assessment outcomes?","instructions":"Select Yes or No.\n\nNotes:\n1. 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).\n2. 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.\n3. 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).","responseText":"Yes","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":8,"questionText":"AGB Q171. If Yes, which Safeguard PIC(s) are you proposing to include in the RA?","instructions":"Choose the applicable Safeguard PICs from the provided list (more than one option can be selected).","responseText":" • 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.\n • 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.\n • 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.\n • 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.\n • 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.\n • 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.\n • Registry Operators will develop and publish registration policies to minimize the risk of cyber bullying and/or harassment.","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":14,"sectionId":"12","sectionTitle":"Registry Voluntary Commitments (RVCs)","sectionInstructions":"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.","questions":[{"displayOrder":1,"questionText":"AGB Q172. Are you proposing to include one or more Registry Voluntary Commitments (RVCs) in the Registry Agreement (RA) that are unique to your applied-for string?","instructions":"1. Select Yes or No.\n2. 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).\n3. 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.\n4. 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).\n\nNotes:\nIf 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.","responseText":"No","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":16,"sectionId":"11","sectionTitle":"Brand & Code of Conduct Exemptions","sectionInstructions":"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).","questions":[{"displayOrder":1,"questionText":"AGB Q179. Are you applying for a Brand TLD?","instructions":"Select Yes or No","responseText":"No","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":7,"questionText":"AGB Q185. Does the applying entity request a Code of Conduct Exemption?","instructions":"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.","responseText":"No","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":17,"sectionId":"13","sectionTitle":"Additional Information and Supporting Materials","sectionInstructions":"This question set collects any additional information that the applying entity would like to provide, including any supporting materials.","questions":[{"displayOrder":1,"questionText":"AGB Q222. If the applying entity wishes to provide any additional information or supporting materials that the applying entity believes may be of interest to the public or relevant to the application, please include them here.","instructions":"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: \r\na) Individual registry policies;\r\nb) Separate agreement with a third-party to fulfill certain commitments; \r\nc) Terms of use; \r\nd) Additional Community Registration Policies not intended for RA inclusion; \r\ne) Other materials that clarify the applying entity’s mission, values, or intended use of the gTLD. \r\n\r\nNotes:\r\n1. This question is optional and for informational purposes only. \r\n2. The information provided here will not be evaluated as part of the application, or be contractually binding on the applying entity. \r\n3. All submissions to this question will be posted for the public to review and comment. ","responseText":"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.\n\nAs 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","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":18,"sectionId":"14","sectionTitle":"Bona Fide Intent and Prohibited Communications","sectionInstructions":"This question set contains attestations related to the applying entity’s acknowledgment of bona fide intent and prohibited communications.","questions":[{"displayOrder":1,"questionText":"AGB Q223. By submitting this Application, the applying entity confirms that it is submitting this Application with a good faith (“bona fide”) intent to operate the gTLD for which it has applied, and that the applying entity has read and understands the provisions of Section 5.2.3.1 Prohibited Communications and Activities of the Applicant Guidebook regarding the New gTLD Program rules prohibiting certain communications and activities to prevent parties from privately resolving string contention among themselves.","instructions":"Confirm the statement using the checkbox.","responseText":"true","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":2,"questionText":"AGB Q224. By submitting this Application, the applying entity confirms that it has read and understands the provisions of Section 5.2.3.1  Prohibited Communications and Activities of the Applicant Guidebook regarding the New gTLD Program rules prohibiting certain communications and activities to prevent parties from privately resolving string contention among themselves.","instructions":"Confirm the statement using the checkbox.","responseText":"true","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]}]}}