[Top][All Lists]

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

Re: LGPL vs. GPL

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

Ciaran O'Riordan <> wrote:
> JohnF <> writes:
>> "let the best program win."  If the commercial application is
>> truly better, maybe its superior functional specifications will
>> inspire an open source "knock off."
> It might, but it's predictable that the developer of the proprietary
> application will try to make life as difficult as possible for any computer
> users who want to migrate from the proprietary program to the free software
> "knock off".
> Even if the free software application ends up technically superior, society
> will be stuck using the inferior proprietary application.  Maybe because
> their data will end up in some undisclosed format.  Maybe because the
> proprietary developer will patent some functionality and legally block the
> free software developer from implementing an equal feature.  Maybe they'll
> use the DMCA, maybe DRM, ...

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
That was a general remark meant to cover all the specific tactics
(and, I'm sure, others I'm not even aware of) that you mentioned
above.  Or maybe I'm missing some other issue you're addressing
and that's just going totally over my head.

> It also puts users in the position of wanting to use the software, but never
> being able to see what it's actually doing.  (This is in my mind because
> Slashdot featured a story today about some company that's making software
> for journalists to bypass China's Internet censorship - and I'm amazed
> because I don't see the source code anywhere.  How does anyone know what the
> software is really doing?  It could be from the Chinese government.  Or if
> this version really is good, the next version might not be, but no one can
> check.)

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.

>> If that doesn't happen,
>> then the superior commercial application has every ethical right
>> to dominate the market if users are willing to pay the price
>> (dollar price as well as closed source price).
>> And is slowly becoming a viable open source
>> "knock off" alternative.
> I think it's been capable of doing what 99% of people want already for the
> last few years, but people are stuck with MS word because MS have leveraged
> the software to gain control over the software users' data.
> To let the best program win, the users have to be in a free position to
> choose between the available options.  Among free software applications,
> this is usually assured (or at least, it's guaranteed to be possible).  When
> software that resepects users rights has to compete against software that
> tries to control users, the free market then fails to give people "the
> best".

I think we've already agreed (as per my self-quote above)
that certain tactics used to curtail competition are unfair,
including proprietary formats that intentionally hold user
data hostage.
     I also think your additional argument, where we disgaree,
is that a program author who chooses not to release his source
code is also holding user data hostage.  However, to my mind,
as long as the author doesn't patent/whatever any data formats
(which might prevent user data -- which I agree should be owned
by the user -- from being imported and used by other programs),
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).

>> That decision is legitimately made by the copyright holder.
> Legally legitimate, yes, just as existing import laws make it possible for
> me to go into certain shops in my developed country and buy the produce of
> child labour.

Let's please not drag that false "child labor" argument into
this any more.  Granted, child labor is a problem, but if
that's what's on your mind, a gnu newsgroup isn't the place to
discuss it.  Besides my previous remarks, children from countries
with child labor problems aren't typically well educated enough
to be writing software in a sweatshop.  At worst, maybe children
are working in a paper mill producing the cardboard that copies
of Vista are packaged in.

> Whether these things are ethical is another question altogether.


> [snip: mail by company claiming to be helping schools]
>> The writer goes on to request permission to distribute mimetex outside
>> the gpl.  What the heck am I supposed to do in a case like this?
> That's a tough one alright.
     That's why I picked this guy to make an example of.
     And, hey, in addition to "helping schools", don't forget
     the additional emotional tug on your heartstrings that
     he's helping "chronically and seriously ill children."
     I did do a few google searches on this guy, and he indeed
     seems to be involved in a school-related enterprise,
     but I couldn't unambiguously determine whether he's
     more interested in helping children or helping himself.
> Unfortunately, businesses are very good at selling petrol-guzzlers as "green
> cars", or equally-addictive cigarettes as "light", or sugar bars as "health
> food", or litigation companies as "innovation drivers", etc. etc.  When
> someone says they're helping schools, but refusing to let the schools see
> what the software is doing or make copies, it's very difficult to discern
> whether this is really a society-improving company or if they're just
> another company trying to control a market and coldly using all available
> communication means ("we're helping kids") at their disposal.
> If the company were releasing their software as free software, it would be a
> lot easier to believe that their work really is aimed at helping the schools
> that use their software.  By keeping the software proprietary, they're
> probably making the school dependent on their company (maliciously or not),
> so it's hard to judge this proprietary software company's true intentions.
>> 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.
> Maybe it's easy for me to say, since I haven't been put in that position,
> but one simple answer that leaves you out of the loop would be to tell them
> that it's GPL'd, and that they can avoid all compatibility problems by
> making their software GPL'd too.
> To personalise it, in the helping-schoolkids example, you could also note
> that by GPLing their software, they'd be allowing schools in Africa, South
> East Asia, and other poor regions to benefit from their software.

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 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.
     That is, anyone emailing a gpl author for a license waiver
would have their email forwarded to, with the
author's agreement that they'd make the waiver decision.
Moreover, maybe fsf could charge some nominal fee to the requestor
for this service, and obtain some small revenue from it.
     I, for one, would be delighted to agree to this arrangement.
These kinds of emails are just a pain in the neck for me,
and (as you've hinted at above) I'm not competent to deal
with them, anyway.
John Forkosh  ( mailto:  where j=john and f=forkosh )

reply via email to

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