No subject

Tue Aug 30 15:12:41 CDT 2005

WineHQ tree after the license change and imported them into their own tree.
So these DLLs (and only those) are covered under the LGPL. 

This means also that if these DLLs are more advanced than the one in WineHQ,
you can submit patches to merge them back into WineHQ's mainline.

</p></quote>

Dmitry Timoshkov found a description of how the licenses interrelate:
<quote who="Dmitry Timoshkov">
Anyway, were is a snippet of the LICENSE file at the root of the WineX
tree:

"Source code and other software components explicitly identified as 
Copyright TransGaming Technologies Inc. is covered by the Aladdin 
Free Public Licese, (AFPL) the terms of which are listed below. In
particular, redistribution of the following components in source or
object code form is allowed only under the terms specified by the AFPL:
<ul>
 <li>dlls/ddraw</li>
 <li>dlls/dsound</li>
 <li>dlls/dinput</li>
 <li>dlls/d3dgl</li>
 <li>dlls/d3d8</li>
 <li>dlls/dinput8</li></ul>

This is not an exhaustive list. Other components that include 
TransGaming Technologies Copyright notices are also covered by 
the AFPL, with the exception of components covered under the 
GNU Lesser General Public License."
</quote>

The AFPL is <a href="http://www.gnu.org/licenses/license-list.html#NonFreeSoftwareLicense">not considered</a>
a free software license by the Free Software Foundation. TransGaming chose
distribute their WineX software under that license because of the restrictions
it imposes. When the original Wine sources were under the X11 license this 
was no problem. The X11 license, a BSD derivative, basically says you can
take the software and do whatever you want with it. That includes adding
components (such as a Direct3D implementation) and re-licensing it however
you wish. Since then some of TransGaming's components have been updated 
and have adopted the new LGPL license. Gav State dropped a note to clarify
which parts are LGPL'ed:
<quote who="Gavriel State">
All of this info can be found here:
 <ul><a href="http://www.transgaming.com/license.php?source=1">
 http://www.transgaming.com/license.php?source=1</a></ul>

The LGPLed components in the WineX tree are:
 <ul>
     <li> dlls/avicap32/ (libavicap32.so)</li>
     <li> dlls/msdmo/ (libmsdmo.so)</li>
     <li> dlls/quartz/ (libquartz.so)</li>
     <li> dlls/msacm/winemp3 (libwinemp3.so)</li>
     <li> dlls/wininet (libwininet.so)</li>
     <li> dlls/urlmon (liburlmon.so)</li>
     <li> programs/regsvr32 (libregsvr32.so)</li></ul></p></quote>

That prompted Tom Wickline to ask for a clarification of what, if any, 
components were covered by the X11 license. As of press time there was
no answer on that. All parts of the ReWind tree (the successor of the
forked Wine code) are still covered under the X11 license.

</section>
<section 
	title="Using Standard Fonts" 
	subject="Can I turn off freetype at runtime"
	archive="http://www.winehq.com/hypermail/wine-devel/2003/11/0363.html" 
	posts="3"
	startdate="11/17/2003"
>
<topic>Configuration</topic>
<p>
Bill Medland needed some help finding a configuration option:</p>
<quote who="Bill Medland"><p>
Is it possible to turn off the freetype use at runtime, e.g. by changing 
something in the config file?
</p><p>
Basically under SuSE several dialogs are drawing with 5 pixel text whereas 
under Windows they are about 9 pixel high (which I don't understand because I 
think that they should not exceed 8).  Under RedHat they are 7 pixel which 
are at least readable.
</p><p>
I hope that if I can turn off the freetype then on SuSE it will get the same 
font as on RedHat
</p><p>
I tried setting an Alias but it didn't make any difference; it still used the 
same font instead of the alias</p></quote>

