Re: Berkeley DB 6.0 license change to AGPLv3
On Fri, Jul 19, 2013 at 04:29:21PM +0200, Ondřej Surý wrote: Hi, would FOSS Exception similar to http://www.mysql.com/about/legal/licensing/foss-exception/ fix the relicensing problem? If so, I will propose Oracle developers to add the FOSS Exception to Berkeley DB licensing. The MySQL FOSS Exception doesn't include 4-clause BSD, so it still might bar some software to create derivative works with Berkeley DB, but the list would be considerably shorter. Or they will need to add the 4-clause BSD license to the exception list. Notably, it's also missing the GPL version 2. This isn't a problem for MySQL, since it's already GPLv2, but there's probably quite a bit of software that is GPLv2 that uses Berkeley DB. Also, there is a wide variety of BSD licenses that are incompatible, as you've pointed out. Personally, I think the easiest and best solution is simply to stick with Berkeley DB 5.3. It avoids all the pain of relicensing and the inevitable licensing bugs that *will* show up. Not to mention that some upstreams will be unamused at Oracle's shenanigans and won't want to support BDB 6. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Bug#531040: ITP: xvidcore -- High quality ISO MPEG4 ASP codec library
[ -legal CC'd; M-F-T set to -legal only; in no case should you CC me]
On Fri, May 29, 2009 at 02:18:00PM +0200, Loïc Martin wrote:
License is GPL2+, except for 2 files (src/dct/{fdct.c,idct.c} ) which are
GPL2+, but with the additionnal note:
Permission is hereby granted to use, copy, modify, and distribute this
software (or portions thereof) for any purpose, without fee, subject to
these
conditions:
(1) If any part of the source code for this software is distributed, then
this
README file must be included, with this copyright and no-warranty notice
unaltered; and any additions, deletions, or changes to the original files
must be clearly indicated in accompanying documentation.
I don't know if this is compatible with the GPLv2. The requirement to
include the README file may be considered an additional restriction.
(2) If only executable code is distributed, then the accompanying
documentation must state that this software is based in part on the work
of
the Independent JPEG Group.
This is not compatible with the GPLv2. It is an additional restriction.
I don't believe this is a problem with the GPLv3, but if you use it
under the GPLv3 then you cannot link it with GPLv2 applications.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
signature.asc
Description: Digital signature
Re: tg3 firmware - was (Fw: [CASE#221365]: Closed - need firmware files)
[CC'd -legal as well; you probably want to follow up there.] On Thu, Apr 09, 2009 at 05:46:58PM +0200, Daniel Knabl wrote: Seems to me that Broadcom Inc. does really allow Debian to re-distribute the included firmware explicitly. The GPLv2 requires that distributors provide source code in certain circumstances. Source code is defined in the GPLv2 as the preferred form for modification. Unless Broadcom uses a hex editor to modify the firmware, Debian does not have the source code (the preferred form for modification) and therefore cannot provide it upon request. Since Debian cannot comply with the license, it is not permitted to distribute it at all. Doing so would be copyright infringement. If Broadcom were to license the firmware under a revised BSD license or another license that does not require providing source code, then Debian would be permitted to distribute it in non-free. This issue is completely separate from whether the firmware has source code according to the DFSG. As a practical matter, only certain very old revisions of the hardware actually need the firmware at all for basic functionality. Most hardware using the tg3 driver (like my laptop) are completely functional without any firmware at all. Certain extra features, like TCP Segment Offloading (TSO), are enabled by the firmware, but these features are not required for basic functionality. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: tg3 firmware - was (Fw: [CASE#221365]: Closed - need firmware files)
On Thu, Apr 09, 2009 at 10:06:55PM +0100, Neil Williams wrote: On Thu, 9 Apr 2009 20:41:12 + brian m. carlson sand...@crustytoothpaste.ath.cx wrote: [CC'd -legal as well; you probably want to follow up there.] I don't need to be CC'd, thanks. M-F-T set accordingly. On Thu, Apr 09, 2009 at 05:46:58PM +0200, Daniel Knabl wrote: Seems to me that Broadcom Inc. does really allow Debian to re-distribute the included firmware explicitly. The GPLv2 requires that distributors provide source code in certain circumstances. Source code is defined in the GPLv2 as the preferred form for modification. Unless Broadcom uses a hex editor to modify the firmware, Debian does not have the source code (the preferred form for modification) and therefore cannot provide it upon request. Since Debian cannot comply with the license, it is not permitted to distribute it at all. Doing so would be copyright infringement. That wasn't the result of the GR: Option 5 Assume blobs comply with GPL unless proven otherwise I'm going to ignore for the moment the fact that this title has a negligible relation to the proposal's content and that the actual proposal supports my point. There are two issues here: * Broadcom says that the entire driver (presumably including firmware) is GPLv2. Because we know that it is not shipped with source code (see below), we know that this is insufficient to make the firmware legally distributable. * The firmware actually has a separate license that reads as follows: * Firmware is: *Derived from proprietary unpublished source code, *Copyright (C) 2000-2003 Broadcom Corporation. * *Permission is hereby granted for the distribution of this firmware *data in hexadecimal or equivalent format, provided this copyright *notice is accompanying it. This license does not allow for modification. Therefore, Debian can legally distribute the firmware, but only in non-free. I have no objection to Debian distributing this firmware in non-free; nevertheless, as I stated in my original post, whether Debian distributes this firmware is mostly irrelevant with regard to having a functioning tg3 driver. Do we know if there is source code for this firmware. There is no proof that the firmware does not comply with the GPLv2 AFAICT, therefore the GR requires that we assume that the firmware does comply, whatever that means with regard to the preferred form for modification. Why assume that using a hex editor is impossible? I'm not saying that using a hex editor is impossible. I'm saying that there's source code: * Firmware is: *Derived from proprietary unpublished source code, *Copyright (C) 2000-2003 Broadcom Corporation. I don't know about you, but I'd much prefer to modify any sort of program, firmware or not, using C or assembly rather than editing the binary directly. I suspect that this is the case for any reasonable programmer. Thus, we do not have the preferred form for modification, and thus, we cannot distribute it under the GPLv2. This issue is completely separate from whether the firmware has source code according to the DFSG. How can it be separate? The assertion from your reply was that there was source code behind the hex. Is there *evidence* and *proof* that this is the case? Yes. Why would Broadcom lie about there being source code? -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Bug#508249: ITP: libio-pager-perl -- pipe output to a pager if destination is a TTY
On Tue, Dec 09, 2008 at 11:19:42AM +0200, Damyan Ivanov wrote: * Package name: libio-pager-perl Version : 0.05 Upstream Author : Jerrad Pierce [EMAIL PROTECTED] * URL : http://search.cpan.org/dist/IO-Pager/ * License : other - Thou shalt not claim ownership of unmodified materials. - Thou shalt not claim whole ownership of modified materials. - Thou shalt grant the indemnity of the provider of materials. This may be a problem. I know in the past, clauses requiring indemnification were not allowed. CCing debian-legal for discussion. Please follow up there. - Thou shalt use and dispense freely without other restrictions. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Copyright question
[Please follow up to -legal only. Full quote for the benefit of -legal.] On Wed, Feb 06, 2008 at 04:30:01PM +0100, Jean Parpaillon wrote: Hi, I intend to package HPL benchmarks. Copyright file contains the following statements: -- 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed at the University of Tennessee, Knoxville, Innovative Computing Laboratories. 4. The name of the University, the name of the Laboratory, or the names of its contributors may not be used to endorse or promote products derived from this software without specific written permission. I've read DFSG and I'm not sure if items 3 and 4 are problematic. Can someone help me ? If it's not ok, may it be in contrib ? This is a standard BSD-with-advertising-clause, so yes, this is DFSG-free. Only DFSG-free material may go in main or contrib; material that does not meet the DFSG must go in non-free. Also note that due to the advertising clause (clause 3), this license is not compatible with the GPL. In future, please post questions about copyright and licenses to -legal, where the regulars are well versed. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Sun Java available from non-free
[For -legal people, the license is attached.] On Wed, 2006-05-17 at 11:01 +0200, Michael Meskes wrote: On Wed, May 17, 2006 at 08:20:14AM +0200, Jeroen van Wolffelaar wrote: Official packages of Sun Java are now available from the non-free section of Debian unstable, thanks to Sun releasing[11 Java under a new license: the Operating System Distributor License for Java (DLJ)[2][3]. This license, while still non-free, allows the Sun Java Runtime Environment (JRE) or Java Development Kit (JDK) to be distributed by Debian, with our own packaging. Could someone please explain to me why paragraph 2(f) does not pose a problem? I couldn't find ANY discussion about the license on Debian legal which surprises me a little bit, but then maybe I just missed the relevant parts of the license. Anyway, as a non-lawyer I'm surprised that we seem to accept that we have to defend and indemnify Sun. Also, section 4 poses a major issue. If, for any reason, the Linux kernel doesn't do something that Java requires, then we are obligated to either fix it or inform everyone who has acquired Java from us. Section 10 is not possible with our infrastructure. The ftp-master scripts merely remove the package from the tag database, not the archive (at least until there are no dependencies), and not from all of our mirrors. Section 2(b) prohibits allowing people to develop software with Java that is to be run on another system. Section 2(c) prohibits us from using the software in conjunction with C, C++, Perl, Python, or *any reasonable Turing-complete programming language*. Section 12 requires that this software be in non-US/non-free. It is not, which is not only a violation of the license, but a violation of United States law. This conflicts with other project policies and exposes Debian/SPI to major legal liabilities. I think that this should be removed from the archive as soon as possible, preferably before the next mirror pulse. Operating System Distributor License for Java version 1.1 SUN MICROSYSTEMS, INC. (SUN) IS WILLING TO LICENSE THE JAVA PLATFORM STANDARD EDITION DEVELOPER KIT (JDK - THE SOFTWARE) TO YOU ONLY UPON THE CONDITION THAT YOU ACCEPT ALL OF THE TERMS CONTAINED IN THIS LICENSE AGREEMENT (THE AGREEMENT).� PLEASE READ THE AGREEMENT CAREFULLY.� BY INSTALLING, USING, OR DISTRIBUTING THIS SOFTWARE, YOU ACCEPT ALL OF THE TERMS OF THE AGREEMENT. 1. DEFINITIONS. Software means the code identified above in binary form, any other machine readable materials including, but not limited to, libraries, source files, header files, and data files), any updates or error corrections provided by Sun, and any user manuals, programming guides and other documentation provided to you by Sun under this Agreement, and any subsequent versions that Sun makes available to you hereunder. Operating System means any version of the Linux or OpenSolaris operating systems that manages the hardware resources of a general purpose desktop or server computer and shares these resources with various software programs that run on top of it. Programs means Java technology applets and applications intended to run on the Java Platform Standard Edition (Java SE platform) platform on Java-enabled general purpose desktop computers and servers. 2. License Grant. Subject to the terms and conditions of this Agreement, as well as the restrictions and exceptions set forth in the Software README file, Sun grants you a non-exclusive, non-transferable, royalty-free limited license to reproduce and use the Software internally, complete and unmodified, for the sole purposes of running Programs and designing, developing and testing Programs. Sun also grants you a non-exclusive, non-transferable, royalty-free limited license to reproduce and distribute the Software, directly or indirectly through your licensees, distributors, resellers, or OEMs, electronically or in physical form or pre-installed with your Operating System on a general purpose desktop computer or server, provided that: (a) the Software and any proprietary legends or notices are complete and unmodified; (b) the Software is distributed with your Operating System, and such distribution is solely for the purposes of running Programs under the control of your Operating System and designing, developing and testing Programs to be run under the control of your Operating System; (c) you do not combine, configure or distribute the Software to run in conjunction with any additional software that implements the same or similar functionality or APIs as the Software; (d) you do not remove or modify any included license agreement or impede or prevent it from displaying and requiring acceptance; (e) you only distribute the Software subject to this license agreement; and (f) you agree to defend and indemnify Sun and its licensors from
Re: Missing documentation for autoconf
On Tue, 2006-02-21 at 14:02 +0400, olive wrote: Brian M. Carlson wrote: Everything is always possible. Even understanding how a program works without source by disassembling it. If a free program depends on an non-free library you can reimplement the free library. ITYM the non-free library. Your first sentence is not true. Assuming the consensus reality, I cannot teleport from one place to another. Your arguments are unpersuasive, because the DFSG requires source. Also, if a program requires the use of a Windows system library, it is most likely not possible to completely reimplement the non-free library. Even wine has not successfully done this. But I think that for certain software; not having the documentation is a major inconvenience not a minor one. What about not being able to modify or even *remove* sections of the document that are useless, inaccurate, incomplete, inappropriate, wrong, or otherwise unsuitable for a modified document? I call that a major inconvenience, as well as a freedom issue. I also do not believe you because if autoconf-doc were required for using autoconf, then autoconf should have a Depends: (or at least, a Recommends:) on it. This is not the case. It's depend what you want to do with it. If you just want to make the configure from an existing configure.ac then the doc is not necessary. If you want to implement an autoconf script by yourself; then I think the doc is necessary. As for other softwares too. I thought Debian was sufficiently comprehensive to be able to develop on it the software that are part of it and with the missing doc; this is not the case anymore. You snipped an important part of my text: Another difference is that there are many different free examples of input for autoconf, and no free examples of the non-free library. IOW, people could look at other autoconf scripts and determine what is necessary. I'm sure GNU hello (package hello) includes some great examples. By your own admission, if all you want to do with it is generate configure, you don't need the documentation. That's what the vast majority of people want to do with it. We do not, AFAIK, provide shell script tutorials for posh for people who want to program POSIX shells, but the vast majority of shell users probably to either simply use the shell, or already know how to program it. If the consensus is that documentation is required for use (I do not agree at all), then that would be cause for removing autoconf from main, not including autoconf-doc. Every software depend (indirectly) on autoconf (you need it to generate the configure script from the configure.ac; which is the real source. By convenience an already made configure script is already present in the source code of most packages in order that the package can be built without autoconf; but if you want to modify this script the real source is the configure.ac). autoconf is needed to build essential software such as gcc and the basic gnu utilities from which every other software depend. You missed my point. My point is that given: Package X is non-free. Package Y is free. Package Y depends on package X. then: Package X is still non-free. IOW, package X does not become free just because package Y depends on it, and further package Y must go in contrib while it still depends on package X. But here, we don't have that problem, because autoconf in no way depends on autoconf-doc. The docs are not necessary for usage of autoconf. signature.asc Description: This is a digitally signed message part
Re: Missing documentation for autoconf
Please only quote those portions of the text to which you are replying. I have removed the text that you quoted. On Tue, 2006-02-21 at 09:46 +0400, olive wrote: The social contract say also We will never make the system require the use of a non-free component. It is reasonable to think that the use of Debian requires the GFDL documentation. If Debian think there are non-free they are breaking the social contract; could someone explain me how this is not a break of the social contract. How is this required? Several programs in Debian have little or no documentation. Because people have the source, they can discover how those programs work. Contrast this with a free program depending on a non-free library, where people cannot use the free program without using (or reimplementing) the non-free library. Another difference is that there are many different free examples of input for autoconf, and no free examples of the non-free library. IOW, it may be inconvenient to use the code in question, but it is possible. Documentation is not required to use code which has source. You may have heard the phrase, Use the source, Luke. I also do not believe you because if autoconf-doc were required for using autoconf, then autoconf should have a Depends: (or at least, a Recommends:) on it. This is not the case. If the consensus is that documentation is required for use (I do not agree at all), then that would be cause for removing autoconf from main, not including autoconf-doc. signature.asc Description: This is a digitally signed message part
Re: GR proposal: GFDL with no Invariant Sections is free
On Sat, 2006-02-04 at 11:35 +0400, olive wrote: Once again if a license clearly fail the DFSG I will never advocate to include it. But there are a lot of case where this is not the case and I think people claim that the license violates the DFSG just because they do no like it. There is no rule which say that every bits of a file can be modified; but there are law which says that you must be able to use your freedom. Debian has already accepted resctriction similar to the GFDL (acknoledgement of the BSD license etc,...); the invariant sections are in nature not more (these are acknoledgement for the GNU project; and yes it a bit longer). In the sense of the Free Software movement, the word free is an absolute, much like pregnant or dead. In English, one is either pregnant or not: one cannot be more or less pregnant[0]. Similarly, one is either dead or not dead. One cannot be half-dead[1]. Different jurisdictions might legitimately disagree on how to define whether someone is dead: is it brain function, heart beat, or breath? Likewise, people might legitimately disagree on what Free Software is. In Debian, we use the DFSG as our guidelines, but ultimately the opinion that is applied is that of the ftpmaster in question. Also, I think that Exhibit A licenses[2] are stupid, I don't like them, and I would not license my work under them. However, they are not necessarily non-free just because I don't like them. By the way, there are licenses which in my opinion more clearly violates the DFSGL and are nevertheless accepted. I think of a license of a file in x.org which prohibit to export it to Cuba. This seems clearly be a discrimination and moreover it fails the dissident test (even if in this case the dissidant might be a U.S citizen; not a chinese one). For someone (like me) living outside the U.S. this is even more flagrant because to export goods to Cuba is perfectly legal from my country. If it actually says that (and not merely reminds people that violating their local laws may land them in prison), then please do file a serious bug on that package. Actually, don't bother, because I think it's a little thing that shouldn't matter so much, and although I'm not a DD, my opinion should be forced on the whole of Debian. Anyway, most everyone here in the US agrees with me, so I'm obviously right[3]. [0] This should not be confused with the forms more *nearly* pregnant or less *nearly* pregnant. [1] Unfortunately, this gross grammatical error is all too common in both the vernacular and among well-known authors who should know better. [2] Exhibit A licenses are those that have traditionally had a section called Exhibit A; they redefine everything under the sun. [3] This paragraph is meant to be illustrative and should not be taken as my real views on anything. signature.asc Description: This is a digitally signed message part
Re: Linking clause deleted from GNAT GPL
On Thursday 24 November 2005 20:42, Andrew Donnellan wrote: On 11/24/05, Henning Makholm [EMAIL PROTECTED] wrote: Here's an example: This program is licensed under the GPL...etcetc.. If your name is Jim then sections 3a and 3b do not apply. is LESS restrictive than just the GPL. And it is still fully GPL-compatible. I don't think you understand. The restriction is on the removal of the additional permissions. In your example, the restriction is that if I do not wish to grant those additional permissions to Jim *, then I am still forced to do so. To quote the GPL (from memory), You may not impose any further restrictions on the recipients' exercise of the rights granted herein. A license that is less restrictive for some people downstream (who might want to use the code in non-free programs) will be more restrictive for other people downstream (who might want to produce derived works and not see them used in non-free programs). No, it will just force some other people to release under a less restrictive license. Exactly! But what if I don't want to do that? The restriction is forcing others to use license terms that are not in the GNU General Public License. The problem is not even the GCC code (though that is a problem too), but the fact that some of the Ada source in Gnat is licensed as GPL _without_ the exception. Because GPL and GPL+exception are incompatible licenses, an executable containing both kinds of code cannot legally be distributed. 1. I don't think they are incompatible. Section 2 sayeth: b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. If you cannot license them under the same terms for any reason, whatever it might be, then sections 4, 5, 6, and 7 apply. If that reason is because there is an exception that cannot be removed, then it would still apply. The reason that many exceptions (including the one recommended by the FSF) allow removal of the exception, is so that they are under the same license. 2. The exception is only needed when the Ada source has generics that can be instantiated. I have no idea about Ada, so I cannot comment on this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Licenses for DebConf6 [was: Re: DebConf6: Call For Papers]
On Monday 07 November 2005 11:28 pm, Francesco Poli wrote: [Added Cc: debian-legal, because the topic may be of interest there, I would say.] [No need to Cc: me, as long as you keep Cc:ing debian-legal (just to make things clear: I am subscribed to debian-legal, but not to debian-devel)] used in conjunction with the presentation. The authors have the freedom to pick a DFSG-free license for the papers themselves and retain all copyrights. The authors have the freedom to pick a DFSG-free license means that they *may* do so, but are not required to. Am I correct? The way I read it was that the authors may pick any license, so long as it's DFSG-free. Do you see how it could be read that way? Now, because they are the copyright holders, they could additionally license it in some other way, too. But they must at least offer a DFSG-free license. -- Brian M. Carlson [EMAIL PROTECTED] Running on GNU/kFreeBSD; i686-pc-kfreebsd-gnu Support alternative kernels in Debian! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RIPEMD crytographic hash function
On Sunday 23 October 2005 08:38, Nathanael Nerode wrote:
Andreas Rottmann wrote:
[CC'ed debian-legal, they can probably give a more detailed and
informed analysis of the proposed license]
Done, please forware appropriate information as needed.
[snip license analysis]
RIPEMD-160 is available in many different implementations, and knowing a
thing or two about cryptography, I can probably point you to several
implementations, depending on the license you want to use.
Since it is an algorithm with a publicly available reference, it is possible
to simply reimplement it from scratch, which I am willing to do; see below.
It is included in:
* GnuPG (GPL)
* libtomcrypt (PD[0])
* libcrypto++5.1 (PD)
* libcrypto++5.2c2 (PD)
* libgcrypt (LGPL)
* libcrypto (OpenSSL license)
* libmcrypt (GPL?)
* and many more...
I am even willing to modify the chosen implementation to make it interface
compatible with the one in question, or to write one myself under the MIT
License, with a regression suite, since I should probably do that anyway.
What interface, language, and ABI did you want to use, and can I have some
semblance of the program for which I am doing this? As for languages, I
can do C, C++, Perl, Python, C# for Mono, and a few others I can't think of
right now.
[0] Do not even *think* about getting into the Can software be placed in
the public domain? argument yet again.
--
($_,$a)=split/\t/,join'',map{unpack'u',$_}DATA;eval$a;print;__DATA__
M961H[EMAIL PROTECTED];!UF%OG-U(#QUF%OG-U0=D:75MUC8VUL=G)U;6LN
MFUL+F=Y/@H)2QA8F-D969G:EJ:VQM;F]P7)S='5V=WAYBQN=V]R8FMC
5:75Q96AT9V1YF%L=G-P;6IX9BP)
pgpGQ0OD8dTpw.pgp
Description: PGP signature
Re: generated source files, GPL and DFSG
On Thu, 2005-07-28 at 15:15 +0100, Steve McIntyre wrote:
I'm arguing with your interpretation of program to mean anything you
want - in this case potentially any random string of bytes. That most
certainly _is_ new, and is completely bogus. As I said, propose a GR
to change the wording s/program/software/ of DFSG#2 if you want that
meaning. Redefining/reinterpreting commonly-used words is a very good
way to alienate people...
If you are only looking at the DFSG, you are missing the point. The
point is that the Social Contract requires that all software in Debian
(that is, main) must comply with the Debian Free Software Guidelines.
That was the interpretation debian-legal used before last year's GR, and
the GR, while editorial, simply made that clearer.
Therefore, if the DFSG said that All ham sandwiches must include source
code..., then the Social Contract would still require that all
provisions of the DFSG apply to all of main.
In addition, DFSG 6 and several other DFSG sections apply to programs.
If you are claiming that suddenly non-program software does not have to
comply with DFSG 6, then we have a problem.
Also, from policy 2.2.1:
Every package in _main_ and _non-US/main_ must comply with the DFSG
(Debian Free Software Guidelines).
Note that it does not say: Only programs in _main_... or Every
program in _main_ Therefore, it is still a serious bug.
In addition, the etch RC policy requires that:
All content in main and contrib must meet the DFSG, both in .debs and
in the source (including the .orig.tar.gz)
I see no support for your opinion in actual, codified Debian policy[0].
[0] By policy, I don't mean just policy.txt.gz; I mean all technical and
non-technical policy documents.
--
($_,$a)=split/\t/,join'',map{unpack'u',$_}DATA;eval$a;print;__DATA__
M961H[EMAIL PROTECTED];!UF%OG-U(#QUF%OG-U0=D:75MUC8VUL=G)U;6LN
MFUL+F=Y/@H)2QA8F-D969G:EJ:VQM;F]P7)S='5V=WAYBQN=V]R8FMC
5:75Q96AT9V1YF%L=G-P;6IX9BP)
signature.asc
Description: This is a digitally signed message part
Re: generated source files, GPL and DFSG
On Thu, 2005-07-28 at 20:08 -0700, Steve Langasek wrote:
On Fri, Jul 29, 2005 at 12:44:26AM +, Brian M. Carlson wrote:
On Thu, 2005-07-28 at 15:15 +0100, Steve McIntyre wrote:
[argument of program vs. software]
If you are only looking at the DFSG, you are missing the point. The
point is that the Social Contract requires that all software in Debian
(that is, main) must comply with the Debian Free Software Guidelines.
That was the interpretation debian-legal used before last year's GR, and
the GR, while editorial, simply made that clearer.
Therefore, if the DFSG said that All ham sandwiches must include source
code..., then the Social Contract would still require that all
provisions of the DFSG apply to all of main.
Yes, the DFSG must be applied to everything in main.
So then it must be applied to non-programs as well.
How do you get from there to the words 'ham sandwich' must be read as
'software', exactly?
My point was that regardless of the words to be used to describe the
material that the DFSG talks about (in my example, ham sandwich), the
Social Contract explicitly applies the DFSG to all works in main (the SC
explicitly uses the word work). Because of this, it would be silly to
say that some works require more freedoms than others.
I would say that DFSG 2 should apply to at least documentation, as well
as programs. My argument goes as follows: if I write a groff document,
and convert it into HTML with the groff in Debian, it will be
non-standards conformant HTML and pretty crappy HTML in general. Newer
versions of groff at least fix some of the problems, so it is
conceivable that you might want to reprocess it with groff CVS. You'd
need the source to do that. If DFSG 2 should apply to documentation as
well as programs, then why shouldn't it apply to all software?
I might be more persuaded that your interpretation were the case, even
with the Social Contract as it is now, if the text of DFSG 2 were The
program must include source code... . This section does not apply to
non-programs. Of course, then we have the definition of program about
which to worry.
Also, nobody has proposed a definition of program that is not the same
as software, in regards to the DFSG. If you can find one that is
acceptable to at least the ftpmasters (and hopefully debian-legal), then
please state it.
Most likely, someone made an error of precision when writing the DFSG,
as it is common in English to use varying terms to refer to the same
thing and not to repeat words unnecessarily. Although in this case, as
I said, the authors of the DFSG were imprecise. They aren't dead, so it
is still possible to ask them what they meant (and I believe this has
already been done).
You also snipped my text about DFSG 6, so I have a question. Do you
think that DFSG 6 should not apply to all works in main? Or DFSG 7, 8,
or 9? If not, why exempt DFSG 2, when there clearly is a definition of
source that can define what the source is for every piece of software?
--
($_,$a)=split/\t/,join'',map{unpack'u',$_}DATA;eval$a;print;__DATA__
M961H[EMAIL PROTECTED];!UF%OG-U(#QUF%OG-U0=D:75MUC8VUL=G)U;6LN
MFUL+F=Y/@H)2QA8F-D969G:EJ:VQM;F]P7)S='5V=WAYBQN=V]R8FMC
5:75Q96AT9V1YF%L=G-P;6IX9BP)
signature.asc
Description: This is a digitally signed message part
Re: OpenSolaris license
On Thu, 2005-07-21 at 19:23 +0100, Alvaro Lopez Ortega wrote:
Hi all,
I would like to know what do you guys think about the CDDL license
[1]. Does it meet with the Debian Free Software Guidelines?
First of all, please paste the entire license in the mail, so that if
people use things like offline IMAP or POP3, they can read the mail even
if they're not online. It also takes a lot less bandwidth for dialup
users to read a mail than to read a web page.
Second of all, I'd like to point out that we have archives of our
mailing lists, and even if you couldn't find those, we have *Google*.
Try searching for OpenSolaris debian-legal . This will point you to the
most relevant articles.
I believe the conclusion[0] (stated by the illustrious Mr. Suffield) was
that it is a lawyerbomb.
It is my opinion that Exhibit A-style licenses suck, hard. They are
confusing and attempt to define everything under the sun (no pun
intended).
My analysis of it follows:
0. Offering a warranty is not allowed, because it requires that one
indemnify others, which is obviously not free.
1. Section 6.1 is unacceptable for Debian, which does not have an army
of lawyers looking for people to sue. Debian's patent policy is that we
ignore patents which are not actively enforced and do not seek out
knowledge about the existence or validity of patents. Therefore,
anything which conflicts with that policy would be undistributable by
Debian.
2. Section 8 is redundant and superfluous.
3. Section 9 should not allow usage of jurisdictional specification, as
if a jurisdiction is specified, that would be non-free because of
choice-of-venue. For example, the notice on [1] is unacceptable.
4. I don't like the wording of Section 3.2. Contrast this:
The Modifications that You create or to which You contribute are
governed by the terms of this License. You represent that You believe
Your Modifications are Your original creation(s) and/or You have
sufficient rights to grant the rights conveyed by this License.
with this:
You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License. ... These requirements apply
to the modified work as a whole. If identifiable sections of that
work are not derived from the Program, and can be reasonably
considered independent and separate works in themselves, then this
License, and its terms, do not apply to those sections when you
distribute them as separate works. But when you distribute the same
sections as part of a whole which is a work based on the Program, the
distribution of the whole must be on the terms of this License, whose
permissions for other licensees extend to the entire whole, and thus
to each and every part regardless of who wrote it.
Basically, it's trying to borg code that isn't even related (and
licensed, say, under the MIT License) if that code is incorporated into
OpenSolaris. I would be more comfortable if it didn't try to relicense
my code without my permission (and yes, I know that with the MIT License
sublicensing is allowed, but it's not the same as being governed by the
terms of this License). I'm picking a nit here.
I'm not sure if this license is free or not, but I sure wouldn't want my
code to be licensed under it. I definitely agree it's a lawyerbomb.
And OpenSolaris, as packaged, is non-free, because of the
choice-of-venue.
The first thing I want to do is to be ensure everything is ok with
the license. After that, we can start discussing all the rest of
the issues.
I think the closest to Debian you're currently going to get is non-free,
and that's if it's distributable.
If you can get Sun to dual-license under the GNU General Public License,
that would help, because then we could use it under those terms, which
are certainly free. After all, the stated reasons not to use the GNU
General Public License that I have read are based on the fact that Sun
wants to use proprietary software with the system, which is fine, but
Debian cannot do that, since Debian would have to extirpate any code
that was proprietary anyway.
I would love to use some code from OpenSolaris, if it were
dual-licensed.
HTH.
[0] http://lists.debian.org/debian-legal/2004/12/msg7.html
[1] http://www.opensolaris.org/os/downloads/
--
($_,$a)=split/\t/,join'',map{unpack'u',$_}DATA;eval$a;print;__DATA__
M961H[EMAIL PROTECTED];!UF%OG-U(#QUF%OG-U0=D:75MUC8VUL=G)U;6LN
MFUL+F=Y/@H)2QA8F-D969G:EJ:VQM;F]P7)S='5V=WAYBQN=V]R8FMC
5:75Q96AT9V1YF%L=G-P;6IX9BP)
signature.asc
Description: This is a digitally signed message part
Re: Public Domain and Packaging
On Mon, 2005-07-18 at 11:45 -0700, Sean Kellogg wrote:
On Monday 18 July 2005 11:07 am, Brian M. Carlson wrote:
What we *don't* want, is software that is copyrighted (which PD software
isn't) and then without a license, because that gives us almost no
rights whatsoever.
There is no such thing as software that isn't copyrighted. All original
expression that is fixed in a tangible form is immediately copyrighted (at
least, that's the U.S. rule). There is still lots of debate as to whether it
is possible to disclaim that copyright... but there is no question that it
is, at the moment of creation, copyrighted.
False. You, as a lawyer-to-be, should know better than to be imprecise.
U.S. Government software is not copyrighted, and cannot be so,
excepting, of course, the United States Postal Service, which is granted
an exception under 19 U.S.C.
Mr. Crowther is better off accepting he has a copyright and simply attaching
a
COPYING file that says I grant anyone and everyone an irrevocable license to
copy, modify, distribute, perform, display, or engage in anyother act
requiring my permission with this software. Yes, there are a host of legal
questions with that as well, but it gets us way closer to the pale than
attempts to disclaim the copyright.
As for non-government software, no one can force a monopoly upon another
person if that person does not want it. What Mr. Crowther can do is
simply disclaim the copyright and never enforce it, even if he does have
it under some theory of law. If his heirs attempt to enforce it, they
will be dilatory under the doctrine of laches.
--
($_,$a)=split/\t/,join'',map{unpack'u',$_}DATA;eval$a;print;__DATA__
M961H[EMAIL PROTECTED];!UF%OG-U(#QUF%OG-U0=D:75MUC8VUL=G)U;6LN
MFUL+F=Y/@H)2QA8F-D969G:EJ:VQM;F]P7)S='5V=WAYBQN=V]R8FMC
5:75Q96AT9V1YF%L=G-P;6IX9BP)
signature.asc
Description: This is a digitally signed message part
Re: Alternatives to the Affero General Public License
On Tue, 2005-06-21 at 19:05 -0700, Gregor Richards wrote:
Because the AGPL has some implementation issues that make it possibly
incompatible with the DFSG, I've been trying to find an alternative that
would still protect source-code redistribution on line. Basically, I'm
trying to write a special exception to the GNU GPL that would add this
without some of the practical problems, and possibly with DFSG and OSI
compliance. I'm not entirely clear on to what extent point 4 (Integrity
of The Author's Source Code) applies. Clearly, the AGPL creates an
invariant section like the GFDL, which doesn't work. My proposed
change works more like clause 2(c) of the GNU GPL. There's no exact
code that needs to be kept, but a certain functionality does. I don't
think this contradicts anything in the DFSG, but I'm no expert, and
would like your opinions.
Here's my proposition so far:
As an exception to the GNU General Public License, any user who wishes
to distribute modified copies of program (the Program) is also
required to abide by this additional rule:
This is an additional restriction, forbidden by section 6. Section 6
states, in part:
You may not impose any further restrictions on the recipients'
exercise of the rights granted herein.
This results in having an inconsistent license, and is consequently not
distributable at all, except by the copyright holder.
Also, the word insure should be ensure, on the fourth line of the
first starred item. The word insure means to secure against loss.
The word ensure means to make sure or to be certain.
As a side note, what you are trying to do is not compliant with the
DFSG. We have rejected software that requires that people send copies
or otherwise make copies available[0] as compatible with the DFSG.
Whether it is compliant with the OSI is not a discussion for this list.
[0] See http://wiki.debian.net/?DissidentTest
--
($_,$a)=split/\t/,join'',map{unpack'u',$_}DATA;eval$a;print;__DATA__
M961H[EMAIL PROTECTED];!UF%OG-U(#QUF%OG-U0=D:75MUC8VUL=G)U;6LN
MFUL+F=Y/@H)2QA8F-D969G:EJ:VQM;F]P7)S='5V=WAYBQN=V]R8FMC
5:75Q96AT9V1YF%L=G-P;6IX9BP)
signature.asc
Description: This is a digitally signed message part
Re: cl-typesetting license
On Sat, 2005-04-16 at 16:32 +0200, Jakob Bohm wrote:
On Mon, Apr 11, 2005 at 07:50:36AM -0400, Anthony DeRobertis wrote:
Ingo Ruhnke wrote:
Sound free to me, since not the output of the library is required to
confirm to it, but the interface which generates the input for the
library. So to me it looks basically just like something like GPLs 2c
section applied to the web.
Not really. GPL 2(c) tells me what changes I may make to the software in
question. This tells me what changes I may/must make to other software.
GPL 2(c) is the obnoxious banner clause that says that if you
take a random piece of non-interactive GPL code and incorporate
it in an interactive program, then that program must include a
startup banner telling the users that this is Free Software
under the GPL.
Right, and this is relevant if and only if:
1) the original GPL work printed such an announcement; and
2) the relevant work is a derivative work of both GPL'd code and code
that prints such a notice.
Similarly, cl-typesetting #5, says that if you incorporate
cl-typesetting in a larger program then that program (not its
output) must display a cl-typesetting banner in its primary
startup screen.
Ah, but this is not a derivative work of cl-typesetting. cl-typesetting
(I am assuming) merely processes some marked-up data.
GPL 2(c) presumes a command-like program similar to
gdb/bash/emacs in its example text, cl-typesetting#5 presumes a
HTML-based user interface such as a cgi/php/jsp frontend.
Yes, but the HTML-based interface is a derivative work not of
cl-typesetting, but of the input. The GPL'd program we are discussing is
a derivative work of only the works which make up the executable. cl-t
#5 would contaminate other software, specifically the input to the
typesetter.
So one must look very carefully to determine what places GPL
2(c) just within the DFSG (other than DFSG#10), and what causes
cl-typesetting #5 to be within or outside the DFSG.
You are comparing apples to oranges. The GPL'd program is a derivative
work under the GPL; the postprocessed text is not a derivative work of
cl-typesetting, unless cl-typesetting copies significant portions of its
own code into the output, like bison does[0].
As an analogy, I would like to point out that I am writing free
documentation (how it is licensed is not really relevant) with troff
markup. Does my documentation then become a derivative work of groff?
I hope not. Otherwise, once sarge releases, all the BSD manpages with
advertising clauses would become undistributable.
That said, I would like to point out that GPL 2(c) is not a favorite of
many people on this list. It is my belief, however, that any
interpretation of the DFSG (ignoring section 10) which would make the
licenses in DFSG 10 non-free is an incorrect one.
[0] Bison now has an exception for the output.
--
($_,$a)=split/\t/,join'',map{unpack'u',$_}DATA;eval$a;print;__DATA__
M961H[EMAIL PROTECTED];!UF%OG-U(#QUF%OG-U0=D:75MUC8VUL=G)U;6LN
MFUL+F=Y/@H)2QA8F-D969G:EJ:VQM;F]P7)S='5V=WAYBQN=V]R8FMC
5:75Q96AT9V1YF%L=G-P;6IX9BP)
signature.asc
Description: This is a digitally signed message part
Re: Is Open Publication License v1.0 compatible?
On Fri, Feb 27, 2004 at 03:09:15PM -0500, Oleksandr Moskalenko wrote: I'd like to package an html manual for the package I'm preparing. However, it's covered by the Open Publication License v 1.0. http://opencontent.org/openpub/ Is it DFSG-free? I checked the http://www.gnu.org/philosophy/license-list.html#DocumentationLicenses and they consider it free if none of the part VI optional clauses are excercised. It is free under the same conditions (no optional clauses). -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 signature.asc Description: Digital signature
Re: license for Federal Information Processing Standards
On Tue, Feb 24, 2004 at 04:12:28PM -0500, Hubert Chan wrote: As mentioned in my previous mail, I am creating a package for hashcash. The source for the package includes a document, fip180-1.txt, which is a copy of the Federal Information Processing Standards Publication 180-1 (the definition for SHA-1). I am unable to determine whether or not FIPS documents are free, and was wondering if anyone had any experience with that. The FIPS home page is: http://www.itl.nist.gov/fipspubs/ Again, please cc me as I am not subscribed. All works of the United States Government (of which FIPS 180-1 is one) are ineligible for copyright and are explicitly public domain. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 signature.asc Description: Digital signature
Re: Patent issues
On Wed, Feb 18, 2004 at 05:22:29PM +0100, Roland Stigge wrote: I wonder if it is still possible for sarge to be released before 7 July 2004 (international expiration of US4558302). If not, we could start to move GIF/LZW patent encumbered packages from non-free and contrib to main. They will most likely not be moved until the patent expires. Packages that contain LZW code should not be in contrib; they should be in non-free because they cannot be practiced under a DFSG-free license. I wonder what Debian considers the threshold of importance for patents that can be ignored and patents that we care about. Active enforcement. Of course, if the patents are enforced, but are allowed to be practiced under a DFSG-free license, then that's different. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 signature.asc Description: Digital signature
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: crypto in non-free
On Sat, Jan 31, 2004 at 01:02:17PM +, Ian Beckwith wrote: Hello. What is the policy on crypto in non-free? The initial crypto-in-main announcement excluded non-free. Is that still the case? Yes. I am packaging the latest ckermit, and I have enabled crypto support (kerberos 4 5, openssl, TLS, DES, CAST and support for an external ssh client). I failed to resolve the license problems, so it is staying in non-free. The current version of ckermit in debian doesn't have any crypto options enabled, so this won't have come up before. ckermit doesn't contain any crypto code itself, it does everything by linking to external libraries. Is that relevant? So, does debian handle BXA declarations for non-free stuff, or will ckermit have to go into the ghetto that is non-US/non-free? 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. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 signature.asc Description: Digital signature
Re: JasPer License Issues: Some Potentially Good News
On Thu, Jan 29, 2004 at 06:50:32PM -0800, Michael Adams wrote: Hi Folks: [I have tried to include everyone that was involved in the discussions on the JasPer software license on the distribution list for this email. Quite a number of people were involved. I hope that I did not miss anybody.] I have some potentially good news. Image Power seems to be agreeable to revising the JasPer software license to address the concerns raised by you and other members of the open-source community. I have appended the first preliminary draft of the new license to this email for your feedback. I would very much appreciate your comments, as it would be a waste to go through the trouble to change the license for you folks if the result will not meet your needs. BTW, the new license was largely copied from the open-source-certified X11 license. Image Power has added condition 3 and I wonder if this is alright. The IBM Public License (certified by the Open Source Initiative) also seems to have a similar type of clause. So, this appears not to go against the spirit of open source. Thanks, Michael --- Michael Adams, Assistant Professor Dept. of Elec. and Comp. Engineering, University of Victoria P.O. Box 3055 STN CSC, Victoria, BC, V8W 3P6, CANADA E-mail: [EMAIL PROTECTED], Web: www.ece.uvic.ca/~mdadams --- cut here --- JasPer License Version 2.0 Copyright (c) 1999-2000 Image Power, Inc. Copyright (c) 1999-2000 The University of British Columbia Copyright (c) 2001-2003 Michael David Adams All rights reserved. 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: 1. The above copyright notice and this permission notice (which includes the disclaimer below) shall be included in all copies or substantial portions of the Software. 2. The name of a copyright holder shall not be used to endorse or promote products derived from the Software without specific prior written permission. 3. If User breaches any term of this license or commences an infringement action against any copyright holder then the User's license and all sublicenses that have been granted hereunder by User to other parties shall terminate. I am uncomfortable with this. I am not sure what the canonical debian-legal position is. This is also not compatible with the GPL, if that's an issue for you. THIS DISCLAIMER OF WARRANTY CONSTITUTES AN ESSENTIAL PART OF THIS LICENSE. NO USE OF THE SOFTWARE IS AUTHORIZED HEREUNDER EXCEPT UNDER THIS DISCLAIMER. THE SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. THE USER ACKNOWLEDGES THAT NO ASSURANCES ARE PROVIDED BY THE COPYRIGHT HOLDERS THAT THE SOFTWARE DOES NOT INFRINGE THE PATENT OR OTHER INTELLECTUAL PROPERTY RIGHTS OF OTHER PARTIES. EACH COPYRIGHT HOLDER DISCLAIMS ANY LIABILITY TO THE USER FOR CLAIMS BROUGHT BY ANY PARTY BASED ON INFRINGEMENT OF INTELLECTUAL PROPERTY RIGHTS OR OTHERWISE. AS A CONDITION TO EXERCISING THE RIGHTS GRANTED HEREUNDER, EACH USER HEREBY ASSUMES SOLE RESPONSIBILITY TO SECURE THE INTELLECTUAL PROPERTY RIGHTS NEEDED, IF ANY. THE SOFTWARE IS NOT FAULT-TOLERANT AND IS NOT INTENDED FOR USE IN MISSION-CRITICAL SYSTEMS, SUCH AS THOSE USED IN THE OPERATION OF NUCLEAR FACILITIES, AIRCRAFT NAVIGATION OR COMMUNICATION SYSTEMS, AIR TRAFFIC CONTROL SYSTEMS, DIRECT LIFE SUPPORT MACHINES, OR WEAPONS SYSTEMS, IN WHICH THE FAILURE OF THE SOFTWARE OR PRODUCT COULD LEAD DIRECTLY TO DEATH, PERSONAL INJURY, OR SEVERE PHYSICAL OR ENVIRONMENTAL DAMAGE (HIGH RISK ACTIVITIES). THE COPYRIGHT HOLDERS SPECIFICALLY DISCLAIM ANY EXPRESS OR IMPLIED WARRANTY OF FITNESS FOR HIGH RISK ACTIVITIES. This disclaimer is much better. I believe the last one prohibited use in nuclear facilities. This one merely states that it is NOT INTENDED FOR USE IN such systems. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 signature.asc Description: Digital signature
Re: Freetype patent issues
On Thu, Jan 22, 2004 at 09:20:58PM +0100, Alex de Landgraaf wrote: Hey debian-legal, Interested in improving font-AAing in Debian, I've taken a look at some of the patches in Debian for the freetype package. Now patents have hinderd true AA using freetype in Debian in the past ( 2 years ago), but since the freetype 2.0 series this shouldn't be a problem anymore [1]. In the current freetype package, the bytecode interpreter is _enabled_ using a patch (030-bytecode-interpreter.diff), I suspect this patch still remains from the 1.0 freetype series, when this and other patches were used to supply an unpatented bytecode interpreter. According to the freetype site, this would now cause freetype to fall under the patents granted to Apple, just like the 1.0 series. Disabling this patch would make freetype in debian patent-free again (from my point of view), while drasticly improving AA fonts in Debian (and derivatives alike). A bug [2] has already been submitted to do this some time ago. Then why this email? I'd like to be sure that I'm right on this subject. The last discussion about freetype seems to be a few years old, so it might be best to get some more informed people look at this issue again and correct me if I'm wrong :) It appears you are correct. If the bytecode interpreter is enabled, this would cause freetype to fall under the Apple patents; however, since Apple Computer is not actively enforcing its patent, we are not going to force the issue. The debian-legal stance on patents is to ignore those that are not being actively enforced (e.g. the Forgent patent on JPEG) and concern ourselves only with those that the patent holders give us grief about (e.g. IDEA, MP3, etc.). Debian is not patent-free, and will not be patent-free. CAST5 and CAST6 are patented but are available for use royalty free. DSA is patented by, IIRC, David Kravitz of the NSA. Putting a cursor on the screen using XOR is patented. I'm sure the Linux console driver (as well as the Hurd console driver) uses that technique, because it is efficient. Copy-on-write memory semantics are patented by SGI. And so on. If Apple decides to actively enforce its patent, you should upgrade the severity to serious if the license available for general use is not compatible with the Debian Free Software Guidelines. That being said, the maintainer should get a move on and remove the patch so that the fonts look right. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 signature.asc Description: Digital signature
Re: Distribution agreement for ATI FireGL drivers
On Sat, Jan 10, 2004 at 09:44:15PM +0100, Steinar H. Gunderson wrote: [I am not subscribed to debian-legal; please Cc any followups to me.] Hi, I've been trying to get ATIs FireGL drivers into non-free for a while (see the ITP at bug #218369), but there doesn't seem to be a proper license for it. I talked to ATI (who in general have been very helpful about this and other Linux issues) about this, and their legal department sent the following distribution agreement and requested that I sign it (I have of course not done so yet): This violates policy 2.3. We reserve the right to restrict files from being included anywhere in our archives if * their use or distribution would break a law, * there is an ethical conflict in their distribution or use, * we would have to sign a license for them, or * their distribution would conflict with other project policies. Sorry. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 signature.asc Description: Digital signature
Re: Changes in formal naming for NetBSD porting effort(s)
[I am not subscribed to debian-bsd.] On Wed, Dec 17, 2003 at 10:36:35AM -0500, Branden Robinson wrote: [I am not subscribed to debian-bsd.] [We're back off-topic for -legal.] On Sun, Dec 14, 2003 at 07:33:17PM -0500, Brian T. Sniffen wrote: Branden Robinson [EMAIL PROTECTED] writes: Street names from Berkeley have appeal, and few fundies assign Manichean properties to asphalt. You haven't met the Amish? :) Anyway, that doesn't sound like a bad naming scheme in principle. Got any specific names in mind? Well, I've found a list of choices [0] [1] [2]. The lists are from the Berkeley Unified School District, so I assume they're in Berkeley. [0] http://www.berkeley.k12.ca.us/OS/zones/n.html [1] http://www.berkeley.k12.ca.us/OS/zones/f.html [2] http://www.berkeley.k12.ca.us/OS/zones/o.html -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 signature.asc Description: Digital signature
Re: Bug#223961: libdvdread3: makes download of possibly illegal libdvdcss too easy
On Mon, Dec 15, 2003 at 06:50:10PM +0100, Adrian Bunk wrote: On Sun, Dec 14, 2003 at 11:16:11PM +0100, Andreas Metzler wrote: Adrian Bunk wrote: Package: libdvdread3 Version: 0.9.4-3 Severity: critical This is not a critical bug. This is a serious bug. The definition of a critical bug is: critical makes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package. The definition of a serious bug is: serious is a severe violation of Debian policy (that is, it violates a must or required directive), or, in the package maintainer's opinion, makes the package unsuitable for release. I assume, therefore, that your objection is based on policy 2.3, which reads in part as follows: We reserve the right to restrict files from being included anywhere in our archives if * their use or distribution would break a law, * there is an ethical conflict in their distribution or use, * we would have to sign a license for them, or * their distribution would conflict with other project policies. because you did not include a Justification: header. Please state if this is not so. The debconf note says: -- snip -- Many DVDs use css. To play these, a special library is needed to read them, libdvdcss. Debian cannot distribute this library according to some laws, but it is available on other places on the internet for download. Run `/usr/share/doc/libdvdread3/examples/install-css.sh' to download and install it. -- snip -- These some laws not only prevent distribution of libdvdcss, they also disallow the use of libdvdcss in some countries (e.g. in Germany). [...] It is rather dubious and not proven in court that using libdvdcss for *playing* DVDs (not copying them) is indeed illegal in Germany. I suggest further discussion on -legal. It's at least a grey area, and most likely in more countries than just Germany. If you as a private person say I think it is legal to use libdvdcss for playing DVDs, it's your choice. But for a user, it should be very clear that there are legal risks when using libdvdcss. Ignorance of the law is no excuse. If I choose to use an MP3 encoder in this country without paying Frauenhofer and Thomson exorbitant fees, I'm taking that risk. Any reasonable user should already know that libdvdcss is dangerous, and if one doesn't want one's door battered in by the cops, one shouldn't use it. That said, it doesn't meet the standard set out above: the use of the install-css.sh file itself does not break a law, even though the use of the resulting download might. While this is nitpicking, this is the standard set out in policy, and is the criteria for serious bugs. If you can state reasons that there is an ethical conflict or that the distribution would conflict with other project policies, or, find another section in policy that backs up your argument, fine; otherwise I think this is NOTABUG (tm). -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 signature.asc Description: Digital signature
Re: jabber-yahoo copyright file
will be changing this to GPL in the next release. -- Jamin W. Collins Remember, root always has a loaded gun. Don't run around with it unless you absolutely need it. -- Vineet Kumar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 signature.asc Description: Digital signature
Re: how (not) to write copyright files
On Sun, Dec 14, 2003 at 03:29:09PM +0100, Peter Palfrader wrote: [I intent to send this to debian-devel-announce, please tell me if I'm completely wrong] Hi, when reviewing several NMs' packages I came accross many broken copyright files in recent weeks. Upon investigation I found that many (many!) copyright files in the archives are not really any better. This is an example on how _NOT_ to do it: [snip lacking copyright file] This lacks some quite important information: - who owns the copyright. This must give the year and the copyright owner. This is a serious bug. From policy 12.5: Every package must be accompanied by a verbatim copy of its copyright and distribution license in the file `/usr/share/doc/package/copyright'. This file must neither be compressed nor be a symbolic link. This is also mentioned in policy 2.3. - It does not really say that the software in question is licensed under the GPL, and it loses information like 'GPL v2 or any later version'. This is true also. A proper copyright file looks like this: [...] [snip proper copyright file] You forgot where the upstream source was obtained, although you might have included that in the [...]. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 signature.asc Description: Digital signature
Re: simplest copyleft license for a wiki
On Sat, Nov 22, 2003 at 02:38:20PM +0100, Alex Schroeder wrote: I'm looking for some advice concerning the wording of the following license. The goal is to keep this license as short as possible while still making it a copyleft license upgradable to any of the other licenses. 1. You have the right to copy, modify, and/or distribute the work. 2. You must grant recipients the same rights. 3. You must inform recipients of their rights. 4. When you distribute the work, you must provide the recipients access to the preferred form for making copies and modifications, for no more than your costs of doing so. 5. Recipients must place identical restrictions on derivative works. 6. You may change the license to any other copyleft licsense such as the GPL, GFDL, CC SA, or the XEmacs manual license. s/licsense/license/ You should spell these licenses out in full, such as the GNU General Public License, as published by the Free Software Foundation. You should include the as published by clause so that nobody unscrupulous decides to publish a GPL that is really a proprietary license. There are some rather serious problems with the GFDL that Debian is trying to work out with the FSF. You can search the archives when they come back online. Item 4, for example, has a peculiar wording because the old wording was deemed unclear: You must make it trivially easy for recipients to copy and modify the work. This does seem to be ambiguous. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 signature.asc Description: Digital signature
Re: [fielding@apache.org: Review of proposed Apache License, version 2.0]
On Mon, Nov 10, 2003 at 03:22:39PM +0530, Mahesh T. Pai wrote: Brian M. Carlson said on Sat, Nov 08, 2003 at 10:39:29AM +,: I'm not sure that this is even legal, at least in the US. Will you please clarify why?? I'm assuming you meant the copyright assignment statement, and certainly, I will clarify. According to David Turner, IIRC, it requires written paperwork for copyright assignment. Debian, though, usually accepts emails as well, but not licenses that have default assignments. This was a big deal with ReiserFS (search the archives for more info). -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 signature.asc Description: Digital signature
Re: [fielding@apache.org: Review of proposed Apache License, version 2.0]
, except as required for reasonable and customary fair use while describing the origin of the Work. Further information on guidelines for use of related marks and/or how to obtain permission for use of those marks may be found in the NOTICE file, if any is included with the Work. 11. Disclaimer of Warranty. The Work is provided on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. 12. Limitation of Liability. Under no circumstances and under no legal theory, whether in tort (including negligence), contract, or otherwise, shall any Contributor be liable to any person for any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or the use of the Work including, without limitation, damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses. This limitation of liability shall not apply to liability for death or personal injury resulting from Licensor's negligence to the extent applicable law prohibits such limitation. Some jurisdictions do not allow the exclusion or limitation of incidental or consequential damages, so this exclusion and limitation may not apply to You. END OF TERMS AND CONDITIONS APPENDIX: How to apply the Apache TCK License to your work. To apply the Apache TCK License to your work, attach the following boilerplate notice, with the fields enclosed by brackets [] replaced with your own identifying information. (Don't include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same printed page as the copyright notice for easier identification within third-party archives. Copyright (C) [] [name of copyright owner] Licensed under the Apache TCK License, Version 1.0 (the License) as the Technology Compatibility Kit for the following specification: [ Widget Interface, revision 5.1 http://www.example.com/specs/widget/5.1/ ] You may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/tck-license-1.0.txt Software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 signature.asc Description: Digital signature
Re: [fielding@apache.org: Review of proposed Apache License, version 2.0]
BIG NOTICE: None of these licenses are official. They are all drafts. On Sat, Nov 08, 2003 at 10:03:55AM +, Brian M. Carlson wrote: I am including the licenses inline. I will immediately follow up with comments, so that it is apparent which comments are mine and which are not. 3. Contributors and Contributions. C. A Contribution is submitted when any form of electronic, verbal, or written communication is sent to the Licensor, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the Contributor as Not a Contribution. D. Any Contribution submitted by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions, unless You explicitly state otherwise in the submission. I'm not sure that this is even legal, at least in the US. 5. Reciprocity. If You institute patent litigation against a Contributor with respect to a patent applicable to software (including a cross-claim or counterclaim in a lawsuit), then any patent licenses granted by that Contributor to You under this License shall terminate as of the date such litigation is filed. In addition, if You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work itself (excluding combinations of the Work with other software or hardware) infringes Your patent(s), then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. I think that we have prohibited such litigation-termination licenses as non-free. 7. Redistribution with Modification. You may modify Your copy or copies of the Work or any portion of it, thus forming another work product based on the Work (a Derivative Work), and reproduce and distribute such modifications or the Derivative Work, provided that You also meet the following conditions: (a) You must give any other recipients of the Derivative Work a copy of this License along with the Derivative Work. (b) You must retain, in the source code of any Derivative Work that You distribute, all copyright, patent, or trademark notices from the source code of the Work, excluding those notices that only pertain to portions of the Work that have been excluded from the Derivative Work. If the Work includes a NOTICE file as part of its source code distribution, the Derivative Work must include a readable copy of the notices contained within that NOTICE file, excluding those notices that only pertain to portions of the Work that have been excluded from the Derivative Work, in at least one of the following places: within a NOTICE file distributed as part of the Derivative Work; within the source code or documentation, if provided along with the Derivative Work; or, within a display generated by the Derivative Work, if and wherever such third-party notices normally appear. You may add Your own notices alongside or as an addendum to the original NOTICE information. The contents of the NOTICE file are for informational purposes only and do not modify the terms and conditions of this License. Others might wish to comment on this section. My problem is that if NOTICES contains advertisement notices (like in this case), the license is probably not GPL-compatible. (c) You must cause any modified files to carry prominent notices stating that You changed the files. You may add Your own copyright statement to such modifications and may provide (sublicense) additional or different license terms and conditions for use, reproduction, distribution or further modification of Your modifications, or for the Derivative Work as a whole, provided that the sublicense complies with the conditions stated in this License. 8. Redistribution with Additional Terms. You may choose to offer, and to charge a fee for, warranty, support, indemnity, or liability obligations and/or other rights consistent with the scope of the license granted herein (Additional Terms). However, You may do so only on Your own behalf and as Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold every Contributor harmless for any liability
Re: The license of LaTeX2HTML
On Sat, Oct 25, 2003 at 10:20:26PM +0200, Roland Stigge wrote: [... disclaimer ...] Use and copying of this software and the preparation of derivative works based on this software are permitted, so long as the following conditions are met: A The copyright notice and this entire notice are included intact and prominently carried on all copies and supporting documentation. B No fees or compensation are charged for use, copies, or access to this software. You may charge a nominal distribution fee for the physical act of transferring a copy, but you may not charge for the program itself. This is non-free. It is also GPL-incompatible. C If you modify this software, you must cause the modified file(s) to carry prominent notices (a Change Log) describing the changes, who made the changes, and the date of those changes. D Any work distributed or published that in whole or in part contains or is a derivative of this software or any part thereof is subject to the terms of this agreement. The aggregation of another unrelated program with this software or its derivative on a volume of storage or distribution medium does not bring the other program under the scope of these terms. [... disclaimer ...] == The point is that point B seems to violate DFSG point 1, since The license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license may not require a royalty or other fee for such sale. Upstream doesn't want to change the license himself after 2 weeks of intense discussion. At least, the University of Leeds would have to be asked about changes, because the original authors worked there 10 years ago, when the latex2html project was. That would require at least the time of a complete Debian release cycle and would have to be really convincing. My suggestion was to apply the GPL or any other OSI-approved license. Note that some OSI-approved licenses (notably the RPSL and the APSL) are non-free. The one you suggested (the LPPL) has had some notorious problems in the past. Whether it is acceptable now, I don't know [0]. Additionally, the upstream maintainer, Ross Moore, isn't convinced about my point because he doesn't understand why Debian would be that greedy and claim money for latex2html where it at least could claim it for the rest of the distribution. But my interpretation of DFSG.1 is clear. His opinion was that point D already allows Debian to ship the package in main, but I don't agree with that. Debian is not greedy. In fact, Software in the Public Interest (Debian's parent corporation, since Debian is prohibited from holding assets of any kind) is not-for-profit corporation. But if someone wished to include a portion of latex2html in their own code and then sell that code, that's permitted by the DFSG. That's not permitted by this license. We have the DFSG not to protect Debian's freedom but to protect the freedom of Debian's *users*. Point D says that if we ship (or actually, provide for download) latex2html and gcc, then gcc does not fall under the license of latex2html. This means that latex2html passes DFSG 9, not that it passes DFSG 1. What do you think about it? Should we interpret the DFSG more liberally and say that the selling is just related to the _aggregation_ of our packages (that would be a question about the interpretation and maybe a call for further explanation in DFSG.1) or do we have to put latex2html into non-free? I would interpret it as the latter (but see below). The latter case would be very bad because latex2html is quite popular and 35 packages in main build-depend on it (!). Practicality is irrelevant to whether a license is free or not. And in this case a workaround is available. Maybe I should add that some files in latex2html are GPL'ed, which possibly forces us / the maintainer to apply the GPL to the whole package. If some files are GPL, then the whole work must be distributed under the GPL. Unfortunately, this license is incompatible with the GPL; therefore, we cannot distribute it at all. If you cannot resolve this issue with upstream, you should file a bug on ftp.debian.org requesting its removal. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=204684 [0] See the archives for details. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 signature.asc Description: Digital signature
Re: If not GFDL, then what?
On Sat, Oct 11, 2003 at 12:24:23PM -0400, Mark Pilgrim wrote: I am up to speed on the recent discussion of the GFDL, and I have read the various position statements published by members of the Debian community. Here is my situation: 1. I have a book, http://diveintopython.org/, which is currently licensed under the GFDL, with no Invariant Sections and no Front- or Back-Cover Texts. 2. This book is scheduled to be published on paper by Apress next summer, and they are aware that all their editing work between now and then will also fall under the GFDL. 3. There are complete or partial translations of the book in 6 languages, all covered by the GFDL. 4. Yesterday, a Debian package maintainer (Ross Burton) contacted me wishing to create a Debian package out of the book. He initially claimed that I would need to relicense it, then later (after talking with other maintainers) that this was unnecessary, but ultimately he was unsure who was right or how long it would stay in Debian main, if indeed it got there at all. Here is what I would like to do: 1. Give away my book for free. I am assuming you mean Make my book free software, this is fine. 2. Force translations and all derivative works to remain free. Ok. You may need to negotiate with the translators over the license change, though. 3. Force my editor's contributions to remain free. Assuming this is in the contract, this is fine too. 4. Allow Apress to publish the book commercially. DFSG-free licenses cannot prohibit commercial use. If a license prohibits commercial use, it is by definition non-free. 5. Put the book in Debian main. Excellent! What license would you recommend for that? I would recommend the GNU General Public License, version 2. This accomplishes your goals, and it is unequivocally free. You would be compelled to provide source to those who receive a binary, that is, anyone who receives a book, DVI, PS (unless you wrote it this way), or other non-source material, must either (a) receive the source on a medium customarily used for software interchange, or (b) be provided with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code ... on a medium customarily used for software interchange. If you provide the source on a website, then most people will just download it from there, and you probably never have to perform source distribution. Also, with choice (a) above (which corresponds to 2a in the GPL), you need not force the user to accept the source. Providing it along with the binary is fine, if the user wants it, he or she will take it; if not, then not. You can find more information on a Debian system in /usr/share/common-licenses/GPL, which is complete copy of GPL version 2. If you do not use Debian, you can find a copy at the GNU Project's web site: http://www.gnu.org/copyleft/gpl.html. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams signature.asc Description: Digital signature
Re: If not GFDL, then what?
On Sat, Oct 11, 2003 at 04:18:39PM -0500, Branden Robinson wrote: On Sat, Oct 11, 2003 at 05:00:16PM +, Brian M. Carlson wrote: I would recommend the GNU General Public License, version 2. This accomplishes your goals, and it is unequivocally free. I have equivocated on its freeness before, with respect to clauses 2a) and 2c). I apologize. I didn't remember reading that when I wrote my message. I did not mean to misrepresent your opinion or anyone else's, only to represent my own. Also, I see no reason the author can't dual-license under the GNU GPL and and the GNU FDL. It might be easier to get the publisher to go along with that if they've already bought into the rhetoric that the GNU GPL is an inappropriate license for printed documentation. The author asked for a recommendation. I offered one which met the specified criteria. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams signature.asc Description: Digital signature
Re: Export clauses in XFree86 licensing
On Wed, Sep 17, 2003 at 11:55:23AM -0500, Branden Robinson wrote: On Tue, Sep 16, 2003 at 10:19:54PM +0200, Henning Makholm wrote: 7. Compliance with Laws; Non-Infringement. Recipient shall comply with all applicable laws and regulations in connection with use and distribution of the Subject Software, including but not limited to, all export and import control laws and regulations of the U.S. government and other countries. Recipient may not distribute Subject Software that (i) in any way infringes (directly or contributorily) the rights (including patent, copyright, trade secret, trademark or other intellectual property rights of any kind) of any other person or entity or (ii) breaches any representation or warranty, express, implied or statutory, which under any applicable law it might be deemed to have been distributed. This fails the Chinese Dissident test. It discriminates against those that are not subject to United States law. It does not allow for disclaiming of warranty. It imposes a burden on the recipient to ensure that he or she does not infringe a third party's rights. Fails DFSG 5. 8. Claims of Infringement. If Recipient at any time has knowledge of any one or more third party claims that reproduction, modification, use, distribu- tion, import or sale of Subject Software (including particular functionality or code incorporated in Subject Software) infringes the third party's intel- lectual property rights, Recipient must place in a well-identified web page bearing the title LEGAL a description of each such claim and a description of the party making each such claim in sufficient detail that a user of the Subject Software will know whom to contact regarding the claim. Also, upon gaining such knowledge of any such claim, Recipient must conspicuously include the URL for such web page in the Exhibit A notice required under Sec- tions 2 and 3, above, and in the text of any related documentation, license agreement or collateral in which Recipient describes end user's rights relat- ing to the Subject Software. If Recipient obtains such knowledge after it makes Subject Software available to any other person or entity, Recipient shall take other steps (such as notifying appropriate mailing lists or news- groups) reasonably calculated to inform those who received the Subject Soft- ware that new knowledge has been obtained. This discriminates against those who do not have internet access or for whom internet access is prohibitively expensive. This also lends credence to claims which may be frivolous (can we say SCO?). It discriminates against distributors whose target audience doesn't know or care about any such new knowledge, such as Debian. How would Debian contact everyone that downloaded this software? This imposes an unreasonable burden on users. Fails DFSG 5 and 6. (From the SGI FREE SOFTWARE LICENSE B): 7. Claims of Infringement. If Recipient learns of any third party claim that any disposition of Covered Code and/or functionality wholly or partially infringes the third party's intellectual property rights, Recipient will promptly notify SGI of such claim. This fails the Desert Island test. This imposes a burden on users to do SGI's work for them, which users should not have to do. Fails DFSG 5. IANAL. TINLA. IANADD. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams signature.asc Description: Digital signature
Is the Sun RPC License DFSG-free?
reopen 181493 ! thanks For the debian-legal people, this is the controversy at hand: Sun RPC code is included as part of glibc. The license, which is included below, prohibits distribution of the original code under its original terms, which would make the license non-free. Including non-free code into otherwise free code does not make the code free, IMO. Copyright (C) 1984, Sun Microsystems, Inc. Sun RPC is a product of Sun Microsystems, Inc. and is provided for unrestricted use provided that this legend is included on all tape media and as a part of the software program in whole or part. Users may copy or modify Sun RPC without charge, but are not authorized to license or distribute it to anyone else except as part of a product or program developed by the user. SUN RPC IS PROVIDED AS IS WITH NO WARRANTIES OF ANY KIND INCLUDING THE WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE, OR ARISING FROM A COURSE OF DEALING, USAGE OR TRADE PRACTICE. Sun RPC is provided with no support and without any obligation on the part of Sun Microsystems, Inc. to assist in its use, correction, modification or enhancement. SUN MICROSYSTEMS, INC. SHALL HAVE NO LIABILITY WITH RESPECT TO THE INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY PATENTS BY SUN RPC OR ANY PART THEREOF. In no event will Sun Microsystems, Inc. be liable for any lost revenue or profits or other special, indirect and consequential damages, even if Sun has been advised of the possibility of such damages. I'd like an opinion. M-F-T is set appropriately. On Sun, Aug 17, 2003 at 08:48:04PM -0500, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report #181493: glibc: Sun RPC code is non-free, which was filed against the glibc package. It has been closed by one of the developers, namely GOTO Masanori [EMAIL PROTECTED]. Their explanation is attached below. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact the developer, by replying to this email. This explanation is unsatisfactory. I think that the Sun RPC code is non-free, and I want an opinion from debian-legal. At Mon, 18 Aug 2003 02:28:48 +1000, Anthony Towns wrote: This bug should be closed. OK, I've closed now. Regards, -- gotom -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgp4y3NvKCuy4.pgp Description: PGP signature
Re: Patents, gimp-nonfree and LAME
On Thu, Aug 21, 2003 at 10:55:12PM -0700, Paul C. Bryan wrote: My question is: what are the guidelines on packaging code that has patented technology? Does GIMP's GIF support get distributed because Unisys is not actively enforcing its LZW patent, while LAME does not get distributed because Fraunhofer is actively enforcing its MP3 patent? No, Unisys is very actively enforcing its patent. It is acceptable to distribute LZW in non-free because it can be used for non-commercial purposes only, which would make it eligible for non-free. With LAME, Frauenhofer requires that for every copy of an MP3 encoder, somewhere around $.50 to $.75 be charged (I didn't look this up, so don't blame me if this is wrong; look it up yourself) per copy. Debian doesn't want to assume the responsibility for reporting, etc. to Fraunhofer, especially since SPI is a US (Indiana?) corporation. Generally, if a patented technology is only licensed under non-free terms, it will be put in non-free, unless it requires affirmative action on the part of Debian (like the MP3 patent), in which case Debian will refuse to package it at all. Some patented technologies, such as the encryption algorithm CAST-128 [0], are available for use under DFSG-free terms, and so may be placed in main, assuming the software implementing them is also DFSG-free. [1] http://www.debian.org/devel/wnpp/unable-to-package.en.html [0] http://www.rfc-editor.org/rfc/rfc2144.txt -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgpqQzP0I1zkh.pgp Description: PGP signature
Re: gif-creating applications?
On Fri, Aug 08, 2003 at 01:02:13PM +0200, Andreas Barth wrote: Hi Hello. what's the legal status of inclusion of gif-creating applications in debian? Is it ok to include it in main, contrib or non-free? http://www.gnu.org/philosophy/gif.html says that the latest patent expiry is 7 July 2004, but Unisys seems to have given parts of their patent free (but only for non-comercial use). Unisys has changed its collective mind several times. It is not safe to rely on the opinion of Unisys. Any new uploaded code would go only to testing, and release if probably after patent expiry. Actually, they would go to unstable, and then when the testing scripts decided that it was appropriate, only then would they go to testing. (I'm not asking about a new programm, but of code that's already in non-free at the moment, so a total remove will break existing programms.) So, my question is: 1. Is it ok to have gif-producing binaries in testing/main? No. The GIF algorithm uses (in most cases) LZW (Lempel-Ziv-Welch), which has not yet expired in Germany. We cannot include it main, because Unisys is only willing to license the patent for it under non-commercial terms, and those terms are not sufficient to fulfill the DFSG. GIF-producing binaries that use only RLE (run length encoding) are not patent-encumbered and may be placed in main. 2. Is it ok to have gif-producing binaries in testing/non-free? Yes, assuming the binaries otherwise would be eligible for non-free. 3. Is it ok to have the source of gif-producing binaries in testing/main? No. LZW is prohibited in the source and binaries. Many a developer has had to change the orig.tar.gz file because it contains LZW code which must be extirpated. I'm not a reader of debian-legal. I really would prefer if I just can get a verdict after your discussion, but it's probably better if you would Cc me on replies. Thank you for including a proper Mail-Followup-To:. That's the best way to get a proper response where you want it. Please note that I am not a Debian Developer. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgpRdKZOcDkUk.pgp Description: PGP signature
Re: migrating away from the FDL
On Sun, Jul 20, 2003 at 10:49:04AM +0200, Mathieu Roy wrote: To my knowledge, only a very vocal minority of Debian Developers argues for the removal of documentation licensed under the GFDL (and even their views are far from consistent). You guys might be putting the future of the project at risk, without actually realizing what you are doing. Virtually every person on this list finds the GFDL non-free in some situation. By on this list, you mean people that subscribed to this list? On this list could also mean people who just pop in for the GFDL discussions, since I have no way of knowing if they're subscribed. If so, you're wrong. I suscribed and it don't makes me considering the GFDL non-free. I was not attempting to assert that by subscribing one automatically has a certain mindset; if that's what people think I meant, let me correct that right now. I used the term virtually because I realize that people (like you, perhaps) might disagree with the opinion of what appears to be the sweeping majority (at least that's what I see, by those who speak up; if you don't speak up, I don't know your opinion; I can't read minds) of people on this list. I realize (and this is a gross generalization; please pardon me) that people that have stronger ties to the FSF and GNU are more likely to feel that the GFDL is free than those that have stronger ties to Debian. The case might be that people who disagree with the statement the GFDL is non-free might not be saying anything and they might actually constitute the majority. I feel this an unlikely possibility, though. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgpRCsZxtCE3I.pgp Description: PGP signature
Re: migrating away from the FDL
On Sat, Jul 19, 2003 at 10:40:50PM +0200, Florian Weimer wrote: Wouter Verhelst [EMAIL PROTECTED] writes: No, this is not a mail about large-scale bugs I intend to file about packages using the FDL. It's about 'how do I relicense stuff in non-FDL licenses'. The next logical step is 'how do I rename Debian GNU/Linux' to 'Debian Linux', I presume. I think you are exaggerating a tad. This person came to us asking how to relicense software he wrote. We only gave him information on how to do so. If he wanted to relicense software in non-APSL licenses, we would have given him that information too (which would probably have been very similar). To my knowledge, only a very vocal minority of Debian Developers argues for the removal of documentation licensed under the GFDL (and even their views are far from consistent). You guys might be putting the future of the project at risk, without actually realizing what you are doing. Virtually every person on this list finds the GFDL non-free in some situation. Most of the people who you see as the vocal minority of DDs are people who are very vocal anyway. We've even had the original authors of some of the documentation complain that they didn't like what the FSF did by changing the licensing, but that they couldn't do anything about it. I'm not a DD, and I think it's non-free. You can see the bug on glibc about it. That's part of why glibc took forever to get into testing. Other bugs have been filed on gcc docs. This problem is not going away. Also, I don't see how the future of the project can be at risk over a non-free license. It is so obviously non-free that if it were a) by anyone else but the FSF and b) not so deeply ingrained in our archives, everything licensed under it would be extirpated from main at once. For example, look at section 4. If my original document included a section Entitled History that contained a 10,000 word Ode to My Goldfish (thank you whoever came up with that brilliant idea), nobody else could remove it. That would be obviously non-free. Let me take this opportunity, in case I haven't already, to announce that any document, software, or other copyrightable work that I have created or to which I hold copyright that is licensed under any version of the GNU Free Documentation License (including draft versions) is hereby licensed under the GNU General Public License, as published by the Free Software Foundation, version 2 only. That should take care of the GFDL'd manpage that I submitted to fix a bug. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgpP0NUjL8qqg.pgp Description: PGP signature
Re: Bug#200411: www.debian.org: confusing description of non-US sections
On Thu, Jul 17, 2003 at 11:45:39AM +0200, Matt Kraai wrote: On Wed, Jul 16, 2003 at 06:46:15PM +, Brian M. Carlson wrote: Patented software does not have to be patent-encumbered (for example, we have many programs and libraries in both main and non-US/main that use CAST5 [0], which is patented). Patent-encumbered software would use things like LZW, which is non-free because of the licensing that is required to use it. CAST5's RFC [0] states: The CAST-128 cipher described in this document is available worldwide on a royalty-free basis for commercial and non-commercial uses. I'd further point out that packages relegated to non-US purely because of US patents are not usable in the US, which is something that traditionally non-US/main has been. Also, for example, if LZW had just a year left to expire on it in the US, instead of in Germany, would we relegate it to non-US/main? I hope not. Would the the descriptions be correct if the following patch was applied? *** packages.wml.~1.52.~ Tue Jul 8 17:25:45 2003 --- packages.wml Thu Jul 17 11:34:47 2003 *** *** 27,34 restricting use or redistribution of the software./dd dtemNon-US/Main/em/em/dt ddPackages in this area are free themselves but cannot be ! stored on a server in the U.S. because they are encumbered by ! patent issues./dd dtemNon-US/Non-Free/em/dt ddPackages in this area have some onerous license condition restricting use or redistribution of the software. They cannot --- 27,33 restricting use or redistribution of the software./dd dtemNon-US/Main/em/em/dt ddPackages in this area are free themselves but cannot be ! exported from a server in the U.S./dd dtemNon-US/Non-Free/em/dt ddPackages in this area have some onerous license condition restricting use or redistribution of the software. They cannot I would be fine with this. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgpP4ZHFwp26e.pgp Description: PGP signature
Re: Bug#200411: www.debian.org: confusing description of non-US sections
On Mon, Jul 14, 2003 at 11:42:09PM +0200, Matt Kraai wrote: On Mon, Jul 14, 2003 at 09:15:01PM +, Brian M. Carlson wrote: On Mon, Jul 07, 2003 at 09:59:34PM -0700, Matt Kraai wrote: The thread http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00029.html documents the exact rationale for these sections. The following patch incorporates its conclusions into the packages page. I'd appreciate it if the readers of debian-legal would double-check it. What I saw in that thread was Wichert saying that things in non-US needed to be there because of patents, and Steve Langasek saying that that those things needed to be in non-US/non-free. That's not what I see below. I only found one reply from Steve Langasek at http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00032.html I interpret this as saying that cryptographic software that is non-free cannot move to a server in the US because it does not fall under the same BXA exemptions that allow us to export free cryptographic software. I didn't see anything in his message regarding patents. He did not mention anything specifically regarding patents, but he did mention non-US/non-free quite prominently: I have seen no official endorsement given of merging non-US/non-free into the principal Debian mirror network. But the software is still non-free. It didn't suddenly become free and eligible for non-US/main. -dtemNon-US/Main/em and emNon-US/Non-Free/em/dt - ddThese packages cannot be exported from the USA, they are mostly - encryption software packages, or software that is encumbered by - patent issues. Most of them are free, but some are non-free./dd +dtemNon-US/Main/em/em/dt + ddPackages in this area are free themselves but cannot be + stored on a server in the USA because they are encumbered by + patent issues./dd Things in main or non-US/main should not be patent encumbered. non-US/main is designed so that packages can be imported into the US, but not exported. If it would not fit the DFSG for any reason, including being patent-encumbered in the US or other places, then it does not belong in non-US/main. What belongs in non-US/main? Only software left over from the crypto-in-main transition? As I said before: any software which is legal to use in the US, legal to import into the US, but illegal or restricted to export from the US. Remnants of crypto-in-main might be a good idea. I can't possibly imagine every situation in which non-US/main might be useful, just like I can't imagine every inconsistent license (and trust me, there's a lot of them) that passes through this mailing list. I am confident, though, that it will be useful. [snip] One final nitpick: please properly capitalize non-US, non-free, and main. I was being consistent with the titles of the other sections as listed on that page. I understand that. I just disagree with the way it was done, and wanted to throw out another point of view. If you don't like it, don't change it. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgpJYXvRm1hBk.pgp Description: PGP signature
Re: Bug#200411: www.debian.org: confusing description of non-US sections
On Tue, Jul 15, 2003 at 09:16:30AM -0500, Steve Langasek wrote: On Mon, Jul 14, 2003 at 11:42:09PM +0200, Matt Kraai wrote: On Mon, Jul 14, 2003 at 09:15:01PM +, Brian M. Carlson wrote: On Mon, Jul 07, 2003 at 09:59:34PM -0700, Matt Kraai wrote: -dtemNon-US/Main/em and emNon-US/Non-Free/em/dt - ddThese packages cannot be exported from the USA, they are mostly - encryption software packages, or software that is encumbered by - patent issues. Most of them are free, but some are non-free./dd +dtemNon-US/Main/em/em/dt + ddPackages in this area are free themselves but cannot be + stored on a server in the USA because they are encumbered by + patent issues./dd Things in main or non-US/main should not be patent encumbered. non-US/main is designed so that packages can be imported into the US, but not exported. If it would not fit the DFSG for any reason, including being patent-encumbered in the US or other places, then it does not belong in non-US/main. What belongs in non-US/main? Only software left over from the crypto-in-main transition? There have, in practice, been packages relegated to non-US for purely patent reasons. Whether these packages warrant the classification of non-US/main or non-US/non-free is a bit of a judgement call. Since the DFSG mainly talks about software licenses, I would question whether it's appropriate to speak of patent-encumbered software as non-free when the patent holder is not the author. Patented software does not have to be patent-encumbered (for example, we have many programs and libraries in both main and non-US/main that use CAST5 [0], which is patented). Patent-encumbered software would use things like LZW, which is non-free because of the licensing that is required to use it. CAST5's RFC [0] states: The CAST-128 cipher described in this document is available worldwide on a royalty-free basis for commercial and non-commercial uses. I'd further point out that packages relegated to non-US purely because of US patents are not usable in the US, which is something that traditionally non-US/main has been. Also, for example, if LZW had just a year left to expire on it in the US, instead of in Germany, would we relegate it to non-US/main? I hope not. [0] http://www.rfc-editor.org/rfc/rfc2144.txt -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgpYYfJuDuqk1.pgp Description: PGP signature
Re: Bug#200411: www.debian.org: confusing description of non-US sections
On Mon, Jul 07, 2003 at 09:59:34PM -0700, Matt Kraai wrote: On Tue, Jul 08, 2003 at 02:24:25PM +1000, Ben Finney wrote: The packages page at http://www.debian.org/distrib/packages currently says: = Non-US/Main and Non-US/Non-Free These packages cannot be exported from the USA, they are mostly encryption software packages, or software that is encumbered by patent issues. Most of them are free, but some are non-free. = The point about encryption software is out of date since we can get any crypto software exported from the USA these days. The last sentence is needlessly vague. The thread http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00029.html documents the exact rationale for these sections. The following patch incorporates its conclusions into the packages page. I'd appreciate it if the readers of debian-legal would double-check it. What I saw in that thread was Wichert saying that things in non-US needed to be there because of patents, and Steve Langasek saying that that those things needed to be in non-US/non-free. That's not what I see below. -dtemNon-US/Main/em and emNon-US/Non-Free/em/dt - ddThese packages cannot be exported from the USA, they are mostly - encryption software packages, or software that is encumbered by - patent issues. Most of them are free, but some are non-free./dd +dtemNon-US/Main/em/em/dt + ddPackages in this area are free themselves but cannot be + stored on a server in the USA because they are encumbered by + patent issues./dd Things in main or non-US/main should not be patent encumbered. non-US/main is designed so that packages can be imported into the US, but not exported. If it would not fit the DFSG for any reason, including being patent-encumbered in the US or other places, then it does not belong in non-US/main. +dtemNon-US/Non-Free/em/dt + ddPackages in this area do not necessarily cost money, but + have some onerous license condition restricting use or + redistribution of the software. They cannot be exported from + the USA because they are encryption software packages or they + cannot be stored on a server in the USA because are encumbered + by patent issues./dd Things that belong in non-US, but are patent-encumbered or otherwise fail to meet the DFSG for any reason belong in non-US/non-free. This includes things that would be eligible for the crypto-in-main transition were they free, but in fact are not. For example, IDEA code belongs here. One final nitpick: please properly capitalize non-US, non-free, and main. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgpUPkuGEhY7M.pgp Description: PGP signature
Re: wall's license?
On Sun, Jun 08, 2003 at 04:06:16PM +0300, Shaul Karl wrote: With a testing machine, $ dpkg -p bsdutils | tail -2 Included are: logger, renice, replay, script, wall According to /usr/share/doc/bsdutils/copyright, It was downloaded from ftp://ftp.win.tue.nl/pub/home/aeb/linux-local/utils/util-linux/ Copyright: getopt, more, pg, and whereis may be redistributed under the terms of the UCB BSD license found on Debian systems in the file /usr/share/common-licenses/BSD Everything else may be redistributed under the terms of the GNU GPL Version 2 or later found on Debian systems in the file /usr/share/common-licenses/GPL Yet both wall.c and wall.1 seems to contain the UCB BSD license. Shouldn't it be under the UCB BSD license? Yes, they should. And the third clause of the license should be patched out. File a bug. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgpTWGIF4xWHO.pgp Description: PGP signature
Re: Open Software License
On Mon, Jun 02, 2003 at 04:16:48PM -0400, Joey Hess wrote: This is a new one to me. It's the license of elfutils, which is included in rpm 4.2. This isn't GPL compatible, so in case it is actually being linked with rpm itself, that would be a problem. I'm not commenting on the freeness of the license. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgp73AnYjahoo.pgp Description: PGP signature
Re: Removal of non-free
On Mon, May 26, 2003 at 01:29:16AM -0600, Joel Baker wrote: where it's reasonably justified; I think (though I wish it weren't true) that some things like old RFCs are unlikely to be republished under a Free license anytime soon (and some might never be, since the authors are dead; Jon Postel, for example, is the author of many early RFCs). At least some early RFCs are free. You can see the bug on doc-rfc, which *still* hasn't been closed, and is *still* in main. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgpFd17YsYeVK.pgp Description: PGP signature
Re: Legal questions about some GNU Emacs files
On Mon, Apr 28, 2003 at 04:34:54PM -0700, Alex Romosan wrote: Steve Langasek [EMAIL PROTECTED] writes: You have turned the DFSG soundly on its head. In a world of copyrights, all works are non-free *by default*; it is only if they meet certain requirements, as detailed in the DFSG, that we consider them free. Are you saying that the WHY-FREE op-ed piece should be considered free because the DFSG doesn't say anything about opinion pieces? _you_ have turned the DFSG on its head by taking something meant for software and applying it to non software. i've read the DFSG now a million times and all i can see is references to software and source code. it doesn't say anything about documentation, nor does it say anything about being able to modify political manifestos. show me where in the DFSG there is a mention of anything other than software. why should be distribute WHY-FREE? because it is our raison d'être. with out it debian wouldn't even exist and we wouldn't be having this conversation. generalizing a little bit, emacs is not just a text-editor (or mail reader, compiler, oh well, operating system), emacs is a political statement and as such it should include the WHY-FREE manifesto. Okay, here's the deal. We've discussed this 42e69 times before, and we'll do it that many times again, if not more. But I would like to point you to http://lists.debian.org/debian-legal/2002/debian-legal-200208/msg00364.html et seq. I would especially like to point out something that Joe Wreschnig said [0]: My point is that fine, I guess Debian can include non-free non-software. However, it's difficult if not impossible to prove that any given stream of bits is not software. So the only non-free things we can include are proven non-software, like ham sandwiches or desks. I will pay a cash reward to the first person who modifies apt to make it possible to download a desk. ;-) [0] http://lists.debian.org/debian-legal/2002/debian-legal-200208/msg00385.html -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgpmpqEP1lTFz.pgp Description: PGP signature
Re: Proposed statement wrt GNU FDL
On Sat, Apr 26, 2003 at 01:50:33AM -0400, Anthony DeRobertis wrote: RFC 1884 (December 1995) RFC 2373 (July 1998) RFC 3515 (August 2003) ^^^ Uhh, I didn't know that the IETF issued RFCs in the future. Perhaps you meant April 2003? -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgpjlBVCBWGn2.pgp Description: PGP signature
work with GPL and GPL with extra note
I am creating a piece of documentation that is licensed under the GPL (it must be licensed this way, because I have derived information from glibc). I am also getting information from some Linux manpages. But a few manpages have licenses like this: .\ This is free documentation; you can redistribute it and/or .\ modify it under the terms of the GNU General Public License as .\ published by the Free Software Foundation; either version 2 of .\ the License, or (at your option) any later version. .\ .\ The GNU General Public License's references to object code .\ and executables are to be interpreted as the output of any .\ document formatting or typesetting system, including .\ intermediate and printed output. .\ .\ This manual is distributed in the hope that it will be useful, .\ but WITHOUT ANY WARRANTY; without even the implied warranty of .\ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the .\ GNU General Public License for more details. .\ .\ You should have received a copy of the GNU General Public .\ License along with this manual; if not, write to the Free .\ Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111, .\ USA. The second paragraph is what I am most concerned about. Is it possible to combine a work that is pure GPL and a work that is GPL with this interpretation clause? No need to Cc:, I'm subscribed. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgpwlAOcMKLvR.pgp Description: PGP signature
Re: Legal questions about some GNU Emacs files
On Sat, Apr 26, 2003 at 08:08:01PM +0200, Jérôme Marant wrote: According to Dylan Thurston (see #154043), some files shipped with GNU Emacs could be considered as non-free. One of them is /usr/share/emacs/21.3/etc/LINUX-GNU. The problem seem to come from the footer which mentions: Copyright 1996 Richard Stallman Verbatim copying and redistribution is permitted without royalty as long as this notice is preserved. Also in /usr/share/emacs/21.3/etc/WHY-FREE Copyright 1994 Richard Stallman Verbatim copying and redistribution is permitted without royalty as long as this notice is preserved; alteration is not permitted. What do you people think of this? What do I think? I think WHY-FREE is a very ironic name for something so non-free. It should be removed, of course. I'm sorry if RMS will be unhappy, but the DFSG does not make exceptions if people are unhappy. Documentation *is* software, and therefore its licenses must follow the DFSG; I thought we just decided that. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgpbfK3Nh0hNW.pgp Description: PGP signature
Re: monit: GPL and OpenSSL..
On Tue, Apr 22, 2003 at 01:46:18PM +0200, Fredrik Steen wrote: Hi, One of the packages I maintain is monit[0], they now have a long awaited feature using SSL. I have read that GPL and OpenSSL is not compatible and have You are correct. OpenSSL has an advertising clause which is incompatible with the GPL. There is an exception for anything that is normally distributed...with the major components...of the operating system on which the executable runs, unless that component itself accompanies the executable. It is the opinion of debian-legal that OpenSSL does not fall under this exception. been mailing with the developers of monit. They asked if was okay for Debian to add add this to the license: This program is released under the GPL with the additional exemption that compiling, linking, and/or using OpenSSL is allowed. Would this be sufficient for Debian? Well, it depends on what you mean by Debian. Debian cannot add anything to the license; only the copyright holders can do so. If you meant that this was a license only for Debian, that program would go in non-free. DFSG 8 prohibits Debian-specific licenses. *But that aside*, that license is free. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgpAKWA9D9cuN.pgp Description: PGP signature
Re: motion to take action on the unhappy GNU FDL issue
On Thu, Apr 17, 2003 at 01:27:05PM -0700, Mark Rafn wrote: On Wed, 16 Apr 2003, Branden Robinson wrote: I am seeking seconds for this proposal. I think this proposal is the right thing to do, especially the hard work of creating the documents before filing bugs. Unfortunately, I am unwilling to take on the task myself, though I'm happy to provide feedback and sections of text where I can. Between this and the fact that IANADD, I don't think I have standing to provide a second. I also support this proposal. I don't have too much time, but I'm willing to help where I can. I'm also not a DD, so I'm not going to attempt a second. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgpMqE02KJJ1p.pgp Description: PGP signature
Re: plagiarism of reiserfs by Debian
[subscribed to -legal, not to -devel; Cc: accordingly] On Sun, Apr 20, 2003 at 01:24:09AM +0200, Wouter Verhelst wrote: Op za 19-04-2003, om 22:51 schreef Lukas Geyer: the issue seems to be the fix of #152547. If we are not allowed to remove a screenful of advertising from the output of a program, then this unduly restricts the freedom to distribute modified versions. Uhm. From the GPL, section 2: c) If the modified program normally reads commands interactively ^ when run, you must cause it, when started running for such I tried mkreiserfs out (I use good old ext2!) and the only command it reads interactively is a y or n when asked to continue formatting my test file which is not a block special device. interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) Let's assume for a second that the yes-or-no response *is* a command (which is debatable). GPL 2c only requires that one print or display 1) a copyright notice; 2) a notice of warranty or the lack thereof; 3) a notice that redistribution is permitted under the GPL; and 4) how to view the GPL. It does not require that one spew almost an entire screenful of advertisement. And, because neither mkreiserfs nor reiserfsck even display a copyright notice, it falls under the exception. Otherwise put: if the program shows the 'no warranty' clause from the GPL at startup, you may not remove it. Although a 'no warranty' message Which it doesn't. messages being printed for legalese reasons. I, personally, see nothing wrong with that; it certainly doesn't result in software being non-free. I do. DFSG 3 requires that [t]he license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. GPL 2c passes muster only because it displays license material. Even that is controversial on this list. debian-legal has consistently held that license material can be immutable and still free. I have never seen debian-legal say that advertisements and conversations with one's lawyer can be immutable and still free. If you disagree, please show me a reference. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgpaVoOdY79Bo.pgp Description: PGP signature
Re: Suggestion to maintainers of GFDL docs
On Wed, Apr 16, 2003 at 09:40:49AM -0400, Peter S Galbraith wrote: Consider this a suggestion to maintainers of packages that contain documentation that are under the GFDL, especially if it contains invariant sections. Imagine if an Emacs user visited Info and saw this: * Menu: * Distrib:: How to get the latest Emacs distribution. * Copying:: The GNU General Public License gives you permission to redistribute GNU Emacs on certain terms; it also explains that there is no warranty. * GNU Free Documentation License:: The license for this documentation. * Why you shouldn't use the GFDL:: Debian doesn't recommend using this license. Debian can't legally distribute such an info document. Because the GFDL is incompatible with the GPL, it is prohibited to even create an info document from GFDL'd texinfo source. See #183860. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgp1MByC1oaVL.pgp Description: PGP signature
Re: Bug#182402: ttf-freefont is violating the GNU GPL
On Wed, Feb 26, 2003 at 09:10:58AM +1100, Peter Hawkins wrote: Hi... On Tue, Feb 25, 2003 at 01:17:00AM -0500, Simon Law wrote: Package: ttf-freefont Version: 20021016-2 Severity: serious The package ttf-freefont is licensed under the GNU General Public License, as listed in the appended debian/copyright file. I can confirm this from http://savannah.nongnu.org/download/freefont/COPYING . Since ttf-freefont _does_ _not_ include the complete corresponding machine-readable source code, Yes it does. It includes complete machine readable source code of the fonts in a particular format (ie. TTF). Since TTF files are effectively like images (albeit in a very specialised format), you can modify and improve them with the appropriate tools. True, there are other formats you could provide the fonts in, but I would argue that TTF fulfils all the requirements of source code based distribution. Section 3 of the GNU General Public License contains the following text: The source code for a work means the preferred form of the work for making modifications to it. If you can legitimately justify that the preferred form for modifications is the ttf files, then by all means, distribute them as source. But I would argue that is not the case. The README [0] states: The files with .sfd (Spline Font Database) are in PfaEdit's native format. Please use these if you plan to modify the font files. PfaEdit can export these to mostly any existing font file format. In fact, if you pay close attention to the file dates in the upstream archive, it appears freefont-ttf-20020306.tar.gz is the newest release for the TTF files, and freefont-sfd.tar.gz (dated 2003/02/19) is the newest release of the SFD files. Even upstream doesn't seem to release SFD files quite as often as TTF files. Excuse me? 2003 is sooner than 2002. I recommend that you immediately upload a package containing the source SFD files to satisfy our licensing obligations. You should use both http://savannah.nongnu.org/download/freefont/freefont-ttf.tar.gz and http://savannah.nongnu.org/download/freefont/freefont-sfd.tar.gz to construct the package. Well, I can do this but I would like an opinion from debian-legal before I haemorrhage archive space like this (this would triple the size of the source package from 1.2mb to more like 3.9mb). If you really thought this was the way to go, I guess I would instead Build-Depend on pfaedit and have to automate the generation of the TrueType fonts. It really doesn't matter to me how you do it. I don't know if pfaedit can create ttf files from the command line, though. As well, the debian/copyright notice does not actually specify the correct copyright statement. I suggest revising it thus: This needs to be fixed anyway. The notice of copyright is important. [0] http://savannah.nongnu.org/download/freefont/README -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgpxii2kl1FUo.pgp Description: PGP signature
Re: Bug#181969: ITP: jasper -- Image library for the JPEG-2000 Part 1 Standard
OF ANY OF SUCH PARTIES, BE LIABLE TO THE USER OR ANY OTHER PERSON FOR ANY INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF GOODWILL, WORK STOPPAGE, COMPUTER FAILURE OR MALFUNCTION, OR ANY AND ALL OTHER COMMERCIAL DAMAGES OR LOSSES, EVEN IF SUCH PARTY HAD BEEN INFORMED, OR OUGHT TO HAVE KNOWN, OF THE POSSIBILITY OF SUCH DAMAGES. THE JASPER SOFTWARE AND UNDERLYING TECHNOLOGY ARE NOT FAULT-TOLERANT AND ARE NOT DESIGNED, MANUFACTURED OR INTENDED FOR USE OR RESALE AS ON-LINE CONTROL EQUIPMENT IN HAZARDOUS ENVIRONMENTS REQUIRING FAIL-SAFE PERFORMANCE, SUCH AS IN THE OPERATION OF NUCLEAR FACILITIES, AIRCRAFT NAVIGATION OR COMMUNICATION SYSTEMS, AIR TRAFFIC CONTROL, DIRECT LIFE SUPPORT MACHINES, OR WEAPONS SYSTEMS, IN WHICH THE FAILURE OF THE JASPER SOFTWARE OR UNDERLYING TECHNOLOGY OR PRODUCT COULD LEAD DIRECTLY TO DEATH, PERSONAL INJURY, OR SEVERE PHYSICAL OR ENVIRONMENTAL DAMAGE (HIGH RISK ACTIVITIES). LICENSOR SPECIFICALLY DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY OF FITNESS FOR HIGH RISK ACTIVITIES. USER WILL NOT KNOWINGLY USE, DISTRIBUTE OR RESELL THE JASPER SOFTWARE OR UNDERLYING TECHNOLOGY OR PRODUCTS FOR HIGH RISK ACTIVITIES AND WILL ENSURE THAT ITS CUSTOMERS AND END-USERS OF ITS PRODUCTS ARE PROVIDED WITH A COPY OF THE NOTICE SPECIFIED IN THIS SECTION. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgpy3OELPTdMs.pgp Description: PGP signature
Re: acceptable restrictions on modification (was: proposed licence change for moodle)
On Sun, 2003-01-26 at 19:56, Branden Robinson wrote: On Wed, Jan 22, 2003 at 02:12:49PM -0500, David Turner wrote: [RMS doesn't make decisions for Debian...] As much feedback during the FSF's public comment period on GNU FDL 1.2 revealed, there are many people who disagree with his calculus. Indeed, and nobody is suggesting that Richard's word be accepted as gospel. I've written to the FSF's board about the FDL. Have you? On the other hand, I notice that the FDL'd glibc-doc, at least, is still in Debian main... See bug 171659. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgpVYkpSNOtuM.pgp Description: PGP signature
Re: OSD DFSG - different purposes
On Mon, Jan 27, 2003 at 01:26:39PM -0500, Russell Nelson wrote: Mark Rafn writes: It might be advantageous to examine some software that is OSD-free but not Debian-free, or vice versa, Does anybody know of any such software? Any software under this license[0] is non-free but is OSI Certified Open Source Software. I don't particularly remember why; you can search the archives, but the consensus was that it was non-free. We've found other such software, I think, but this was the most glaring, because several people were hoping that the license would be free (myself included). IANAL, IANADD. [0] http://www.opensource.org/licenses/real.php -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgpgOLj184Mv8.pgp Description: PGP signature
Re: OSD DFSG - different purposes
On Mon, Jan 27, 2003 at 03:24:20PM -0500, Russell Nelson wrote: Henning Makholm writes: This denies a user the right to make modifications and distribute the modified software (with source code) to his neighbour *without* also distributing it to the public at large. The consensus on debian-legal that this right is a sine qua non for DFSG-freedom is strong and well established. Where does it say this in the DFSG? Debian has a strong common law tradition with regard to the DFSG. We interpret it in certain ways to protect people's freedoms. You might say that this discriminates against people that are on desert islands. Note that vim's license is acceptable even though that clause is in there because it states that if it is not possible to contact the maintainer to return modifications then the requirement ceases. which I take to mean that one who accepts the license must effectively give Apple a royalty-free license to use each an every patent he controls. Where does it say this in the DFSG? I'm not sure, but it's certainly atrocious. You might want to search the archives or wait about a day or so for some of the regulars to debate with you over it. which mentions stopping *use*. We object to the notion that one needs to to comply with specific terms simply to use the software (as opposed to modifying or distributing it). Where does it say this in the DFSG? US copyright law explicitly permits use. We generally do not approve licenses that attempt to take rights that user already has. If you want to get technical, forbidding use of such software would be in conflict with US law, and therefore would discriminate against people in the US. My point being that these requirements *should* be in the DFSG, not that you shouldn't come to that conclusion. I seem to remember that there were also originally a you-must-follow-US-export-laws clause in the license originally certified by OSI, but that must have been removed since. Yup, that was a major screw-up on our part. It's since been repaired by the replacement of it by the license you see now. That discriminated against people not in the US. If I am not in the US (which I am), then why should I have to abide by its laws? -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgp6fjdrnI6El.pgp Description: PGP signature
Re: License of honeyd
On Tue, Dec 17, 2002 at 02:15:49PM +0100, Javier Fernández-Sanguino Peña wrote: I was thinking on packaging honeyd [1] a small daemon to simulate servers and create a virtual honeynet. I'm, however, not completely sure the license is DFSG-free. [ Old 4-clause BSD license ] I'm ok with 1, 2 and 4. But 3 (and advertisement clause) I'm not sure about. I've searched the list but havent't found any information on wether advertisement clauses are ok or not. The latest license mentioning an advertisement clause [2] wasn't turned down because of this. Should this go to non-free or free? This is free. It's the 4-clause BSD license. It is, however, GPL-incompatible, so if you're linking GPL software with it, that's not ok. I'm sure you know the drill. It's the same with OpenSSL. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgpDQLSYBzq6D.pgp Description: PGP signature
Re: License DSFG-free?
On Mon, Dec 02, 2002 at 09:25:43AM +0100, Christian Kurz wrote: according to my ITP on debian-devel and in the BTS, I'm going to package tinycdb. First the current license for this package: |This package is written by Michael Tokarev, based on ideas and API |found in cdb-0.75 package by D.J.Bernstein, http://cr.yp.to/cdb.html. | |You can do whatever you like with this package. The code is placed |at the public domain. Public domain is free. One manpage calls it something like the only true free. |This package is distributed in a hope it will be useful, but |WITHOUT ANY WARRANTY; without even the implied warranty of |MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. However, because a program that is in the public domain has no copyright (and can therefore have no license), you cannot technically disclaim warranty. Well, you can, but you do not have the option of saying, If you do not accept the fact there is no warranty, you cannot use the program, as in the GPL, MIT, BSD, Apache, or other licenses. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgpeqQVHIMw6A.pgp Description: PGP signature
Re: OpenSSL, SUN and ECC (patent issue)
On Thu, Oct 10, 2002 at 10:16:50PM +0300, Richard Braakman wrote: On Thu, Oct 10, 2002 at 04:59:50PM +0200, Toni Mueller wrote: [obnoxious clause] We've discussed it on this list already, but the remaining open question is, what patents do they have that they refer to here? If ECC is patent-encumbered, then I think it's a bad idea to include support for it, regardless of where the code comes from or what its license is. There are enough free algorithms available now so that we don't have to encourage use of non-free ones anymore. ECC itself is not patent encumbered, but the most popular curves are. These curves (mathematical equations, essentially) are patented by Certicom, not Sun. It's like patenting a (p, q) pair for DSA or Elgamal, except that these curves are ANSI standards, and so everyone uses them (even though some of them are obviously insecure). Anyone can create their own curves, however, so this is not an issue unless the ECC code includes parameters for those curves (which it probably does). The proper thing to do is for Debian versions to lock out patented curves, even if they are self-generated. If we do this, we have covered ourselves. Otherwise, we should remove the ECC code into non-US/non-free. -- Brian M. Carlson [EMAIL PROTECTED] http://decoy.wox.org/~bmc 0x560553E7 Fifty flippant frogs Walked by on flippered feet And with their slime they made the time Unnaturally fleet. pgpPalIeWuDiu.pgp Description: PGP signature
