Should Wine move to LGPL 3?
Hello, I was wondering if there are any plans in place for Wine to move to the newly revised LGPL 3 licence before the release of 1.0? http://www.gnu.org/licenses/lgpl.html Cheers, Tom Wickline -- Microsoft's patent protection scheme is the equivalent of bailing water with a sieve.
Re: Should Wine move to LGPL 3?
On 7/13/07, Victor [EMAIL PROTECTED] wrote: Also Wine isn't just a library. (LGPL) Nor is the LGPL a license exclusively for libraries. --tim
Re: Should Wine move to LGPL 3?
On Friday 13 July 2007 15:01:26 Tom Wickline wrote: Why shouldn't Wine move? IMHO: Before changing license, there must be a really good reason to do that - for example, if application won't survive without doing so. And before change, license must be reread at least one hundred times - just to make sure it is understood correctly and there will be no problems. It is a serious step. Also Wine isn't just a library. (LGPL) -- Victor Eremin ([EMAIL PROTECTED]) signature.asc Description: This is a digitally signed message part.
Re: Make visible mdi client window before as Switch Maximized MDI Children test will be activated. [try2]
Anatoly Lyutin [EMAIL PROTECTED] wrote: You can find the results of the test run under XP here: http://test.winehq.org/data/200707121000/xp_XP-PRO-IE7/user32:msg.txt I get the same failures. Thanks. I have viewed this. It was failed on 0x00ae messages. I could not find description of this message. Do you know something about it? It's a not documented XP message, have a look how other message sequences cope with it. http://test.winehq.org/data/200707121000/2003_W2K3-SE-SP2/user32:msg.txt shows that the run under W2K3 has exactly the same failures in your test. Hmm.. I want to asked you about this: msg.c:3285:expected 0008 - actual 0008 msg.c:3285:expected 0281 - actual 0007 msg.c:3285:expected 0281 - actual 0007 msg.c:3285:expected 8005 - actual 0007 msg.c:3285:expected 0007 - actual 0007 msg.c:3285:expected 0009 - actual 0009 msg.c:3285:expected 0008 - actual 0008 msg.c:3285:expected 0281 - actual 0007 msg.c:3285:expected 0281 - actual 0007 msg.c:3285:expected 8005 - actual 0007 msg.c:3285:expected 0007 - actual 0007 msg.c:3285:expected 0222 - actual 0222 msg.c:3285:expected 0047 - actual 0047 msg.c:3287:end of test for switch maximized MDI children Why does not this fail? Is this correct? You have in view of it? Sorry, I don't understand what you are trying to ask, or why the sequence above should fail. or you mean that failed on : msg.c:3271:expected 0001 - actual 0001 msg.c:3271:expected 0046 - actual 0046 msg.c:3271:expected 0083 - actual 0024 msg.c:3271: Test failed: Create maximized visible 2nd MDI child 2 window(Switch test) But I take this part from another test only for creating MDI child. I can see msg sequence for this test and fix it if I can. I see 2 failures in your test in the run under W2k3, and 3 failures under XP in the logs referenced above. -- Dmitry.
Re: SUBLANG Rules
I think the best thing is for Wine to support things like LC_ALL=nn nb LANG=nn nb because even though we provide a Nynorsk translation, most programs will only be available in Bokmål. It seems that Vista supports many user preferred languages and many system fallback languages so it should possible to implement. But I don't know how it works under the hood. Are the functions from ntdll documented somewhere? I've put Chinese and Portugese on the Wiki as languages using sublang codes because we already have distinct translations for different variants using the sublang codes. Also as far as I know the variants are quite different and in other open source projects they also usually have distinct translations. But of course it would be interesting to learn what native speakers think about it. Mikolaj Zalewski
Re: Should Wine move to LGPL 3?
On 7/13/07, Tom Wickline [EMAIL PROTECTED] wrote: On 7/13/07, Michael Stefaniuc [EMAIL PROTECTED] wrote: Tom Wickline wrote: I was wondering if there are any plans in place for Wine to move to the newly revised LGPL 3 licence before the release of 1.0? http://www.gnu.org/licenses/lgpl.html Why should Wine move? Why shouldn't Wine move? LGPL3 = GPL3 + additional permissions: This version of the GNU Lesser General Public License incorporates the terms and conditions of version 3 of the GNU General Public License, supplemented by the additional permissions listed below. The GPL3 has no track record so far, and it's too political and controversial for my liking. Let's wait a while before making the decision. bye michael -- Bye Damjan
Re: Make visible mdi client window before as Switch Maximized MDI Children test will be activated. [try2]
Anatoly Lyutin [EMAIL PROTECTED] wrote: I have asked that I can not understand why in test expected and obtained message does not coincide and test does not fail. Ex.: msg.c:3285:expected 0008 - actual 0008 msg.c:3285:expected 0281 - actual 0007 msg.c:3285:expected 0281 - actual 0007 msg.c:3285:expected 8005 - actual 0007 Why distinction between the expected and the obtained messages leads to fail in another tests but not fail in this place? If a message is marked as optional it can be skipped without causing the test to fail. I see 2 failures in your test in the run under W2k3, and 3 failures under XP in the logs referenced above. That's right. But there 2 failures are not mine ( More precisely they directly do not concern to my test. ) These are tests for creation MDI children. Not switching. Here are the failures I see in http://test.winehq.org/data/200707121000/2003_W2K3-SE-SP2/user32:msg.txt msg.c:3252: Test failed: Create maximized visible 1st MDI child window(Switch test): the msg 0x0081 was expected, but got msg 0x0024 instead msg.c:3271: Test failed: Create maximized visible 2nd MDI child 2 window(Switch test): the msg 0x0083 was expected, but got msg 0x0024 instead Same failures exist in the XP run, plus another one: msg.c:3285: Test failed: Child not switch correctly -- Dmitry.
Re: Proposal to phase out *winehq.com email addresses
Am Freitag, 13. Juli 2007 10:44 schrieb Robert Shearman: Stefan Dösinger wrote: OK with me. The dual address thing is also confusing for everyone who sets up his own filters in the mailer, mostly to sort out mails into different folders. You should sort on the List-Id header instead. I'm doing that now, but I used to sort on the address, and apparently many people sort the mails based on the address instead of the list id.
Re: Proposal to phase out *winehq.com email addresses
Stefan Dösinger wrote: Am Donnerstag, 12. Juli 2007 23:39 schrieb Duane Clark: Due to the rather large amount of spam sent to the *winehq.com email addresses (as opposed to *winehq.org), I would like to phase them out. I will state up front that this proposal benefits only me or any future moderator. Since I have been doing that for about 6 years now, hopefully I'll get a bit of sympathy ;) OK with me. The dual address thing is also confusing for everyone who sets up his own filters in the mailer, mostly to sort out mails into different folders. You should sort on the List-Id header instead. -- Rob Shearman
Re: Should Wine move to LGPL 3?
Tom Wickline wrote: I was wondering if there are any plans in place for Wine to move to the newly revised LGPL 3 licence before the release of 1.0? http://www.gnu.org/licenses/lgpl.html Why should Wine move? bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111
Re: winedump: Cast-qual warnings fix
Andrew Talbot [EMAIL PROTECTED] writes:
+ const char *iter, *base_type, *catch_unsigned;
+ union
+ {
+ const char*constant;
+ char *nonconst;
+ } type_str;
That's not better than simply casting const away, it's just hiding the
problem from the compiler.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: Should Wine move to LGPL 3?
On 7/13/07, Michael Stefaniuc [EMAIL PROTECTED] wrote: Tom Wickline wrote: I was wondering if there are any plans in place for Wine to move to the newly revised LGPL 3 licence before the release of 1.0? http://www.gnu.org/licenses/lgpl.html Why should Wine move? Why shouldn't Wine move? bye michael --
Re: Should Wine move to LGPL 3?
On Friday 13 July 2007 13:18:41 Damjan Jovanovic wrote: On 7/13/07, Tom Wickline [EMAIL PROTECTED] wrote: Why shouldn't Wine move? LGPL3 = GPL3 + additional permissions: This version of the GNU Lesser General Public License incorporates the terms and conditions of version 3 of the GNU General Public License, supplemented by the additional permissions listed below. That's correct. This means that, as the GPLv3, the LGPLv3 is more compatible with international laws, as opposed to being US-centric like the (L)GPLv2 was. Also, all the other reasons to move to the GPLv3 apply. The GPL3 has no track record so far, and it's too political and controversial for my liking. At Samba, we have decided to switch to GPLv3 for the coming releases, releasing the libraries that were under the LGPLv2 under the LGPLv3. As for other projects, see http://gpl3.palamida.com:8080/index.jsp Let's wait a while before making the decision. What specifically are we waiting for? Until the GPLv3 is tested in court? Until someone TiVolizes Wine? Christmas? Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
unsuspected success in tests/monthcal?
Hi, For some days I now get unexpected successes in dlls/comctl32/tests/monthcal.c. ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so monthcal.c touch monthcal.ok err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp= lp= err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=0001 lp= err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp= lp= err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp= lp= err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp= lp= err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=0001 lp= monthcal.c:818: Test succeeded inside todo block: Expected 131073, got 131073 make[2]: *** [monthcal.ok] Error 1 Does anyone else see them too? Ciao, Marcus
Re: unsuspected success in tests/monthcal?
Marcus Meissner wrote: For some days I now get unexpected successes in dlls/comctl32/tests/monthcal.c. ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so monthcal.c touch monthcal.ok err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp= lp= err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=0001 lp= err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp= lp= err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp= lp= err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp= lp= err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=0001 lp= monthcal.c:818: Test succeeded inside todo block: Expected 131073, got 131073 make[2]: *** [monthcal.ok] Error 1 Does anyone else see them too? I get this one: /home/michi/work/wine/tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so /home/michi/work/wine/dlls/comctl32/tests/monthcal.c touch monthcal.ok monthcal.c:773: Test succeeded inside todo block: Expected 65536, got 65536 make[2]: *** [monthcal.ok] Error 1 bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111
Re: Should Wine move to LGPL 3?
On Fri, Jul 13, 2007 at 01:18:41PM +0200, Damjan Jovanovic wrote: The GPL3 has no track record so far, and it's too political and controversial for my liking. Let's wait a while before making the decision. Many groups are exceedingly worried about parts of GPL3. Not only commercial companies who may not have been obeying the general spirit of the GPL, but also people writing software that is BSD licensed are worried about having GPL3 utilities included in a software release, and having GPL3 source residing in the local CVS tree. David -- David Laight: [EMAIL PROTECTED]
Re: winedump: Cast-qual warnings fix
On Fri, Jul 13, 2007 at 12:29:36PM +0200, Alexandre Julliard wrote:
Andrew Talbot [EMAIL PROTECTED] writes:
+ const char *iter, *base_type, *catch_unsigned;
+ union
+ {
+ const char*constant;
+ char *nonconst;
+ } type_str;
That's not better than simply casting const away, it's just hiding the
problem from the compiler.
And I'm not sure that the compiler is required to treat the two
fields of the union as being the same data item.
Certainly if the fields of the union are 'void *' and 'intptr_t'
you can't assume that a value written to one field of the union
can be immediately read from the other.
David
--
David Laight: [EMAIL PROTECTED]
Re: Make visible mdi client window before as Switch Maximized MDI Children test will be activated. [try2]
Dmitry Timoshkov wrote: Anatoly Lyutin [EMAIL PROTECTED] wrote: Can you send me output when you run my test on XP? It will be nice. You can find the results of the test run under XP here: http://test.winehq.org/data/200707121000/xp_XP-PRO-IE7/user32:msg.txt I get the same failures. Thanks. I have viewed this. It was failed on 0x00ae messages. I could not find description of this message. Do you know something about it? http://test.winehq.org/data/200707121000/2003_W2K3-SE-SP2/user32:msg.txt shows that the run under W2K3 has exactly the same failures in your test. Hmm.. I want to asked you about this: msg.c:3285:expected 0008 - actual 0008 msg.c:3285:expected 0281 - actual 0007 msg.c:3285:expected 0281 - actual 0007 msg.c:3285:expected 8005 - actual 0007 msg.c:3285:expected 0007 - actual 0007 msg.c:3285:expected 0009 - actual 0009 msg.c:3285:expected 0008 - actual 0008 msg.c:3285:expected 0281 - actual 0007 msg.c:3285:expected 0281 - actual 0007 msg.c:3285:expected 8005 - actual 0007 msg.c:3285:expected 0007 - actual 0007 msg.c:3285:expected 0222 - actual 0222 msg.c:3285:expected 0047 - actual 0047 msg.c:3287:end of test for switch maximized MDI children Why does not this fail? Is this correct? You have in view of it? or you mean that failed on : msg.c:3271:expected 0001 - actual 0001 msg.c:3271:expected 0046 - actual 0046 msg.c:3271:expected 0083 - actual 0024 msg.c:3271: Test failed: Create maximized visible 2nd MDI child 2 window(Switch test) But I take this part from another test only for creating MDI child. I can see msg sequence for this test and fix it if I can. -- Best regards Anatoly Lyutin.
Re: Should Wine move to LGPL 3?
I've been meaning to ask about this since (L)GPL3 was released. The version 3 of the (L)GPL license has numerous benefits: - It's much more legally sound in the rest of the world (IMO one of the most important factors about the new license) - numerous reasons for this e.g. referencing WIPO rather than US laws. - It has an explicit patent agreement (really an extension of the above - (L)GPLv2 has an implicit patent agreement, but this is only valid in the US) - this means that people who contribute to and/or distribute WINE cannot sue WINE (or WINE users) for patent infringement. - It is compatible with the Apache 2.0 license, meaning that there is an even bigger pool of source code to draw from. - It helps ensure that companies cannot prevent people from modifying the source code by providing them explicit legal rights to change the code in these circumstances, and requiring information to allow users to change it. - For LGPL only, It makes 100% sure that GPL+linking exception and LGPL can be combined legally in all jurisdictions by merging them (which is essentially the only real difference, barring slightly different wording in the v2.1 of LGPL vs v2. of GPL) - It prevents patent agreements where only some people are protected. - It provides a mechanism for first-time accidental violations to be 'cured' more easily - ... and lots of other minor changes to improve the validity of the legal status of the license. There are some points not directly related to the license itself that might be of interest: - Samba has decided to become GPL3+ only, as they want the added protections provided by the license. WINE and Samba seem like projects that may potentially wish to share code (a very quick search brings up articles like this http://www.winehq.org/?issue=272), and if WINE sticks to supporting GPLv2+ rather than GPLv3+, then WINE will no longer be able to integrate Samba code. - Solaris may go GPLv3, another potentially useful repository of code to draw from that would not be possible under GPLv2. So as you can see, (L)GPL version 3 has a lot of benefits. It also has broad support (excluding Linus of course, who I must point out objects only to a single clause in the license that can be resolved by adding an extra permission, as GPLv3 permits), including strong corporate backing (e.g. IBM, Red Hat, MySQL, Sun, even Novell). As one of the projects that Microsoft would most like to destroy, the added protections in this updated version of the license would seem even more valuable. Kind regards, Ian Macfarlane ps: As a last note to Damjan - all GPL versions have been considered both radical and political when they were released. In retrospect, the protections that they provided have been considered invaluable.
Re: Make visible mdi client window before as Switch Maximized MDI Children test will be activated. [try2]
Dmitry Timoshkov пишет: Anatoly Lyutin [EMAIL PROTECTED] wrote: You can find the results of the test run under XP here: http://test.winehq.org/data/200707121000/xp_XP-PRO-IE7/user32:msg.txt I get the same failures. Thanks. I have viewed this. It was failed on 0x00ae messages. I could not find description of this message. Do you know something about it? It's a not documented XP message, have a look how other message sequences cope with it. Ok. Thank you. http://test.winehq.org/data/200707121000/2003_W2K3-SE-SP2/user32:msg.txt shows that the run under W2K3 has exactly the same failures in your test. Hmm.. I want to asked you about this: msg.c:3285:expected 0008 - actual 0008 msg.c:3285:expected 0281 - actual 0007 msg.c:3285:expected 0281 - actual 0007 msg.c:3285:expected 8005 - actual 0007 msg.c:3285:expected 0007 - actual 0007 msg.c:3285:expected 0009 - actual 0009 msg.c:3285:expected 0008 - actual 0008 msg.c:3285:expected 0281 - actual 0007 msg.c:3285:expected 0281 - actual 0007 msg.c:3285:expected 8005 - actual 0007 msg.c:3285:expected 0007 - actual 0007 msg.c:3285:expected 0222 - actual 0222 msg.c:3285:expected 0047 - actual 0047 msg.c:3287:end of test for switch maximized MDI children Why does not this fail? Is this correct? You have in view of it? Sorry, I don't understand what you are trying to ask, or why the sequence above should fail. I have asked that I can not understand why in test expected and obtained message does not coincide and test does not fail. Ex.: msg.c:3285:expected 0008 - actual 0008 msg.c:3285:expected 0281 - actual 0007 msg.c:3285:expected 0281 - actual 0007 msg.c:3285:expected 8005 - actual 0007 Why distinction between the expected and the obtained messages leads to fail in another tests but not fail in this place? I very want to understand difference. or you mean that failed on : msg.c:3271:expected 0001 - actual 0001 msg.c:3271:expected 0046 - actual 0046 msg.c:3271:expected 0083 - actual 0024 msg.c:3271: Test failed: Create maximized visible 2nd MDI child 2 window(Switch test) But I take this part from another test only for creating MDI child. I can see msg sequence for this test and fix it if I can. I see 2 failures in your test in the run under W2k3, and 3 failures under XP in the logs referenced above. That's right. But there 2 failures are not mine ( More precisely they directly do not concern to my test. ) These are tests for creation MDI children. Not switching. -- Best regards Anatoly Lyutin.
Re: Make visible mdi client window before as Switch Maximized MDI Children test will be activated. [try2]
Dmitry Timoshkov wrote: Anatoly Lyutin [EMAIL PROTECTED] wrote: If a message is marked as optional it can be skipped without causing the test to fail. Thank you. I did not know about it. It will help me. Here are the failures I see in http://test.winehq.org/data/200707121000/2003_W2K3-SE-SP2/user32:msg.txt msg.c:3252: Test failed: Create maximized visible 1st MDI child window(Switch test): the msg 0x0081 was expected, but got msg 0x0024 instead msg.c:3271: Test failed: Create maximized visible 2nd MDI child 2 window(Switch test): the msg 0x0083 was expected, but got msg 0x0024 instead I have reviewed this. This my mistake. You are right. I try to fix it. Thanks. Same failures exist in the XP run, plus another one: msg.c:3285: Test failed: Child not switch correctly -- Best regards Anatoly Lyutin.
Re: programs/winefontcfg: Add winefontcfg (try 3)
All in all the app looks like it's coming along nicely.
I apologize for catching so few problems in each pass,
but we'll get there.
Is there a way you can get the path to the currently running
instance instead of hardcoding it?
Then it would work even if winefontcfg isn't on the PATH.
+static const WCHAR cmdstr[] = {
+'w', 'i', 'n', 'e', 'f', 'o', 'n', 't', 'c', 'f', 'g', '.',
'e', 'x', 'e', '.', 's', 'o', ' ',
You're still using nonstandard C; you can't have
initializers on nonstatic arrays. This is the third
time I have pointed this out; you should look
to make sure you don't do this anywhere in the program.
You should make sure the app can build with visual C 6 if you haven't
lately, too.
+static void TabSelChanged(HWND hTab)
+{
+int tab[NUMTAB][MAXOBJPERTAB] = {
Say, why is hwndTab static here? I bet that's a cut and paste error:
+static HWND InitTab(HWND hdlg, HFONT hf)
+{
+static HWND hwndTab;
Looks like variable reuse abuse here; maybe you should
have a more mnemonic name for the return value of wcstolong:
+j = wcstolong(buf);
It might be nice to have comments identifying the big hunks
of the program, e.g. if all the code for one tab was grouped under
a comment with the name of the tab.
- Dan
Re: Should Wine move to LGPL 3?
The GPL3 has no track record so far, and it's too political and controversial for my liking. Let's wait a while before making the decision. Many groups are exceedingly worried about parts of GPL3. Not only commercial companies who may not have been obeying the general spirit of the GPL, but also people writing software that is BSD licensed are worried about having GPL3 utilities included in a software release, and having GPL3 source residing in the local CVS tree. Code licensed under BSD is not compatible with GPLv2. They can't include GPLv2 code in codebase licensed under BSD. So there is no difference between GPLv2 and GPLv3 for BSD people. -- Tomas
Re: Should Wine move to LGPL 3?
On 7/13/07, Ian Macfarlane [EMAIL PROTECTED] wrote: I've been meaning to ask about this since (L)GPL3 was released. I'd also like to weigh in on my reasons for liking the (L)GPLv3. The termination clause is clarified and a grace period added for compliance. As it stands right now, if someone was to inadvertently not adhere to the terms of a (L)GPLv2 program an over zealous major contributor could revoke distribution rights downstream to the offender even if the offender was in the process of trying to remedy the situation. It may only be a technicality but this bothers me. When corporate powers, with their own motives of profit outweigh commitment to FreeSoftware, are major contributors all the loopholes have to be closed. Imagine a world where SCO had contributed a lot of (L)GPL code and then they had gotten lucky to find a technicality in the license to revoke it for everyone. -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: Should Wine move to LGPL 3?
Ian Macfarlane wrote: - Samba has decided to become GPL3+ only, as they want the added protections provided by the license. WINE and Samba seem like projects that may potentially wish to share code (a very quick search brings up articles like this http://www.winehq.org/?issue=272), and if WINE sticks to supporting GPLv2+ rather than GPLv3+, then WINE will no longer be able to integrate Samba code. This point is actually moot. Samba is GPL and Wine is LGPL. I don't see v3 having changed something in regard to that. If Wine wants to use Samba code it has to ask the people that own the copyright to relicense their work. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111
Re: Should Wine move to LGPL 3?
On 7/13/07, Tomas Kuliavas [EMAIL PROTECTED] wrote: Code licensed under BSD is not compatible with GPLv2. They can't include GPLv2 code in codebase licensed under BSD. So there is no difference between GPLv2 and GPLv3 for BSD people. BSDv2 is compatible with all versions of the GPL. Very little code is left floating around under the orginal BSD license these days. -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: [msi/tests] Remove the whole directory after the test
On 7/13/07, Paul Vriens [EMAIL PROTECTED] wrote: Hi, RemoveDirectory only removes empty directories. Changelog Remove the whole directory after the test No, this is wrong. The line above, CreateDirectory(msitest\\msitest, NULL); is what needs to be removed. -- James Hawkins
Re: Should Wine move to LGPL 3?
Code licensed under BSD is not compatible with GPLv2. They can't include GPLv2 code in codebase licensed under BSD. So there is no difference between GPLv2 and GPLv3 for BSD people. BSDv2 is compatible with all versions of the GPL. Very little code is left floating around under the orginal BSD license these days. Last time I've checked programmers could use code licensed under BSD license in GPL software, but they couldn't use code licensed under GPL in BSD licensed software. BSD is compatible with GPL, but GPL is not compatible with BSD. BSD people are not concerned about compatibility of BSD license with GPL, they are concerned about incompatibility of GPL with BSD. Same thing applies to GPLv2 and GPLv3. The only people worried about GPLv3 and not worried about GPLv2, are the ones that use GPL software and restrict end user rights with hardware or patents. -- Tomas
Re: programs/net: Add russian resources
Konstantin Kondratyuk [EMAIL PROTECTED] wrote: Changelog: add russian resources in programs/net Did you test this translation? You are using KOI8-R which won't work properly in russian resources. -- Dmitry.
Re: [msi/tests] Remove the whole directory after the test
James Hawkins wrote: On 7/13/07, Paul Vriens [EMAIL PROTECTED] wrote: Hi, RemoveDirectory only removes empty directories. Changelog Remove the whole directory after the test No, this is wrong. The line above, CreateDirectory(msitest\\msitest, NULL); is what needs to be removed. You mean the line that you wrote ;-). I'll sent another patch. Cheers, Paul.
Re: [Resend PATCH 2/2] gdi32: Do not fill in the color table if lpvBits is NULL
On 13/07/07, Jeremy White [EMAIL PROTECTED] wrote: --- dlls/gdi32/dib.c | 14 +++--- 1 files changed, 11 insertions(+), 3 deletions(-) The patch mixes tabs and spaces. Also, in general, I don't think we should include text from MSDN.
Re: unsuspected success in tests/monthcal?
Committish 7495d changed the rendering of the calendar. Just by chance, the coordinates used in the hit test now lands on a spot that passed the hit test. On 7/13/07, Michael Stefaniuc [EMAIL PROTECTED] wrote: Marcus Meissner wrote: For some days I now get unexpected successes in dlls/comctl32/tests/monthcal.c. ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so monthcal.c touch monthcal.ok err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp= lp= err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=0001 lp= err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp= lp= err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp= lp= err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp= lp= err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=0001 lp= monthcal.c:818: Test succeeded inside todo block: Expected 131073, got 131073 make[2]: *** [monthcal.ok] Error 1 Does anyone else see them too? I get this one: /home/michi/work/wine/tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so /home/michi/work/wine/dlls/comctl32/tests/monthcal.c touch monthcal.ok monthcal.c:773: Test succeeded inside todo block: Expected 65536, got 65536 make[2]: *** [monthcal.ok] Error 1 bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111
RE: [Resend PATCH 2/2] gdi32: Do not fill in the color table iflpvBits is NULL
The patch mixes tabs and spaces. Also, in general, I don't think we should include text from MSDN. *blush*. Teach me to edit this on a test machine, without my .vimrc... I'll tweak the comment, but I felt it was important to motivate the if statement; I don't feel that it's obvious from the API why you fill in color sometimes and not others. Cheers, Jeremy p.s. While I'm coming clean, *another* failure on my part was to fail to credit Huw; this is mostly his insight. I provided the clue, and the hopeless failure to get a clean patch in :-/.
Re: Should Wine move to LGPL 3?
Am Freitag, 13. Juli 2007 17:22 schrieb Kai Blin: What specifically are we waiting for? Until the GPLv3 is tested in court? Until someone TiVolizes Wine? Christmas? Some possible TiVolization of wine I have brought up on #winehackers with third party signatures: Hypothetial: Assumed ddraw.dll was signed by Microsoft. Now we have an app that checks for this signature, and refuses to run otherwise. This app is not part of wine, and it is not LGPLed. Now some company lures Microsoft into signing a compiled ddraw.dll.so, and ships a wine build which makes that picky app happy. They provide the source. A user recompiles, and cannot use his own build because the non LGPL app, not shipped by that company refuses because of a missing signature. Would the company shipping the signed DLL build be in violation of the LGPL v3? They do not own the key, and they do not have any influence on the third party app that refuses to run. Where could this apply in practise: - If we ever implement Vista's protected audio or video DLLs we may need a signature on them. - Parallels is shipping Wine's D3D code for Windows. Windows Vista, especially the 64 bit edition, is pretty picky regarding unsigned drivers. Wine's code in Parallels is technically not in the position of a driver, but it is related. PUMA or PVP(or however the DRM in Vista is called these days) will most likely never work on any platform whose fundamentals are open source, so scenario 1 is most likely moot. Scenario 2 doesn't have any technical restrictions, but Microsoft signing Wine code sounds like hell freezing over. But that was said about Novell-Like contracts too. So it may be unlikely, but TiVolization of Wine can happen. But are the above two scenarios against our interests?
Re: Should Wine move to LGPL 3?
On Friday 13 July 2007 18:23:32 Michael Stefaniuc wrote: Ian Macfarlane wrote: - Samba has decided to become GPL3+ only, as they want the added protections provided by the license. WINE and Samba seem like projects that may potentially wish to share code (a very quick search brings up articles like this http://www.winehq.org/?issue=272), and if WINE sticks to supporting GPLv2+ rather than GPLv3+, then WINE will no longer be able to integrate Samba code. This point is actually moot. Samba is GPL and Wine is LGPL. I don't see v3 having changed something in regard to that. If Wine wants to use Samba code it has to ask the people that own the copyright to relicense their work. Yes, I'm afraid I have to agree here. Samba-Wine cooperation on the code level is hampered by licensing issues anyway. However, even though this point is not valid, the other points certainly are. For what it's worth, switching to the LGPLv3 gets a +1 from me. Unless someone can come up with a scenario where the LGPLv3 would actually be harmful, let's switch. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: Should Wine move to LGPL 3?
The usual disclaimer, IANAL, yadda yadda. On Fri, Jul 13, 2007 at 10:55:38PM +0200, Stefan Dösinger wrote: Hypothetial: Assumed ddraw.dll was signed by Microsoft. Now we have an app that checks for this signature, and refuses to run otherwise. This app is not part of wine, and it is not LGPLed. Now some company lures Microsoft into signing a compiled ddraw.dll.so, and ships a wine build which makes that picky app happy. They provide the source. A user recompiles, and cannot use his own build because the non LGPL app, not shipped by that company refuses because of a missing signature. Would the company shipping the signed DLL build be in violation of the LGPL v3? They do not own the key, and they do not have any influence on the third party app that refuses to run. No, I think this is (perhaps deliberately?) not included in requiring Installation Information: GPLv3 6. Conveying Non-Source Forms. contains: G If you convey an object code work under this section in, or G with, or specifically for use in, a User Product, and the G conveying occurs as part of a transaction in which the right of G possession and use of the User Product is transferred to the G recipient in perpetuity or for a fixed term (regardless of how G the transaction is characterized), the Corresponding Source G conveyed under this section must be accompanied by the G Installation Information. This is because object code and User Product (here the third party app.) are in your case not part of a transaction (a as in the meaning of one, can be derived from context), nor is the origin the same in both transactions. There is a twist, because our company didn't sign the binaries in our hypothetical case, but Microsoft did. So Microsoft would convey the object code to our company and thus would need to obey it's licence. Another twist is that the LGPL (both v3 and v2.1!) require that the combined work will operate properly with a modified version. So it seems that the LGPL v2.1 would already forbid something like this case (obviously this affects the one who wants to combine the work, be it a user who installs the third party application or the third party who bundles wine with their application). Scenario 2 doesn't have any technical restrictions, but Microsoft signing Wine code sounds like hell freezing over. But that was said about Novell-Like contracts too. Btw. the GPL v3 does only speak about something like technical restriction in: 3. Protecting Users' Legal Rights From Anti-Circumvention Law. No covered work shall be deemed part of an effective technological measure under any applicable law... This part does not try or want to forbid copy prevention (TPM enforced or not). The LGPL also has an exception for this section: You may convey a covered work [...] without being bound by section 3 of the GNU GPL. . The part that should prevent tivo-ization is the part about Installation Information under 6. Conveying Non-Source Forms., which avoids to talk about something like that. I hope nothing slipped my mind here :) , Jan
Re: programs/winefontcfg: Add winefontcfg (try 3)
Nigel wrote: Is there a way you can get the path to the currently running instance instead of hardcoding it? Then it would work even if winefontcfg isn't on the PATH. +GetFullPathNameW(exename, MAXSTRLEN, szFullPathName, NULL); That just prepends the current directory onto the given filename, which is not what you want, I think. I think you want something like GetModuleFileName(NULL, szPathFullName, MAXSTRLEN).
Re: [Resend PATCH 2/2] gdi32: Do not fill in the color tableiflpvBits is NULL
Jeremy White [EMAIL PROTECTED] wrote: p.s. While I'm coming clean, *another* failure on my part was to fail to credit Huw; this is mostly his insight. I provided the clue, and the hopeless failure to get a clean patch in :-/. Since you are going to resend the patch anyway please add a missing HeapFree call to the test. -- Dmitry.
