JohnF <[EMAIL PROTECTED]> writes: > I thought I'd already acknowledged that class of problems in a > preceding post in this thread (quoting myself) ... > "Of course, I do condemn big companies, like, sometimes, MicroSoft, > when they try to dominate the market by choking competition rather > than by developing superior applications. That's a whole different > story."
You got me :-) I was suffering a lack of imagination with my examples in the last email :-/ I think I've listed a better variety of problems below. > Well, we all use products whose manufacture, and often ingredients, > are "trade secrets", not revealed to the end user. If you don't > like that, then don't use the product. Or, if you feel that, to you, > the benefits of the product outweigh any negative aspects, then > go ahead and use it. Your choice. I don't think this idea of handing all responsibilities to the buyers/users is good policy for software. I think it should be legislated against, like it was in the food industry. Food developers used your argument when mandatory labeling was first proposed. Governments decided that, in the public's interest, it was better to legislate a public right-to-know what ingredients, including their rough amounts for macro ingredients and exact amounts for micro ingredients, were in food products. Software users not knowing what's happening inside the software they use leads to many problems: * Most people are using software which is invading their privacy (usually without the user being aware) * Users, or third-parties, cannot check the security of their software * If bugs, including security problems, do exist, users have no power to to anything about it, other than ask the original developer * Data is being saved in a format that the user cannot understand, and which can be difficult or impossible to get raw data back out from if you want to move to another application * If a small change is needed to make someone's life easier, or if a certain feature is needed, users are powerless to improve their situation I don't think software users consciously weighed up these problems and decided that the software they use is still worth using. In the mean time, while there is no legislation to protect software users, we rely on software developers to voluntarily solve these social problems by releasing their software as free software. > then there's no hostage situation. Other authors can write > new programs that reimplement the old format, or that import data > from the old format to some new format (or both). Big examples where this has proved to be a monumental amount of work for imperfect results include Samba, OpenOffice.org, and Gnash. Of course, to give well-known examples, I've had to pick examples involving anti-competitive megacorporations, which you've agreed are a pain. To give examples not involving such companies, people won't recognise the names, but it happens. For example, a music notation program that a friend uses. It's proprietary, and my friend finds using that program a real frustration, but his data (gotten from friends) is in that program's format. Other programs exist, and maybe the data format isn't so complicated, but it's just a small software package for a small number of hobbyists. No one's going to hire the necessary programmer to do this task of decoding the format so that a converter can be written. If that software was free software, someone could write a converter a lot easier (they might even be able to simply re-use a lot of the code), so someone might actually do it. Or someone could make the original application less frustrating. > Let's please not drag that false "child labor" argument into It was meant as an example of why putting all responsibility with the buy/user isn't always a good policy. ...but I think the food manufaturers example is better anyway. >>> But it would be really nice to >>> have a more straightforward procedure for dealing with these kinds >>> of situations, especially a procedure that leaves me out of the loop. I thought of another one: assign copyright to FSF. If you do this, then when someone emails you asking for an exception, you can just tell them that FSF holds the copyright and they should ask FSF if they want an exception. Information about this is here: http://www.gnu.org/licenses/why-assign.html http://www.gnu.org/licenses/gpl-faq.html#AssignCopyright http://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html > My thought about this is that, besides the gpl, perhaps the fsf > could draft an optional agreement whereby authors of gpl'ed > software agree to let [EMAIL PROTECTED] determine whether or > not any specific request for a "gpl waiver" is or isn't legitimate, > and is or isn't in the best interests of the community. Copyright assignment to FSF would do this. I imagine the result would be that they would refuse almost all requests for exceptions, and you might not get a say in the decision, so it's not precisely the solution you're suggesting, but it would relieve you of this work. You could mention on your website or documentation that FSF is the copyright holder, and that anyone with licence questions should go straight to FSF. Then you would get fewer emails to start with, and the few you get could be simply ignored and passed on to FSF. -- CiarĂ¡n O'Riordan, +32 477 36 44 19, http://ciaran.compsoc.com/ Support free software, join FSFE's Fellowship: http://fsfe.org Recent blog entries: http://fsfe.org/en/fellows/ciaran/ciaran_s_free_software_notes/using_latex_to_make_pdf_documents_with_japanese_characters http://fsfe.org/en/fellows/ciaran/ciaran_s_free_software_notes/links_sean_daly_kde_swpat_chessboxing http://fsfe.org/en/fellows/ciaran/ciaran_s_free_software_notes/links_india_pats_clipperz_freegis_rms_emacs http://fsfe.org/en/fellows/ciaran/ciaran_s_free_software_notes/using_and_writing_emacs_22_input_methods _______________________________________________ gnu-misc-discuss mailing list gnu-misc-discuss@gnu.org http://lists.gnu.org/mailman/listinfo/gnu-misc-discuss