Wine license change
vorlon at dodds.net
Mon Feb 11 14:33:44 CST 2002
On Fri, Feb 08, 2002 at 06:10:50AM -0500, Roger Fujii wrote:
> Steve Langasek <vorlon at dodds.net> wrote:
>> On Thu, Feb 07, 2002 at 05:45:36PM -0500, Roger Fujii wrote:
>>> If you are using marketing speak for "contribute". GPL requires 1)
>>> for you to show your work 2) You effectively license your software to
>>> the FSF. It doesn't say it has to be in any useful form to be worked
>>> back into the originating project (if any).
>> We're talking about the LGPL, not the GPL.
> true with either. Your "contributions" must be licensed as LGPL/GPL.
The LGPL and the GPL have different restrictions on the creation of
certain types of derivative works. The thing about Wine is that it's not
*a* library, it's a *set* of libraries -- reimplementations of DLLs. Even
under the LGPL, there are many ways to build proprietary value-added
software on top of Wine. All you have to do is create your own
reimplementation of the particular DLL that you get your value from
without using any LGPLed code in the process. And guess what, there's
already an existing body of BSD-licensed Wine code that such companies can
draw from to do just that.
If this lends support to the argument that the LGPL can be easily
'circumvented', it also negates some of the objections to such a switch.
(At least, the ones that aren't based in rhetoric and personal phobias.)
>> The rest of this paragraph shows a serious disconnect with the text of
>> the LGPL. Have you actually read the license in question?
> I have no clue what you are talking about. I didn't say anything until
> the "Here we go again". And Yes, I have read the *GPL, many, many, many
'Effectively license your software to the FSF'. The LGPL, as a license,
is designed to be idempotent, just as the BSD license is; under each
license, everyone is granted the *same* freedoms. There's nothing in the
text of the LGPL that can be interpreted as licensing your software to the
FSF that isn't already present with the existing license.
I'm glad you've read the LGPL. There are many who form their strong
opinions -- positive or negative -- about licenses without bothering to
read them and understand them first.
>> "Source code" for a work means the preferred form of the work for
>> making modifications to it. For a library, complete source code means
>> all the source code for all modules it contains, plus any associated
>> interface definition files, plus the scripts used to control
>> compilation and installation of the library.
> If you are contesting the "useful form", let's say I did this: Took
> the original GPLed code and run it through a lexical translator so that
> all labels and such are changed. Make my changes with respect to THIS
> codebase. Now publish this. This AFAIK, fulfills the technical requirement
> of the *GPL, but it certainly isn't a usable form.
In that respect, you're correct that no one has to release the source
code in a form that's easily reintegratable with the main Wine tree. And
if someone wanted to be spiteful, they could do what you describe -- but
they would still have to release the source code in the form that THEY use
it when working on and compiling Wine, which means their changes are still
visible for others to study.
> you are ABSOLUTELY right. The spectrum is PD->BSD->GPL-------->Propriatary.
> But then, things in the PD really isn't licensed, so X11/BSD is probably
> as close as one can get.
>> and any software license that permits you to maintain any portion of your
>> copyright is a fraud if it claims to be Free. If you really cared about
>> giving absolute freedom to the users of code that you write, you would
>> place all of your code in the public domain.
> we can quibble about what "free" means, but saying GPL is "more free" than
> X11/BSD doesn't make any sense. Given the current license is X11/BSD and
> the argument is for changing it to LGPL, I can't see how one can use the
> "freedom" argument in this case.
> geez. no need to get bent out of shape. I'll rephrase and say BSD is
> MORE free than GPL. Happy?
I don't believe anyone has argued that Wine should be placed under the
LGPL because the LGPL is more free than the BSD license. I disagree with
the idea that what users are allowed to do with the code is the only
metric of freedom that's important to consider, but since this relicensing
discussion wasn't brought about by concerns that the current license is
non-free, I don't think it's relevant, either. You're correct that the
BSD license is more free than the GPL per this particular metric.
>> On the other side, companies like Lindows.com don't impress me as bringing
>> any added value back to the community -- they may succeed in increasing
>> the percentage of non-Windows desktops in the world, but the current Wine
>> license makes it possible for all the profits from their OS to pad the
>> wallets of marketroids, sales critters and smooth-talking business execs,
>> without contributing anything back to the Wine tree. I have no problem at
>> all with the idea of eliminating that particular business model.
> The problem with that particular argument is that it makes the fundamental
> assumption that all people who don't contribute back NOW is evil foreever.
> You just don't know what will happen in the future. Maybe Sun/IBM buys out
> lindows.com in 6 months when they are broke, and opens the source. Or,
> maybe in a year, they have a change of heart (has happened before with other
> companies). The point is that it's arguably better to have more players.
Actually, I don't think that assumption is key to my argument. Consider
that a company which takes without giving back will either spend a lot of
developer time re-merging upstream fixes into their local product, or will
create a product which diverges significantly from the main tree. Either
scenario, when considered by itself (that is to say, setting aside any
reasons this might be profitable), constitutes an inefficient use of
programmer time; the cost of keeping a private tree is higher than the
cost of letting the community maintain the tree for you.
If the company is one like Corel, who profits not by selling Wine but by
selling products that run under Wine, then trying to keep their changes
private is misguided -- most such companies would still see the advantage
of a Windows implementation that they didn't control exclusively, so long
as Microsoft didn't control it either, and would not be turned off by the
LGPL -- in fact, both we and they would benefit from the LGPL, because of
the more efficient use of developer time. Other companies in that
situation might indeed shy away from an LGPLed Wine; but I can't think of
a rational reason for doing so, and companies that make irrational
business decisions don't strike me as a good reason to avoid a licensing
choice that benefits the rest of us.
If the company is one like, say, Lindows.com, and they have a business
model based on selling a branded, enhanced version of Wine, there are
rational reasons for possibly not wanting to use an LGPLed code base.
There are several different options for such a company. Some might choose
to risk the LGPLity, and decide to see if they can make a profit just from
selling people something they can already get for free. This is not out
of the question; every Linux vendor is doing this today, and if 90%
marketing + 10% programming works for Microsoft, it should work for others
too, right? Others would consider that they still have the option of
using the slightly out-dated, BSD-licensed Wine tree as a starting point
for their proprietary modifications. If they're going to be creating
their own proprietary code fork anyway, does it really matter that they
don't have access to the last one month, two months, six months of bug
fixes? And if it does matter that much, shouldn't they consider using
LGPLed versions of components that aren't core to their value-added
This leaves the last possibility; that such a company chooses not to enter
the market, or fails to come into being, because they can't find numbers
that make sense using either a slightly-older, BSD-licensed Wine or an
up-to-date LGPL-licensed Wine. And we do lose something by not having
such companies around, particularly if they happened to have a 'change of
heart' down the road and freed their source code.
Does the loss of such companies as players in the Wine community outweigh
all of the other potential advantages described above, including the
advantage of some otherwise closed-source companies choosing to open
their source as a result? I don't think it does. I think that today, if
we look at nothing more than raw lines of code that Codeweavers
contributes to Wine that we are told would not available for use in a
BSD-licensed tree going forward, it makes sense to switch to the LGPL; and
I think the benefits only go up from there.
More information about the wine-devel