Welcome to the Pypliner's Podcast, Episode 309, sponsored by Inter-SYS Corporation, providers of points, the pipeline operations excellence management system, compliance and operation software for the pipeline control center to address control remandagement, SCADA and audit readiness. Find out more about points at intersyscorp.com. I supported the industry through one of our authorized distributors for roughly 21 years, so one never thinks they're going to have a career in engineering standards or intellectual property, but yet here I am and I found myself doing just that. Ditto, I had no idea that's what I'd be doing, you know.
Of course my domain is a little different than yours, but there's probably more more similarity than there are differences. Sure, yeah, absolutely. A question I think a lot of people wonder about is why are the standards, you know, all the API standards copyrighted? That's a great question Russell, I really appreciate it.
API is not unlike any other standard development organization or national standard body. There are probably about a thousand around the world standard bodies that produce standards and copyright them. Part of it is obviously to protect the intellectual property itself, that derivative work products aren't created, that would certainly harm the integrity of the standards, but the other aspect of it is that the committee's invested a significant amount of time and we have over 7,000 volunteers that help to produce the standard and we want to make sure that these consensus based standards are used effectively, not just within the confines of the United States, Canada, and Mexico, but around the world. Yeah, I think the other thing too that people probably don't realize is just how many people are involved as paid participants.
Like what is the cost of putting these standards together is pretty consequential. What is the size of the API staff that works on standards? Well, the work on standards, wow, that's a really great, also another great question. There are at API, and again, this is just a rough number, there are about 250 individuals that work at API.
When you say that work on standards, all of our programs, whether it's the monogram program, the individual certification program, the engine oil program, training, all of these are all oriented around the standards themselves. When you talk about the development of the standards, there are probably 50-ish people that specifically are engaged or involved in the development and the support of the development of the standards. Then again, you have all these other programs that support the industry that again, circulate around the standards themselves. Yeah, I think also the APIs following the, you've kind of inferred this, but you're following a formal ANSI certified process, and there's cost associated with having your standards programs and your standards themselves reviewed by third-party auditors to make sure you're conforming to those ANSI standards for creating standards.
Yeah, and that's not trivial too. Right, right. So the way we would position it is we adhere to ANSI's accredited process. We ensure that they're recognized not just for their technical rigor, but also the third party accreditation, as you mentioned.
That process facilitates acceptance by state, federal, and increasingly international regulators to adopt those standards. Right, and then lastly, a lot of these standards actually require research in order to create the technical information or the technical knowledge to actually write the standards. And that's another part of the cost of doing all this. Well, yeah, exactly.
There's organizations that we contract to do either studies or research reports or testing, laboratory testing. So all of that kind of gets baked into the cake, if you will, regarding the standards process and committees and all such have budgets to operate from to ensure that we're developing products, products being standards, recommended practices, specifications that help industry do their business more effectively. Yeah, exactly. So it's easy to overlook, because when you're on the industry side and you're participating as an industry participant in writing the standards, it's easy to overlook what all is going on behind the scenes at API in order to put these standards together.
You become more aware of the work you're doing and less so aware of the work that API is doing. I don't mean that as a condemnation, it's just kind of the natural result of the process. So it tends to raise this question, right? Yeah, it's funny when we're talking earlier about the number of people that are engaged from API in the standards development process.
I mean, the end goal, so we have standards for upstream, midstream downstream and so on, and all of these volunteers that participate, but ultimately when we're producing a standard or a recommended practice or specification, the goal is to gain consensus, right? And that's that, to gain consensus means that there has to be cooperation, understanding amongst everybody and to drive towards a collective goal. And that takes effort, time, and exactly it takes research, it takes support. It's a really fascinating, it's not simply if you're just a consumer of the product and you're not really involved in the committee process.
There's a lot of effort that goes on behind the scenes to get it to its final goal and across the finish line, if you will. Yeah, if you're a member, if you're involved with the committee process, you tend to see the work you and your committee members are doing and not all the other stuff that's being done by API, right? I guess the point I'm making is that part of the reason for the copyrights is they can provide an opportunity for API to generate income and that income is used to underwrite that ongoing process, which is very much a non-trivial kind of thing. Right, and again, it's also about adoption not just here, but around the world.
I mean, if we can get adoption of those standards internationally, it helps our member companies do business internationally. It helps everybody that consumes the standard to ensure that there's interoperability, sustainability, safety, all of those elements. But part of our goal is to continue to drive towards international, not just here within the United States and Canada, but around the world, try and ensure adoption. It makes our business function better.
Yeah, being an engineer that's done a fair amount of international work over my career, it's always way easier when you go someplace and they're using the API standards. Exactly. Exactly. If they're using I so I get a little twisted.
So, yeah, so again, I'm really just trying to educate the listeners about the fly behind this why this material is copyrighted, really what goes on and so forth. So, probably everyone who listens to this podcast at one time or another is interacting with an API standard. What are the obligations of a user when it comes to using API standards and making sure we're doing things properly? Yeah, so we have authorized distributors all around the world and API, of course, sells our standards through our web store.
But around the world, there's different ways in which to consume the content. But mostly, the most important thing that a user can gather from this is when you buy a standard, there are certain obligations, relative to copyright that you need to be aware of. And of course, as we talk through this process, we just want to make sure people understand what how to use it, what they can do with it, all of the distributors and including API's website, when you purchase a standard, there's an end user license agreement, which basically explains what you're allowed to do and not allowed to do with the standard and always would recommend that when you print a standard off that you keep that with you because it helps you, it helps guide you in decision making and so far as how to use a standard. Well, I think there's a few kind of specific things I want to talk about around copyright.
One is fair use and what is that and what does that mean for a user? And then we've already kind of talked about the end user license and how it describes the obligations. And then the other thing I want to do is talk a little bit about those standards that are incorporated by reference into regulatory requirements. Sure.
Because that's a little bit of a different kind of thing, right? Yeah, yeah. So let's tackle copyright and fair use as a starting point. So again, going back to the end user license agreement, because I think this is really helpful and prescriptive, if you will.
When you buy a single copy of a standard, you're really just entitled to the single copy of the standard. How is delivered to you, whether it's in a PDF format or a paper format? That doesn't really change how you're permitted to use it. So you're allowed to have a printed copy.
You're allowed to have a backup copy of that document. So you could other printed copy, you may have an extra copy that you stick in a file cabinet and store it away. Should you destroy your what we'll call your use copy? In either scenario, PDF or paper, you're not permitted to put it up on a shared drive.
That's that would be a violation of copyright. Most people don't know that. So it's probably just good to be aware of that. If you need something in a more distributive fashion, there are options out there.
We can talk about that in a minute. Regarding fair use, it's a complex question. There's a lot of legal language and legal terms around the concept of fair use. I would always recommend and advocate if you have a question as to whether or not you can take a paragraph out of a standard and pop it into a handbook or a guide or something like that.
I would always recommend that you talk to whatever internal counsel relative to that, because that's really going to dictate how your company looks at the concept of fair use. There's terms like endominous and all kinds of fun things that, again, it's legal jargon that it's always good to have somebody help support that. On the other end of this equation, API, we have a relatively robust permissioning process because we always get questions from textbook manufacturers and people producing handbooks or marketing materials. Companies come to us and say, hey, I want to take this table or I want to take this section of the standard and I want to incorporate it into this other work.
So we do have mechanisms through our permissions or through our contractual process to help and support and assist in those endeavors. But regarding fair use, I think it always comes down to the business practice. Is it considered a fair and so far as business practice to take a piece of a standard and put it in something else? Again, just would refer you back to your own legal counsel.
I think it's always important. You and I had a conversation earlier and unfortunately people in the podcast can get to hear it. I always like to joke and say, if you're not sure, if you think that this should raise a question as to whether or not you're permitted or not permitted to do that, the answer probably is, you're probably not permitted to do that. So you just want to be careful and seek support and assistance.
Yeah, and I, again, for the listeners benefit, I asked them over the question, do you know the difference between research and plagiarism? And I told them that the difference is, research is when you take a little from a lot of places and plagiarism when you take a lot from a little place. That's kind of the difference between fair use and copyright violation. There you go.
I think that if you're using standards and you're paying for the use of the standard and you're using that content, and there is an expectation that you're going to use that content to inform policy procedure in your company around how you operate. So that can certainly be considered within fair use. And I agree with Mo that if you're not sure about what you're doing and how you're doing it, then your internal legal will be able to talk to that because you will have a company policy about all that. Yeah, and just to further extend the conversation a little bit, there are alternative ways.
We have ways in which to address various types of scenarios. We talked about permissioning, we talked about buying an individual copy. There's also subscription offerings, right? So you can subscribe to a standard, you can subscribe to a group of standards.
When you have a group of people within an organization that have a shared need for a set of content, generally the best solution is to seek out subscription services. That means that everybody can download a copy of a standard, everybody can have access to it. There's a platform that makes sure that the content is up to date. It does make life a bit easier.
The platform itself becomes the point of distribution. So rather than, again, in violation of copyright, putting something up on a shared drive, the concept of quote unquote a shared drive would be use the subscription platform as the way it's the mechanism, if you will, access the standards that are critical in your business. Yeah, and in that case, the right to use is for an organization versus a person. That tends to simplify things a lot, a lot.
You still have copyright obligations like I can't take it and hand it to my buddy over there at Acne Corp. But I'm, anyways, I think it's important that people kind of understand why and how. And then there's also the standards that are incorporated by reference into various regulatory requirements. I'm most familiar about pipeline standards.
I think the thing to be aware of there is those standards that are incorporated by reference are always a specific version of the standard. And often the standard that's incorporated by reference is not the most current version of the standard. Yeah, that's correct. I actually add some context to that.
So, again, talking about many multiple mechanisms. So, API has an incorporated by reference reading room. So, that's also available. And to your point, Russell, we've been encouraging regulators to advance that process, if you will, to move towards the more current standards and away from some of these historical standards.
And I know it takes a big effort on behalf of those regulatory bodies. So, I know it's no small task to do that. But we have, I think in federal regulations, again, just off the cuff, there's about 650 standards that are referenced. In some cases, you're going to find, you can find, depending upon who that standard, you might find multiple regulatory bodies, one pointing to an earlier edition and one pointing to yet an earlier edition standard.
So, you have, in some cases, the same standard being referenced and different additions being referenced. So, that's obviously something we want to help regulators, ensure that there's consistency. And then you've got the states, the states also incorporate API standards into their codes as well. So, there's about 3,800 API references in US states.
Well, and then you have other governing bodies outside of the US that incorporate those standards by reference as well. Yeah, we have, again, this is just off the top of my head. So, I apologize, there's about 30 countries that have incorporated API standards as references into their regulations. And so, that's, there's about 1,100 regulations internationally around the globe that, and again, we're continuing to encourage that, we're continuing to work with those organizations to adopt API standards.
Yeah, well, and that actually helps, that actually helps American business. It helps international business if we're all working against the same standards, particularly having a background in measurement and custody transfer uber critical in that domain, for sure. Well, we all know if anything happens anywhere in the world regarding the industry, everybody hears about it. So, it's important that you have standards and specifications with that level of technical rigor that improve safety, reliability, environmental protection.
The more people utilize these standards, the better off our industry is. Yeah, so, I want to talk a little bit more about mechanism. So, we've talked about print, we haven't talked about PDF, secure PDF, but both of those are really mechanisms for individual use. We've talked about subscription.
How flexible is API in terms of working with companies to help them utilize the standards and make sure that they're following those copyright provisions? Well, so it's an interesting question. When you say flexible, I kind of want to get a sense of, well, let me, let me build a little more context if I might. And I'll just kind of disclose to the listeners that Mo and I have been talking about a requirement that we have with one of our software products where we would like to incorporate the API standards into our software product, particularly around pipeline safety management, because there's a whole library of API standards that are referenced in the pipeline safety management standard.
So, we're asking some questions about, well, how does that fit for us? What I'm really trying to tee up for you Mo is for other folks that might have a need to use the standards and that need might be non-standard use, I guess, is what I'm driving at. How does API work with folks like myself and our companies to support the industry and to support what those organizations are trying to do? Yeah, thank you for the clarity.
I appreciate it. The way which we go about it today is we have different types of contracts, we're different types of use, right? So, we do have software agreements, we have companies that come to us and say, just as you have, we want to take API standards incorporated into our software, or in many cases, some of our standards are constructed in such a way that you could actually create a software application that is literally a reflection of the standard in and of itself. We do work with a variety of software companies to do that.
In fact, they're listed as authorized distributors on our website. We work with training organizations who have come to us and said, hey, we have some unique circumstances, we want to be able to have access to your standards and distribute the standards, sell them through our training platform. So, we do have, again, I hate to keep using the word, but mechanisms, but we do have tools and mechanisms, if you will, that allow for different types of use. Generally, when we have a scenario where software company is doing it, it's really a distribution contract.
It might be limited to certain set of standards, but that's a software combination with distribution. And our perspective is pretty straightforward. It gets a little more complicated. I'll give you another, for instance, we have a company that has doing validation slash verification of requirements, and they wanted to take a standard and incorporate it into some of this rules-based tool set that they have.
So, again, it was just a different use case that we worked to try and accommodate to give them additional support that they needed relative to the standards that we produced. But we do have ways in which to do that. Yeah. I think what's important for people to know is that API is going to try and work with you.
I mean, their interest is having people effectively use the content in order to deliver value to the industry. It's all easy until you know enough about it. I say that all the time. My wife has told me I'm going to quit saying that on the podcast, but in this domain in particular, sometimes what you're actually doing is pretty simple, but all the things you have to figure out in order to figure out exactly what you're going to do can get quite complex.
Yeah. That kind of leads right into, I think, the conversation around digitization, right? I think that's where I see things going in the not too distant future, because what we're seeing right now is a large percentage of engineers leaving the workforce retiring. So, the Vainty boomers are at that age.
And in fact, for many years now, it's not just our industry. It's so many other industries. The aerospace industry has the same issue. So, as engineers retire and younger engineers are coming into the workforce, you've got a couple issues.
One is knowledge harvesting, right? I'm not going to go down that path. There's how do you ensure that the younger generation of engineers has access to the knowledge base that's retiring. So, that's the first thing.
So, what you commonly see, the answer to that question is a lot of retirees have contracts after retirement where they support younger engineers. That's one way in which to help address that. But there's this question of how many young engineers are coming into any industry. There's a gap in so far as the numbers are concerned.
You have fewer people coming into engineering than are departing. And so, that gap has to be filled. And so, there's got to be technology advancements that help to drive where we're going as an industry. And ultimately, for all of our economies and global trade, this feels like a necessity to ensure that there's a continuance of growth.
So, technology is going to hopefully help fill that gap. Well, I think what I would say about my career as an engineer is I very much underestimated the importance of and the value of being able to read and write. That sounds kind of tongue-in-cheek. It's not really because being able to read standards and understand what they say, particularly when Standard A references standard B and standard B references standard C and standard C references standards E, F, and A.
Just being able to read and navigate all that and build a frame around it in your mind, particularly when it's new content. That is a very important skill. Technology is going to help us with that, for sure. AI, particularly generative AI, has a lot of promise in that domain in order to help you search through all the relevant standards and put together a narrative that distills it all down to something meaningful.
generative AI has a lot of promise in that domain. I'm sure there's copyright issues in that. We can't hold the pull the podcast down. We can do a whole thing on that.
I'll try not to go down that route. It's fascinating, right? If the machine takes a little from a lot of places, is that different than the person doing it? Exactly.
Well, like I said, how do you know if the machine is taking a little from a lot or a lot from a little? Right? So anyways, I think that's certainly one of the things that's going to help with. And then the ability to kind of move from narrative standards to usable standards or usable content that's derived from narrative standards is, I think there's a lot we can do in that domain to improve things.
Yeah, what we're seeing, and again, what I'm suggesting isn't necessarily a trend in the industry. It seems that there's a lot of exploration in requirements management. It necessitates two things from API's perspective. The first is that we have to adopt a different way of writing standards.
So when we talk about machine-readable content, we have to, we're going to be ingesting content into a platform again, very early in the stages. But if we're doing that, then we have to modify the way in which we write standards. Now we've been working on that. There's been an effort to adopt what's called the encosy methodology of requirements writing.
And we've adopted that. It's not a snap your fingers, and overnight all the standards are written with clear, concise requirements, clear, concise, and maybe the better word is standalone requirement. But over time, we're going to get there. But right now you've got a lot of organizations looking to figure out if requirements management is going to be one of those technical gap support systems that help bridge.
And to your earlier point about standard A, referencing standard B and C and all the way around, and you've got a cyclical referencing system where you have many standards referencing one another, the hope is that requirements management will assist with that. So in one... Well, being a guy who did requirements management in the space program many, many, many years ago, requirements management can create some process and structure about understanding very complex and related systems. But it doesn't minimize the complexity.
Sure, sure. But I think that it's an area that does offer some improvement because ultimately if you were just doing this in hardcopy or you were just doing this with PDF copies, there's concern, right? The concern is... Oh, right.
Having a structured approach, having information linked, being able to navigate it in different ways, all that's really critical for sure. And engineers have built up a knowledge base to understand the complexity of a system or a group of systems working together through their collective experience. And then you have a group of younger engineers coming into the workforce and they don't have that. And this is a way in which they can start to understand those complexities.
Yeah, absolutely. Well, I often ask myself in these conversations, what's my key takeaways? I guess in this conversation, my key takeaways are there's good and valid reasons why API copyrights is content. We, as users of that content, have an obligation to honor those copyrights.
And API is willing to work with you so that you can get done what you need to get done utilizing those copyrights. That's kind of my takeaway. How do you think I did? You just pretty well...
I really... Yeah, I mean, look, I've enjoyed this process. I've enjoyed talking to you. This has been a very relaxed conversation and it's fun for me.
I don't know that I was saying to friends and family, I'm like, I don't know how interesting this is going to be, but you've made it interesting. So I really appreciate that. Well, thank you very much. I mean, I'm a little weird.
I find this kind of stuff interesting and the passion for it does tend to come through. So I appreciate the feedback, Mo, and it's been a pleasure to have you own and have the conversation and I look forward to working with you as we go forward. Absolutely. And I want to say I share the passion and I share the passion for the industry that we serve.
I think we've got a fantastic group of people and I'm really happy to be where I am doing what I'm doing. It's an enjoyable opportunity and role. Thank you. I hope you enjoyed this week's episode of the Pipelineers Podcast and our conversation with Mo.
Just a reminder before you go, you should register to win our Customize Pipelineers Podcast Yeti Tumblr. Just visit pipelinepodcastnetwork.com slash win and end yourself in the drawing. If you'd like to support this podcast, please leave us a review on Apple Podcast, Google Play, Spotify, or wherever you happen to listen. If you have ideas, questions, or topics you'd be interested in, please let me know either on the Contact Us page at pipelinepodcastnetwork.com or reach out to me on LinkedIn.
Thanks for listening. I'll talk to you next week.