Dr. Seuss, licensing, and WINE

David Elliott dfe at tgwbd.org
Sat Feb 9 21:46:04 CST 2002

On 2002.02.09 19:18 Patrik Stridvall wrote:
> David Elliott wrote:
> > On 2002.02.09 06:39 Patrik Stridvall wrote:
> > In some ways it is.  Many times when entities are violating
> > some license
> > or law a decision is partly based on what exactly their
> > intentions were.
> > Although I would not like to rely on this and I think
> > clarifying what and
> > what is not allowed is better than leaving it up to good intentions.
> Yes, but in the case of copyright it doesn't really make much sense.
> For determining the punishment for any infringment, yes.
> For determining whether something infringes, no.
> And sure I guess hiding behind fair use is harder if you intent is bad.
Sorry, should have clarified that more.  It is true that intent is used in 
the punishment phase, usually not the actual trial.

> However does the Joe Hacker in my earlier example that used a propriety
> library to avoid dual booting and shared it with fellow hobbyists
> have "intent to infringe"?
This is pointless to discuss.  I don't want a license where no one can 
possibly link wine with binary components.  The LGPL does not prohibit 

> > > > Thus TransGaming does not hurt.  Lindows really doesn't hurt
> > > > either, and
> > > > the users of Lindows win because should they need to
> > update the LGPL
> > > > components of Wine they can do so and still continue to link
> > > > to Lindows
> > > > binary only components.
> > >
> > > Exactly, but they will be able to do that without the LGPL.
> > > It is in the respective companies intrest to make it so.
> > >
> > If that is so, then why aren't they doing it already?
> 1. Lack of time.
> 2. Lack of insight what their users might want.
> 3. Lack of concerned users.
> I'm sure you can find more reasons.
Because the current license allows them to get away with it.

> > Sure it is.  The LGPL's purpose in life is to make sure the
> > users of the
> > program can continue to recompile the code that was LGPL to
> > begin with.
> OK. Reformulate. There is no reason to force this to happend,
> since it is likely to happend eventually anyway. See below.
No, there is EVERY reason to enforce this.

> > > Even if I would be inclined to agree, I would rather let
> > the FSF lawyers
> > > draw up a completely new license lets call it, hmm, MGPL (Middleware
> > > GPL),
> > > for use in, hmm, what should I call it, say two-ended
> > libraries that Wine
> > > IMHO really is.
> > >
> > > This MGPL should clarify that it is legal to "plug-in" proprietary
> > > application/libraries in both ends while code the middle that is
> > > the Wine source code should have some copyleft like protection and
> > > additional that sublicening the code as LGPL is allowed.
> > >
> > > Note however I'm not really proposing this but it might be
> > a reasonable
> > > compromise. Perhaps something for the LGPL camp to chew on.
> > >
> > What you describe sounds to me like what I am describing.  A
> > modified and
> > clarified LGPL.  Essentially when you start adding or
> > deleting from the
> > LGPL you are in fact making a new license.  You are saying
> > the same thing
> > I am.
> As you wish, this is of no moment.
See below.

[SNIP offtopic stuff about politics]
> Of course, the ignorant masses really gets what they deserve.
> I primarily think it is unfortunate that I live in the
> same world as them.
hehe :-)

[SNIP more stuff about politics]
> > Yeah, doesn't that suck.  Kind of like people use proprietary
> > software so
> > they get what they deserve.  We can't stop them from using it as that
> > limits the freedom's of the proprietary software companies
> > and the users
> > who want to use that software.  However what we can do is
> > remove the need
> > to use proprietary software.  Wine is a first step towards this.
> Yes, but I never think the need for proprietary software will disappear.

Obviously not in the grand scheme of things.  But basic day to day tasks 
like just being able to use your computer should not require proprietary 
software.  I would extend basic tasks to basic word processing and 
web-browsing functionality.  Your typical Linux distribution is already at 
that point.  The only thing missing is the ability to continue to run the 
Windows based programs that offer extended functionality.  Wine fills that 
need and will help to transition users to a more reasonable and open 

Wine is such an important product and yet most of the developers don't 
really care about its future.  Moving users from Windows to some 
proprietary Windows clone isn't really helping.


