August 1999 - XEmacs-Beta - XEmacs Mailing List Archives

[Fwd: Xemacs 21.1.6 minor build problem.] 26 years

Jason Kim

1 participants
0 comments

Re: Qt/XEmacs vs. the GPL (was: Re: kde-xemacs or gnome-xemacs?) 26 years

Alastair Burt

Per Abrahamsen <abraham(a)dina.kvl.dk> writes: > Traditionally, the FSF has ignored violations when people have > linked with non-GPL compliant free software. I have no idea if > this will begin to include QPL now that it has become free > software. RMS's message to gnu.misc.discuss when Troll Tech changed the QPL seemed to indicate that the FSF would grudgingly accept linking with QT [1] Subject: On the QPL Date: 1998/11/21 Author: Richard Stallman <rms(a)gnu.org> The latest news about Qt is that Troll Tech has proposed to rerelease it under a new license, the QPL. This license would make Qt free software; there would no longer be a principled reason to reject using it, and thus no principled reason to reject using KDE. Indeed, if Qt is Troll Tech's only product (which might be so; I don't know), then by a strange reversal, this would actually make them a free software company. However, the QPL has major practical drawbacks: source modifications can be released only in the form of patches, and it is incompatible with the GNU GPL. This means that linking existing GPL-covered software with Qt would require giving special permission. With Qt being free software, there would be no fundamental reason to refuse this special permission, but it remains better if we can avoid it. As a practical matter, it will be preferable to use Harmony, both to avoid the need to make special exceptions, and to avoid the practical inconvenience of the requirement to distribute modifications patches. --- Alastair Footnotes: [1] http://x47.deja.com/[ST_rn=ap]/getdoc.xp?AN=414217499&CONTEXT=935307065.5...

1 participants
0 comments

Re: kde-xemacs or gnome-xemacs? 26 years

Justin Vallon

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > Jan Vroonhof writes: > > Kyle Jones <kyle_jones(a)wonderworks.com> writes: > > > > > We already allow XEmacs to link against vendor provided non-free > > > libraries. Motif, for instance. What's the difference? > > > > Motif is an RMS sanctioned "system library". I have nothing against > > linking with QT. I am simply not prepared to take any heat from the > > FSF for something simple as looks. > > Oh, right, this matters for the binary kits. For source > distributions, we can use any library. I don't see any difference. Aren't the binary kits dynamically linked against Motif, anyway. Are you allowed to ship archive linked Motif applications? As for non-distribution of third-party libraries, what about requiring dynamic linking? Surely there is nothing anybody could say that would prevent a dynamically linked Qt executable from being freely distributed, no? -- -Justin vallon(a)mindspring.com

3 participants
2 comments

Re: kde-xemacs or gnome-xemacs? 26 years

Justin Vallon

Glynn Clements <glynn(a)sensei.co.uk> writes: > Justin Vallon wrote: > > > The point is whether an xemacs binary linked against Qt (dynamically) > > can be (legally) distributed to the end-user, or whether that end-user > > needs to compile xemacs from source to be allowed to use Qt. > > Which seems to hinge on whether a binary is considered a derivative > work of any header files which are used in its compilation. The answer > to this doesn't seem (to me) to be particularly clear. Commercially: This would be the case [with respect to any reasonably sane license]. If I get a developer's license, I can build and distribute the program against licensed code. Some dev licenses are 'run-time' licenses that allow me to redistribute libraries. Others require that each end-user purchase their library/code. The situation where you could not redistribute such dynamically linked code would be absurd, because it would effectively prohibit you from distributing object code in any form. GPL: Maybe it isn't a sane license. -- -Justin vallon(a)mindspring.com

1 participants
0 comments

Qt/XEmacs vs. the GPL (was: Re: kde-xemacs or gnome-xemacs?) 26 years

Per Abrahamsen

There is a lot of misunderstandings in this thread. I have spend a lot of time on these issues, and I believe I can state both the FSF position and the opposition. Please read. 1. FSF position: GPL'ed code can be distributed linked with code under any license that has no restriction that are not also in the GPL. This means you can link and distribute with PD code, X11 code, and LGPL code, as all these have fewer restrictions that the GPL. The BSD license and the QPL both have additional restrictions, so they are not GPL-compatible, even though they are "free software". Traditionally, the FSF has ignored violations when people have linked with non-GPL compliant free software. I have no idea if this will begin to include QPL now that it has become free software. Opposition: Recently a lot of people have started claiming that _only_ the GPL is compatible with the GPL. This seem to be a meme based on a misunderstating, rather than on someone who know the law. I haven't seen it backed (nor refuted) by those people who know the law. It is always people repeating what they have read other people say on the net. 2. FSF position: There is no distinction between static and dynamic linking. Not even if you don't distribute the dynamic library. Opposition: There are. If the user does the link, the GPL does not apply. 3. FSF position: The FSF has ignored the issue of include files, it has been irrelevant because of their position on dynamic libraries. 4. FSF position: Motif is a "standard system component", and can therefore be linked with GPL software. Opposition: That is by no mean clear. 5. FSF position: Qt is _not_ a "standard system component". However, this position may have changed since Qt is now part of most Linux distributions. Opposition: That is by no mean clear. 6. FSF position: Distributing GPL _source_ that depend on non-system GPL-incompatible libraries are a violation. Opposition: No way! So the situation is: Given how heated the KDE/Qt vs GPL debate was, it is almost certain that RMS will be forces to comment on a Qt/KDE enabled XEmacs. The most likely outcome is that a source distribution will be OK, as long as you still can build XEmacs without Qt, while a binary distribution will be seen as a violation of his copyright. It is not certain that a court will agree with RMS. My *opinion* is that RMS, although he disagree with the project, never has challanged the XEmacs developers right to do what they do. It would be stupid to change that now. So ask first.

2 participants
1 comments

Re: udp support 26 years

Stephen Tse

Adrian Aichner <aichner(a)ecf.teradyne.com> writes: > >>>>> "Stephen" == Stephen Tse <stephent(a)sfu.ca> writes: > > Stephen> Here is the refined version of my earlier patch. Can > Stephen> anyone in NT check if I broke anything in process-nt.c, > Stephen> please? ^ > | > Hi Stephen, | > | > this is the reason why I sent in the build-report. =) I knew it. I just wondered it'd be nice if _someone_ takes the chance to implement udp in nt. Nevermind.

