tl;dr: ISO is seeking testimonials from “open source organizations” by June 4th on the importance of open access to ISO standards documents; this RFC is about that statement.

Background

Roughly speaking, under the usual ISO and IEC rules, all committee-related documents are only accessible to committee members or other members of their organization. There was an historical experiment run by JTC1, the committee within ISO which is responsible for technology-related standards, to open access to committee documents. This experiment was successful but was never finalized with ISO, so the documents were left freely available in practice but ISO had expected access to be closed off again. Fast forward about 30 years later: ISO realized there were far more documents with open access than they thought and so they’re trying to close off all access to those documents moving forward. JTC1 has been working to convince ISO and IEC about the importance of open access for several years now, and as part of that conversation, ISO is seeking testimonials from companies and open source organizations on the importance of open access to standards documents. The documents in question are: working drafts, committee drafts, and new work item proposals (introducing a new Technical Specification or International Standard) proposals (N-numbers documents, but also potentially P-numbered papers including things like issues lists and defect reports); other documents such as meeting minutes, agendas, standing documents, and committee policies will become closed access and the final version of the standard will remain closed access as it is today.

Our community would likely have never existed were it not for open access to these documents and ISO closing access now poses a significant threat to our community’s future because standards like C, C++, and FORTRAN are the backbone of our implementation and of our 17k+ downstream forks. Our community members come from all over the world, are of all ages, come and go as they please, and we do not have the means by which to manage them as though they were employees of the LLVM Foundation so that we can continue to guarantee everyone has access to the same information necessary for implementing these standards. Further, this hinders our ability to meaningfully communicate with our users for things like the status of our implementation efforts which are tracked on a per-document basis for both features and defect reports, or for our users to validate our interpretation of the standard when there’s disagreement over a particular behavior.

Plan

I met with members of the LLVM Foundation this week to apprise them of the situation and they agree that the LLVM Foundation should make a statement on behalf of the community, but the statement they make should come from us. The rough plan for this is:

  • I have linked the draft the statement I think the community should make, just to give us a starting place;
  • The community can recommend edits on that draft statement up until May 27; I will update the statement as suggestions arrive;
  • The Project Council will meet out-of-band on May 28 to finalize the statement;
  • I will post the final draft to this thread in Discourse and submit it to the LLVM Foundation on May 29;
  • The LLVM Foundation will meet to ratify the document (potentially with edits) on Jun 2;
  • I will submit the final testimonial to ISO on Jun 3 (drop dead date of Jun 4).

Note that due to the limited time for feedback and editing with the Jun 4 deadline, there may not be time for lengthy discussions about the content or for iterations with the community if the Project Council or LLVM Foundation make edits to the statement. Hopefully those edits will be minimal (if any). It’s not ideal but ISO did set a tight deadline and we are appreciative of the community’s understanding.

Call to Action

The draft testimonial can be found here: Open Access to Standards Documents - Google Docs

Please leave comments and suggest edits. ISO has already received feedback about the impacts on standards committees themselves, so our feedback should be focused on the impact to our ability to support ISO standards. It is also worth keeping in mind that from ISO’s perspective, these documents were not supposed to be public, so reasoning along the lines of “we’ve always had access” won’t be as compelling as explanations of what tangible harms come from losing access.

Also, if you work for a company which has a downstream fork of the project or otherwise relies on open access to ISO documents, please advocate within your organization to make a similar testimonial. If your organization needs help submitting a testimonial, you can reach out to me directly for help.

As always, if you have questions, feel free to ask here and I’ll provide what information I can.

CC @project-council

That approach would raise a lot of questions (both theoretical and practical) and would be efforts happening outside of our community. The goal here is to focus on what we can accomplish for a testimonial by the Jun 4 deadline. If ISO closes down access anyway, there will be follow-up discussions about how our community will adjust so I don’t think we should plan for the worst yet.

I am unsure how that could possibly feasible, and would likely require essentially reverse engineering the standard based on existing implementations which seems implausible - both from the PoV of consistency and correctness.

I think there’s a secondary point here: the specification is quoted in the clang sources - is ISO proposing that we remove those references such that people lose the ability to understand the what and why of code?

Thank you for championing this, @AaronBallman! I think the draft LGTM, but I also left a comment with suggestions if you’re looking for other points to hit on.

It would be great for the accidentally-open status quo to get formalized.

I removed the post because it implied a position that i do not hold. This is a corrected post:

Of course, there is also another possibility that could be discussed: a clean-room reauthoring of the C++ Standard outside ISO’s framework. If the committee ever reached consensus that this direction was worth exploring, the C++ Alliance has the resources to support the effort. We hold no position on whether it should happen.

The idea is simple. " if " there is consensus for this direction, then the steps would be: 1. remove any comments from the clang front end which contain references to copyright standards material. 2. use source code analysis to reverse-engineer a standards document (this will of course be rough) 3. use that document as the starting point for a human-led review effort to make corrections. 4. Add missing sections using a clean-room approach.

This is a contingency - obviously, it would suck if it came to this. But I think the idea has merit even if not implemented.

9

Do you mean just referring to bits of the standard, like:

// C++17 [class.copy.ctor]p6:

or quotes from the standard? Either way, I think the answer is no. The former cannot be copyrighted, the latter should be OK under fair use assuming they are small quotations of only the relevant part (not entire pages of the spec).

I reached out to the SC22 convener for more information about this and he said that this is not something ISO is proposing; they’re only going after the documents listed in JTC1 SD23 (which is not open access, lol).

I ran into the issue of the lack of guaranteed open access while trying to create the Ecosystem IS. At one point I, and a coauthor, wrote our understanding of the importance of open standards here https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3339r0.html. I subsequently hit multiple walls in both WG21 and ISO legal in pursuing that route. But, yes, essentially open source tooling can only exist with open communication and open standards.

Righto, such clarity :smiley:

I spoke with the SC22 chair about this and have an update which I’ve incorporated into the RFC wording.

The documents in question do not include P-numbered papers as produced by WG21, but instead are for new project proposals (proposing a new TS or IS). P-numbered papers are never submitted directly to ISO, but their contents may be partially applied to a working draft and that working draft is what ISO asserts copyright over. So if WG14 (C) and WG5 (FORTRAN) switch to document handling practices like WG21 (C++), the LLVM community will continue to have access to feature proposals and issues lists. It is not a guarantee that these committees will change practices, but we have more influence over those committees because we directly participate and I believe they will be amenable to supporting open source communities. However, we still need ISO to agree to open access because we need access to those working and committee drafts, so this testimonial continues to be important for us and our downstreams.

I propose we ignore any specifications that are not universally accessible, now and in the future.

As a compiler dev I don’t want to need to be part of ISO to read their specs.

As a user I’m not going to code against a spec I can’t read.

So if ISO papers are public, cool, we can evaluate them on their merits. If they’re private, cool, we can ignore them entirely.

I claim this is the right stance to take as an open compiler project. ISO should continue to choose which papers they want disregarded as they see fit.