Re: License concerns regarding package lft
Terry Hancock [EMAIL PROTECTED] wrote: [...] A court is going to consider what the apparent intent was -- not try to stretch the meaning beyond the obvious. Intent is not written on the paper. It seemed obvious to me that this clause hinders binaries. It seemed obvious to Florian Weimer that it rules out private changes. So, I don't think it's obvious what the intent was. [...] You can do that, because the license is POORLY WRITTEN. Which I have already said. Miraculously, you and I appear to AGREE on that point. One consequence of this is that some lawyer might try to play the same games with the language that you are doing here. In other words, this is an obvious lawyerbomb and we need further data. [...] I'm trying to understand how it is possible to claim that compilers don't fit the meaning of materials there That would be by using the *normal*, *first* definition of materials and not some alternate meaning that has come about by association. Normal? First? Those imaginary English Language Meaning Norms don't exist. On the shelf behind me, I have ten dictionaries, and there's more in the office across the landing and in my living room at home. It doesn't matter whether one can support a view with a dictionary - I've made that mistake in the past. Is it ambiguous? Yes. Is it clarified by licensor statements or case law? I haven't found any. There is also the point that it wouldn't make any sense to require the meaning you are attempting to press: is there even a compiler which can be released in source format under conditions of this license? If not, then it stands to reason that the author, knowing this, cannot have intended to limit compilation to such a hypothetical compiler. [...] It wouldn't be the first source-only-distribution licence I've seen, or the first licence to rely on US-style Fair Use. [...] Intent is a matter of pragmatics[1] -- the study of situated utterances as evidence for meaning, not semantics[2] -- the study of isolated utterances for potential meaning. [...] I repeat my pragmatic questions ignored so far: can we tell how this is interpreted by the licensor? Can we claim binaries are GPL by clause 6 or does the 'no permission is granted...' style of clause 7 overrule it? Any more comments? Please stop getting so personal and flamey. Regards, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License concerns regarding package lft
Terry Hancock [EMAIL PROTECTED] wrote: No, what I *said* is that tools are not materials, which they are not -- at least not unless you use them as such. If you build a house out of hammers, *then* the hammers are materials, otherwise, they are tools. So, to be clear: you would claim that if one says 'this house is made using these materials' then the tools are not included in 'materials'? Would you expect an art *materials* catalogue to include easels, brushes, knives and other things used to make the art but not included in it? Here are the top three results of a web search for art materials: http://www.dickblick.com/ http://www.homecrafts.co.uk/html/categories.asp?cat1=3 http://www.artdiscount.co.uk/ [...] foregone conclusion in a license text that definitions are relative to the work being licensed! When a license says derivative, we all understand without being told that derivative of the work being licensed is meant, and not derivative of some other, unrelated work. I don't see the relevance of stating the obvious here. Hence, when we say materials, we mean used AS materials, not things that could in principle be used as materials but were in fact used as tools. But they are used as materials IMO. Returning to the house-building example, I don't see hammers as consumed entirely by my construction, so I wouldn't expect to see them on my bill of materials, but they are materials used in the construction, so I'd expect them to be available from a building materials supplier. [...] The strawman you are attempting to bait me with [...] Please, get over this. I'm not baiting anyone with any scarecrow. I'm trying to understand how it is possible to claim that compilers don't fit the meaning of materials there - in fact, unlike most hammers, most compilers even leave part of themselves in the construction - and whether this is based on a misunderstanding like the one posted about copyleft and upstream contributions recently. Regards, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License concerns regarding package lft
MJ Ray wrote: Terry Hancock [EMAIL PROTECTED] wrote: No, what I *said* is that tools are not materials, which they are not -- at least not unless you use them as such. If you build a house out of hammers, *then* the hammers are materials, otherwise, they are tools. So, to be clear: you would claim that if one says 'this house is made using these materials' then the tools are not included in 'materials'? This is not so much clear as completely different, but yes, that is the principle meaning of the word materials and the ony logical reason why the author would've used the term here. A court is going to consider what the apparent intent was -- not try to stretch the meaning beyond the obvious. Would you expect an art *materials* catalogue to... Hereafter, you are trying to stretch the meaning to something that it obviously wasn't intended to mean. You can do that, because the license is POORLY WRITTEN. Which I have already said. Miraculously, you and I appear to AGREE on that point. One consequence of this is that some lawyer might try to play the same games with the language that you are doing here. I think the court would laugh in his face, but who knows? I'm trying to understand how it is possible to claim that compilers don't fit the meaning of materials there That would be by using the *normal*, *first* definition of materials and not some alternate meaning that has come about by association. There is also the point that it wouldn't make any sense to require the meaning you are attempting to press: is there even a compiler which can be released in source format under conditions of this license? If not, then it stands to reason that the author, knowing this, cannot have intended to limit compilation to such a hypothetical compiler. This is yet more evidence for an intent which agrees with the obvious interpretation of the language. So, are you saying you honestly believe the author's intent was to block compilation of changes to his package altogether? If so, why distribute source at all? Furthermore, you believe that having this irrational intent, he then tried to hide it by using a word which *might* be interpreted to support his intent, but whose most obvious meaning contradicts it? I find that a pretty implausible theory. Your interpretation is distorts the license's original intent by using alternate meanings of words. As such it may even be semantically correct (that is, it may be within the set of possible semantic meanings of the utterance), but it is pragmatically incorrect (it is not the subset of that set that was meant by the author -- as we can tell from context). Intent is a matter of pragmatics[1] -- the study of situated utterances as evidence for meaning, not semantics[2] -- the study of isolated utterances for potential meaning. You're pounding very hard on the semantics, trying to broaden the set of possible meanings, and you're not wrong about that as far as you go, but that's missing the point. The question was not what could this sentence possibly mean, but what did this sentence mean when the author wrote it -- which is what actually matters legally. The rest of the license, the fact of using the license, the fact of releasing software with source code and the consequences of licensing choices all provide situational information which supports the pragmatic interpretation of the sentence in question. The fact that courts (or we) have to go beyond semantics to understand the license is a serious flaw of the license, which I've already pointed out, but as evidence of the author's actual intent, I think it is sufficient. Cheers, Terry IANAL, TINLA, etc. [1] http://en.wikipedia.org/wiki/Pragmatics [2] http://en.wikipedia.org/wiki/Semantics -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License concerns regarding package lft
Martin Millnert wrote: 7. no permission is granted to distribute, publicly display, or publicly perform modifications to the Distribution made using proprietary materials that cannot be released in source format under conditions of this license; Section 7 seems suspicious. Isn't that just a copyleft requirement? This is effectively how the GPL works -- denying distribution rights if the work is combined with proprietary work. The wording could stand to be improved, though. Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License concerns regarding package lft
Martin Millnert [EMAIL PROTECTED] wrote: [...] 7. no permission is granted to distribute, publicly display, or publicly perform modifications to the Distribution made using proprietary materials that cannot be released in source format under conditions of this license; [...] Section 7 seems suspicious. Is this saying (amongst other things) that someone cannot use any incompatibly-licensed compiler to produce binaries of it? After all, that compiler would be materials that cannot be released in source format under conditions of this licence. If so, how does that not break DFSG 9 by contaminating other software? In practical terms, we are compiling lft with gcc http://buildd.debian.org/fetch.cgi?pkg=lftver=2.0-1arch=ia64stamp=1045692069file=log and gcc is under the GPL http://www.gnu.org/licenses/gpl.html which cannot be released in source format under MainNerve Public License. Why are the lft binary packages distributable? There is a slightly different licence at http://pwhois.org/license.who but this part has not changed. Hope that helps, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License concerns regarding package lft
MJ Ray wrote: Martin Millnert [EMAIL PROTECTED] wrote: [...] 7. no permission is granted to distribute, publicly display, or publicly perform modifications to the Distribution made using proprietary materials that cannot be released in source format under conditions of this license; [...] Section 7 seems suspicious. Is this saying (amongst other things) that someone cannot use any incompatibly-licensed compiler to produce binaries of it? IMHO, it does NOT mean that. I think that a compiler or other toolchain element is not a material -- materials are things that go into a structure and become part of it: lumber, paneling, roofing, etc. NOT circular saws, hammers, jigs, etc. This would be as opposed to tools: from GCIDE: Material \Ma*teri*al\, n. The substance or matter of which anything is made or may be made. [1913 Webster] Based on this license, I believe that the copyleft would extend to things that are incorporated into or linked into the work: software libraries fonts graphic resources but NOT to things that are only used in the production process: compilers editors UNFORTUNATELY, my interpretation relies on the definition and usage of the word materials. Which I think is less clear than it could be, and perhaps requires a very good grasp of English usage, which may be especially problematic internationally. So, if possible, I would encourage the original author to improve the license text (which shouldn't bother them, because I don't think they intend anything beyond DFSG). Changing using to from -- i.e. made from proprietary materials -- makes it much clearer. There are people who would object further that proprietary is poorly defined and also that stating things in the negative is pretty confusing. But I think it is usable like it is, even if no such changes can be made. Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License concerns regarding package lft
Terry Hancock [EMAIL PROTECTED] MJ Ray wrote: 7. no permission is granted to distribute, publicly display, or publicly perform modifications to the Distribution made using proprietary materials that cannot be released in source format under conditions of this license; Is this saying (amongst other things) that someone cannot use any incompatibly-licensed compiler to produce binaries of it? IMHO, it does NOT mean that. I think that a compiler or other toolchain element is not a material -- materials are things that go into a structure and become part of it: lumber, paneling, roofing, etc. NOT circular saws, hammers, jigs, etc. This would be as opposed to tools: [...] So, in your opinion, houses are not made using tools and binary packages are not made using compilers? I disagree. I think that it might be debatable if it said 'made from' but it doesn't. The meaning of tools doesn't change the meaning of materials. Overlapping meanings and different meanings for similar words in different fields are not that unusual in English. [...] perhaps requires a very good grasp of English usage, which may be especially problematic internationally. Referencing a near-century-old US dictionary while suggesting that an Englishman is wrong about English usage won't win my friendship. (FWIW, the dictionary seems accurate as written in this case, but beside the point here and not supporting the claim above.) So, if possible, I would encourage the original author to improve the license text [...] Probably a good idea and a good idea for the improvement not to mention 'materials' at all. I'm still worried by the current phrasing - can we tell how this is interpreted by the licensor? Can we claim binaries are GPL by clause 6 or does the 'no permission is granted...' style of clause 7 overrule it? I see that Florian Weimer was also concerned by this phrasing in http://lists.debian.org/debian-legal/2005/07/msg00220.html although it wasn't mentioned what package was being discussed. Any more comments? Regards, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License concerns regarding package lft
MJ Ray wrote: Terry Hancock [EMAIL PROTECTED] So, in your opinion, houses are not made using tools and binary packages are not made using compilers? No, what I *said* is that tools are not materials, which they are not -- at least not unless you use them as such. If you build a house out of hammers, *then* the hammers are materials, otherwise, they are tools. And yes of course that means that hammers used to build one house and then used as materials for another are both tools and materials, but it is a foregone conclusion in a license text that definitions are relative to the work being licensed! When a license says derivative, we all understand without being told that derivative of the work being licensed is meant, and not derivative of some other, unrelated work. Hence, when we say materials, we mean used AS materials, not things that could in principle be used as materials but were in fact used as tools. Because the license does say materials, it confines the meaning of the word using (which can have multiple meanings -- a flaw in the wording, but not a flaw in the intent). The strawman you are attempting to bait me with is an assertion of the exact opposite claim: i.e. that using not only confines the meaning of materials but that it would confine the meaning of a word like tools to mean materials. This claim is obviously false. However, that has no bearing at all on what I said. In fact, it is the nature of the word using to be almost entirely defined by the noun: to use X means to do whatever you normally do with X. Thus, the meaning of use materials lies entirely in the definition of materials. Hence, the definition of the word -- which you did not refute -- is what determines the meaning of that phrase in the license. Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
License concerns regarding package lft
Hello Debian Legal, I stumbled upon a package, lft, and noticed that the distributed packaged was somewhat of age. I looked it up and found quite updated source at the program developers webpage [1]. So I pondered over why this is not included; maybe the package maintainer is just asleep. Then I found the license [2], and thought that might be the fault. Following that I checked the license included in the ordinary Debian package, distributed in main. I now noticed that they are alike, which prompted this message. I'm running Debian Etch and this is the output of dpkg -s lft: Package: lft Status: install ok installed Priority: optional Section: net Installed-Size: 88 Maintainer: Vince Mulhollon [EMAIL PROTECTED] Architecture: i386 Version: 2.2-3 Depends: libc6 (= 2.3.2.ds1-21), libpcap0.7 Description: layer-four traceroute lft sends various TCP SYN and FIN probes (differing from Van Jacobson's UDP-based method) utilizing the IP protocol time to live field and attempts to elicit an ICMP TIME_EXCEEDED response from each gateway along the path to some host. lft also listens for various TCP and ICMP messages along the way to assist network managers in ascertaining per-protocol heuristic routing information and can optionally retrieve various information about the networks it traverses. . Homepage: http://www.mainnerve.com/lft/index.html This is the contents of /usr/share/doc/lft/copyright: This package was debianized by Marco d'Itri [EMAIL PROTECTED] on Tue Feb 11 11:54:28 CET 2003. It was downloaded from http://www.mainnerve.com/lft/ Upstream Author: MainNerve, Inc. Copyright: MainNerve Public License for Open Source -- Copyright (c) 2002 MainNerve, Inc. This MainNerve, Inc. Distribution (code and documentation) is made available to the open source community as a public service by MainNerve. Contact MainNerve at [EMAIL PROTECTED] for information on other licensing arrangements (e.g. for use in proprietary applications). Under this license, this Distribution may be modified and the original version and modified versions may be copied, distributed, publicly displayed and performed provided that the following conditions are met: 1. Modified versions are distributed with source code and documentation and with permission for others to use any code and documentation (whether in original or modified versions) as granted under this license; 2. if modified, the source code, documentation, and user run-time elements should be clearly labeled by placing an identifier of origin (such as a name, initial, or other tag) after the version number; 3. users, modifiers, distributors, and others coming into possession or using the Distribution in original or modified form accept the entire risk as to the possession, use, and performance of the Distribution; 4. this copyright management information (software identifier and version number, copyright notice and license) shall be retained in all versions of the Distribution; 5. MainNerve may make modifications to the Distribution that are substantially similar to modified versions of the Distribution, and may make, use, sell, copy, distribute, publicly display, and perform such modifications, including making such modifications available under this or other licenses, without obligation or restriction; 6. modifications incorporating code, libraries, and/or documentation subject to any other open source license may be made, and the resulting work may be distributed under the terms of such open source license if required by that open source license, but doing so will not affect this Distribution, other modifications made under this license or modifications made under other MainNeve licensing arrangements; 7. no permission is granted to distribute, publicly display, or publicly perform modifications to the Distribution made using proprietary materials that cannot be released in source format under conditions of this license; 8. the name of MainNerve may not be used in advertising or publicity pertaining to Distribution of the software without specific, prior written permission. This software is made available as is, and MAINNERVE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, WITH REGARD TO THIS SOFTWARE, INCLUDING WITHOUT LIMITATION ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, AND IN NO EVENT SHALL MAINNERVE BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, TORT (INCLUDING NEGLIGENCE) OR STRICT LIABILITY, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. Section 7 seems suspicious. Cheers, -- Martin Millnert [EMAIL