1 participants
0 comments

eicq 0.3.0 pre-release 26 years

Stephen Tse

http://www.sfu.ca/~stephent/eicq/download/eicq-0.3.0-alpha.tar.gz Here is a working version of eicq using new internal udp support and c extension module. Follow the installation in README, but it is not enough. You need to unpack eicq-module.tgz to your module path and run make. I do not update Makefile or install method since I know there will be massive change with packaging. Thank you.

1 participants
0 comments

Re: udp support 26 years

Adrian Aichner

>>>>> "Stephen" == Stephen Tse <stephent(a)sfu.ca> writes: Stephen> Here is the refined version of my earlier patch. Can Stephen> anyone in NT check if I broke anything in process-nt.c, Stephen> please? ^ | Hi Stephen, | | this is the reason why I sent in the build-report.

1 participants
0 comments

screenshot (Re: [SITE] update progress) 26 years

Stephen Tse

john s jacobs anderson <jacobs(a)azstarnet.com> writes: > *THINGS I NEED* > if anyone would like to contribute some screenshots of cool looking > XEmacsen, that would be nice. > http://www.sfu.ca/~stephent/eicq/eicq.gif This is my desktop screenshot containing only two frames of xemacs. But it is mule'd and running my eicq; I am not sure that's what you want. I appreciate you put some caption for it.

1 participants
0 comments

Re: kde-xemacs or gnome-xemacs? 26 years

William M. Perry

Glynn Clements <glynn(a)sensei.co.uk> writes: > Justin Vallon wrote: > > > The point is whether an xemacs binary linked against Qt (dynamically) > > can be (legally) distributed to the end-user, or whether that end-user > > needs to compile xemacs from source to be allowed to use Qt. > > Which seems to hinge on whether a binary is considered a derivative work > of any header files which are used in its compilation. The answer to this > doesn't seem (to me) to be particularly clear. The bit with header files depends on the header files. Typical example is the old bison headers, that made it impossible to develop a lex/yacc grammar with bison. Newer versions of bison now have a special exemption for that one header file - from a bison-generated file: /* As a special exception, when this file is copied by Bison into a Bison output file, you may use that output file without restriction. This special exception was added by the Free Software Foundation in version 1.24 of Bison. */ The Qt header files don't pollute derivative works like the GPL, as far as I know. -- William M. Perry <wmperry(a)gnu.org> Contrary to what most people say, the most dangerous animal in the world is not the lion or the tiger or even the elephant. It's a shark riding on an elephant's back, just trampling and eating everything they see.

1 participants
0 comments

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta August 1999