9 ms·

Im responding to this claim: "Proprietary software starts off with a high level of trust - trusting just one company. But it can never progress past this." It

Im responding to this claim: "Proprietary software starts off with a high level of trust - trusting just one company. But it can never progress past this." It's totally false. The evaluation side has been done more times than I can count. It doesn't even have to start with a single source. Many products started as a collaboration of multiple organizations checking each others work that share the result. Another model is CompSci inventing something with details open at the start, patented, and then turned into closed source product. Finally, there's Shared Source models where you can have, fix, or extend the source so long as you're paying. Burroughs B5000 (1961), first system resilient to 0-days, was distributed in source form to customers. You were oversimplifying proprietary systems then attacking that simplification.

mindslight 10y ago
I appreciate your historic perspectives, but it feels like we're merely quibbling over terms/framework on this one. I don't think I'm oversimplifying, more like it's current mass-oriented software that essentially falls into two basic camps, Free and proprietary, with various small tweaks to each model. For example, something like a mass-NDA for every user is going to fail for consumer-oriented software, whereas a company contracting a discrete number of external auditing decomposes into trust through branding. I'd love to find a commercial model that could work for consumer-oriented Free software [0], and I think it could sound quite similar to something you describe. It's just that those type of multi-party collaborations have been pulled into the attractor of free-as-in-beer, at least as far as the code itself is concerned. [0] I say Free instead of Open, because I can envision software lacking just FSF freedoms 1b and 3 could get stuck in a bad state as well. Like say everyone knows there is a bug and how to fix it, but is legally prevented from doing so.
- nickpsecurity 10y ago
  "but it feels like we're merely quibbling over terms/framework on this one. I don't think I'm oversimplifying" You were. You made a blanket statement about the whole, proprietary model. In recent comments, you've changed your statement to talk about how the model is applied in the general case. As in, popular implementations vs all implementations. I'll reply to the new comment anyway. "For example, something like a mass-NDA for every user is going to fail for consumer-oriented software, whereas a company contracting a discrete number of external auditing decomposes into trust through branding." That's basically what happened. It could go further where lots of users get the NDA with cross-checks but not mass on high-volume scale. It helps if the software is designed in such a way where it can be shown it doesn't manipulate the system. I once proposed memory safety, safe API use, and sandboxing as a start on that. Automated tools could assess those. One could go further with information-flow labels tracking confidentiality or integrity enforced by compiler, runtime, or hardware. A few CompSci projects do it but not mainstream. "I'd love to find a commercial model that could work for consumer-oriented Free software" They pay for it. Then they get it. The source is in a FTP server or something somewhere. Things like branding, enterprise features, and tie-ins keep them buying from original supplier. Been done in a few ways although always a risk of clones. "[0] I say Free instead of Open, because I can envision software lacking just FSF freedoms 1b and 3 could get stuck in a bad state as well. Like say everyone knows there is a bug and how to fix it, but is legally prevented from doing s" Dual-licensed (proprietary + GPL) covers this. A few, quick proposals follow on non-free trying to approximate free. One could do a shared-source license that allows bug fixes. One could allow redistribution of software to other paying customers. One could cap what's to be paid or for how long before what's purchased becomes perpetual. One can make it go FOSS if it's EOL'd or gets under certain amount of developer time/contributions (tricky measure). Recent proposal was time limit on how long a version or individual product would be paid with it going FOSS after that time limit. So, quite a few options here. One thing that's important to remember is that FOSS will always have a disadvantage over benign, paid model. The disadvantage is you can contractually ensure those being paid are doing support, bug-fixes, enhancements, pen testing, etc. They can also cover the pro's to do it right. They have lawyer money for patent trolling that will come their way. Combined with shared source like above, they might also get most or all benefits of FOSS with benefits of paid. It's why I'm highly interested to see companies experiment with hybrid models. A few have showed up here but nowhere near enough.

mindslight 10y ago

I appreciate your historic perspectives, but it feels like we're merely quibbling over terms/framework on this one. I don't think I'm oversimplifying, more like it's current mass-oriented software that essentially falls into two basic camps, Free and proprietary, with various small tweaks to each model. For example, something like a mass-NDA for every user is going to fail for consumer-oriented software, whereas a company contracting a discrete number of external auditing decomposes into trust through branding. I'd love to find a commercial model that could work for consumer-oriented Free software [0], and I think it could sound quite similar to something you describe. It's just that those type of multi-party collaborations have been pulled into the attractor of free-as-in-beer, at least as far as the code itself is concerned. [0] I say Free instead of Open, because I can envision software lacking just FSF freedoms 1b and 3 could get stuck in a bad state as well. Like say everyone knows there is a bug and how to fix it, but is legally prevented from doing so.

nickpsecurity 10y ago
"but it feels like we're merely quibbling over terms/framework on this one. I don't think I'm oversimplifying" You were. You made a blanket statement about the whole, proprietary model. In recent comments, you've changed your statement to talk about how the model is applied in the general case. As in, popular implementations vs all implementations. I'll reply to the new comment anyway. "For example, something like a mass-NDA for every user is going to fail for consumer-oriented software, whereas a company contracting a discrete number of external auditing decomposes into trust through branding." That's basically what happened. It could go further where lots of users get the NDA with cross-checks but not mass on high-volume scale. It helps if the software is designed in such a way where it can be shown it doesn't manipulate the system. I once proposed memory safety, safe API use, and sandboxing as a start on that. Automated tools could assess those. One could go further with information-flow labels tracking confidentiality or integrity enforced by compiler, runtime, or hardware. A few CompSci projects do it but not mainstream. "I'd love to find a commercial model that could work for consumer-oriented Free software" They pay for it. Then they get it. The source is in a FTP server or something somewhere. Things like branding, enterprise features, and tie-ins keep them buying from original supplier. Been done in a few ways although always a risk of clones. "[0] I say Free instead of Open, because I can envision software lacking just FSF freedoms 1b and 3 could get stuck in a bad state as well. Like say everyone knows there is a bug and how to fix it, but is legally prevented from doing s" Dual-licensed (proprietary + GPL) covers this. A few, quick proposals follow on non-free trying to approximate free. One could do a shared-source license that allows bug fixes. One could allow redistribution of software to other paying customers. One could cap what's to be paid or for how long before what's purchased becomes perpetual. One can make it go FOSS if it's EOL'd or gets under certain amount of developer time/contributions (tricky measure). Recent proposal was time limit on how long a version or individual product would be paid with it going FOSS after that time limit. So, quite a few options here. One thing that's important to remember is that FOSS will always have a disadvantage over benign, paid model. The disadvantage is you can contractually ensure those being paid are doing support, bug-fixes, enhancements, pen testing, etc. They can also cover the pro's to do it right. They have lawyer money for patent trolling that will come their way. Combined with shared source like above, they might also get most or all benefits of FOSS with benefits of paid. It's why I'm highly interested to see companies experiment with hybrid models. A few have showed up here but nowhere near enough.