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
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?
Why should Wine move?
bye michael
On 7/13/07, Michael Stefaniuc mstefani@redhat.com 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?
Why should Wine move?
Why shouldn't Wine move?
bye michael --
On 7/13/07, Tom Wickline twickline@gmail.com wrote:
On 7/13/07, Michael Stefaniuc mstefani@redhat.com 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?
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
On Friday 13 July 2007 13:18:41 Damjan Jovanovic wrote:
On 7/13/07, Tom Wickline twickline@gmail.com 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
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?
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
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
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.
On 7/13/07, Tomas Kuliavas tokul@users.sourceforge.net 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.
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.
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)
On 7/13/07, Victor ErV2005@rambler.ru wrote:
Also Wine isn't just a library. (LGPL)
Nor is the LGPL a license exclusively for libraries.
--tim
-
Damjan Jovanovic -
David Laight -
Jan Zerebecki -
Kai Blin -
Michael Stefaniuc -
Stefan Dösinger -
Steven Edwards -
Tim Schmidt -
Tom Wickline -
Tomas Kuliavas -
Victor