[Fresco-devel] Re: ACE

>     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] ?

Under the very hypothetical scenario in question  -- we're arguing corner
cases here -- it would be up to you whether the changes constitute an
"improvement" or not.  If so, you gain; if not, you lose nothing.
What you ignore is that LGPL drives away businesses from using the
code at all, so the chances of ever gaining are reduced, not
increased, by LGPL.  It's like taxes -- you can't raise them without
expecting an influence on economic behavior in the market.

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

What would you have the business do, sit around waiting for you?
They want to ship a product.  And LGPL requires that they create an
alternate distro when the product ships.

Scenario #2 is that the competition demands to see LGPL source
code and reverse-engineers MegaCorp's product with it, then undercuts
them in the marketplace.

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

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


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

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

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

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

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

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.

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

http://www.tuxedo.org/~esr/faqs/Licensing-HOWTO.html#LGPL
"OSI does not recommend the LGPL. The Free Software Foundation has
itself deprecated this license....  OSI ... recommends only
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 ?

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

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

Mark


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

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

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

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

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


[* - authoritative looking footnote]
SISSL
http://gridengine.sunsource.net/project/gridengine/domainFAQ.html
"The ... Sun Industry Standards Source License ... is a good license
where interoperability and commercial considerations are important."

http://www.sun.com/smi/Press/sunflash/2000-07/sunflash.20000719.1.html
"In addition to the GPL, Sun intends that all code contributions to
the OpenOffice.org project, including Sun's contribution of the
StarOffice source code, will be made available under the Sun Industry
Standards Source License (SISSL). This dual-licensing approach is
designed to allow all organizations and individuals to use the source
code freely and openly as they choose."

http://wwws.sun.com/software/sunone/identity/ipl/faq.html#0q20
What is the "Sun Industry Standards Source License" (SISSL)?
"The Sun Industry Standards License is designed to encourage and
support the development of industry standards. The license has
requirements designed to discourage divergence from the referenced
standard(s). If developers deviate from the standard(s), and they may
do so, but they must declare their deviation from the standard(s)
through a public specification description and a public reference
implementation of those deviations."

http://www.openoffice.org/white_papers/OOo_project/strategy.html
http://www.openoffice.org/FAQs/faq-licensing.html