Re: ISO 3166 copyright
On Wed, May 28, 2003 at 09:35:29PM +0100, Alastair McKinstry wrote: > The purpose of the package was to provide an accurate, LGPL'd version of > the ISO 3166, 639 and 4217 standards., along with translations into the > various languages supported by Debian. > > I was not aware of the copyright notice that you gave a pointer to; I > shall have to think about that, and get an opinion on debian-legal. Bah, there's no copyright in those lists; just like there's no copyright in the listings of the phone book. Please attack and destroy people with _Feist v. Rural Telephone Service Co._[1]. [1] http://www.law.cornell.edu/copyright/cases/499_US_340.htm -- G. Branden Robinson| Good judgement comes from Debian GNU/Linux | experience; experience comes from [EMAIL PROTECTED] | bad judgement. http://people.debian.org/~branden/ | -- Fred Brooks pgpQAcQ8dqNwq.pgp Description: PGP signature
Re: The debate on Invariant sections (long)
Of course, both the FSF and Debian regard the BSD advertising clause as an inconvenience, not as grounds for ruling the license to be non-free; so while RMS's reasoning may be to some degree inconsistent here (advocating against one inconvenient license and for another), This isn't inconsistent--consistency does not make sense here. We all accept various inconveniences to achieve our ends, while rejecting others as not worth while. And each decision depends on the magnitude of the costs and benefits. To choose the same option in all such decisions would be irrational. The BSD advertising clause produced a large practical inconvenience because it was cumulative for the entire system. An ad would have to mention every contributor in the entire system who had used such a clause, and there might literally not be room in an ad for so many. I carefully designed the GFDL not to have such a space problem if there were many publishers, but such a situation probably won't arise anyway. The GFDL only cumulates for a single manual, not the entire system distribution. In a nightmare one can imagine large numbers of cover texts in one manual, but it isn't likely to happen. Where the BSD advertising clause produced a mountain, the GFDL produces a molehill.
Re: GDB manual
Unfortunately, other people purporting to act on behalf of the FSF do. Did they really claim to be speaking for the FSF, or were they just expressing support for the FSF? Anyone can do the latter, but we did not ask anyone to speak for the FSF about this issue on this list. (Meanwhile, messages regarding the perceived problems have generally been ignored outright. Even messages asking for clarification: "It looks to me like the FDL prohibits this. Depending on where and how you sent them, that might or might not indicate a problem. [EMAIL PROTECTED] is the standard place for inquiries. If questions sent there did not get answered, please show me the unanswered message so I can investigate what went wrong. I will try to make sure it does not happen again. But the issue here is the question of how Debian should decide interpret its standards--whether they should be interpreted so strictly as to reject the GFDL, and also the GPL if it hadn't been "grandfathered."
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
Anthony DeRobertis <[EMAIL PROTECTED]> writes: > On Tuesday, May 27, 2003, at 15:20 US/Eastern, Brian T. Sniffen wrote: > >> Anthony DeRobertis <[EMAIL PROTECTED]> writes: >>> OK, then I take it you're in favor filing seriouss bug against >>> ftp.debian.org asking for the removal of apache-ssl and *many* more >>> packages like it. >> >> Not quite -- I'd prefer to find a more reasonable solution first, and >> begin implementing it second. > > Can we call Lotus v. Borland a reasonable solution? ;-) Heh. Given the chain of logic: "A means of operation is not copyrightable"; "All user interfaces are means of operation"; "exec() is a programmatic user interface"... I'm even willing to concede that exec() is always a boundary between works. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Bug #189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Tuesday, May 27, 2003, at 12:22 US/Eastern, Nathanael Nerode wrote: First, any interface which could be used by humans is a "method of operation". This is essentially all interfaces. That's a good question. I think the decision only covers interfaces that humans need to use to use the program (and all its features). However, for a library, it is quite arguable that the API is covered. Since dynamic linking involves the copying of small, (usually) uncopyrightable, code segments, together with the use of an interface, dynamic linking incurs no obligations, and the FSF's interpretation is quite wrong. This is quite possible, especially since if the normally copyrightable commands used in a menu are not copyrightable because they are a method of operation, its possible the method names, etc., needed to dynamic link are, too. Second, any interface which is designed for use by humans is a "method of operation". This is more restrictive, but does not touch the question of secret interfaces. Suppose that passing "-EF)#I^FMCVS)[EMAIL PROTECTED])[EMAIL PROTECTED]" on the grep command line gives access to the secret operations -- is this the means by which a "person" operates something? I think its probable. Even if it isn't, I doubt you could claim copyright over the above string. Same problem with the longer (random) string. If my second extrapolation is the correct one, then the documentation status *may* be relevant as evidence for whether the interface was designed for humans or not, though what matters is whether the GPL program creator documented it. I think that a program which uses command line arguments, one of the standard ways of user interaction on Unix, is very strong evidence that it is a method of operation. It'd be hard, I think, to argue that the command line interface is not intended for humans. (In fact, its other interface designed for 'people to operate it' is the interface for being statically linked with programs, so use of static linking probably isn't covered either! Although in that case the combination is probaly a 'derived work' and may not be redistributable; but individuals can do the linking themselves quite freely.) The GPL never covered use, and copyright law (at least in the US) specifically exempts copying needed to use a computer program, so I don't think the GPL ever prohibited private, non-distributed linking. If my third extrapolation is the correct one, then the FSF's library linking interpretation is valid, but we've wandered into a remarkably fuzzy realm. Certain command-line options are rarely, if ever, used by humans; for instance, options designed to produce better program-readable output. Those options are _very_ often used by humans. Part of the UNIX user interface is the pipe operator in every shell. However, if the 'linkage' causes program B to rely on copyrighted elements of program A, but the 'linkage' is not actually performed except by the end-user, then there is no infringment on the part of the distributor. And the GPL puts no restrictions on 'use', or indeed creation of derived works as long as they're not distributed, so there's no cause for contributory infringment, as far as I can tell. I don't think there is any way to be a contributory infringer when there is no infringement. I'm not sure if eventually dynamic linking will become a way around copyleft licenses, but I wouldn't be surprised if --- should it ever be tested in court --- it turns out to often be. Disclaimer: This is not legal advice! Very strong ditto there.
Re: Bug #189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Tuesday, May 27, 2003, at 14:25 US/Eastern, Steve Langasek wrote: This assumes that the FSF's interpretation depends on the claim that dynamic linking creates a derived work. Well, from carefully reading the GPL, this appears to be what it says. A quote: a "work based on the Program" means either the Program or any derivative work under copyright law:" that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. So, if a new_program is neither a derivative work of Program or Program itself, then it is not a "work based on the Program" as used in the GPL. And then: In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. So, the GPL is very clear that new_program is not covered by the GPL.
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Tuesday, May 27, 2003, at 15:19 US/Eastern, Brian T. Sniffen wrote: All of those -- TCP, HTTP, and DEB -- are generic formats. .deb isn't. There is, AFAIK, only one implementation. At the very least, alien and dpkg deal with it; I believe there are others. If I remember correctly, alien uses dpkg-deb to do its work. Even if not, isn't alien GPL? [...] but really, you'd rather be writing a derivative of a GPL work than a GFDL work. At least we can agree on that ;-) I wonder how this relates to library interfaces... Me too.
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Tuesday, May 27, 2003, at 15:20 US/Eastern, Brian T. Sniffen wrote: Anthony DeRobertis <[EMAIL PROTECTED]> writes: OK, then I take it you're in favor filing seriouss bug against ftp.debian.org asking for the removal of apache-ssl and *many* more packages like it. Not quite -- I'd prefer to find a more reasonable solution first, and begin implementing it second. Can we call Lotus v. Borland a reasonable solution? ;-)
Re: ISO 3166 copyright
The purpose of the package was to provide an accurate, LGPL'd version of the ISO 3166, 639 and 4217 standards., along with translations into the various languages supported by Debian. I was not aware of the copyright notice that you gave a pointer to; I shall have to think about that, and get an opinion on debian-legal. While the ISO 639 list came from elsewhere To the best of my knowledge, representing such a list in a different electronic form does not represent a breach of copyright, and the list in the iso-codes package, collected from various places on the web with corrections by others, is not a breach of copyright; however I will get a legal opinion on this matter. If the _short_ country names are protected, one possibility is to only use the long forms in the iso-3166.tab file, with the translations translating the long form into short form for each .po file, including an English .po file. (Note: this information is used in other places within Debian, so the issue goes beyond this package). Regards, Alastair McKinstry On Wed, 2003-05-28 at 20:12, Bram Vandoren wrote: > Hi, > > I am looking for a descent country list to use in a GPL application. > > I found the list in your iso-codes package and on this page: > http://www.iso.ch/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/index.htm > > On top of that page there is a copyright notice: > 'The short country names from ISO 3166-1 and the alpha-2 codes are made > available by ISO at no charge for internal use and non-commercial purposes. > The use of ISO 3166-1 in commercial products may be subject to a licence > fee.' > > Does your package has the same restriction or did you find it somewhere else? > > Thanks, > Bram Vandoren.
Re: OpenLDAP Licenseing issues
Steven, The OpenLDAP Foundation believes it the Regents' statement grants a license to redistribute derived works and is confident that the University, who is quite aware of our actions (as they actively participate in them), does not consider our actions to infringe on their rights. You are welcomed to your opinions. I suggest, however, that before you rely on your or other people's opinions (including ours), that you consult with a lawyer familiar with applicable law and the particulars of your situation. The Foundation sees no reason for it to expend its limited resources seeking clarifications which it believes are unnecessary. You are, of course, welcomed to expend time and energy seeking clarifications you think are necessary. I suggest you contact University's general counsel office (http://www.umich.edu/~vpgc/). Regards, Kurt
Re: Fw: [argouml-dev] Licence issue (debian in particular)
Many thanks to everybody for your responses. As I understand, I'll have to remove this code from argouml or move argouml to non-free... or ask Sun to change their license ;-) Am I right? Joel Baker <[EMAIL PROTECTED]> wrote: > On Tue, May 27, 2003 at 07:44:33PM +0200, Henning Makholm wrote: > > Scripsit Joel Baker <[EMAIL PROTECTED]> > > > > > Or, in other words, it may well fail DFSG #6, because the upstream > > > is very likely to be completely unwilling to open themselves up to > > > the lawsuits that could result from a critical failure of their > > > software when used in a safety-critical system where a failure > > > could wreak havoc over a large geographical area. > > > > But they could protect themselves perfectly well without trying to > > use their license to *forbid* use in saftety-critical systems. What > > they're saying here is not just "it'll not be our fault if something > > happens" - they're saying "you will be in violation of the license > > if you use it for X, so you can except to be sued". > > Actually, that's arguable. The reason the boilerplate appeared in the > first place, in commercial software, was the exceedingly high > potential liability if a court found that you were not, in fact, > allowed to disclaim responsiblity, and someone used it in a > safety/life-critical system. > > Remember, just because it says "No warranty, express or implied" > doesn't make it true, in some places. Conversely, I'm not actually > saying it should be allowed as an exception; it was mostly trying to > explain why Sun probably has that clause, and why they might refuse to > remove it (we can only hope they'll remove it for an attempt at free > licensing, entirely *because* the liability issues could be > significantly different, and merely requiring a positive understanding > that the software is not meant for those uses could potentially > suffice). > > > > (Similar notices are often seen for life-critical systems such as > > > medical, military support, or other similar stuff). > > > > To the best of my knowledge we don't have any such (== trying to > > restrict use rather than merely disclaim warranty) notices in > > Debian. If we have, bugs should be filed against those packages. > > See above; I wasn't trying to imply it should be exempted, as-is, and > I'm sorry if it came across that way. It was mostly meant as context > (especially for folks who've never seen the requirements list for > nuclear-safe stuff). Though I think removing the word 'licensed' there > would probably make it pass, since it doesn't explicitly forbid you > from doing it, only require that you grasp that it wasn't built for > that (and, as such, shifts the liability from them, for allowing it, > to you, for being stupid enough to have not followed the > requirements). -- Arnaud Vandyck, STE fi, ULg pgppcUE0YEMhg.pgp Description: PGP signature
Re: OpenLDAP Licenseing issues
* Kurt D. Zeilenga ([EMAIL PROTECTED]) wrote: > There were a number of files in U-Mich LDAP software distribution > which contained no notice or a notice with no license statement. > The OpenLDAP Foundation considers each of these files to be > copyright by U-Mich and subject to the license which U-Mich provided > in the U-Mich LDAP distribution. A copy of that license remains > in the COPYRIGHT file now distributed with OpenLDAP Software. I have read the U-Mich license which is included in the COPYRIGHT file and it does not appear to grant the right to modify the work and redistribute the modified version. The lack of this right is of concern to us and I would think it would be of concern to the OpenLDAP Foundation as well. An example of where this might come up is shown at http://www.openldap.org/devel/cvsweb.cgi/libraries/liblutil/setproctitle.c?hideattic=1&sortbydate=0 where a file under the U-Mich license was modified and then distributed. Can you clarify this apparent discrepancy between the rights grants by the license and the acts of the OpenLDAP Foundation? My general feeling on this is that the right to redistribute modified works was intended to be granted by U-Mich and that they meant to imply it in their license and that is what the OpenLDAP Foundation has been operating under. Having this stated explicitly would benefit anyone looking at the licenseing for OpenLDAP when determining if they can use it or if they can include it in their distribution. Since I would expect this is of concern to the OpenLDAP Foundation I would hope that they might be willing to clarify it or to contact U-Mich to have them clarify it since they likely have a contact at U-Mich. If the OpenLDAP Foundation does not share my view then I would ask if they would be kind enough to point us in the right direction at U-Mich so that we might contact them to resolve this question. > And, as stated in the OpenLDAP COPYRIGHT file, some files may > be subject to additional restrictions. > > The OpenLDAP Foundation makes no assertion of compatibility or > incompatibility between terms placed upon OpenLDAP Software by > its copyright holders and terms placed upon other works by > their copyright holders which OpenLDAP Software may be combined > with. Our primary concern is to understand the licenseing under which OpenLDAP is distributed so that we may make an informed decision as to how it fits in our distribution. We do not ask the OpenLDAP Foundation to make the determination for us as to how OpenLDAP may fit into our distribution or how the OpenLDAP licenseing interacts with other licenses in our distribution but only to clarify the licenseing terms under which the OpenLDAP Foundation distributes OpenLDAP. Thanks, Stephen pgpQsyhUhaztS.pgp Description: PGP signature
Re: The debate on Invariant sections (long)
Perhaps the best thing to do is contact someone from the Wikipedia and ask them to summarize the situation in a mail to RMS, and relate to him whether or not they felt "burnt", or perceived a threat of inconvenience large enough to cripple their project. They can do that if they want, but even supposing that the GFDL turns out to have undesirable results in a certain situation, that doesn't really relate to the issue at hand: whether it is a free documentation license.
Re: OpenLDAP Licenseing issues
At 09:13 PM 5/27/2003, Steve Langasek wrote: >I am assuming that all files without copyright statements are >effectively under the OpenLDAP Public License. As Executive Director of The OpenLDAP Foundation, let me state that I believe your assumption to be incorrect. OpenLDAP Software is a combined, derived work. The COPYRIGHT file contained in the distribution details terms which apply to the work as a whole. The foundation generally regards the University of Michigan (U-Mich) to have significant rights to OpenLDAP Software as the primary copyright holder of the original U-Mich LDAP software distribution from OpenLDAP Software is derived. There were a number of files in U-Mich LDAP software distribution which contained no notice or a notice with no license statement. The OpenLDAP Foundation considers each of these files to be copyright by U-Mich and subject to the license which U-Mich provided in the U-Mich LDAP distribution. A copy of that license remains in the COPYRIGHT file now distributed with OpenLDAP Software. And, as stated in the OpenLDAP COPYRIGHT file, some files may be subject to additional restrictions. The OpenLDAP Foundation makes no assertion of compatibility or incompatibility between terms placed upon OpenLDAP Software by its copyright holders and terms placed upon other works by their copyright holders which OpenLDAP Software may be combined with. The OpenLDAP Foundation suggests that anyone redistributing software consult with legal counsel before doing so. Nothing in this message should be construed as legal advice. -- Kurt Zeilenga, Executive Director, The OpenLDAP Foundation.
