> Errors & Omissions business insurance. Basically goof-proofing. I keep it, even though I don't really do contract work for others.
Ah, that is good to know. I will need that for sure.
> As a contractor, I'd consider it an exception to not provide full source (and proof of provenance).
Question: does a full git repo provide proof of provenance? As in, if a repo has no dependencies, and the git history shows that you personally wrote every line, does that work as proof of provenance? I think it does, but you seem to know your stuff.
> I'm always leery of licensing requirements. I think it depends on the application.
> I do think that supply-chain dependencies should have some form of assurance, but I don't think we should expect to have a full license requirement for a brand-fluffing app.
I'm not sure what you are trying to tell me here. Could you clarify?
> Question: does a full git repo provide proof of provenance? As in, if a repo has no dependencies, and the git history shows that you personally wrote every line, does that work as proof of provenance?
I would think so. You could always simply copy-paste from "unwanted" sources, but having a Git repo, with full history, goes a long way towards proof of ownership. It can also help with justifying billing (some people bill by tasks, such as bug-fixing, or adding features).
> I'm not sure what you are trying to tell me here. Could you clarify?
I think that "supply chain" dependencies (like standard SDKs and libraries that are used as a "baseline") are juicy hack targets (think SolarWinds).
I would like to think that these types of dependencies should be held to much stricter standards than maybe a dancing cat animation.
Of course, there's that whole "blurry line" thing. A device SDK might not be used by many folks, but every person that has one of those devices, would use it. If the device were some kind of forensic tool, or bespoke military gadget, then that seldom-used SDK could be a rich target. You'd want it held to the same standards (or higher), than a C compiler or encryption library.
But people that like to license, want to license everything. They would insist on holding cat animations to the same standards as nuclear launch key crypto. I've seen this in action. People like that, almost stopped all productive work at a company I worked at. I won't go into details, but it's a very real problem, when you start to have industry standards and gatekeepers.
Software needs to be flexible. It's very, very difficult to have flexibility and Quality shacking up together. In the company I worked for, the hardware people insisted that flexible software was automatically "bad quality," so we were forced to apply rigid hardware development methodologies to software development; with ghastly results.
That post is excellent and is now in my bookmarks.
I'm glad I asked for clarification because when you mentioned licensing, I first thought that you meant things like software licenses. Now, I know you mean things like engineer licenses.
Up to this point, I personally would like licensing, but only for the most critical projects, such as avionics, nuclear power plants, crytography, and perhaps even foundational projects like compilers. But only those things.
So I am glad you made me aware that people who want licensing tend to go overboard with it. That means I will need to reconsider my position. I wonder how the engineering world has solved that problem, or if they even have.
> I think that "supply chain" dependencies (like standard SDKs and libraries that are used as a "baseline") are juicy hack targets (think SolarWinds).
Yeah, this is one reason I wiped all outside code from the repo where I am building my software. [1] [2] [3] [4] [5]
> Software needs to be flexible. It's very, very difficult to have flexibility and Quality shacking up together. In the company I worked for, the hardware people insisted that flexible software was automatically "bad quality," so we were forced to apply rigid hardware development methodologies to software development; with ghastly results.
I think that this can be done with good design, which is the reason why my Design phase part of process is so long.
I have many reasons to think so, but a good intro to my thoughts is "Constraints Liberate, Liberties Constrain" talk by Runar Bjarnason. [6]
Of course, this only goes so far, but I have found it works in practice.
A good example is the bc/dc I wrote. I constrained its behavior a lot with assertions and maintaining the assumptions that the assertions test. I also implement a lot of the code with respect to constant data, i.e., I use constant data to define the behavior of code. (An example of this is the list of bc keywords, or the translation between characters and dc commands.)
The end result is actually a program that is fairly easy to extend: I simply relax the assumptions or change the constant data, with some exceptions where extension is harder because of bad design, like [7].
Nevertheless, you are completely right: software needs to be flexible, and flexibility and Quality often hate each other. Maybe that's what makes software a harder thing to get Quality out of than hardware, or architecture, or engineering?
The tower collapse in Miami is a prima facia example of the need for credentialed engineering. In some countries, every time they have a 4-richter temblor, buildings fall like dominoes, and people die all over. These are usually nations with lax and/or corrupt engineering culture, while Tokyo can take a 6, and people just pick up the glassware, and carry on.
I remember that story about the engineer in Oregon that was fined for claiming to be an engineer, without a license.
That was ridiculous (especially when you consider that there's a rather ... large ... corporation that has huge plants, all over Oregon, filled with uncredentialed "engineers").
Ah, that is good to know. I will need that for sure.
> As a contractor, I'd consider it an exception to not provide full source (and proof of provenance).
Question: does a full git repo provide proof of provenance? As in, if a repo has no dependencies, and the git history shows that you personally wrote every line, does that work as proof of provenance? I think it does, but you seem to know your stuff.
> I'm always leery of licensing requirements. I think it depends on the application.
> I do think that supply-chain dependencies should have some form of assurance, but I don't think we should expect to have a full license requirement for a brand-fluffing app.
I'm not sure what you are trying to tell me here. Could you clarify?