<p>Lionel Ulmer spotted some lines in the sample configuration that
appeared to fit:</p>
<quote who="Lionel Ulmer"><p>
<ul><code>
; Use the Render extension to render client side fonts (default "Y")<br />
;;"ClientSideWithRender" = "Y"<br />
; Fallback on X core requests to render client side fonts (default "Y")<br />
;;"ClientSideWithCore" = "Y"<br />
; Set both of the previous two to "N" in order to force X11 server side fonts<br />
;<br />
; Anti-alias fonts if using the Render extension (default "Y")<br />
;;"ClientSideAntiAliasWithRender" = "Y"<br />
; Anti-alias fonts if using core requests fallback (default "Y")<br />
;;"ClientSideAntiAliasWithCore" = "Y"</code></ul></p><p>

I never tested it and do not know if it still works... But it certainly
sounds like it should do what you require :-)
</quote>
Huw Davies agreed that should work.

</section>
<section 
	title="Integrating With NetMeeting" 
	subject="Netmeeting under wine"
	archive="http://www.winehq.com/hypermail/wine-devel/2003/11/0349.html" 
	posts="3"
	startdate="11/17/2003"
><p>David Martinez Prado wanted know if Microsoft NetMeeting worked
with Wine.  Apparently he couldn't even get it to install.  No one
else appeared to know about it either.  Jerome Bouat gave a pointer
to another application,
<quote who="Jerome Bouat">
 use GnomeMeeting: <a href="http://www.gnomemeeting.org/">
 http://www.gnomemeeting.org/</a></quote></p>

According to the GnomeMeeting FAQ it's compatible with NetMeeting.

At that point Tom Wickline decided to stir things up and flamed
Jerome for not promoting a Wine solution. Other pointed out that
NetMeeting doesn't currently work with Wine and it will be quite a
challenge to fix it. Most Wine developers seem to always aupport
native programs first, but the trade-off may be a learning curve or
lost $$$ when switching to a new app. Shachar Shemesh explained his
position,
<quote who="Shachar Shemesh">
Well, I guess making a new app work on Wine is a non-trivial task, and 
so people prefer to focus their efforts where the app is truely needed - 
i.e., where no native free software alternative is available. This does 
not mean that David can't hack wine to make NetMeeting work himself, or 
that Alexandre won't commit it. It just means that I, for one, have 
little incentive to jump in at the moment. Once Jerome pointed (me) to 
GnomeMeeting (how did they skip the chance to call it Gnomeeting??), 
it's not my itch any more.</quote>

</section>
<section 
	title="Using Wine's Builtin C Runtime" 
	subject="include files"
	archive="http://www.winehq.com/hypermail/wine-devel/2003/11/0428.html" 
	posts="6"
	startdate="11/19/2003"
	enddate="11/20/2003"
>
<topic>Winelib</topic>
<p>Ralf Juengling had a question about using some of Wine's builtin
functions for compilation:</p>
<quote who="Ralf Juengling"><p>
A Makefile created by winemake &amp; configure adds <tt>
/whereever/include/wine/windows</tt> to the include paths.
</p><p>
Why doesn't it also add
<tt>/whereever/include/wine/msvcrt </tt>?
</p><p>What is the status of the include files in msvcrt?</p></quote>

With regard to the first question, Alexandre replied,
<quote who="Alexandre Julliard">
Because not everybody wants to use msvcrt. Unless you need some
specific features of the Windows C run time, in a Winelib app you are
better off using the standard Unix C library.
</quote> As to the status, Alexandre felt they were fine,
<quote who="Alexandre Julliard">
They should work just fine. Make sure you also import msvcrt if you
use the headers.
</quote>

<p>Ralf didn't think they would work though:</p>
<quote who="Ralf Juengling"><p>

... but I also need things defined in &lt;math.h&gt;. The file 
mscvrt/math.h coming with wine, however, is empty. So have
to include things from the Windows C runtime library 
and the Unix C library. For some reason, the cpp picks
wine's version of 'math.h' first even if '-I/usr/include'
precedes '-I/local/include/wine/msvcrt' on the command line.

So my solution to make it compile was to remove wine's 
'math.h'. That's why I would say the include files are 
incomplete. How do other people deal with a case like the 
one I described?
</quote>

<p>Ralf overlooked Alexandre's obvious answer,
<quote who="Alexandre Julliard">
By submitting a patch to add the missing definitions &lt;g&gt;
</quote></p>

</section></kc>

--gKMricLos+KVdGMg--