3 ms·

Those aren't manufacturing defects. They are all changes of dependencies that should be made clear in the contract anyways. I have to admit that i am not too f

Those aren't manufacturing defects. They are all changes of dependencies that should be made clear in the contract anyways. I have to admit that i am not too familiar with how Linux versioning works (more of a windows environment guy), but if I buy software that was developed for windows 7, that stops working on windows 10 then it's obviously not a manufacturing defect. That's me changing to OS to a none supported one. I believe that "System Requirements" is a fair section for software to have. And assuming that i was informed before hand that the software depends on Twilio API version X.Y i won't see those changes as a manufacturing defect either. In my opinion, manufacturing defects are things such as: - the software corrupting data during normal operation - the software behaving differently than specified in the documentation - the software not handling edge cases correctly > easy to use extensible API for all SMS providers Don't ever use that language within your technical/legal documents. It's fine for marketing, but when it comes to specifications always be specific. If you write something like this, but not what Providers/API in particular you are using/offering then don't be surprised if I am annoyed when your software stops working. After all I literally had no way of knowing what you supported, you didn't give me that very specific information.

mbesto 4y ago
I don't understand why you responded to those two specific examples, I simply made them up because they were two plausible cases for "the environment changes and your contract needs a whole bunch of if/then statements to allow for them under the rules you've created to be successful and find so simple". I'm still amazed your not getting the point yet, which is: - Think really hard about every possible permutation license software could encounter and then multiply that by 100x and that's how you would need to structure this imaginary contract you keep referring to. - Said contract would be expensive and require a very technically knowledgable lawyer (see my reference to Google/Oracle which you conveniently glossed over). In case you are unaware: https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_.... It's mind boggling to me that software developers (which, based on your language, I presume you are) understand the intricacies and complexities of software development, yet are so hand wavy about the realities of busy "see its just so easy...".

mbesto 4y ago

I don't understand why you responded to those two specific examples, I simply made them up because they were two plausible cases for "the environment changes and your contract needs a whole bunch of if/then statements to allow for them under the rules you've created to be successful and find so simple". I'm still amazed your not getting the point yet, which is: - Think really hard about every possible permutation license software could encounter and then multiply that by 100x and that's how you would need to structure this imaginary contract you keep referring to. - Said contract would be expensive and require a very technically knowledgable lawyer (see my reference to Google/Oracle which you conveniently glossed over). In case you are unaware: https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_.... It's mind boggling to me that software developers (which, based on your language, I presume you are) understand the intricacies and complexities of software development, yet are so hand wavy about the realities of busy "see its just so easy...".