Re: Should Wine move to LGPL 3?
On 7/24/07, Scott Ritchie [EMAIL PROTECTED] wrote: MS explicitly excluded Wine from that deal anyway. Thanks, Scott Ritchie I dont think that it matters what the patent covenant covers or not for this to work, all it takes is that they distribute it via vouchers as part of the SuSE distribution, and with some luck in the unfolding of these events, LGPLv3 patent provisions might disarm them by itself, but IANAL...
Re: Should Wine move to LGPL 3?
On 7/25/07, Scott Ritchie [EMAIL PROTECTED] wrote: On Wed, 2007-07-25 at 21:01 +0200, Marcus Meissner wrote: On Wed, Jul 25, 2007 at 03:28:13PM +0100, Damjan Novak wrote: On 7/25/07, Damjan Novak [EMAIL PROTECTED] wrote: I dont think that it matters what the patent covenant covers or not for this to work, all it takes is that they distribute it via vouchers as part of the SuSE distribution, and with some luck in the unfolding of these events, LGPLv3 patent provisions might disarm them by itself, but IANAL... On second thought, reading further the text and FAQ of the licence, I think Im wrong, sorry. Also, Wine is not on SLED/SLES, just on openSUSE, which is not protected by the patent covenant. And it is explicitly left out. Ciao, Marcus On the other hand, it's quite possible that Parallels would enter into some sort of patent thingy with Microsoft, and they DO distribute Wine. Thanks, Scott Ritchie But it's only wined3d right? And that's based on OpenGL. Why they would even consider a patent convent would boggle me. Of course, the threat for unenumerated patents is enough for some. Jesse
Re: Should Wine move to LGPL 3?
On Wed, 2007-07-25 at 21:01 +0200, Marcus Meissner wrote: On Wed, Jul 25, 2007 at 03:28:13PM +0100, Damjan Novak wrote: On 7/25/07, Damjan Novak [EMAIL PROTECTED] wrote: I dont think that it matters what the patent covenant covers or not for this to work, all it takes is that they distribute it via vouchers as part of the SuSE distribution, and with some luck in the unfolding of these events, LGPLv3 patent provisions might disarm them by itself, but IANAL... On second thought, reading further the text and FAQ of the licence, I think Im wrong, sorry. Also, Wine is not on SLED/SLES, just on openSUSE, which is not protected by the patent covenant. And it is explicitly left out. Ciao, Marcus On the other hand, it's quite possible that Parallels would enter into some sort of patent thingy with Microsoft, and they DO distribute Wine. Thanks, Scott Ritchie
Re: Should Wine move to LGPL 3?
On Wed, Jul 25, 2007 at 03:28:13PM +0100, Damjan Novak wrote: On 7/25/07, Damjan Novak [EMAIL PROTECTED] wrote: I dont think that it matters what the patent covenant covers or not for this to work, all it takes is that they distribute it via vouchers as part of the SuSE distribution, and with some luck in the unfolding of these events, LGPLv3 patent provisions might disarm them by itself, but IANAL... On second thought, reading further the text and FAQ of the licence, I think Im wrong, sorry. Also, Wine is not on SLED/SLES, just on openSUSE, which is not protected by the patent covenant. And it is explicitly left out. Ciao, Marcus
Re: Should Wine move to LGPL 3?
On Sun, 2007-07-22 at 19:22 +0200, Damjan Novak wrote: Hi! I just stumbled on this list and discussion, and though to just mention a highly speculative, but potentially very rewarding advantage of using LGPLv3 for wine. According to this opinion at groklaw: http://www.groklaw.net/article.php?story=20070709101318827 Microsoft MIGHT end up being effectively forced to distribute GPLv3 code under the deal with Novell, and hence loose any chance to sue about patents any so licenced projects included in SuSE, and I suppose wine is included in that distro. Given the nature of the wine project, Im thinking it could benefit greatly from such potential shelding from Microsofts patent portfolio, if things happen to unfold in this very optimistic scenario.. just a thought... MS explicitly excluded Wine from that deal anyway. Thanks, Scott Ritchie
Should Wine move to LGPL 3?
Hi! I just stumbled on this list and discussion, and though to just mention a highly speculative, but potentially very rewarding advantage of using LGPLv3 for wine. According to this opinion at groklaw: http://www.groklaw.net/article.php?story=20070709101318827 Microsoft MIGHT end up being effectively forced to distribute GPLv3 code under the deal with Novell, and hence loose any chance to sue about patents any so licenced projects included in SuSE, and I suppose wine is included in that distro. Given the nature of the wine project, Im thinking it could benefit greatly from such potential shelding from Microsofts patent portfolio, if things happen to unfold in this very optimistic scenario.. just a thought...
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: 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: 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: 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.
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: 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: 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: 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: 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
