Re: draft for new Vim license
[EMAIL PROTECTED] (Thomas Bushnell, BSG) wrote: Bram Moolenaar [EMAIL PROTECTED] writes: I have attempted to add the possibility to allow people to distribute a modified Vim, under the condition that they include the source code. This makes it possible to distribute it in a (more or less) closed group of people and not having to provide a copy to the maintainer (that's me). For example, it would be possible to distribute a modified version of Vim within a company, so long as the sources are also available to the people using this modified version of Vim. Thus it's possible that the changes are kept as a secret within that company. The new license you just posted, in my opinion, would be DFSG-free. It seems to me that it would also be GPL compatible, but I'm not certain and I'd want to hear what RMS has to say about that. I agree that the license is DFSG-free. However, I don't think that it is GPL-compatible. In the license, there are four options for distributing modified copies. The first option (3a) is just the old Vim license and is GPL incompatible. The second (3b) is permission to distribute those modified versions even if you're not the one who modified it. The third (3c) is more tricky. It reads c) Provide the changes, including source code, with every copy of the modified Vim you distribute. This may be done in the form of a context diff. You can chose what license to use for new code you add, so long as it does not restrict present or future official Vim distributions in any way. If the license were GPL-compatible, I could license my changes under the GPL, and never talk to the Vim maintainer. However, one of the things that Bram wants to be able to do is relicense the whole thing under a proprietary license. This is exactly the sort of thing that the GPL is designed to prevent. So a GPL patch would restrict future official Vim distributions. I don't think that there is a way out of this quandary. Relicensing the code of contributors under a proprietary license is one of Bram's goals with his license, and the GPL is just not compatible with it. The fourth option (3d) is very similar to the GPL's option of allowing written offers instead of actual source code. It has an enforced licensing problem that is very similar to the third part, but is otherwise (I think) compatible with the GPL. Regards, Walter Landry [EMAIL PROTECTED]
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
On Thu, Jan 03, 2002 at 06:45:50PM -0800, Thomas Bushnell, BSG wrote: [EMAIL PROTECTED] writes: I do not really understand why, I guess accepting it in the definition of derivative work is the basis, but I cannot help, but wonder as I have not seen legal challanges that support this. It's a perfectly normal case of a derivative work. When you link program A with program B, you are creating a derivative work, A+B. You can only distribute that work if the licenses of A and B permit it. Don't dismiss this as completely obvious. It's not uncontroversial. For example, the kernel is GPLed but will load and run programs with incompatible licenses. Those programs make syscalls to the kernel to perform system work; how is this permitted? It is so different from an incompatibly-licensed program linking to a GPLed library? The ldso license is interesting (/usr/doc/ldso/copyright, possibly only on potato or earlier systems). The commentary implies that ld.so deliberately uses the BSD license because the GPL is too strict. It also has the following paragraph: * It is the general understanding of the above contributors that a * program executable linked to a library containing code that falls * under the GPL or GLPL style of license is not subject to the terms of * the GPL or GLPL license if the program executable(s) that are supplied * are linked to a shared library form of the GPL or GLPL library, and as * long as the form of the shared library is such that it is possible for * the end user to modify and rebuild the library and use it in * conjunction with the program executable. This seems to suggest that a program linking to a GPLed library does not have to be GPLed itself. Interesting that the ld.so license avoids being GPLed anyway to avoid this exact problem. Tcl can dynamically load shared libraries so that scripts can use library functions. tcl itself appears to have a BSD-type license. What if a tcl script, using a non-GPL compatible license, causes tcl to load a GPL library (eg libreadline)? The script is being interpreted by the Tcl shell, it's not capable of being linked to anything itself. libterm-readline-gnu-perl is a package of a Perl module to use libreadline from Perl progams. According to the license, it's available under the same terms as Perl ie your choice of GPL or the Artistic license. But since any combination of GPL program + a GPL-compatibly-licensed program must by GPLed, you really can't use it under the Artistic license at all ie the GPL always dominates. So non-GPL programs apparently can't use that library. Getting off-topic a bit, there's an interesting clause in the license for libio, in /usr/doc/libc6/copyright (on potato anyway). As a special exception, if you link this library with files compiled with a GNU compiler to produce an executable, this does not cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public License. Why does the license require you to use a GNU compiler? Bizarre. Just some thoughts, Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
Hamish Moffatt [EMAIL PROTECTED] writes: Don't dismiss this as completely obvious. It's not uncontroversial. For example, the kernel is GPLed but will load and run programs with incompatible licenses. Those programs make syscalls to the kernel to perform system work; how is this permitted? Because the kernel is not one program together with the applications it runs. It is so different from an incompatibly-licensed program linking to a GPLed library? Yes, it is different. One is a program making callouts to a different entity, the kernel. The case we were talking about is that of library linking. The ldso license is interesting (/usr/doc/ldso/copyright, possibly only on potato or earlier systems). The commentary implies that ld.so deliberately uses the BSD license because the GPL is too strict. It also has the following paragraph: The ldso people don't have any ability to change the licenses of the actual authors of the libraries in question. There are lots of different cases. A great deal of difficulty is caused by people asserting that totally different cases must all be treated the same way. Post one case at a time, and not a giant spew of a jillion examples, as if they all argued for one single point. Each separate case is a separate discussion. Many of the examples you cited are cases where it is not very important whether the combined thing is a single derived work or not, because the licenses are more permissive than the GPL. Other cases involve explicit declarations by the authors of the programs about how they intend the license to be interpreted. Many involve things like the kernel that are not libraries at all. Getting off-topic a bit, there's an interesting clause in the license for libio, in /usr/doc/libc6/copyright (on potato anyway). As a special exception, if you link this library with files compiled with a GNU compiler to produce an executable, this does not cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public License. Why does the license require you to use a GNU compiler? Bizarre. I have no idea. But what on earth does it have to do with the present conversation? Why do you think that getting off-topic a bit, in a post which already contained so much that is off-topic, has any hope of doing any good for the conversation?
Re: draft for new Vim license
Walter Landry [EMAIL PROTECTED] writes: If the license were GPL-compatible, I could license my changes under the GPL, and never talk to the Vim maintainer. However, one of the things that Bram wants to be able to do is relicense the whole thing under a proprietary license. This is exactly the sort of thing that the GPL is designed to prevent. So a GPL patch would restrict future official Vim distributions. Ah yes, I missed that last part. So it does seem to me that it is not GPL compatible, as long as it wants to reserve the right to include changes in future vim distributions, which themselves might be released under nonfree terms.
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: Yes, it is different. One is a program making callouts to a different entity, the kernel. The case we were talking about is that of library linking. I should add here that it is relevant that the callouts to the kernel are callouts to an interface which is defined as not making things a combined derived work, which is not normally the case for a library. It is relevant and important here that the authors of the kernel intend that understanding of those callouts. If some nefarious added callouts to a GPL'd program which normally had nothing similar, and then had some non-free program use those callouts, all as an attempt at a subterfuge to defeat the GPL, this would not be allowed. Thomas
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
On Thu, Jan 03, 2002 at 10:43:48PM -0800, Thomas Bushnell, BSG wrote: [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: Yes, it is different. One is a program making callouts to a different entity, the kernel. The case we were talking about is that of library linking. I should add here that it is relevant that the callouts to the kernel are callouts to an interface which is defined as not making things a combined derived work, which is not normally the case for a library. It is relevant and important here that the authors of the kernel intend that understanding of those callouts. What is the definition of a callout? Why is it so different to a published library function? Apart from convenience of argument, that is. You dismissed my Tcl example without comment but I don't see how it is different to the kernel case. A non-free program running in the Tcl interpreter can have the Tcl interpreter load a GPLed library such as libreadline. The non-free program is not linked to the library. So why is this illegal? Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
Hamish Moffatt [EMAIL PROTECTED] writes: On Thu, Jan 03, 2002 at 10:43:48PM -0800, Thomas Bushnell, BSG wrote: [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: Yes, it is different. One is a program making callouts to a different entity, the kernel. The case we were talking about is that of library linking. I should add here that it is relevant that the callouts to the kernel are callouts to an interface which is defined as not making things a combined derived work, which is not normally the case for a library. It is relevant and important here that the authors of the kernel intend that understanding of those callouts. What is the definition of a callout? By callout I mean a mechanism for one program to call another. Why is it so different to a published library function? Apart from convenience of argument, that is. Libraries are much more tightly integrated with their callers, for example. You dismissed my Tcl example without comment but I don't see how it is different to the kernel case. A non-free program running in the Tcl interpreter can have the Tcl interpreter load a GPLed library such as libreadline. The non-free program is not linked to the library. So why is this illegal? Maybe it is disallowed. I haven't thought about it.
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: Why is it so different to a published library function? Apart from convenience of argument, that is. Libraries are much more tightly integrated with their callers, for example. Oh, and you ignored my stressing the importance of considering intent and common practice. It is the intent of kernel designers that the kernel is not one program together with the programs that it loads. It generally *is* the intent of library authors that the library is part of the programs with which they are linked. The nature and structure of the situation is important, as are the intentions of the parties. But the real point, which people frequently seem to miss, is that only this way can the integrity of the copyleft be maintained. If the use of dynamic loading were sufficient to get around the GPL, then its copylefting provisions would be entirely a dead letter, and it would be no better that the BSD license. For that very reason, the FSF and GPL-users in general staunchly stick to the importance of this rule, because it is the only thing that preserves the integrity of the copyleft itself. Now, if you want to argue the point further, *please* take it up with RMS or with Eben Moglen. There's really no advantage to wasting debian-legal with it. That's what I was trying to get across to [EMAIL PROTECTED], and now he's suckered us into a stupid argument. Thomas
Re: draft for new Vim license
Thomas Bushnell wrote: Walter Landry [EMAIL PROTECTED] writes: If the license were GPL-compatible, I could license my changes under the GPL, and never talk to the Vim maintainer. However, one of the things that Bram wants to be able to do is relicense the whole thing under a proprietary license. This is exactly the sort of thing that the GPL is designed to prevent. So a GPL patch would restrict future official Vim distributions. Ah yes, I missed that last part. So it does seem to me that it is not GPL compatible, as long as it wants to reserve the right to include changes in future vim distributions, which themselves might be released under nonfree terms. But so long as changes are only included using the Vim license, would there be any problem? Thus isn't the license GPL-compatible for as long as no incompatible-licensed changes have been included? -- WOMAN: Well, 'ow did you become king then? ARTHUR: The Lady of the Lake, [angels sing] her arm clad in the purest shimmering samite, held aloft Excalibur from the bosom of the water signifying by Divine Providence that I, Arthur, was to carry Excalibur. [singing stops] That is why I am your king! The Quest for the Holy Grail (Monty Python) /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.moolenaar.net \\\ ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim ))) \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
Re: draft for new Vim license
Branden Robinson wrote: Thanks very much for putting effort into this, Mr. Moolenaar. I know a lot of people don't find it easy to deal with paranoid license freaks. Thanks for taking a good look at the new text. I'll include most of your suggestions. You are also allowed to include executables that you made from the ^^^^^^ permitted distribute Does allowed and permitted mean something different? modified Vim you distribute. This may be done in the form of a context diff. You can chose what license to use for new code you add, so long as it does not restrict present or future official Vim distributions in any way. Uh, I think that asking people to use a license that does not restrict future official Vim distributions in any way is making an impossible demand. They cannot know what license may be placed on Vim in the future. Can I suggest this instead? You can choose what license to use for the changes you make, as long as it does not restrict the ability of anyone to comply with this license when they use a modified version of Vim that includes your changes. That's basically what you mean, right? I'm not sure. I would like to allow people to use any license for the new code that they write. After all, it's their work. But, at the same time I don't want this to result in bad things: - A proprietary version of Vim being made available (or sold) to a large audience. Thus someone slightly modifiying Vim and making money from it, without the possibility for me to get a chance to include the changes in the official release. - That it would not be possible to re-implement the same functionality and add it to the official Vim release (e.g., it should not be allowed to patent a specific solution). At the same time it should be possible for a company to make some changes which they want to keep a secret and use that changed version only within the company. The demand that the source code is available to everybody who uses this version should prevent the first of the above bad things from happening. The idea is that a company that would try to sell a modified version of Vim for $$$ doesn't want to include the source code. But the patent thing must be avoided by adding a remark to the license. That's why I added the does not restrict... part. This is the tricky part of the new license! Also, you regard the availability of Debian source packages as complying with c), right? I think that Debian always makes the source code available to me (in fact, to everybody), thus it would fall under a). -- I'm sure that I asked CBuilder to do a full install. Looks like I got a fool install, instead. Charles E Campbell, Jr, PhD /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.moolenaar.net \\\ ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim ))) \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
Re: draft for new Vim license
Scripsit Bram Moolenaar [EMAIL PROTECTED] Thomas Bushnell wrote: Ah yes, I missed that last part. So it does seem to me that it is not GPL compatible, as long as it wants to reserve the right to include changes in future vim distributions, which themselves might be released under nonfree terms. But so long as changes are only included using the Vim license, would there be any problem? From Vim's point of view, the entire GPL'ed code constitute an addition (a special case of a change), so it is all subject to the conditions you apply to changes. If you want to exempt, say, the addition of library code from your conditions on modifications in general, you need to add language in the license text that says so explicitly. (And doing so may not be a trivial task if you do not want to introduce loopholes that allow people to disguise essential part of their contributions as undisclosed library code). -- Henning Makholm What has it got in its pocketses?
Re: Netscape on Alpha?
hi I am not good at legal issues so I am cross posting this to debian-legal the problem: Debian Alpha is lacking a good browser the solution: there is a version of Netscape 4.7-4 that was compiled by Compaq for Tru64; this version is also distributed by RedHat for Alpha; some people have passed it thru alien and installed it, and it works; it would take me 20 minutes to upload it into Debian archives (unstable/non-free) the question: it contains some libraries by Compaq: can I upload it? The license follows. thanks. On Fri, Jan 04, 2002 at 01:11:01PM +0100, Kerstin Hoef-Emden wrote: Hi, On Fri, 4 Jan 2002, Andrea Mennucc wrote: what about uploading that package to the debian archives, in non-free? Do the license of Compaq and the Debian policy allow this? Presumably a debian-maintainer with access-permission for uploads has to do this? The package is 16.6 MB large and this is the dpkg -I output: new debian package, version 2.0. size 16583190 bytes: control archive= 6444 bytes. 0 bytes, 0 lines conffiles 1582 bytes,38 lines control 15331 bytes, 197 lines md5sums 257 bytes, 8 lines * postinst #!/bin/sh 194 bytes, 6 lines * prerm#!/bin/sh Package: netscape Version: 4.7-4 Section: alien Priority: extra Architecture: alpha Installed-Size: 34054 Maintainer: Kerstin Hoef-Emden [EMAIL PROTECTED] Description: Netscape prebuilt for Alpha Linux The Alpha Tru64 Unix version of Netscape, which runs on Alpha Linux. Requires COFF support in the kernel. There may be problems running Java due to differences in the thread models between Tru64 Unix and Linux. This RPM embeds the instructions at http://www.alphalinux.org/docs/netscape_du.shtml. Includes some Compaq Tru64 Unix libraries. . Disclaimer of Warranty: . The products and product information furnished hereunder are furnished AS IS without warranty, service or support of any kind. You assume all risks as to the quality or performance of the products and responsibility for any costs associated with the service or support of the products. COMPAQ disclaims all implied warranties including, without limitation, all implied warranties of merchantability and fitness. . Limitation of Liability: . In no event will COMPAQ be liable for any damages whatsoever, including loss of data or use, lost profits, or any incidential or consequential damages arising out of or in connection with this agreement or the use or performance of the products, whether in an action of contract or tort including negligence. . %changes Repackaged to install files directly rather than by running a script to unpack a tar file. . Moved install directories from /usr/local/... to /usr/lib/... to match RedHat 6.1 for Intel. EOF--- ps: please someone send me a link to an URL from which I may download the .rpm and the .deb a. -- A Mennucc E' un mondo difficile. Che vita intensa! (Renato Carotone) pgpHo3Cp3vDRM.pgp Description: PGP signature
Re: draft for new Vim license
Henning Makholm wrote: Scripsit Bram Moolenaar [EMAIL PROTECTED] Thomas Bushnell wrote: Ah yes, I missed that last part. So it does seem to me that it is not GPL compatible, as long as it wants to reserve the right to include changes in future vim distributions, which themselves might be released under nonfree terms. But so long as changes are only included using the Vim license, would there be any problem? From Vim's point of view, the entire GPL'ed code constitute an addition (a special case of a change), so it is all subject to the conditions you apply to changes. Yes. Thus if you add code and put it under the GPL, then the GPL would apply to the whole (if I understand the GPL correctly). So the question is if this would cause a conflict with the Vim license, which would prohibit you from distributing this version. I don't know the GPL well enough to judge about this. If you want to exempt, say, the addition of library code from your conditions on modifications in general, you need to add language in the license text that says so explicitly. (And doing so may not be a trivial task if you do not want to introduce loopholes that allow people to disguise essential part of their contributions as undisclosed library code). Compiling Vim with libraries is not considered changing Vim. This falls under the first item, generating an executable from an unmodified Vim. Only when you would add a library and call a function in it, you would be modifying Vim. So you could play tricks by adding a library that replaces a tactical function, which is called without changing Vim. Well, good luck with this unmodified version of Vim! :-) -- ARTHUR: You fight with the strength of many men, Sir knight. I am Arthur, King of the Britons. [pause] I seek the finest and the bravest knights in the land to join me in my Court of Camelot. [pause] You have proved yourself worthy; will you join me? [pause] You make me sad. So be it. Come, Patsy. BLACK KNIGHT: None shall pass. The Quest for the Holy Grail (Monty Python) /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.moolenaar.net \\\ ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim ))) \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
On Fri, Jan 04, 2002 at 06:03:30PM +1100, Hamish Moffatt wrote: On Thu, Jan 03, 2002 at 10:43:48PM -0800, Thomas Bushnell, BSG wrote: [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: Yes, it is different. One is a program making callouts to a different entity, the kernel. The case we were talking about is that of library linking. I should add here that it is relevant that the callouts to the kernel are callouts to an interface which is defined as not making things a combined derived work, which is not normally the case for a library. It is relevant and important here that the authors of the kernel intend that understanding of those callouts. What is the definition of a callout? Why is it so different to a published library function? Apart from convenience of argument, that is. I think you're overlooking the fact that in the case of a GPL library, the publishing of the interface is ALSO done under the GPL. Are you using GPL header files when compiling? Then the binary output is a derived work of the GPLed library. This is not to imply that someone who reverse-engineers a GPL header file can necessarily link against a GPL library without also being bound by its license terms; it only shows that in the usual case, there's clear support for the claim that library linking creates a derived work. Steve Langasek postmodern programmer pgpqoOCGrwWXP.pgp Description: PGP signature
