On Tue 30 Jun 2009 10:04, Richard Stallman pondered: > > Portable hand held medical devices - such as Glucometers. They fall > into both categories. They are medical devices, who's "bad" > software could cause a user to give them selves too much insulin > (hypoglycemia -> pass out -> seizure -> death), or too little > insulin (Hyperglycaemia -> stupor -> coma -> death). > > That would be a good reason for the user not to change the software in > this device. However, that does not mean he should be stopped.
The FDA disagrees :) They add requirements to ensure they detect faulty devices. It is a fact of physics that flash devices go bad over time - I'm sure even you appreciate the ability to know if something in your devices is the image that you thought it is, and doesn't have bit errors. When they FDA certifies a device, they need to make sure that both hardware and the software on the unit when it gets to you - is the same as the version that they approved. If hardware can go wrong - there are normally power on self checks that test for this - and the unit will not power on if it detects the hardware is modified. > After all, the user could also change the circuitry in the device, if > he is inclined to do so. That too could make it give bad readings. It is not likely that the user has a the equipment to do so - it's not practical to think so anymore. All the "circuitry" are integrated circuits. There are very few (none) external components to modify. Test strips are connected directly to the measurement IC, and the measurement IC is connected directly the the processor. www.analog.com/AD5933 To make any meaningful modifications (which doesn't just remove a power supply, and cause the unit to die) starts out with a plazma etch machine - not exactly something most people have access to. (Here is one for $10k if you want)... http://www.2spi.com/catalog/instruments/etchers1.shtml Yeah, you could make your own fuming nitric acid on your stove, but that is even more over the top - plus - most fuming acids reacts with exposed bond pad metallization and normally result in ball bond discontinuity - hampering any further analysis, and making the device stop functioning... I don't recommend it. > So what? We do not need a nanny state stopping people from going out > of their way to take risks. Warning them is enough. Then solve it through the legistation process - don't debate with developers. The Federal Government (in the US) gave the FDA the requirement to do this in Federal Food, Drug, and Cosmetic Act (FD&C Act) of 1938 (amended since) - when people were accidently putting poisonous solvents in an "Elixir". http://en.wikipedia.org/wiki/Elixir_Sulfanilamide I'm glad they are there. When you go to Trader Joe's in Cambridge (or where ever you go for sustenance), Are you OK with the "nanny state" ensuring the food is safe to eat? > They are marketted, and purchased by end consumers (Amazon shows > 115 results in their search), and I would think that would make > them fall into the "User Products". > > These are indeed User Products, and the user who buys them should have > control over what they do. That "nanny state" government that we live in - says otherwise. Maybe I'm not fully understanding your position or what the intent of the GPL3 is - but it appears to me that there is a gap between the certification required in some markets/products, (and how people apply these certifications), and the rights given to end users under the GPL3 that make them not compatible. If a product is required to be locked down by a certifying authority, (whom ever that may be), they can't use GPL3 code. Your statements appear to me (to paraphrase) - those not willing to follow your rules should not have access to your code. And I'm completely fine with that. We contribute to various FSF projects that are under the GPL3 without any issue. What I don't understand is the fact that the GPL3 seems to punish developers who are developing products for certain markets when their certifying authority (like the FDA) has requirements which are not compatible with the GPL3. This really has nothing to do with tivoization, since in the Tivo case - they had no greater certification authority - and were just trying to restrict people's use. > I hope that you can respect my choice - and not try to convince me > or others that your choices are superior to mine. > > If your mind is made up, I will not pointlessly annoy you by trying to > convince you. I will continue trying to convince others. That is great - and I applaud your efforts. I think that the work you are doing is valuable, and the contributions you have made have been critically important to the free and closed software developments that people to today. But attempting to convincing other developers your rules are the best, without providing the pros (more freedom for end users) and cons (developers of certain products/markets which have requirements contrary to the requirements of the GPL3 will be excluded from using future versions) seems to be a little duplicitous. There is little a developer can do about changing the requirements of the FDA. Maybe you should be working with these types of certification authorities, rather than individual developers? You have a much more recognised name than most of the people on this list - I'm sure that you could get a meeting with Ms Hamburg or Aneesh Chopra before I could - and would have a bigger impact too... http://www.fda.gov/AboutFDA/CommissionersPage/default.htm http://www.usa.gov/dotgovbuzz/0509.html#dotgovspotlight > In 1983, almost everyone thought my ideas were foolish, but I did not > let that stop me, so now we have the GNU/Linux operating system. I never said your ideas were foolish - I don't think I even implied it. I wouldn't contribute to free software projects if I though the concepts were flawed or foolish. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
