3 ms·

> That’s not a bad idea. You already have basic E&O, but that is kind of a “broad brush.” I feel dumb, but could you tell me what "E&O" means? > That could co

> That’s not a bad idea. You already have basic E&O, but that is kind of a “broad brush.” I feel dumb, but could you tell me what "E&O" means? > That could cost you customers. I know the corporation that I worked at, would never agree to it. They were quite tinfoil about IP. They owned a ginormous patent portfolio, and were quite secretive in their processes. They would insist on keeping the source completely proprietary. Yeah, I thought that might be the case. I'm okay with that. The FOSS part is because I don't believe that customers should be in be dark about anything regarding my software. It would be like an architect not giving the plans to a building to the customer. Not professional, in my opinion. Of course, to satisfy customers like the ones you mentioned, I could just give them the source. I guess this is one point where my personal preference overrides because I believe in FOSS. To satisfy customers like that, however, maybe it would be enough if no one knows they are a customer of mine? No idea. Anyway, I'm okay with losing customers like that; I don't think I would need many customers to pay the bills. > I know that you are basically selling a personal guarantee, which is an idea I could stand behind, but that is still an individual attribute, as opposed to a standard industry one. It could be a potential personal selling point, and a competitive advantage. > The real goad would be an industry-wide need for it. Basically, established precedent for suing developers (and distributors) of bad software. > That’s a pretty classic Damoclean sword. Lots of claymores, buried, there. I agree that it needs to be an industry-wide thing. I hate the fact that EULA's basically disclaim all liability. (I'm okay with FOSS software disclaiming all liability because they don't know who is using their software, and it might just be a weekend project. Actually, my FOSS licenses disclaim liability too, so customers would actually be paying for me claiming that liability again.) But here's my hope: I hope that by doing this, and gaining a competitive advantage with it, other companies would either start to ask for it, or demand it, from their vendors, or start to do it for their software to gain a competitive advantage. In other words, I hope that I can get the ball started rolling towards becoming an industry standard. That's partly why I wrote my process down in such detail: so the industry could start to converge on standard processes like the engineering world. (Don't get me started on Agile or any of the other current "industry standard practices." Their foci are in entirely the wrong place, in my opinion.) Edit: Anyway, you're right: lots of claymores there. I need to carefully define the limits of my liability with a lawyer.

ChrisMarshallNY 5y ago
> could you tell me what "E&O" means? Errors & Omissions business insurance. Basically goof-proofing. I keep it, even though I don't really do contract work for others. As a contractor, I'd consider it an exception to not provide full source (and proof of provenance). Yeah, like so many of these things, having working prototypes out there, is one way to set an example. 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.
- ghoward 5y ago
  > 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?
  - ChrisMarshallNY 5y ago
    > 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. I write about "concrete galoshes," here: https://littlegreenviper.com/miscellany/concrete-galoshes/ https://littlegreenviper.com/miscellany/concrete-galoshes/

ChrisMarshallNY 5y ago

> could you tell me what "E&O" means? Errors & Omissions business insurance. Basically goof-proofing. I keep it, even though I don't really do contract work for others. As a contractor, I'd consider it an exception to not provide full source (and proof of provenance). Yeah, like so many of these things, having working prototypes out there, is one way to set an example. 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.

ghoward 5y ago
> 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?
- ChrisMarshallNY 5y ago
  > 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. I write about "concrete galoshes," here: https://littlegreenviper.com/miscellany/concrete-galoshes/ https://littlegreenviper.com/miscellany/concrete-galoshes/