Re: crypto in non-free
On Sun, Feb 01, 2004 at 10:14:30PM +, Brian M. Carlson wrote: non-US/non-free. crypto-in-main is crypto-in-*main*, not crypto-in-non-free. That's part of the reason why we still have non-US. This is due to some restrictions with the definition of public domain that the government uses for BXA licenses; they don't care if it has a copyright (which isn't really public domain) but it can't have a patent or usage restrictions. You may have some trouble uploading, though; klecker doesn't seem to be responding, at least to me. I'd be interested in knowing where you got this idea? The TSU license exception is defined in §740.13 of the EAR which references §734.3(b)(3) and further references §734.7 and §734.10 which does not use the term public domain. Nor does it require that the software not have usage restrictions on it. The standard used is that the technology (not necessarily the source code) is publically available. In fact it specificaly mentions information published in patent applications (provided it follows some certain rules). Essentially the patent has to be a applied for by a foreigner inventor, or filed in a foreign patent by a US inventor. It's difficult to ensure that a crypto tool qualifies under the patent exception because it requires some foot work tracking down the origin of the technology and possibly foreign patents. However, the existence of a patent does not disqualify the license exception. It's simply one of the possible methods of qualifying for it. You can read them here: http://w3.access.gpo.gov/bis/ear/ear_data.html Everything Debian distributes in main would qualify for the TSU exception because the DFSG is a subset of the EAR definition of publically available. The problem with non-free is that some things in it may not meet the definition of publically available. For instance a tool that didn't include the source code would not qualify, even if the binaries are freely distributable. IANAL, TINLA. -- Ben Reser [EMAIL PROTECTED] http://ben.reser.org Conscience is the inner voice which warns us somebody may be looking. - H.L. Mencken
Re: Revised JasPer License
* Nathanael Nerode [EMAIL PROTECTED] [040201 22:28]: It would still be better if the disclaimer disclaimed implied warranties only to, say, the fullest extent permitted by law. :-) This presumably isn't strictly necessary, because the usual interpretation of illegal warranty disclaimers seems to be that the rest of the license remains valid. But it's safer, especially because of the line NO USE OF THE SOFTWARE IS AUTHORIZED HEREUNDER EXCEPT UNDER THIS DISCLAIMER, which read strictly would indicate that if any part of the warranty disclaimer was found invalid, the Software couldn't be used in that jurisdiction. Well, I don't know other jurisdictions, but in Germany something like as permitted by law is automatically moot, and so is the line you quoted, as I was told... (Or the line may be intact but a empty condition as the disclaimer is empty, don't know how they make it..) Hochachtungsvoll, Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
Re: crypto in non-free
On Sun, Feb 01, 2004 at 10:47:45PM -0800, Ben Reser wrote: On Sun, Feb 01, 2004 at 10:14:30PM +, Brian M. Carlson wrote: non-US/non-free. crypto-in-main is crypto-in-*main*, not crypto-in-non-free. That's part of the reason why we still have non-US. This is due to some restrictions with the definition of public domain that the government uses for BXA licenses; they don't care if it has a copyright (which isn't really public domain) but it can't have a patent or usage restrictions. You may have some trouble uploading, though; klecker doesn't seem to be responding, at least to me. I'd be interested in knowing where you got this idea? Thanks for correcting me. The TSU exception came from memory; even though I write crypto software all the time, it's always free, and so I never have to worry about the specifics. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 signature.asc Description: Digital signature
Re: XFree86 license difficulties
On 2004-01-31 14:01:42 + MJ Ray [EMAIL PROTECTED] wrote: On 2004-01-30 19:31:44 + paul cannon [EMAIL PROTECTED] wrote: If XFree86 does not consider linking to create a derived work which must carry the same restrictions as those in the library, then it does not seem there is a problem; an application linking against Qt and Xlib could be solely under the GPL. Or am I off my rocker here? Does XFree86 have some extensions that they developed? If so, how can it not be a derived work if you use those XFree86 extensions? It would be a mess, looking at each application. Please correct me if I'm wrong, but I understood that the FSF's opinion on this is not universal. That is, it is not an irrational view that dynamically linking to a library is only _using_ that library, not creating a derived work from it. It seems to me rather like using a command line utility in a script. One might make wide use of GNU grep extensively in a proprietary program, for example, and do so without affecting or worrying about the license on grep at all. As another example, a command line program could wrap the functionality of nearly all libraries. If someone didn't want to link a program with libcurl, one would simply invoke /usr/bin/curl and get much of the same functionality. Should these be different actions from a licensing standpoint? As always, let me know if I seem to be on crack. -- paul cannon [EMAIL PROTECTED]
Re: XFree86 license difficulties
paul cannon [EMAIL PROTECTED] writes: The opinion of the XFree86 project is irrelevant. It is the licenses on GPLed works that would be violated, not the license on XFree86, so it's the interpretation of the authors of the GPLed works that counts. I don't quite see how this is so. If the XFree86 Project were to say- theoretically- something like linking dynamically to an XFree86 library does not constitute a derived work for the purposes of the XFree86 license then Qt (e.g.) could be dynamically linked to Xlib and be legally distributed under the terms of the GPL. The GPL is satisfied, since the linked product could be distributed under the exact terms of the GPL, and the XFree86 license is also satisfied, since they wouldn't claim any copyright over the linked product. But the XF86 project would still claim copyright on some components of that linked work, and its license is GPL-incompatible. So the combination is not GPL-compatible. If you could find a way to distribute the linkage alone -- the combination without the components -- I suppose your argument would work, but I don't think that's possible or useful. Is there a legal precedent or doctrine specifically stating that linking dynamically against a library produces a derived work? I have seen that the FSF claims this is so, and so it makes sense to apply their rule to products linked with GPL'd works, but it doesn't make sense to me that such thinking should be universally applied (the library is only being used or accessed, not necessarily being modified or distributed). It is being distributed by Debian along with the work linking to it. The FSF's argument may be weak elsewhere, but it's quite strong in the case of an OS vendor distributing GPL'd works with shared libraries. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: XFree86 license difficulties
paul cannon [EMAIL PROTECTED] writes: On 2004-01-31 14:01:42 + MJ Ray [EMAIL PROTECTED] wrote: On 2004-01-30 19:31:44 + paul cannon [EMAIL PROTECTED] wrote: If XFree86 does not consider linking to create a derived work which must carry the same restrictions as those in the library, then it does not seem there is a problem; an application linking against Qt and Xlib could be solely under the GPL. Or am I off my rocker here? Does XFree86 have some extensions that they developed? If so, how can it not be a derived work if you use those XFree86 extensions? It would be a mess, looking at each application. Please correct me if I'm wrong, but I understood that the FSF's opinion on this is not universal. You are definitely not wrong. It's just the Debian folks that believe the faintest whisper from the FSF as were it the word of God. That is, it is not an irrational view that dynamically linking to a library is only _using_ that library, not creating a derived work from it. It seems to me rather like using a command line utility in a script. One might make wide use of GNU grep extensively in a proprietary program, for example, and do so without affecting or worrying about the license on grep at all. As another example, a command line program could wrap the functionality of nearly all libraries. If someone didn't want to link a program with libcurl, one would simply invoke /usr/bin/curl and get much of the same functionality. Should these be different actions from a licensing standpoint? Good point. As always, let me know if I seem to be on crack. You seem to be unusually sane for this list. -- Måns Rullgård [EMAIL PROTECTED]
Re: XFree86 license difficulties
On Mon, 02 Feb 2004, paul cannon wrote: Please correct me if I'm wrong, but I understood that the FSF's opinion on this is not universal. That is, it is not an irrational view that dynamically linking to a library is only _using_ that library, not creating a derived work from it. Considering the fact that the FSF is one of the individuals who owns the copyrights to many GPLed works and actually has the resources and personnel to actively protect those copyrights, their opinion has a great weight in this matter. [Not to mention the fact that the FSF interprets the GPL on a daily basis, and is generally considered to have the canonical interpretation.] Obviously, you can differ from their opinion, but unless you're willing to back up you're opinion with resources of your own, the conservative tack is to give credence to the copyright holder's interpretation. Anything else (especially in matters where the outcome is unclear) is asking for trouble. Don Armstrong -- I was thinking seven figures, he said, but I would have taken a hundred grand. I'm not a greedy person. [All for a moldy bottle of tropicana.] -- Sammi Hadzovic [in Andy Newman's 2003/02/14 NYT article.] http://www.nytimes.com/2003/02/14/nyregion/14EYEB.html http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: XFree86 license difficulties
On Mon, 02 Feb 2004, Måns Rullgård wrote: It's just the Debian folks that believe the faintest whisper from the FSF as were it the word of God. You must have slept through the GFDL discussions then. Don Armstrong -- The sheer ponderousness of the panel's opinion ... refutes its thesis far more convincingly than anything I might say. The panel's labored effort to smother the Second Amendment by sheer body weight has all the grace of a sumo wrestler trying to kill a rattlesnake by sitting on it--and is just as likely to succeed. -- Alex Kozinski in Silveira V Lockyer http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: Revised JasPer License
Walter Landry wrote: Andrew Suffield [EMAIL PROTECTED] wrote: On Sat, Jan 31, 2004 at 06:40:59PM -0800, Michael Adams wrote: Permission is hereby granted, free of charge, to any person (the User) obtaining a copy of this software and associated documentation files (the Software), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: Nearly there, but let's get distribute modified versions in here while we're at it. I wouldn't say that is strictly necessary, though it is nice. The and/or clause covers it well enough, and is similar to many things in Debian already. If we worried about something like Pine happening again, Debian would have to get rid of a lot of software. I agree that it isn't strictly necessary, especially given the clause deal in the Software without restriction, which is pretty vague and broad (and appears intended to cover anything not explicitly listed).
Re: XFree86 license difficulties
On 2004-02-02 20:11:45 + paul cannon [EMAIL PROTECTED] wrote: Please correct me if I'm wrong, but I understood that the FSF's opinion on this is not universal. That is, it is not an irrational view that dynamically linking to a library is only _using_ that library, not creating a derived work from it. Some works with copyright held by FSF are affected by this, so their published opinion probably would count. However, if there is a good reason why the result of a compile that included a file from a work, which appears only in that work because it is an extension unique to that work, is not derived from that work, I'm interested to read it. Using grep on the command-line is a bit different. The use could have been derived from a published description of it and I don't end up including grep as part of the compile. There are quite a few versions of grep, too. I don't know libcurl enough to comment on it and I think that's getting off-topic. -- MJR/slef My Opinion Only and possibly not of any group I know. Please http://remember.to/edit_messages on lists to be sure I read http://mjr.towers.org.uk/ gopher://g.towers.org.uk/ [EMAIL PROTECTED] Creative copyleft computing services via http://www.ttllp.co.uk/
Re: XFree86 license difficulties
paul cannon [EMAIL PROTECTED] writes: As another example, a command line program could wrap the functionality of nearly all libraries. If someone didn't want to link a program with libcurl, one would simply invoke /usr/bin/curl and get much of the same functionality. Should these be different actions from a licensing standpoint? As always, let me know if I seem to be on crack. You're not on crack -- but I don't think you're right either. There's a series of fine distinctions here, and the true answer is murky enough that Debian's right to take the conservative path. You argue that a command line program should be no different from a dynamically linked program. The FSF argues it the other way: that dynamic linking should be treated no differently from static linking. If it *is* different, then the GPL reduces to the LGPL, and the FSF's bargaining chips in Readline and GMP go away. It's interesting to look at how the FSF's position on this evolved from We need this to be the case to This is the case -- check out /usr/share/doc/clisp, for example. That was back when Stallman used reason instead of dogma, though. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: XFree86 license difficulties
MJ Ray [EMAIL PROTECTED] writes: On 2004-02-02 20:11:45 + paul cannon [EMAIL PROTECTED] wrote: Please correct me if I'm wrong, but I understood that the FSF's opinion on this is not universal. That is, it is not an irrational view that dynamically linking to a library is only _using_ that library, not creating a derived work from it. Some works with copyright held by FSF are affected by this, so their published opinion probably would count. The copyright owner does not have the right to dictate rules contradicting copyright law. Not even if he believes copyright law is immoral. However, if there is a good reason why the result of a compile that included a file from a work, which appears only in that work because it is an extension unique to that work, is not derived from that work, I'm interested to read it. You seem to be forgetting that dynamic linking doesn't include any files. -- Måns Rullgård [EMAIL PROTECTED]
Re: XFree86 license difficulties
Brian Thomas Sniffen [EMAIL PROTECTED] writes: paul cannon [EMAIL PROTECTED] writes: As another example, a command line program could wrap the functionality of nearly all libraries. If someone didn't want to link a program with libcurl, one would simply invoke /usr/bin/curl and get much of the same functionality. Should these be different actions from a licensing standpoint? As always, let me know if I seem to be on crack. You're not on crack -- but I don't think you're right either. There's a series of fine distinctions here, and the true answer is murky enough that Debian's right to take the conservative path. Quite right, but being conservative doesn't exclude discussion. Without discussion, in our out of court, the matter will remain murky. You argue that a command line program should be no different from a dynamically linked program. The FSF argues it the other way: that dynamic linking should be treated no differently from static linking. If it *is* different, then the GPL reduces to the LGPL, and the FSF's bargaining chips in Readline and GMP go away. That's their problem. It's interesting to look at how the FSF's position on this evolved from We need this to be the case to This is the case -- check out /usr/share/doc/clisp, for example. That was back when Stallman used reason instead of dogma, though. I never thought I'd see that written by one of the regulars on this list. -- Måns Rullgård [EMAIL PROTECTED]
Re: XFree86 license difficulties
On Mon, 02 Feb 2004, Måns Rullgård wrote: The copyright owner does not have the right to dictate rules contradicting copyright law. Not even if he believes copyright law is immoral. There's no caselaw that I am aware of covering this particular issue defining precisely where a derived work ends and a separate, non-derived work begins in the context of dynamic linking. If you have a few hundred thousands dollars to spend defining this particular grey area via caselaw, feel free to do so. Until then, there's not much that Debian can, or should do, but follow a reasonable, conservative interpretation. Don Armstrong -- UF: What's your favourite coffee blend? PD: Dark Crude with heavy water. You are understandink? If geiger counter does not click, the coffee, she is just not thick. http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: XFree86 license difficulties
On 2004-02-02 22:25:11 + Måns Rullgård [EMAIL PROTECTED] wrote: MJ Ray [EMAIL PROTECTED] writes: Some works with copyright held by FSF are affected by this, so their published opinion probably would count. The copyright owner does not have the right to dictate rules contradicting copyright law. Not even if he believes copyright law is immoral. That is true, but you don't seem to say that it contradicts copyright law. If you want to do that instead of FUDding, I ask you to give references. However, if there is a good reason why the result of a compile that included a file from a work, which appears only in that work because it is an extension unique to that work, is not derived from that work, I'm interested to read it. You seem to be forgetting that dynamic linking doesn't include any files. Sorry, your telepathy is wrong. I didn't query the run-time-only case because I'm not particularly interested in that right now. Most software for XFree86 that I have seen includes files at compile. -- MJR/slef My Opinion Only and possibly not of any group I know. Please http://remember.to/edit_messages on lists to be sure I read http://mjr.towers.org.uk/ gopher://g.towers.org.uk/ [EMAIL PROTECTED] Creative copyleft computing services via http://www.ttllp.co.uk/
Re: XFree86 license difficulties
Måns Rullgård wrote: You are definitely not wrong. It's just the Debian folks that believe the faintest whisper from the FSF as were it the word of God. The FSF have an opinion that's based on some amount of legal advice. Unless we have either the at least the same amount of legal advice or a court case that says otherwise, it would be stupid for us to invite legal action by ignoring their opinions here. -- Matthew Garrett | [EMAIL PROTECTED]
Re: XFree86 license difficulties
On Mon, Feb 02, 2004 at 11:38:45PM +0100, Måns Rullgård wrote: Quite right, but being conservative doesn't exclude discussion. Without discussion, in our out of court, the matter will remain murky. Debating whether GPL-compatibility can legitimately affect dynamic linking every time a GPL compatibility issue comes up is a repetitive waste of time, and will not help resolve the issue at all. If you want to start a thread discussing it, go ahead, but all you're doing right now is subverting the XFree86 thread. It's interesting to look at how the FSF's position on this evolved from We need this to be the case to This is the case -- check out /usr/share/doc/clisp, for example. That was back when Stallman used reason instead of dogma, though. I never thought I'd see that written by one of the regulars on this list. As was pointed out, go read the archives on the GFDL issue. I don't trust the FSF when they call something free anymore; they've lost their credibility. I doubt I'm alone. Claiming that d-legal people don't use their own judgement when evaluating statements from the FSF is completely baseless. -- Glenn Maynard
Re: XFree86 license difficulties
MJ Ray [EMAIL PROTECTED] writes: On 2004-02-02 22:25:11 + MÃ¥ns RullgÃ¥rd [EMAIL PROTECTED] wrote: MJ Ray [EMAIL PROTECTED] writes: Some works with copyright held by FSF are affected by this, so their published opinion probably would count. The copyright owner does not have the right to dictate rules contradicting copyright law. Not even if he believes copyright law is immoral. That is true, but you don't seem to say that it contradicts copyright law. If you want to do that instead of FUDding, I ask you to give references. As much as I'd like to, I don't have any references. However, neither does the FSF. They are simply making claims with no backing whatsoever. However, if there is a good reason why the result of a compile that included a file from a work, which appears only in that work because it is an extension unique to that work, is not derived from that work, I'm interested to read it. You seem to be forgetting that dynamic linking doesn't include any files. Sorry, your telepathy is wrong. I didn't query the run-time-only case because I'm not particularly interested in that right now. Most software for XFree86 that I have seen includes files at compile. No, they merely include an instruction to the dynamic linker to link in libX11.so. The libX11.so that gets linked at runtime could come from any vendor, as long as it is compatible. In practice, there won't be many binary compatible variants around, but that's a non-issue. The important part is that no code from the library is included in the compiled and linked program when distributed. -- Måns Rullgård [EMAIL PROTECTED]
Re: XFree86 license difficulties
Glenn Maynard [EMAIL PROTECTED] writes: On Mon, Feb 02, 2004 at 11:38:45PM +0100, Måns Rullgård wrote: Quite right, but being conservative doesn't exclude discussion. Without discussion, in our out of court, the matter will remain murky. Debating whether GPL-compatibility can legitimately affect dynamic linking every time a GPL compatibility issue comes up is a repetitive waste of time, and will not help resolve the issue at all. If you want to start a thread discussing it, go ahead, but all you're doing right now is subverting the XFree86 thread. Been there, done that, learned something about GNU zealots. I'll try to stay out of this thread from now on. -- Måns Rullgård [EMAIL PROTECTED]
Re: XFree86 license difficulties
On Tue, 03 Feb 2004, Måns Rullgård wrote: As much as I'd like to, I don't have any references. However, neither does the FSF. They are simply making claims with no backing whatsoever. You seem to forget that the GPL and the FSF's interpretation have been researched rather carefully by its drafter, Eben Moglen. This interpretation did not spring up tabula rasa. It is possible that a court ruling might not back up their interpretation, but it is very improper to claim that the FSF has no backing to their interpretation at all. Don Armstrong -- Debian's not really about the users or the software at all. It's a large flame-generating engine that the cabal uses to heat their coffee -- Andrew Suffield (#debian-devel Fri, 14 Feb 2003 14:34 -0500) http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: XFree86 license difficulties
On 2004-02-03 00:46:13 + Måns Rullgård [EMAIL PROTECTED] wrote: As much as I'd like to, I don't have any references. However, neither does the FSF. They are simply making claims with no backing whatsoever. You're making claims with no backing. In my position, would you believe Måns Rullgård or FSF more about how FSF will seek to enforce its licence? If Eben Moglen tries to enforce the FSF view, will Måns Rullgård defend us successfully or insure us? Sorry, your telepathy is wrong. I didn't query the run-time-only case because I'm not particularly interested in that right now. Most software for XFree86 that I have seen includes files at compile. No, they merely include an instruction to the dynamic linker to link in libX11.so. I should have noted that I have mostly seen window manager code. It seems they're not typical. Sorry for the misleading message, but I'd still prefer replies to the case that concerns me more. Bah anti-GNU zealots, driving us off-topic. -- MJR/slef My Opinion Only and possibly not of any group I know. Please http://remember.to/edit_messages on lists to be sure I read http://mjr.towers.org.uk/ gopher://g.towers.org.uk/ [EMAIL PROTECTED] Creative copyleft computing services via http://www.ttllp.co.uk/
Re: XFree86 license difficulties
On Tue, Feb 03, 2004 at 01:49:41AM +0100, Måns Rullgård wrote: Been there, done that, learned something about GNU zealots. I'll try to stay out of this thread from now on. Why do you insist on calling d-legal people GNU zealots? The fact that this is at least the third time in two days that you've made this flame, without giving any backing and ignoring evidence to the contrary, makes you seem an anti-debian-legal zealot. -- Glenn Maynard
Re: XFree86 license difficulties
Wouldn't linking a GPL program against XFree86 fall under the operating system exemption anyway?
Re: XFree86 license difficulties
On Mon, 02 Feb 2004, Ken Arromdee wrote: Wouldn't linking a GPL program against XFree86 fall under the operating system exemption anyway? No, because we don't distribute X in base (or as an essential package.) [In general, if you can have a working system without Y, Y doesn't meet the OS exemption.] Don Armstrong -- Filing a bug is probably not going to get it fixed any faster. -- Anthony Towns http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: XFree86 license difficulties
On Mon, Feb 02, 2004 at 09:35:39PM -0500, Ken Arromdee wrote: Wouldn't linking a GPL program against XFree86 fall under the operating system exemption anyway? Debian can never use this exception, due to the ... unless that component itself accompanies the executable clause. (You can use a GPL program in Windows, but Microsoft can't include a GPL program with Windows.) -- Glenn Maynard
Re: XFree86 license difficulties
On Mon, Feb 02, 2004 at 06:54:06PM -0800, Don Armstrong wrote: On Mon, 02 Feb 2004, Ken Arromdee wrote: Wouldn't linking a GPL program against XFree86 fall under the operating system exemption anyway? No, because we don't distribute X in base (or as an essential package.) [In general, if you can have a working system without Y, Y doesn't meet the OS exemption.] This really depends on how you define normally distributed. I think an arguable position can be made that Debian includes XFree86 normally. Besides your standard doesn't even hold for the examples the GPL gives. You don't need a compiler to have a working system, yet the GPL gives a compiler as an example. It also depends on how you define the operating system which the executable runs. If you define it narrowly then you could say the executable runs on Debian. You could define it more broadly as Linux or Unix like operating systems. In the case of the latter two it is pretty normal to include an X11 implementation of some sort. I think there are several ways of interpreting how broadly to apply the operating system exception. All of which can reasonably be accepted as valid interpretations. I'm not sure if FSF has weighed in on this issue but I'd guess Debian would yield to whatever their interpretation of the issue was. -- Ben Reser [EMAIL PROTECTED] http://ben.reser.org Conscience is the inner voice which warns us somebody may be looking. - H.L. Mencken
Re: XFree86 license difficulties
On Mon, 02 Feb 2004, Ben Reser wrote: On Mon, Feb 02, 2004 at 06:54:06PM -0800, Don Armstrong wrote: No, because we don't distribute X in base (or as an essential package.) [In general, if you can have a working system without Y, Y doesn't meet the OS exemption.] This really depends on how you define normally distributed. I think an arguable position can be made that Debian includes XFree86 normally. Besides your standard doesn't even hold for the examples the GPL gives. You don't need a compiler to have a working system, yet the GPL gives a compiler as an example. The compiler is an example for some operating systems, but I'm not so confident that it applies to Debian. [See the recent discussion on -devel whether gcc should remain standard for an example of why I'm not so confident.] Perhaps we could define the normal distribution as all packages in base or standard... but I would be really wary about getting out of the GPL's derived requirement that way. It also depends on how you define the operating system which the executable runs. This is generally the OS on which the executable as distributed is intended to run, which is (basically) Debian. I'm not sure if FSF has weighed in on this issue but I'd guess Debian would yield to whatever their interpretation of the issue was. Yeah. My own personal feeling is that we shouldn't be distributing anything to which we need to apply this exception, unless it's something that we have historically considered to be covered under it. Don Armstrong -- She was alot like starbucks. IE, generic and expensive. -- hugh macleod http://www.gapingvoid.com/batch3.htm http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: XFree86 license difficulties
On Mon, 02 Feb 2004, Glenn Maynard wrote: On Mon, Feb 02, 2004 at 08:22:05PM -0800, Don Armstrong wrote: Yeah. My own personal feeling is that we shouldn't be distributing anything to which we need to apply this exception, unless it's something that we have historically considered to be covered under it. Huh? unless that component itself accompanies the executable. Debian can't use the OS exception. (It seems that the OS exception is intended to allow people to use GPL programs on non-free systems, while not allowing non-free systems to include GPL programs directly.) For reference the full clause under discussion: 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. If you want to argue that everything we distribute accompanies the executable, I guess that's a possible argument, although that's a new one to me. Doesn't really matter to me though... the net effect is pretty much the same. Don Armstrong -- DIE! -- Maritza Campos http://www.crfh.net/d/20020601.html http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Warning: E-mail viruses detected
This is a message from the Wesleyan E-Mail Virus Protection Robot -- You sent an e-mail to [EMAIL PROTECTED] with the subject Test on Mon Feb 2 23:55:21 2004 that was infected by a virus. We have deleted this file and have not sent it on to the recipient. Please disinfect the file before sending it. More information about this service and instructions on how to disinfect files can be found at http://www.wesleyan.edu/its/advisory/sophos.html. Thank you, The Wesleyan E-Mail Virus Protection Robot * Please note: This is a fully automated robotic service. Your email is NOT being scanned by a human being. **
