[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LGPL vs. GPL
Re: LGPL vs. GPL
Wed, 06 Aug 2008 12:44:15 +0100
Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
JohnF <firstname.lastname@example.org> 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
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:
> 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@example.com 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:
Re: LGPL vs. GPL, Ciaran O'Riordan, 2008/08/05
Message not available