Weekly Edition
Return to the Press pageSponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
Stallman on XFree86 License Change (OfB.biz)
Open for Business talks
with Richard Stallman about the XFree86 license modifications.
"So what is the problem with the new license? "The details of the
requirement conflict with the GNU GPL," Stallman explained, "anyone linking
GPL-covered applications with that XFree86 code would be violating the
GPL.""
(Log in to post comments)
Stallman on XFree86 License Change (OfB.biz) Posted Feb 19, 2004 20:37 UTC (Thu) by ccchips (guest, #3222) [Link] I hope they can get the license compatable. Meanwhile, I get the feeling that the distros are holding off more because of having to get the license texts into the proper places.Other than hard linkage to the kernel, is there some other issue? Are some of the drivers GPL? If so, can they be modules?
Kernel? I'm more concerned about the userspace Posted Feb 19, 2004 21:00 UTC (Thu) by proski (subscriber, #104) [Link] I don't know why you mentioned the kernel. The server is not linked with anything. It interoperates with the kernel using the kernel syscall interface. I don't think the server is an issue.I think the issue is with the software under GPL and LGPL that is linked with XFree86 libraries, such as GNOME and KDE. A workaround would be to distribute 4.4 server and 4.3 libraries, or even the X libraries from freedesktop.org.
Kernel? I'm more concerned about the userspace Posted Feb 19, 2004 21:27 UTC (Thu) by ccchips (guest, #3222) [Link] I must be mistaken, then, because I thought the issue of compatability applied only for static linkage.
Kernel? I'm more concerned about the userspace Posted Feb 19, 2004 22:21 UTC (Thu) by josh_stern (guest, #4868) [Link] I believe that RMS is primarily concerned with client apps that statically link to xlib (which is also part of the XFree86 distribution).
Kernel? I'm more concerned about the userspace Posted Feb 20, 2004 10:02 UTC (Fri) by djabsolut (guest, #12799) [Link] notwithstanding the larger question, why would anyone statically link to xlib ?
Kernel? I'm more concerned about the userspace Posted Feb 20, 2004 15:52 UTC (Fri) by josh_stern (guest, #4868) [Link] For a linux distributor that wanted to make, say, an installer or rescue cdrom that only used lowest common denominator graphics and was supposed to run before the bulk of the software got installed, I can imagine static linking making sense. An embedded application could be another example.
Kernel? I'm more concerned about the userspace Posted Feb 20, 2004 11:05 UTC (Fri) by bockman (subscriber, #3650) [Link] Not only statically linked libraries.I've read somewhere (I think in debian-legal) that FSF holds that also dynamic linking leads to a 'derived product'. So it seems that each GPL application that uses the X libraries is in conflict with new XFree86 licence, unless XFree86 makes a 'special exception' for libraries.
Kernel? I'm more concerned about the userspace Posted Feb 19, 2004 22:28 UTC (Thu) by rsidd (subscriber, #2582) [Link] No, the GPL covers dynamic linkage too.
Kernel? I'm more concerned about the userspace Posted Feb 19, 2004 22:51 UTC (Thu) by josh_stern (guest, #4868) [Link] IANAFSFL, but..The GPL can apply to dynamic linkage, but in this case, since the dynamic libraries in question are part of the system, independent works, and typically distributed separately, the restriction doesn't apply for dynamic linkage.
It is a problem that needs to be fixed Posted Feb 19, 2004 23:09 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] The FSF's lawyer argues that there is a problem even in the case of dynamic linking. Certainly there are various schemes for working around any problems, like building KDE and Gnome against 4.3: that way the app can't be called a derivative work of 4.4 even if an end user uses a 4.4 shared library. But why introduce a big messy legal minefield into the middle of your distro? The Linux and BSD distributors are going to stay away from this one until there's a settlement.
It is a problem that needs to be fixed Posted Feb 20, 2004 3:35 UTC (Fri) by josh_stern (guest, #4868) [Link] From the GPL itself:>However, as a special exception, the source code distributed need not >include anything that is normally distributed (in either source or binary >form) with the major components (compiler, kernel, and so on) of the >operating system on which the executable runs, unless that component >itself accompanies the executable.
>I'm writing a Windows application with Microsoft Visual C++ (or Visual >Basic) and I will be releasing it under the GPL. Is dynamically linking my >program with the Visual C++ (or Visual Basic) run-time library permitted >under the GPL? I always heard these statements explained as an example of a class of exceptions for system/platform components. xlib certainly qualifies as a system/platform component for an xlib application. Regarding the point about distributors, I can only see how it applies to xlib applications they themselves have written, since many Linux distributors have 'merely aggregated' non-free works written by others for a long time). None of the above should be construed as an endorsement of the XFree86 team's irresponsible decision to cause unnecessary headaches for their users, though I do think that the situation highlights some technical flaws in the GPL.
It is a problem that needs to be fixed Posted Feb 20, 2004 4:38 UTC (Fri) by jamesh (subscriber, #1159) [Link] That system library exception in the GPL doesn't really help you if you are distributing both the X libraries and GPL apps together, like all Linux distros do.
It is a problem that needs to be fixed Posted Feb 20, 2004 5:12 UTC (Fri) by josh_stern (guest, #4868) [Link] For the case where the application Y was written by somebody else, if you agree that it is okay for *someone* to distribute Y with GPL license, then you are arguing that the distro people would somehow lose this right if they also distributed library X that Y happens to link to (and they even provide all source code for X). That doesn't make legal sense and is also contrary to the spirit of the GPL.
It is a problem that needs to be fixed Posted Feb 20, 2004 17:12 UTC (Fri) by piman (subscriber, #8957) [Link] That's exactly what that clause means. "You" is the licensee, not the original author of the software. This is why Debian can't distribute GPLd programs linked against OpenSSL, for example.
It is a problem that needs to be fixed Posted Feb 20, 2004 20:23 UTC (Fri) by josh_stern (guest, #4868) [Link] Debian is a collective that often adopts unusual interpretations of licenses in order to avoid internal squabbles. Also, I'm not clear about your example: is Debian saying they can't distribute those works because their previous distribution was a GPL violation,or because it would only become one were Debian to do the distribution, or because Debian want the freedom to create new modified works based on the GPL program. The differences are critical here. The first case is not a problem for xlib due to the system software exception, and I agree with the interpretation in the third case except that there are obvious ways to work around it in practice. But I claim that the second interpretation is an incorrect reading of the GPL itself. Consider:From the preamble: >To protect your rights, we need to make restrictions that forbid Someone supporting the second interpretation is arguing that the GPL is prohibiting the author and/or upstream distributors of a GPL licensed work from giving the same rights to a recipient (who happens to put together a Linux distro). Since the text above is actually part of the license and not simply a policy goal, your interpretation makes the GPL license self-contradictory.
It is a problem that needs to be fixed Posted Feb 21, 2004 19:35 UTC (Sat) by piman (subscriber, #8957) [Link] > Since the text above is actually part of the license and not simply a policy goal...Actually, the GPL's preamble is not part of the licensing terms. The system software exception does not apply if you are the one distributing the GPLd component and the system software. Debian distributes the system software. Ergo, Debian cannot distribute the GPLd components without an exception to the GPL to allow the distributed binaries to link to the GPL-incompatible parts of the system (OpenSSL being the most prominent example). You can replace "Debian" above with "Red Hat", "Mandrake", or any other organization that is not the copyright holder of the GPLd components in question. Strangely, www.gnu.org seems to be down right now, so I can't point you to the GPL FAQ where they discuss license exceptions.
It is a problem that needs to be fixed Posted Feb 21, 2004 23:45 UTC (Sat) by josh_stern (guest, #4868) [Link] > > Since the text above is actually part of the license and not simply a> >policy goal... >Actually, the GPL's preamble is not part of the licensing terms The preamble is part of the license so it is appropriate to use strong >The system software exception does not apply if you are If I'm not the original author of the software and it has
It is a problem that needs to be fixed Posted Feb 21, 2004 3:20 UTC (Sat) by vonbrand (subscriber, #4458) [Link] From the GPL itself:However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It is a weird feeling seeing this quote (obviously intended to cover closed source operating systems) applied to Linux distributions... and to X11, which is the open source (well, now sort of) windowing system on all closed source Unix systems which GNU set out to emulate.
Kernel? I'm more concerned about the userspace Posted Feb 20, 2004 2:12 UTC (Fri) by rsidd (subscriber, #2582) [Link] The key phrase in the GPL is "unless the libraries are distributed withthe application". Which is exactly what all linux distros and BSD's do. It would be ok for a third party to distribute GPL code for running on a linux machine, even with a proprietary X-server.
Kernel? I'm more concerned about the userspace Posted Feb 20, 2004 3:41 UTC (Fri) by josh_stern (guest, #4868) [Link] See my comment above. The GPL restrictions don't apply at the aggregation level, so that particular problem would only seem to apply to, say, a system installer that was written specifically to work with the new xlib.
Kernel? I'm more concerned about the userspace Posted Feb 20, 2004 17:49 UTC (Fri) by stevenj (subscriber, #421) [Link] It's not mere aggregation if one component depends on the other.
Kernel? I'm more concerned about the userspace Posted Feb 20, 2004 23:00 UTC (Fri) by josh_stern (guest, #4868) [Link] This dependence was designed by the original authors of the software. They already signed off on the possibility of using their GPL software with system components that are not GPL when they used a license with that exception. It isn't sensible to claim that using their work in accordance with this already forseeable type of combination amounts to creatinga newly derived work.
Kernel? I'm more concerned about the userspace Posted Feb 19, 2004 22:28 UTC (Thu) by rsidd (subscriber, #2582) [Link] The kernel problem is with the DRI modules, I believe.
Kernel? I'm more concerned about the userspace Posted Feb 20, 2004 0:59 UTC (Fri) by proski (subscriber, #104) [Link] You mean kernel modules or XFree86 modules? The kernel modules will keep the exisitng license, that's for sure. I cannot imagine any kernel maintainer applying a patch to the kernel that would change the license of the DRI modules to the one adopted by XFree86.If you mean the XFree86 modules, they are not linked to the kernel in any way.
Kernel? I'm more concerned about the userspace Posted Feb 20, 2004 2:21 UTC (Fri) by rsidd (subscriber, #2582) [Link] Kernel modules, but some modules come with the XFree86 source (lookin /usr/X11R6/src, which may or may not exist on your system). I think even the ones shipped separately are built inside the XFree86 tree.
Kernel? I'm more concerned about the userspace Posted Feb 20, 2004 10:54 UTC (Fri) by keithw (subscriber, #3127) [Link] The DRI modules are not being re-licensed - XFree86 doesn't have the ability to do so as they don't hold copyright on them.In fact, if you dig into it, the amount of code being re-licensed is remarkably little.
Dawes say the X Libs ARE GPL compatible, they dont use the new 1.1 license Posted Feb 20, 2004 7:23 UTC (Fri) by duncan (guest, #8429) [Link] Read David Dawes statement at http://www.xfree86.org/~dawes/pre-4.4/LICENSE.htmlIn particular, look at the discussion of GPL compatibility issues, To quote: The client-side X libraries distributed with this release (4.3.99.903) carry a subset of the acceptable licenses that satisfy an additional condition: they are GPL-compatible. Other portions of XFree86, including the X servers, may include code with licenses that are not GPL-compatible. Example of such licenses include some of the BSD-style licenses, the FreeType License, the SGI licenses and the XFree86 License version 1.1.
Kernel? I'm more concerned about the userspace Posted Feb 20, 2004 17:51 UTC (Fri) by mmarq (guest, #2332) [Link] " A workaround would be to distribute 4.4 server and 4.3 libraries, or even the X libraries from freedesktop.org. "yeah... If the Linux distros and the BSDs are going to fork XFree, they might as well dump the *ancient* xlib, for something much better and faster... the freedesktop.org x libraries come to mind...
Linking or distributing Posted Feb 19, 2004 23:30 UTC (Thu) by vondo (guest, #256) [Link] The article says anyone linking GPL software with X 4.4 is in violation of the GPL. My understanding is that this isn't strictly true; you have to distribute it to be in violation. As I understand the GPL, Microsoft could link GPL software into their own software all day, so long as they don't distribute it.
Linking or distributing Posted Feb 20, 2004 2:24 UTC (Fri) by rsidd (subscriber, #2582) [Link] That's right, I suppose he meant "any distributor." (It's also notillegal to link to non-GPL libraries that are a "standard part of the system" and "not distributed with your program", so third-party software shouldn't have a problem linking to XFree86 libraries either, just as they can link to proprietary Unix X libraries.)
OfB.biz doesn't resolve Posted Feb 20, 2004 10:27 UTC (Fri) by Duncan (guest, #6647) [Link] Unfortunately, OfB.biz is part of the contested .biz domain, with twocompeting top level implementations. OfB.biz happens to be on the officially blessed one, while the name server on my system, abiding by my policy settings, chooses to use the original one that was ignored when the contract was handed out to the new one. Thus, that site does not exist, for me, and I can't read any articles on it. Oh, well.. <shrug> I'm not going to change MYpolicy over it. Duncan
Useful links: GPL compatibility, XFree86 Posted Feb 20, 2004 15:10 UTC (Fri) by dwheeler (subscriber, #1216) [Link] For a short article on why GPL-compatibility is important, see Make Your Open Source Software GPL-Compatible. Or Else. The latest version includes some links, including links to a detailed analysis of the XFree86 licenses before this massive change by David Dawes. Note that it's not just the client libraries that are at issue; there are, for example, some efforts to put portions of the X Server into the Linux kernel framebuffer code, and that work would obviously be impacted by this sea change in the XFree86 license.
Stallman on XFree86 License Change (OfB.biz) Posted Feb 20, 2004 18:25 UTC (Fri) by mmarq (guest, #2332) [Link] IMHO, after reading all the comments, Linux needs a ALGA or ALVA (g=graphics;v=video), in GPL compatible licence, and that could concentrate all the efforts arround graphics/video from framebuffer, to video cards, to pointing devices, to a really advanced *Human Interface*...Only than all *small* attempts to control the pace and directives, of the extremely important graphics/video subsystem of Open Source Desktops, could be over...
|
|
||||||||||