| |||||||||||||
FreedomFreedomPosted Aug 26, 2009 15:56 UTC (Wed) by giraffedata (subscriber, #1954)In reply to: Freedom by sepreece Parent article: Devices that phone home
But I can definitely see free software advocates demanding that Red Hat at least provide support up to the point where the modification might reasonably be affecting something. That's a good point -- free software advocates might oppose the taint flag concept, as a something that reduces a person's freedom to modify software. On the other hand, the taint flag is a lot like the copyright reserved on GPL software: it reduces a recipient's freedom to redistribute code, but is considered pro-free-software in the balance because it tends in the broader picture to increase others' freedoms with respect to the software. Red Hat refusing to service modified (openly) software doesn't have that going for it.
(Log in to post comments)
Freedom Posted Aug 26, 2009 16:18 UTC (Wed) by smoogen (subscriber, #97) [Link]
Having tried to do technical support on these issues before they become expensive quickly. The only way to support them is on an hourly rate with some sort of growth curve on the pricing. The reasons are the following:
1) Replicate the build environment. I have dealt with patched software that shows some sort of problem that the unpatched software does not. More than half of the time the issue is not the patch itself but how the code was built:
2) Replicate the use. The other large case I ran into is where the software was changed and then used in some odd way that requires specialized settings for. [Oh its using IP->SLIP->RS232->RS422->Radio- to get its network stack.]
3) Poor quality patch or other practices. [Oh thats the patch on the net, I cleaned it up a bit before putting in on the machine... (after 8 hours of debugging)]
And while the number of people who end up in those categories are 'relatively' small.. you end up spending so much time and pulling in so many extra resources that its not cost effective in the end. [Unless you sell support via an insurance policy type model and the costing for that is actually a lot higher than what most customers want.]
Freedom Posted Aug 26, 2009 17:20 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
don't forget fun like specific models of hardware (I've had cases where one version of the e1000 quad card would work and another didn't)
or where the problem is load and timing dependant
even without modifying the code at all (and frequently even without recompiling anything) there are all sorts of ways for things to not work that are hard to duplicate.
Freedom Posted Aug 26, 2009 20:28 UTC (Wed) by giraffedata (subscriber, #1954) [Link] even without modifying the code at all (and frequently even without recompiling anything) there are all sorts of ways for things to not work that are hard to duplicate. Right, so to complete the idea: debugging is a system of gambling. You look at all the possible causes of a problem and attack them according to their relative probabilities and the costs of the attacks. Sometimes, a user modification is high on the probability list, so it makes sense to do something costly like have the user reproduce it on unmodified software or debug it himself or live with the problem. Other times, the nature of the modification (and credibility of the user who tells you what is modified, I might add) puts it way down the list, so maybe it makes sense for the analyst to take 10 minutes to try reproducing the problem on his unmodified system. But when an analyst just makes a blanket statement that he won't work on user-modified code, that can put a crimp in software freedom for no good reason. Having tried to do technical support on these issues before [I know] they become expensive quickly. The only way to support them is on an hourly rate ... There's nothing wrong with that, in terms of preserving software freedom. As long as you charge only for the time related to the user modification. If the bug turns out to exist in unmodified code and you didn't spend any time ruling out the user modification and all your normal tools worked in the debugging process, there's no call to charge the user more than you would have for unmodified code.
Freedom Posted Aug 27, 2009 3:09 UTC (Thu) by vonbrand (subscriber, #4458) [Link] Having tried to do technical support on these issues before [I know] they become expensive quickly. The only way to support them is on an hourly rate ...There's nothing wrong with that, in terms of preserving software freedom. As long as you charge only for the time related to the user modification. If the bug turns out to exist in unmodified code and you didn't spend any time ruling out the user modification and all your normal tools worked in the debugging process, there's no call to charge the user more than you would have for unmodified code. This is a nice theory, but if there are local changes, and the vanilla version (seems) to work fine elsewhere, logic says to check those changes first... if they turn out not be related to the misbehaviour, the work done ruling that out has already been spent. BTW, "software freedom" is not some kind of right you enjoy because you are breathing, it is something others worked hard to give. Please respect them, their wishes and their work.
Freedom Posted Aug 27, 2009 17:22 UTC (Thu) by giraffedata (subscriber, #1954) [Link] if there are local changes, and the vanilla version (seems) to work fine elsewhere, logic says to check those changes first... It's just not that easy. If the local changes are far removed from the area with the symptoms, it often makes sense to check something else first (actually next -- the first thing you checked was that the vanilla version seems to work fine elsewhere) -- if your goal is to minimize the total amount of pain for everyone. if they turn out not be related to the misbehaviour, the work done ruling that out has already been spent. This is consistent with my claim that it's OK (meaning doesn't reduce software freedom) to charge by the hour for work made necessary by the local changes. The user would pay for that work to rule out the local change. But not for anything else. BTW, "software freedom" is not some kind of right you enjoy because you are breathing, it is something others worked hard to give. Please respect them, their wishes and their work. Of course, but I don't see how this is relevant to this thread.
Freedom Posted Aug 27, 2009 17:54 UTC (Thu) by smoogen (subscriber, #97) [Link]
I think it comes down to usage of language without a physical medium to interpret intent.
My first interpretation of your postings language useage was that "Software Freedom" was an absolute right and that Red Hat, Novell, Canonical, etc MUST support any changes a customer makes to their code. That might not have been your intent, but it was how I (and possibly vonbrand) read it at first.
Freedom goes both ways. The companies could offer per hour support on changes, they are also free not to. There is nothing in the GPL which requires them to do so (even in the 3.0 versions).
|
|||||||||||||