[COFF] Re: Commonality of 60s-80s Print Standards

[segaloco via COFF <coff@tuhs.org>]

> > Am I getting into apples vs oranges here?
> 
> 
> Yes. In some areas (such as crypto, whence I came), if you did
> not follow the standards, then you would not interoperate. There were
> no testing labs for compliance (as there was for FIPS, for example).
> I recall compliance tests for ANSI C but that stopped with the
> adoption of ISO C (if my aging memory is correct).
> 
> S.

Okay I think it's making sense to me now.  So the apples of programming standards would come down to:

    - If you want to advertise/contract for interoperability with standards-compliant components, then your component must likewise adhere or you are lying to your customers and liable.
    - Otherwise, if you just want to push something but don't want to pad your market performance with attracting vendors interested in said interoperability, you're free to do so and don't face legal ramifications, you're just selling what could be assessed as a sub-par product, but you're within your legal right to do so as long as you don't suggest otherwise.

Whereas the oranges of EPA standards I'm trying to compare it to are:

    - If you want to produce legal regulatory information that can be used in EPA-related disputes, you must adhere to these legally binding regulations put out by the EPA.
    - You can tell someone yeah I'll test your water for lead, but if they intend to use that number in litigation, a formal environmental survey, or some other legally-binding case, then you're held to the higher standard.  In this case the particulars do matter because you're not selling a random product on the market, you're specifically selling regulatory acceptability as a factor of the product.

I presume the only situations then where adherence to a programming standard by ANSI or another body could actually play some legal role in their operation are either:

    - The vendor is under contract to ensure the product they're producing is conformant (i.e. USDoD requiring NT to present POSIX calls)
    - The vendor cites the standard in published material as applying to their product

But in both cases their due diligence is to prove that they're meeting the standards *for customers that expect it* not that there is any legal requirement that they do this in absence of said expectation.

- Matt G.

P.S. I'll disclaim for anyone that answers that I'm not seeking legal advise by the way, I don't want anyone to feel like they're under the microscope on this :P  If the day comes I'm citing COFF in a court of law I'll just try and fly to Jupiter because bizarro world is probably upon us.