New Debian website license?
G'day, How about the Open Publication License? You can see it at http://opencontent.org/openpub/ I think it covers all concerns and I believe it is DFSG-free. - Craig -- Craig Small VK2XLZ, PGP: AD 8D D8 63 6E BF C3 C7 47 41 B1 A2 1F 46 EC 90 Eye-Net Consulting http://www.eye-net.com.au/ [EMAIL PROTECTED] MIEEE [EMAIL PROTECTED] Debian developer [EMAIL PROTECTED]
x3270 licenses
This is something I should have sorted out a long time ago, but I guess I haven't gotten around to it until now. The x3270 program is currently in non-free. There are two licenses responsible for this, one on some of the fonts, and the other on the code the current version is based on. All other parts of the package have a license very similar to the X11 license. I. The Fonts } Copyright © 1990 by the Georgia Institute of Technology. } All rights reserved except for those rights explicitly mentioned } below. } Permission is granted to distribute freely or to modify and } distribute freely any materials and information contained herein } as long as the above copyright and all terms associated with it } remain intact. This seems pretty much the same as the X11 license, although it doesn't actually mention use. Does this matter? Are there any other problems with this license? II. The Original Code } Copyright © 1989 by Georgia Tech Research Corporation, Atlanta, GA } 30332. } All Rights Reserved. GTRC hereby grants public use of this } software. Derivative works based on this software must incorporate } this copyright notice. What does public use mean? Should I try emailing or writing to GTRC or the Georgia Institute of Technology to find out? Any help would be appreciated. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ This message was composed from the finest electrons used by many of the world's greatest writers.
Re: x3270 licenses
On Mon, Feb 07, 2000 at 08:56:41PM +1300, Carey Evans wrote: This is something I should have sorted out a long time ago, but I guess I haven't gotten around to it until now. The x3270 program is currently in non-free. There are two licenses responsible for this, one on some of the fonts, and the other on the code the current version is based on. All other parts of the package have a license very similar to the X11 license. I. The Fonts } Copyright © 1990 by the Georgia Institute of Technology. } All rights reserved except for those rights explicitly mentioned } below. } Permission is granted to distribute freely or to modify and } distribute freely any materials and information contained herein } as long as the above copyright and all terms associated with it } remain intact. This seems pretty much the same as the X11 license, although it doesn't actually mention use. Does this matter? Are there any other problems with this license? Nope, this is fine. Use is covered by the Fair Use provision of Copyright law. The fonts are free. II. The Original Code } Copyright © 1989 by Georgia Tech Research Corporation, Atlanta, GA } 30332. } All Rights Reserved. GTRC hereby grants public use of this } software. Derivative works based on this software must incorporate } this copyright notice. What does public use mean? Should I try emailing or writing to GTRC or the Georgia Institute of Technology to find out? We don't have permission to redistribute (at all---why is this in non-free?) Please do try to contact the Copyright holders if you can. This license obviously does not say what they intend it to mean. -- Joseph Carter [EMAIL PROTECTED] Debian Linux developer http://tank.debian.net GnuPG key pub 1024D/DCF9DAB3 sub 2048g/3F9C2A43 http://www.debian.org20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 Espy_on_crack I installed 'Linux 6.1', doesn't that make me a unix guru? BenC Espy_on_crack: no, you have to install it twice before you are a guru...once to prove you can do it, the second to fix the things your broke the first time Espy_on_crack oh right, how silly of me pgpgEg5xGv1G8.pgp Description: PGP signature
Thank you Andreas Pour
I have been following the KDE/QT licensing issue with concern for over a year now, and decided to spend the weekend catching up with the last couple months of the kde-licensing archive. In particular I spent time reading Andreas Pour's comments and all the replies to them. I also spent some time just sitting down and rereading the GPL. I found Andreas' comments to be heart warming as his interpretation of the GPL closely reflects the spirit in which my contributions to GPLed software are made. Thank you very much Andreas for your rigourous analysis of the KDE/QT situation, especially: Your GPL interpretation http://lists.kde.org/?/=kde-licensingm=94950776505266w=2 The XFree license comment http://lists.kde.org/?/=kde-licensingm=94950776505271w=2 Personally I would like to see QT issued under a license no more restrictive than the GPL (or even freer). But I don't regard this as a critical issue, and in fact consider Troll Tech to be a good example of what a software company should be like. I can also see that it is possible that non-KDE developers whose GPLed code is used in KDE may have a different interpretation of the GPL than Andreas Pour's preferred one. And that it would be polite (though maybe not legally necessary) to confirm with them that redistributing their code with KDE is ok with them. I think requiring confirmation from those who directly contribute to the KDE project would be legally unnecessary and well beyond the bounds of sensible courtesy. My comments are based on my interpretation of Australian law but are not legal advice. BFN, Don.
Re: x3270 licenses
On Mon, Feb 07, 2000 at 12:19:12AM -0800, Joseph Carter wrote: Nope, this is fine. Use is covered by the Fair Use provision of Copyright law. The fonts are free. Is this the n+1th abuse of Fair Use, or do you actually have some arguments supporting that claim? -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: x3270 licenses
On Mon, Feb 07, 2000 at 12:55:53PM +0200, Antti-Juhani Kaijanaho wrote: Nope, this is fine. Use is covered by the Fair Use provision of Copyright law. The fonts are free. Is this the n+1th abuse of Fair Use, or do you actually have some arguments supporting that claim? You have a copy of the program. You want to tell me you now need special permission to run it? Analogy: You have a book and before you may read it you must get permission. Yeah, I'd say I'm pretty sure running the program is fair use. If it weren't, you would not be allowed to run GPL'd software since you are not given permission to do so. -- Joseph Carter [EMAIL PROTECTED] Debian Linux developer http://tank.debian.net GnuPG key pub 1024D/DCF9DAB3 sub 2048g/3F9C2A43 http://www.debian.org20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 netgod Feanor: u have no idea of the depth of the stupidty of american law pgpdc2F7aSuMg.pgp Description: PGP signature
Re: x3270 licenses
Antti-Juhani Kaijanaho [EMAIL PROTECTED] writes: Is this the n+1th abuse of Fair Use, or do you actually have some arguments supporting that claim? Fair Use has a different meanings in US and Europe, just like Free Speach. -- They say that the gods are angry when they hit you with objects.
Re: x3270 licenses
Scripsit Joseph Carter [EMAIL PROTECTED] On Mon, Feb 07, 2000 at 12:55:53PM +0200, Antti-Juhani Kaijanaho wrote: Use is covered by the Fair Use provision of Copyright law. The fonts are free. Is this the n+1th abuse of Fair Use, or do you actually have some arguments supporting that claim? You have a copy of the program. You want to tell me you now need special permission to run it? I don't think your analogy holds. Remember that we're talking about fonts. In this case use entails reproducing the artistic contents of the font, that is, the lettershapes - so IMO use of a font must be considered form of copying. This again means that the original claim that use of fonts are fair use is wrong, IMO. On the other hand, in the situation at hand there is a blanket permission to distribute the font; that must also cover the special kind of distribution that consist of using the font to typeset a document. -- Henning Makholm Gå ud i solen eller regnen, smil, køb en ny trøje, slå en sludder af med købmanden, puds dine støvler. Lev!
Re: x3270 licenses
On Mon, 7 Feb 2000, Brian Ristuccia wrote: On Mon, Feb 07, 2000 at 02:50:37PM +0100, Henning Makholm wrote: Remember that we're talking about fonts. In this case use entails reproducing the artistic contents of the font, that is, the lettershapes - so IMO use of a font must be considered form of copying. Running a program involves copying it from disk into memory :) Yes, but the copy thus produced is not distributed, so I think the fair use argument is stronger in that case. I recall a precedent here in the US where a document was not infected by the copyright on the fonts used therein. It seemed to say that so long as you've lawfully aquired a font, you're free to use it when typesetting any documents you like. Well, I can't argue with that. But I'm happy for not being the judge who - in these days of digital typesetting - must decide when something is an alternative representation of a font and when it is just a document which happens to contain every letter in the alphabet and enough text to exhibit a selection of common kerning pairs... -- Henning Makholm
Re: x3270 licenses
Brian Ristuccia [EMAIL PROTECTED] writes: I recall a precedent here in the US where a document was not infected by the copyright on the fonts used therein. It seemed to say that so long as you've lawfully aquired a font, you're free to use it when typesetting any documents you like. You might want to check the legal archives before deciding on this. If I recall correctly, this may have been back far enough that fonts were still made of metal and typesetting was still done with plates -- but it should still apply in our case. See the comp.fonts FAQ: http://www.faqs.org/faqs/fonts-faq/part2/ Note that this applies only in the U.S. Particularly it doesn't apply in Europe. -- Unix... is not so much a product as it is a painstakingly compiled oral history of the hacker subculture. --Neal Stephenson
Re: On interpreting licences (was: KDE not in Debian?)
On Sat, Feb 05, 2000 at 12:04:52AM +0100, Marc van Leeuwen wrote: If you insist... I hope I get the details right though. So the scenario is: kghoststript is being distributed as executable of a GPL-ed source dynamically linked against the Qt object library; the distributors read all the source code for all modules it contains to mean all the source code for kghostscript proper (not the library), and they dutifully accompany the executable by this source, both with the GPL licence; they also distribute Qt as usual in source and object format, both with QPL licence. The sources for kghostscript are the exact ones used to build the executable, so CFLAGS does not contain -static. Except that by your logic, the kghostscript executable won't execute. Who do you think you're fooling? -- Raul
Re: On interpreting licences (was: KDE not in Debian?)
On Sun, Feb 06, 2000 at 12:39:51AM -0500, Andreas Pour wrote: Making that change under the scenario described by Marc would violate the GPL, but so would lots of other things, such as linking a GPL program with a proprietary libc. Nope, because there's a special exception in the GPL that allows people to use a proprietary libc. This exception is limited (you couldn't by the proprietary libc in conjunction with the GPLed program, nor could they ship together), but it does exist. Just search for special exception in the text of the GPL. I note in this regard that Section 3 of the GPL defines complete source code as: For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. Notice that it lists only modules it *contains*, not all modules it contains or links to or all modules it contains during execution (the latter being relevant b/c executable work as written in the quoted sentence above refers to the executable work as it is being distributed, not as it exists at run-time). You're claiming here that even though Qt must be linked with kghostscript that the executing program doesn't contain Qt? The next sentence reads: 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. Ok, so you are aware of the part of the GPL which lets the proprietary libc be used. This sentence can easily be read to support the dynamic/static distinction. Eh? You can link the proprietary libc statically and this special exception would still be just as applicable. Normally you would distribute the major component w/ the executable only if it is statically linked, in which case you are required to include the source of that component; but if dynamically linked, you are not required to distribute the source. Even if it's statically linked you're not required to distribute the source for a proprietary libc. As long as libc is distributed with the kernel or the compiler for the operating system, and as long as the kernel or the compiler is *not* distributed with kghostscript, there's no problem with also distributing some of that proprietary libc with kghostscript. I.e., the GPL does distinguish b/w dynamic and static linking. It doesn't even use the term linking in the terms of the license. As to your -static flag, I think you agree, from your past postings, that someone can distribute a GPL'd program dynamically linked against a proprietary Solaris libc, but that this person could not compile it statically by adding the '-static' flag and then distribute the program. So really I don't see how your kghostview example is any different from what is already allowed and done. I did not agree to any such thing. It's perfectly legal to distribute a GPLed program which is statically linked against a Solaris libc. -- Raul
Re: On interpreting licences (was: KDE not in Debian?)
On Mon, 7 Feb 2000, Raul Miller wrote: b/c executable work as written in the quoted sentence above refers to the executable work as it is being distributed, not as it exists at run-time). You're claiming here that even though Qt must be linked with kghostscript that the executing program doesn't contain Qt? The executing program isn't relevant because the GPL doesn't specify the conditions the program can be run under. It only specifies the conditions the program can be distributed under. I.e., the GPL does distinguish b/w dynamic and static linking. It doesn't even use the term linking in the terms of the license. I think it does, by implication if not directly. If you link statically with a proprietary library which is not part of the operating system then you cannot distribute under the GPL. But you can if you link dynamically, because you aren't distributing any proprietary code at all. You're just assuming that the required proprietary code will already be on the target system.
Re: On interpreting licences (was: KDE not in Debian?)
On Mon, 7 Feb 2000, Raul Miller wrote: b/c executable work as written in the quoted sentence above refers to the executable work as it is being distributed, not as it exists at run-time). You're claiming here that even though Qt must be linked with kghostscript that the executing program doesn't contain Qt? On Mon, Feb 07, 2000 at 12:53:51PM -0500, William T Wilson wrote: The executing program isn't relevant because the GPL doesn't specify the conditions the program can be run under. It only specifies the conditions the program can be distributed under. The GPL is what gives permission to distribute that program. The GPL only gives permssion to distribute the program if you also make available the complete source code for that program (where that source has to be available under terms and conditions that satisfy the GPL). You're claiming that the complete source code doesn't contain a part of the program which is necessary for it to run? I.e., the GPL does distinguish b/w dynamic and static linking. It doesn't even use the term linking in the terms of the license. I think it does, by implication if not directly. If you link statically with a proprietary library which is not part of the operating system then you cannot distribute under the GPL. But you can if you link dynamically, because you aren't distributing any proprietary code at all. You're just assuming that the required proprietary code will already be on the target system. Ok, so your assertion is that code which is necessary for the program to run -- which is included in the executing program -- is not a part of the program? -- Raul
Re: x3270 licenses
On Mon, Feb 07, 2000 at 04:17:41AM -0800, Joseph Carter wrote: You have a copy of the program. You want to tell me you now need special permission to run it? Not necessarily. But my question was how Fair Use comes into play, not whether use really is restricted or not. In other words, I was attacking your argument, not your conclusion. AFAIK, US fair use includes such things as scientific or journalistic citation or commentary, and making copies for one's education. For example, republishing a book is not fair use, and use of fonts often is republication. Analogy: You have a book and before you may read it you must get permission. Reading does not involve making a pysical copy of the book. Yeah, I'd say I'm pretty sure running the program is fair use. If it weren't, you would not be allowed to run GPL'd software since you are not given permission to do so. Not true. The GPL *explicitly* allows all use. Fair use is not even near the issue. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: x3270 licenses
On Mon, Feb 07, 2000 at 01:37:01PM +0100, Peter Makholm wrote: Fair Use has a different meanings in US and Europe, just like Free Speach. I know. In Finland, there is no such thing as Fair Use. (Many of) the privileges the Fair Use implicitly grants to people in the US and elsewhere are explicitly enumerated in Finnish copyright law. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: x3270 licenses
On Mon, Feb 07, 2000 at 02:09:27PM -0500, Raul Miller wrote: Anyways, I don't see anything that says that a person who owns a legal copy of a font would not be allowed to prepare text which displays that font. I don't argue against that. I just have the distinct feeling that Fair Use is not the answer here ;-) -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: On interpreting licences (was: KDE not in Debian?)
b/c executable work as written in the quoted sentence above refers to the executable work as it is being distributed, not as it exists at run-time). On Mon, 7 Feb 2000, Raul Miller wrote: You're claiming here that even though Qt must be linked with kghostscript that the executing program doesn't contain Qt? On Mon, Feb 07, 2000 at 12:53:51PM -0500, William T Wilson wrote: The executing program isn't relevant because the GPL doesn't specify the conditions the program can be run under. It only specifies the conditions the program can be distributed under. That's fine: as long as you give the complete source code for the executable program you can execute it under whatever conditions you please. But linking with Qt isn't some random example of some unusual circumstances for running the program. Linking with Qt is the only way you can have a complete copy of the program. And you have to distribute the complete source for the program even if you're not distributing all of the object code. And, of course, that source has to be distributed in a way that meets the terms of the GPL. I.e., the GPL does distinguish b/w dynamic and static linking. It doesn't even use the term linking in the terms of the license. I think it does, by implication if not directly. If you link statically with a proprietary library which is not part of the operating system then you cannot distribute under the GPL. Linking statically with a proprietary library is perfectly legal if (1) the library is distributed with the OS, and (2) the GPLed program is not. Linking dynamically doesn't give any additional permissions. But you can if you link dynamically, because you aren't distributing any proprietary code at all. You're just assuming that the required proprietary code will already be on the target system. Distribute with/without code only matters for that special exception that lets people link (statically or dynamically) with a proprietary libc. And even there you've not understood the requirement. Except for that special exception, you have to distribute the complete source for the program under the GPL even if you're only distributing part of the object code yourself. -- Raul
Re: On interpreting licences (was: KDE not in Debian?)
William T Wilson wrote: On Mon, 7 Feb 2000, Raul Miller wrote: b/c executable work as written in the quoted sentence above refers to the executable work as it is being distributed, not as it exists at run-time). You're claiming here that even though Qt must be linked with kghostscript that the executing program doesn't contain Qt? The executing program isn't relevant because the GPL doesn't specify the conditions the program can be run under. It only specifies the conditions the program can be distributed under. The program as _distributed_ contains portions of Qt, even if dynamically linked. Macros. Data structures. Method definitions. All are parts of Qt necessary for compilation, and which are included in the final executable. I.e., the GPL does distinguish b/w dynamic and static linking. It doesn't even use the term linking in the terms of the license. I think it does, by implication if not directly. If you link statically with a proprietary library which is not part of the operating system then you cannot distribute under the GPL. But you can if you link dynamically, because you aren't distributing any proprietary code at all. You're just assuming that the required proprietary code will already be on the target system. Dynamic linking has been the exception rather than the rule for most of the history of computing. Most libc's, even proprietary, allow distribution of static binaries. -- | Jeff Teunissen -=- Pres., Dusk To Dawn Computing -- d2deek at pmail.net | Disclaimer: I am my employer, so anything I say goes for me too. :) | dusknet.dhis.net is a black hole for email.Use my Reply-To address. | Specializing in Debian GNU/Linux http://dusknet.dhis.net/~deek/
Re: On interpreting licences (was: KDE not in Debian?)
You're claiming here that even though Qt must be linked with kghostscript that the executing program doesn't contain Qt? On Mon, Feb 07, 2000 at 05:17:56PM -0500, Andreas Pour wrote: Well, this is funny indeed. When it suits your desired interpretation, you can change words rather freely; yet at other times you insist on strict reading of the words. Although it is obvious, I will repeat myself: I said executable work, as used in the GPL, not executing program. The reference to executable work in Section 3, which I quoted above, must be the Program . . . in . . . executable form mentioned in the beginning of Section 3 (why? b/c the quoted sentence is defining the term). In short, the term refers only to what is being copied and distributed, rather than what the user ends up executing. If you read Section 3 with a fair eye I think you will see what I mean. It's true that you do not have to distribute in object form everything that's going to go into the complete program. However, it's also true that you must distribute the source for the complete program. I'm asserting that kghostscript without Qt is not the complete program. You do not appear to be disagreeing with me on that point. Instead, you appear to be quibbling that the GPL doesn't require that the entire executable be distributed. The next sentence reads: 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. Ok, so you are aware of the part of the GPL which lets the proprietary libc be used. This sentence can easily be read to support the dynamic/static distinction. Eh? You can link the proprietary libc statically and this special exception would still be just as applicable. No, it would not, b/c then you would actually be distributing the executable proprietary libc, and the next clause kicks in (the exception (unless . . .) to the special exception) to require the source code to be distributed for the libc part as well. Yes, you would be distributing the proprietary libc. But that's legal if (1) the libc would also be distributed with a major component of the operating system, and (2) that major component of the operating system would not accompany the GPLed executable. There's nothing in that exception which says that libc can't accompany the GPLed executable. The requirement is that the GPLed executable can't be accompanied by the major component of the operating system which includes the cannonical copy of libc. Stated even more informally, that exception says: you can use a proprietary libc if everyone already has it, but then the the OS vendor (who stuck everyone with this proprietary libc) can't distribute the GPLed program. The underlying idea is that the OS vendor ought to have the capability to fix the license on the proprietary libc, but users of that OS wouldn't be able to fix the license. -- Raul
Re: On interpreting licences (was: KDE not in Debian?)
Raul Miller wrote: You're claiming here that even though Qt must be linked with kghostscript that the executing program doesn't contain Qt? On Mon, Feb 07, 2000 at 05:17:56PM -0500, Andreas Pour wrote: Well, this is funny indeed. When it suits your desired interpretation, you can change words rather freely; yet at other times you insist on strict reading of the words. Although it is obvious, I will repeat myself: I said executable work, as used in the GPL, not executing program. The reference to executable work in Section 3, which I quoted above, must be the Program . . . in . . . executable form mentioned in the beginning of Section 3 (why? b/c the quoted sentence is defining the term). In short, the term refers only to what is being copied and distributed, rather than what the user ends up executing. If you read Section 3 with a fair eye I think you will see what I mean. It's true that you do not have to distribute in object form everything that's going to go into the complete program. However, it's also true that you must distribute the source for the complete program. Where does it say that (in the GPL, that is). It only says you have to make available the complete source code to what you are in fact distributing. I'm asserting that kghostscript without Qt is not the complete program. You do not appear to be disagreeing with me on that point. Instead, you appear to be quibbling that the GPL doesn't require that the entire executable be distributed. That for sure it does not -- the only complete requirement pertains to source code. The next sentence reads: 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. Ok, so you are aware of the part of the GPL which lets the proprietary libc be used. This sentence can easily be read to support the dynamic/static distinction. Eh? You can link the proprietary libc statically and this special exception would still be just as applicable. No, it would not, b/c then you would actually be distributing the executable proprietary libc, and the next clause kicks in (the exception (unless . . .) to the special exception) to require the source code to be distributed for the libc part as well. Yes, you would be distributing the proprietary libc. But that's legal if (1) the libc would also be distributed with a major component of the operating system, and (2) that major component of the operating system would not accompany the GPLed executable. Right, but if it's statically linked by definition it does accompany the executable. There's nothing in that exception which says that libc can't accompany the GPLed executable. Of course it can, but then you have to include the source code. The requirement is that the GPLed executable can't be accompanied by the major component of the operating system which includes the cannonical copy of libc. Stated even more informally, that exception says: you can use a proprietary libc if everyone already has it, but then the the OS vendor (who stuck everyone with this proprietary libc) can't distribute the GPLed program. I don't see any reference to OS vendor, whether explicit or implicit, in the language of Section 3 of the GPL. The only distinction on the system component exception is whether the system component accompanies the executable or not: if not, you are excused from including the source code for that component, if it does, you are not excused The underlying idea is that the OS vendor ought to have the capability to fix the license on the proprietary libc, but users of that OS wouldn't be able to fix the license. While I may agree that this is a nice theory, it is not reflected in the language of the GPL. This only goes to prove how poorly the GPL is drafted, as we can disagree even on this relatively elementary point. Ciao, Andreas
Re: On interpreting licences (was: KDE not in Debian?)
On Mon, Feb 07, 2000 at 06:14:15PM -0500, Andreas Pour wrote: Where does it say that (in the GPL, that is). It only says you have to make available the complete source code to what you are in fact distributing. I don't think we're disagreeing on this point. However, I think that you are imagining that people are distributing kghostscript executables and not distributing Qt. That's certainly not what Debian would do, if Debian included kghostscript in main. The next sentence reads: 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. Ok, so you are aware of the part of the GPL which lets the proprietary libc be used. This sentence can easily be read to support the dynamic/static distinction. Eh? You can link the proprietary libc statically and this special exception would still be just as applicable. No, it would not, b/c then you would actually be distributing the executable proprietary libc, and the next clause kicks in (the exception (unless . . .) to the special exception) to require the source code to be distributed for the libc part as well. Yes, you would be distributing the proprietary libc. But that's legal if (1) the libc would also be distributed with a major component of the operating system, and (2) that major component of the operating system would not accompany the GPLed executable. Right, but if it's statically linked by definition it does accompany the executable. it meaning the GPLed program? If so, why do you use the phrase accompany the executable? Aren't you talking about the executable of the GPLed program? What does it mean for a program to accompany itself? Why do you raise this point? If it doesn't mean the GPLed program, what is it that you say would be statically linked? There's nothing in that exception which says that libc can't accompany the GPLed executable. Of course it can, but then you have to include the source code. Sure -- you not only have to include the source code, but you have to make sure it's distributed under GPL terms... but then we wouldn't be talking about that proprietary libc. The requirement is that the GPLed executable can't be accompanied by the major component of the operating system which includes the cannonical copy of libc. Stated even more informally, that exception says: you can use a proprietary libc if everyone already has it, but then the the OS vendor (who stuck everyone with this proprietary libc) can't distribute the GPLed program. I don't see any reference to OS vendor, whether explicit or implicit, in the language of Section 3 of the GPL. The only distinction on the system component exception is whether the system component accompanies the executable or not: if not, you are excused from including the source code for that component, if it does, you are not excused It seems to me that you'd call someone distributing major components of a proprietary OS an OS vendor. I'm sure you could construct examples which are exceptions to that rule. But I made it very clear that I was talking informally -- I was talking about the usual case, not trying to be so general that I was covering all potential issues. -- Raul
omniorb's copyright is broken
package: omniorb version: 1:2.8.0-1 severity: important Copyright states it is free It is in non-free README.FIRST mensions additional copyright file, that is not in .deb It have to be clarified ASAP. /usr/doc/omniorb/copyright : omniORB2 is available for general use under the conditions of the GNU General Public Licence and GNU Library General Public Licence. /usr/doc/omniorb/README.FIRST : omniORB2 is copyright ATT Laboratories - Cambridge. It is free software. The programs in omniORB2 are distributed under the GNU General Public Licence as published by the Free Software Foundation. See the file COPYING for copying permission of these programs. The libraries in omniORB2 are distributed under the GNU Library General Public Licence. See the file COPYING.LIB for copying permission of these libraries. omniORB2 contains source code that is derived from the SunSoft OMG IDL Compiler Front End (CFE) version 1.3. The IDL CFE is copyright Sun Microsystems and is distributed here under the terms and conditions written in the file src/tool/omniidl2/COPYING.CFE. We impose no restriction on the use of the IDL compiler output. The stub code produced by the IDL compiler is not considered a derived work of it.
Re: New OPL Draft
As I understand your proposed license, it has no problems falling within the existing DFSG. This is not true for some of the others; whether Debian wants to extend its penumbra in the manner I described is something that will have to be extensively discussed. I'd certainly like your input on this issue; I would be happy to give my opinion, once I see the specific issue. Keith Packard of XFree86, for instance, thinks that we'll never see much in the way of high-quality fonts that are free software, because the problems are just too hard. We already have some, released by a font company under the GPL. Which shows why all such arguments are foolish. It is a mistake to speculate that failure is inevitable; it is much better to try than to give up in advance.
