Re: [Fresco-devel] Re: ACE

>>>>> "M.Evans" == M Evans <[email protected]> writes:

    M.Evans> This API question only becomes a problem if MegaCorp
    M.Evans> contributes code.  And you can always reject their
    M.Evans> contributions.
        
    >> Right. However, we would like to accept their contributions, wouldn't
    >> we ?  In that case, what's the point in adopting licenses, which
    >> discourage contribution[1] ?

    M.Evans> Under the very hypothetical scenario in question  -- we're arguing corner
    M.Evans> cases here -- it would be up to you whether the changes constitute an
    M.Evans> "improvement" or not.  If so, you gain; if not, you lose nothing.

    M.Evans> What you ignore is that LGPL drives away businesses from using the

It hasn't driven away companies like IBM or Oracle, which have lotsa
products linked to LPGLed GNU libc.

    M.Evans> code at all, so the chances of ever gaining are reduced, not
    M.Evans> increased, by LGPL.  It's like taxes -- you can't raise them without
    M.Evans> expecting an influence on economic behavior in the market.

    M.Evans> Now another scenario.  Suppose MegaCorp makes changes, and you may
    M.Evans> accept them.  But you don't examine them until you get back from
    M.Evans> your sabbatical in France -- or until your wife's baby comes to term
    M.Evans> -- or until you finish a financing round for your venture start-up --
    M.Evans> or until your favorite hobby stops robbing you of quality CVS time --
    M.Evans> or until you finish other pieces of the open source project......

    M.Evans> What would you have the business do, sit around waiting for you?

It's their choice. They can write the code themselves, they can use a
COTS solution, they can pay me.

    M.Evans> They want to ship a product.  And LGPL requires that they create an
    M.Evans> alternate distro when the product ships.

So what ? First, they do not pay me, so they can have absolutely no
demands as to when I will (if ever) review their contribution, using
my extremely valuable spare time.  And second, what's the problem with
making a distribution ? I, personnaly, see no trouble maintaining a
separate GCC for some of my clients and believe my, GCC is one of the
most complex projects to maintain out there.

    M.Evans> Scenario #2 is that the competition demands to see LGPL source

It can readily see it.  And not only the competition, but *I* DEMAND
to own (with others, including the company) the modifications made to
*my* (L)GPL source.

    M.Evans> code and reverse-engineers MegaCorp's product with it, then undercuts
    M.Evans> them in the marketplace.

Reverse-engineering by its nature does not require any source code and
is not at all facilitated by the availability of such code.

    M.Evans> Scenario #3 is that I am fired from MegaCorp as a result.

    M.Evans> It takes very little effort to see why LGPL drives business away,
    M.Evans> leaving aside the OSI and FSF remarks.

LGPL drives away business, who try (and fail) to subvert the license.
Businesses, which honestly intend to comply with the letter, spirit
and the intent of the license have absolutely no trouble.

    >> That's the point that most people seem to not understand - using
    >> copylefted software encourages contribution from both sides - from one

    M.Evans> By trying to force contributions the LGPL in fact discourages them by
    M.Evans> driving commercial folks away completely.  It's just too much risk.
    M.Evans> This is the point that most LGPL people seem to not understand.

This is simply not true.  Just open the change logs from any LGPL
package and check the addresses.  You'll find quite a bit .com
addresses.

    >> Personally, I claim that
    >> independent developers are lot less likely to do forks in an
    >> incompatible manner.

    M.Evans> That is an unsupported statement.  Microsoft should be a poster child
    M.Evans> for this argument, but historically they have been forced into accepting
    M.Evans> industry standards on many fronts.

Name me one ! Hell, even TCP/IP has interoperability problems..

    >> Err, how can you argue against "restrictions" of (L)GPL and propose a
    >> more restrictive license[4] ?

    M.Evans> See links below [* - authoritative looking footnote].

    M.Evans> The license experts themselves deprecate LGPL.  Take up
    M.Evans> the cudgels with them.....

    >> FSF deprecates LGPL in favor of GPL.

    M.Evans> They do not deprecate LGPL in favor of GPL.  That's flat-out wrong.
    M.Evans> The draft document says,

OSI has nothing to do with FSF !

    M.Evans> http://www.tuxedo.org/~esr/faqs/Licensing-HOWTO.html#LGPL
    M.Evans> "OSI does not recommend the LGPL. The Free Software Foundation has
    M.Evans> itself deprecated this license....  OSI ... recommends only
    M.Evans> non-copyleft licenses as besrt practuce [sic] for libraries."

    >> And I, personally, have not
    >> appointed Erik S. Raymond as a license expert[5], have you ?

    M.Evans> Oh you've got to be kidding.  He's far more knowledgeable than all
    M.Evans> of us put together.

    M.Evans> Moreover the OSI and FSF have professional lawyers helping them
    M.Evans> make these decisions.  We don't.  So to you and me, he's a bona
    M.Evans> fide expert.

I don't know for OSI, but yes, FSF has lawyers and FSF lawyers do not
make ESR a license expert, any more than make a license expert you or
me.

    >> [1] Yes, discourage. I, working for MegaCorp, have a lot of my own
    >> things to do, so I'd not hurry up to submit my modifications if I
    >> weren't required by the law.

    M.Evans> Bull.  I, working for MegaCorp, know that in five years I will be
    M.Evans> working somewhere else. So I have an incentive to contribute, such that
    M.Evans> when I move to HappyCorp, I can use my old code from MegaCorp.  Isn't
    M.Evans> self-interest wonderful!

    M.Evans> And I, moonlighting at home on pet projects, like to use my code from
    M.Evans> MegaCorp under open source licensing.

    M.Evans> So I, the employee, with a significant say in technical decisions of
    M.Evans> MegaCorp, need better licensing to get approval from my management to
    M.Evans> participate in the project.

    M.Evans> They, the management of MegaCorp, have read the OSI position on LGPL,
    M.Evans> as informed by professional legal counsel at OSI and FSF, and know
    M.Evans> that it means trouble.

Why it doesn't mean trouble for the rest of the companies, which ship
proprietary software for GNU/Linux ?

Simple, because thay intend to comply with it, not to subvert it.

~velco