> > > > We should collectively think of the different scenarios and
> > > > ask one very
> > > > important question: Do we /really/ want to prevent this
> > scenario from
> > > > happening?
> > >
> > > Ah, I forgot that very important question. I intend to supply it but
> > > somehow
> > > it got lost. But perhaps the question:
> > >
> > > 1. Do you consider his or her behavior morally or ethically
> > defendable?
> > >
> > > sums it up pretty well as well.
> > >
> > Sounds kind of like my.. do you think it should be allowed question,
> > although put in a better way.
> Ah yes, you are right, we probably should ask the opposite question as
> well:
> Do you consider it morally or ethically defendable to
> prevent this behavior?
Yes, I think it is morally defendable to prevent people from incorporating 
Wine into proprietary products.  And for most free software projects I 
think it is morally defendable to prevent people from even linking to them 
or using them in any proprietary software.

For Wine I think by nature we must let people link to proprietary software.

> > This is simply not true.  This is very much Wine's problem.
> > If I need
> > some of Lindows's functionality to run my program but would
> > still like to
> > be able to hack on other parts of Wine then I, as a developer
> > and user, am
> > screwed.
> So complain with Lindows support or abandon Lindows and use something
> else or whatever. Eventually they will learn to listen to their
> customers.
This laissez-faire attitude really bothers me.  You say you care, but in 
reality you don't.

> > We cannot
> > put our work on the line and say "Well, hopefully no one will
> > make bad
> > choices with it".
> You can never prevent people from doing bad choice with a product:
> "Design a product even an idiot can use and only an idiot will use it"
This is not the same thing.  What I would like to accomplish is to prevent 
people from incorporating Wine into proprietary products.  I don't want to 
depend on the users of these proprietary products.  Besides dude.. what 
company listens to their customers anymore anyway.

> > > Regardless of any fun you might have had. Ask this question:
> > >
> > > Would you have consider it ethically or morally defendable if the
> > > Wine license had prevented you from using a proprietary ASPI
> > > library with Wine and distributing the result to your friends.
> > >
> > YES!  That is my point.  I would have done it anyway even if
> > their was a
> > proprietary version.  And I think it is important that we
> > allow people to
> > use and distribute proprietary components with a free software Wine.
> Agreed.

[SNIP discussion on time zones]
> > > See my suggestion about the "MGPL" instead.
> > >
> > This is really the same thing as a clarified LGPL.  It's not
> > necessary to
> > write from the ground up a new license, but if we need to
> > take the LGPL
> > and strike out certain sections and/or add to it then that is
> > far better
> > than writing a new license completely from scratch.
> No, it is not, because we want the license to be very clear
> on what is allowed and what is not. No patchwork. A clear
> license with only the absolute minimum number of paragraphs.
> Remember we want companies working on Wine without having
> to spend to much money on their lawyers.

ARGH!!!!!  Licensing software is complex.  If the only argument you have 
against the LGPL is that it is complex, then tough cookies.  The only 
licenses that are extremely simple are the ones that either say "Do 
whatever with it" or the ones that say "We'll take your firstborn if you 
reverse engineer it".

This argument that the LGPL is too complex is a waste of time.  It reminds 
me of microsofts shared source license.  One of its strong points was that 
it was simple.  Know why it was simple?  Because you couldn't do shit with 
the source so it was simple.  At the other extreme we have the X11 which 
is simple, because you can do almost everything with it.

The very nature of moving to a license like the LGPL means it will be 
complex.  This doesn't mean it has to be incomprehensible (and it isn't)  
it just means it'll be complex.

> > > > Hopefully we can get this resolved this time...  It's looking
> > > > promising
> > > > given the few and far between somewhat clear posts and
> > > > disregarding the
> > > > ill-informed wanna-be-on-slashdot shit.
> > >
> > > We will see. I'm neither optimistic nor pessimistic for the moment.
> > >
> > >
> > Well, I /hope/ we can get this resolved since we're talking
> > about the same
> > things.  Your only real concern at this point seems to be
> > that if we were
> > to move to LGPL that some companies may not like it because
> > it's complex.
> Basicly but I very much fear that even a MGPL would be to complex.

So then I nailed it.  You're only real concern seems to be that companies 
may shy away from Wine if the license is so complex.  I wouldn't be that 
concerned about it.  Had Wine been LGPL, Lindows probably still would 
exist and would be playing more nicely with us.

> > They can pay lawyers to figure it out for them. Why do you
> > think lawyers
> > make all the money anyway.
> Because the money that they can avoid spending on lawyers could
> be spent on improving Wine instead.
If you take the average software company, more likely it'll be spent on a 
private jet for the CEO.

Anyway... this mail is getting really long, and if the biggest argument 
you can come up with against the LGPL is that it's too complex then it is 
pointless to continue.


More information about the wine-devel mailing list