I view the situation slightly differently: we now have a few examples of business strategies which employ open-source as part of a freemium sales model or for strategic commoditization. Such businesses can identify the subsets of code which qualify for one or more of the software freedoms, i.e. they have already done the legal groundwork for source-controlled separation into different asset classes. A "marketing standard" for View Source would let them earn incremental returns on the already-cleared code.
Github would have a lot to gain from such a standard, as they are already in the code history and metadata business. It could be prototyped with a browser extension, prior to standardization. In time, businesses will care more about software supply chain transparency, for open and closed code. A "View Source" standard could optionally request authorization before the source is made visible, e.g. from a private Github repo. The value comes from the run-time coupling of source and behavior, and it can be derived from source anywhere on the licensing spectrum between proprietary and public domain.
> A "View Source" standard could optionally request authorization before the source is made visible, e.g. from a private Github repo.
Or they could make a protocol to select which version you want to see: the webm or the plain JS. No need to mix external websites like Github in the loop.
Github would have a lot to gain from such a standard, as they are already in the code history and metadata business. It could be prototyped with a browser extension, prior to standardization. In time, businesses will care more about software supply chain transparency, for open and closed code. A "View Source" standard could optionally request authorization before the source is made visible, e.g. from a private Github repo. The value comes from the run-time coupling of source and behavior, and it can be derived from source anywhere on the licensing spectrum between proprietary and public domain.