gnu-misc-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LGPL vs. GPL


From: JohnF
Subject: Re: LGPL vs. GPL
Date: Wed, 6 Aug 2008 17:01:34 +0000 (UTC)
User-agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (NetBSD/4.0 (i386))

Ciaran O'Riordan <ciaran@fsfe.org> wrote:
> JohnF <john@please.see.sig.for.email.com> 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.

Well, software doesn't have to be free to protect users from
these kinds of problems, just open -- or visible -- source.
But, as I suppose the usual argument goes, legislating that
publicly available software must be open source might
have a chilling effect on developers which could outweigh any
perceived good.  There's always some kind of tradeoff like
that, which can't be quantitatively predicted before the fact
(i.e., before legislation is passed and its actual effects
observed).
     Food is an extreme example, since that can literally
affect your health, e.g., if you're allergic to peanuts and
a "closed ingredient" product is prepared with peanut oil.
Software can also affect your well being (and I've seen
Inside Risk columns where bad software has indeed killed
people), but its ill effects are typically more benign
than food.  Therefore, the "chilling effects" argument
gains some additional merit relative to the ill effects.
Where it all balances out is, again, quantitatively
unpredicatble before the fact.
     But one thing's for sure.  If I, as a completely
uncompensated developer of free software, am ever told
that there now exists legislation which potentially
subjects me to civil or criminal penalties if my
free and uncompensated software fails to comply with it,
then that'll have a chilling effect on me.  For sure!
     Commercial developers are probably a different
story.  So are my own contract programming assignments,
where all my code is a "work for hire" and owned by
someone else -- I've got no problem with that, and
I have errors and omissions insurance in case I mess up.
But I ain't paying for insurance to cover damages
from uncompensated free software that I write.
Right now, the gpl covers that for me, but that
"coverage" disappears if legislation intervenes.
So any legislation should clearly distinguish these
cases.  Similarly, "good samaritan" laws already exempt
well-intended (and uncompensated) bystanders from
unintentional ill effects of their attempts to be helpful.
     I don't see fsf/open/free advocates demonstrating much
sensitivity to these kinds of issues.

>> 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.

It's a complicated issue.  All non-trivial programs have some
kind of non-trivial data structures/formats/whatever.
If those formats are commensurate with the complexity of
the task performed, then that's not an ethical issue.
Hard tasks are going to be hard to program, and hard to
re-program.
     The only issue I can see is when formats are intentionally
made unnecessarily complicated with the specific purpose of
locking users in to a particular program/vendor.
And that'll be tough to legislate.  It's kind of like that
US Supreme Court remark on pornography: I can't define it,
but I recognize it when I see it.

>>>> ... 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.
> <<snip>>

Yup, copyright assignment is definitely a complete solution
to that problem (except for referring requests to the fsf,
which is simple enough that it wouldn't bother me too much).
Thanks for pointing that out to me.  I'll definitely keep
it in mind.  For now, my gut reaction is to keep (copyright)
ownership of my own uncompensated work.  I suppose that's why
I (maybe unconsciously) conjured up a slightly more complicated
procedure that accomplishes approximately the same thing without
copyright assignment.
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )


reply via email to

[Prev in Thread] Current Thread [Next in Thread]