Re: A new practical problem with invariant sections?
On Mon, Feb 13, 2006 at 05:19:32PM +1100, Craig Sanders wrote: On Sun, Feb 12, 2006 at 10:44:51PM -0600, Manoj Srivastava wrote: What if he wants to further distribute the stuff to other people who are using a device like his? I mean, sharing stuff useful to me is one of the prime reasons I like free software -- if stuff is useful, I can share. why are you obsessing with a convenience issue and pretending that it has ANY BEARING AT ALL on freedom issues? it doesn't. The text of Aj's proposal does something similar actually; (2.2) Transparent Copies The second conflict is related to the GFDL's requirements for transparent copies of documentation (that is, a copy of the documentation in a form suitable for editing). In particular, Section 3 of the GFDL requires that a transparent copy of the documentation be included with every opaque copy distributed, or that a transparent copy is made available for a year after the opaque copies are no longer being distributed. For free software works, Debian expects that simply providing the source (or transparent copy) alongside derivative works will be sufficient, but this does not satisfy either clause of the GFDL's requirements. That Debian expects that simply providing the source alongside ... does not appear to make this non-free. It might make be inconvenient for us and/or require us to change the ftp-master scripts, but that doesn't seem to affect its freeness. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A new practical problem with invariant sections?
On Mon, Feb 13, 2006 at 02:34:32AM -0600, Peter Samuelson wrote: [Hamish Moffatt] That Debian expects that simply providing the source alongside ... does not appear to make this non-free. It might make be inconvenient for us and/or require us to change the ftp-master scripts, but that doesn't seem to affect its freeness. One must remember, however, that while a mere convenience issue for our users may be a non-issue for Debian, a mere convenience issue that affects Debian directly is very relevant. Nothing in the SC or DFSG requires Debian to accept any software that comes along and adheres to the letter of the DFSG. As a hypothetical, if the software required Debian's FTP servers to keep the source available for 10 years, unconditionally, we'd probably refuse to ship that software on the grounds that that would be a PITA. Likewise, I think that FDL-licensed content may be DFSG-free, but considering the practical problems it causes us, we'd rather not ship any of it is a consistent and reasonable position to take. Indeed. However Aj's proposal actually argues that the transparent copies clause makes these documents non-free. That doesn't seem to be justified. I don't think Manoj's position statement document adds any additional justification either. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bittorrent licensing, take 2 [MPL and Jabber inside]
On Thu, Mar 31, 2005 at 12:35:03PM +, MJ Ray wrote: Josselin Mouette [EMAIL PROTECTED] wrote: Le mercredi 30 mars 2005 =E0 22:42 +, MJ Ray a =E9crit : Yes. We apologise and stop distributing things under licences with which the archive network can't comply, even if it's not a DFSG problem. That means stopping to distribute mozilla? That's a great pain. [...] Yes, that would suck. The fault would be a mix of MPL's drafters including conditions that they could have known debian didn't support yet and our confusion about the mozilla licence soup. Why would you expect the MPL's drafters to cater specifically to the behaviour of our archive software? Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#298195: ITP: tinywm -- Ridiculously tiny window manager
On Sun, Mar 06, 2005 at 12:05:52AM +, Andrew Suffield wrote: On Sun, Mar 06, 2005 at 01:17:50AM +0900, Nobuhiro Iwamatsu wrote: * Package name: tinywm Version : 1.2.0 Upstream Author : Nick Welch [EMAIL PROTECTED] * URL : http://incise.org/ * License : fair license [...] Usual example of why random people should not be writing licenses. Do upstream developers find our arrogance endearing? (Specifically yours.) How embarassing. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LCC and blobs
On Thu, Dec 30, 2004 at 03:09:52PM -0600, Gunnar Wolf wrote: The blobs for the in-kernel drivers are not to be executed by the host CPU itself, neither is the non-free ICQ, MSN or Yahoo servers (although Gaim can be seen useful by itself as it works with IRC and Jabber... Well, brain, please don't hijack my message ;-) ). They will be run on the other side of the abstraction (call it bus or network). The ROM for an Amiga, Atari or similar machine _does_ get used directly by your PC's CPU. Not really - it is data for the emulator program only. It is not executable on your host CPU, just like the text of the bible. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: LCC and blobs
On Tue, Dec 28, 2004 at 11:44:54AM -0500, Brian Thomas Sniffen wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: On Dec 28, Raul Miller [EMAIL PROTECTED] wrote: On Tue, Dec 28, 2004 at 04:26:26PM +1100, Hamish Moffatt wrote: Yet the ICQ client is not useful without a component which is not in Debian and in fact is not freely available. Same thing applies to hardware drivers. And, for that matter, all of the kernel. From this I conclude that the criteria you would like to use needs some more refining... No, only the criteria Hamish wants to use. He's using very different criteria from me or from Glenn -- I haven't managed to keep track of Raul's opinion here. To be honest, I'm not clear what your criteria are. Can you help me out? Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: LCC and blobs
On Sun, Dec 26, 2004 at 09:22:42PM -0500, Brian Thomas Sniffen wrote: Hamish Moffatt [EMAIL PROTECTED] writes: I think there are parallels with other software in Debian where we have not been so forgiving. We have a number of emulators for game consoles that are packaged and currently living in contrib eg uae, atari800. Those are generally placed in contrib because there's currently no free replacement for the ROMs they require. That seems comparable to Perl or any other interpreter: to be shipped in Free, at least one free program must exist. If such exist for the Atari 800 or whatever UAE emulates, then surely they can be moved to free. Yes, of course. So, we could technically distribute ROMs for atari800 if we found some that met the DFSG, and then we could move atari800 to main. We could technically distribute an ICQ server if we had one that met the DFSG, but we already distribute the client in main. Why? To tell the truth I've forgotten how this relates to the original topic. Such a CD-ROM is useful only by extracting software from it. This is very different from a typical hardware device, which is there for functionality. Sure, you could look at CDs or ROM chips as hardware, but they are methods of software transport. A video card is not, typically, such a method. OK, though in http://lists.debian.org/debian-devel/2004/12/msg02153.html you said thet the contents of EEPROMs were not software. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: LCC and blobs
On Mon, Dec 27, 2004 at 09:45:32PM -0500, Glenn Maynard wrote: Right: some emulators are fairly useless without some kind of image (eg. a BIOS image), just as some drivers are fairly useless without some kind of image (eg. a firmware blob). If all of the pieces were packaged, foo-driver would probably Depend on foo-driver-firmware, and a Playstation emulator might depend on psx-bios-image, but the icq client wouldn't depend on icq-server. (Not that policy's Depends: is necessarily equivalent to the SC's require in all cases, but it seems to line up here.) icq-client does require access to a server to be useful, but there's no expectation that that server be installable by the machine running the client; the lack of an icq-server package is not a piece missing from the client. Yet the ICQ client is not useful without a component which is not in Debian and in fact is not freely available. If the emulators were extended to be able to fetch some basic ROM images off the internet by themselves (eg via HTTP), could they go in main? Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: LCC and blobs
On Sat, Dec 25, 2004 at 04:08:38PM -0500, Brian Thomas Sniffen wrote: Hamish Moffatt [EMAIL PROTECTED] writes: Eh? The contents of EEPROMs are software just as much as the contents of CD-ROMs and hard disks. They are just different media for storing digital information. You can get software out of an firmware-EEPROM on a hardware device. I don't think it's appropriate to call that software as is, or in general. This line *could* be drawn in lots of places, but if you say that the contents of an EEPROM are software, then how about a one-shot PROM? How about a book with a print-out of the source code? The only reasonable place to draw the line, for Debian, is this: can Debian physically ship it in a useful way? For files on disk, the answer is yes. We are constrained only by the license. For the book or the PROM, the answer is no. For an EEPROM, in general, the answer is no. For any such correctly operating device, the firmware is already there. Debian can't usefully ship it. It would be interesting to try supporting an architecture to run on those devices instead of Wind River or whatever, but there isn't one now. I think you have an interesting definition but I wish that we could find a word other than software for it. We have overloaded that word too much already. Originally it meant computer programs; then it meant anything that isn't hardware. Now you're proposing that it is anything that Debian could distribute. As an aside, the anything that isn't hardware definition seems particularly poor. The general public would say that a CD-ROM contains software, but really a CD-ROM is just a piece of plastic with pits in it or not (ie all hardware). Similarly most people would say that a hard disk contains software, but really it just contains some metal platters with a magnetic field. A PROM contains an array of fuses, some of which have been blown. I don't think it contains software any more or less than a hard disk or a CD-ROM. The ICQ server isn't distributed in Debian, so why aren't the clients in contrib? This is an excellent parallel to the firmware situation. The ICQ clients don't depend on the ICQ server software. They depend on a compliant server. It might be a general-purpose computer running non-free software. It might be a specific hardware device. It might be a very fast monkey with a set of switches on an Ethernet cord. It could be anything. This is an abstraction barrier. It would be *nice* to have a free ICQ server-software in Debian. I think there are parallels with other software in Debian where we have not been so forgiving. We have a number of emulators for game consoles that are packaged and currently living in contrib eg uae, atari800. Those are generally placed in contrib because there's currently no free replacement for the ROMs they require. There's an abstraction barrier there too: the hardware/software interface. As we don't have any free software, the hardware (emulator) can't be in main. You can't use the emulator software without additional components from outside of Debian. So you say that the ICQ client depends on components from outside of Debian that are not necessarily software. Well, what if a user has a CD-ROM (or an EEPROM?) full of ROMs for use with atari800; shouldn't atari800 be in main then since many ICQ clients are? Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: LCC and blobs
On Thu, Dec 23, 2004 at 10:55:04PM -0500, Brian Thomas Sniffen wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: Great. Then the driver operates differently depending on the presence of additional software -- it needs a Linux kernel and the firmware. But then drivers also depend on additional softwares stored in flash EEPROMs in devices. That's not software. That's firmware, at best -- you can look at it as software, but then you don't get to distribute any drivers. It is also internally consistent to think of chips as hardware and distribute drivers appropriately. It is never consistent to think of files on disk as anything but software. Eh? The contents of EEPROMs are software just as much as the contents of CD-ROMs and hard disks. They are just different media for storing digital information. So if EEPROMs contain software, why don't [you] get to distribute any drivers? I don't understand. Without either of those, it does not operate. This is a dependency. But then ICQ clients depend on non-free ICQ servers... Which might be software or hardware or undistributed or all sorts of things. The ICQ server isn't distributed in Debian, so why aren't the clients in contrib? Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Are BLOBs source code?
On Sun, Dec 12, 2004 at 09:17:05PM +0100, Marco d'Itri wrote: On Dec 12, Bruce Perens [EMAIL PROTECTED] wrote: A lot of these BLOBs have been identified as ARM7 code, and generally thumb (the 8-bit ARM instructions). I know of some devices (very cheap stuff, nothing fancy) which even uses VxWorks. This explains why it is not even possible for some manufacturers to open the firmwares for their devices. Hard to believe that anything cheap could contain VxWorks :-| Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Reproducible, precompiled .o files: what say policy+gpl?
On Mon, Oct 18, 2004 at 10:24:44PM -0400, Glenn Maynard wrote: On Mon, Oct 18, 2004 at 06:28:01PM -0700, John H. Robinson, IV wrote: Note the exact words (I am assuming that Glenn copied them verbatim): the package in main must be buildable with tools in main Exact words are: In addition, the packages in _main_ * must not require a package outside of _main_ for compilation or execution (thus, the package must not declare a Depends, Recommends, or Build-Depends relationship on a non-_main_ package), If you build with different tools, you have a different package. X That's true if you define a package as an exact .deb, but not if you define it as a source package (.orig.tar.gz/.diff.gz/.dsc). The latter seems to be a more useful definition in the context of compilation, IMHO. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: license check for tqsllib
On Mon, Oct 20, 2003 at 10:16:09AM -0600, Joel Baker wrote: I find that, as a general rule, only very large institutions (which are always wary of license changes) and less than open-minded individuals (with whom it is difficult to discuss any such change reasonably) are actively against such requests, when the problems are laid out and they are told this is actually an issue for us, not just theoretical. Good news: I emailed the upstream authors today and heard back within hours that they've agreed to remove the advertising clause for this software. As soon as I can get the updated license file from CVS I'll be uploading. Thanks all, Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
On Sun, Jan 06, 2002 at 01:39:29PM -0800, Thomas Bushnell, BSG wrote: No. It has always been understood by the GNU Project that using kernel syscalls does not make something one program; the fact that Linus mentions that explicitly doesn't change the fact one whit. How is the GNU Project's understanding relevant when they did not write the Linux kernel? Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
On Sun, Jan 06, 2002 at 07:30:19AM -0800, [EMAIL PROTECTED] wrote: different. The kernel is not strictly GPL'd, but GPL-compatible. That clause that says system calls are a-ok, supports the moral/legal intention of the GPL by requiring such a declariation to be explicit. Correct? No. The kernel is GPLed with the clarification that user-space programs running on the kernel don't combine to be considered a derived work by the kernel. See /path/to/kernel/src/COPYING. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
On Thu, Jan 03, 2002 at 06:45:50PM -0800, Thomas Bushnell, BSG wrote: [EMAIL PROTECTED] writes: I do not really understand why, I guess accepting it in the definition of derivative work is the basis, but I cannot help, but wonder as I have not seen legal challanges that support this. It's a perfectly normal case of a derivative work. When you link program A with program B, you are creating a derivative work, A+B. You can only distribute that work if the licenses of A and B permit it. Don't dismiss this as completely obvious. It's not uncontroversial. For example, the kernel is GPLed but will load and run programs with incompatible licenses. Those programs make syscalls to the kernel to perform system work; how is this permitted? It is so different from an incompatibly-licensed program linking to a GPLed library? The ldso license is interesting (/usr/doc/ldso/copyright, possibly only on potato or earlier systems). The commentary implies that ld.so deliberately uses the BSD license because the GPL is too strict. It also has the following paragraph: * It is the general understanding of the above contributors that a * program executable linked to a library containing code that falls * under the GPL or GLPL style of license is not subject to the terms of * the GPL or GLPL license if the program executable(s) that are supplied * are linked to a shared library form of the GPL or GLPL library, and as * long as the form of the shared library is such that it is possible for * the end user to modify and rebuild the library and use it in * conjunction with the program executable. This seems to suggest that a program linking to a GPLed library does not have to be GPLed itself. Interesting that the ld.so license avoids being GPLed anyway to avoid this exact problem. Tcl can dynamically load shared libraries so that scripts can use library functions. tcl itself appears to have a BSD-type license. What if a tcl script, using a non-GPL compatible license, causes tcl to load a GPL library (eg libreadline)? The script is being interpreted by the Tcl shell, it's not capable of being linked to anything itself. libterm-readline-gnu-perl is a package of a Perl module to use libreadline from Perl progams. According to the license, it's available under the same terms as Perl ie your choice of GPL or the Artistic license. But since any combination of GPL program + a GPL-compatibly-licensed program must by GPLed, you really can't use it under the Artistic license at all ie the GPL always dominates. So non-GPL programs apparently can't use that library. Getting off-topic a bit, there's an interesting clause in the license for libio, in /usr/doc/libc6/copyright (on potato anyway). As a special exception, if you link this library with files compiled with a GNU compiler to produce an executable, this does not cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public License. Why does the license require you to use a GNU compiler? Bizarre. Just some thoughts, Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license
On Thu, Jan 03, 2002 at 10:43:48PM -0800, Thomas Bushnell, BSG wrote: [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: Yes, it is different. One is a program making callouts to a different entity, the kernel. The case we were talking about is that of library linking. I should add here that it is relevant that the callouts to the kernel are callouts to an interface which is defined as not making things a combined derived work, which is not normally the case for a library. It is relevant and important here that the authors of the kernel intend that understanding of those callouts. What is the definition of a callout? Why is it so different to a published library function? Apart from convenience of argument, that is. You dismissed my Tcl example without comment but I don't see how it is different to the kernel case. A non-free program running in the Tcl interpreter can have the Tcl interpreter load a GPLed library such as libreadline. The non-free program is not linked to the library. So why is this illegal? Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: mpsql - why is it non-free?
On Tue, Dec 25, 2001 at 09:39:36PM -0700, Chris Tillman wrote: Permission to use, copy, modify, and distribute this software and its documentation for any purpose, without fee, and without a written agreement is hereby granted, provided that the above copyright notice and this paragraph and the following two paragraphs appear in all copies. The license doesn't say you can distribute modified versions, though. Perhaps that's why it's in non-free? There might be something else which I missed too though. Hmaish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: mplayer / divx
On Wed, Aug 29, 2001 at 01:02:50AM -0400, Brian Ristuccia wrote: Additionally, it's still unclear if instructions (computer or not) explaining how to perform a patented process are capable of being restricted by a patent. Traditionally, patents have applied only to building/performing the invention, not to writing code or books about how to make/do it. In the past, Debian has allowed source code which explains how to perform patented processes such as LZW encoding to be distributed from non-US. Isn't that only because those patents (in particular LZW) don't apply outside of the US? Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
GPL linking question
Hi all, A question about linking non-free programs to GPL; specifically, about what 'linking' specifically means. I'm specifically referring to a (hypothetical) program which requires the mysql server. The mysql server is GPL. The proprietary program implements its own mysql client to connect to the server; it doesn't link against the mysql client code (which is also GPL). The mysql.com web site says you require a commercial license for the mysql server (ie you cannot use it under the GPL) if (among other reasons): You have a commercial application that ONLY works with MySQL and ships the application with the MySQL server. This is because we view this as linking even if it is done over the network. Is that a fair definition of linking? (Note that the above clause is only on the web site, and isn't actually added to the GPL they use for the mysql server software itself.) The GPL FAQ seems to imply that if you keep the proprietary and GPL components at arm's length, like a compiler and the kernel, or an editor and the shell, that's OK. See http://www.gnu.org/copyleft/gpl-faq.html#GPLInProprietarySystem What if the application bundled MySQL but could also connect to other SQL servers, such as Oracle or MS SQL? thanks Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: GPL linking question
On Fri, Jul 27, 2001 at 09:37:18PM -0400, Raul Miller wrote: [2] in general, the difference between a network connection and a cpu bus is only of interest to a technical person. And even there, it's perfectly reasonable (e.g. beowulf clusters) to design programs which are spread out over a network. [3] while the GPL's distribution restrictions might apply to the distribution of an sql application, they aren't relevant if that application is never distributed. The application is to be distributed (sold) under a proprietary license. I suppose an application is linked to the database server a bit more than a compiler/kernel or an editor/shell as in the GPL FAQ's examples. Sounds like this would be in breech of the GPL? Thanks. hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: GPL linking question
On Fri, Jul 27, 2001 at 10:03:07PM -0400, Raul Miller wrote: On Sat, Jul 28, 2001 at 11:52:46AM +1000, Hamish Moffatt wrote: The application is to be distributed (sold) under a proprietary license. I suppose an application is linked to the database server a bit more than a compiler/kernel or an editor/shell as in the GPL FAQ's examples. Sounds like this would be in breech of the GPL? If the application requires GPLed code, then yes. Requires in any sense? The app could use other SQL databases, but would be bundled with MySQL and that would be the default (and what most end users would use). Thanks, Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
license check
Are there any problems with this license (ie is it DFSG-free)? Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 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. The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission. 4. Redistribution of source code must be conform with the 'libpcap' copyright conditions, if that library is included. THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. The libpcap license mentioned appears to be the BSD one: .\ Copyright (c) 1994, 1996, 1997 .\ The Regents of the University of California. All rights reserved. .\ .\ Redistribution and use in source and binary forms, with or without .\ modification, are permitted provided that: (1) source code distributions .\ retain the above copyright notice and this paragraph in its entirety, (2) .\ distributions including binary code include the above copyright notice and .\ this paragraph in its entirety in the documentation or other materials .\ provided with the distribution, and (3) all advertising materials mentioning.\ features or use of this software display the following acknowledgement: .\ ``This product includes software developed by the University of California, .\ Lawrence Berkeley Laboratory and its contributors.'' Neither the name of .\ the University nor the names of its contributors may be used to endorse .\ or promote products derived from this software without specific prior .\ written permission. .\ THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED .\ WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF .\ MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. .\ Thanks, Hamish (please CC me as I do not subscribe to debian-legal) -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome.
license query
(I'm not subscribed to this list, so please cc any replies to me). Just a quick license query; * Permission to use, copy, modify, and distribute this software and * * its documentation for any purpose and without fee is hereby * * granted, provided that the above copyright notice appears in all* * copies that both the copyright notice and this permission * * notice appear in supporting documentation, and that the name* * University of Delaware not be used in advertising or publicity * * pertaining to distribution of the software without specific,* * written prior permission. The University of Delaware makes no * * representations about the suitability this software for any * * purpose. It is provided as is without express or implied * * warranty. * I think the only problem is that it's not clear if the program can be distributed as part of collection which IS charged for (ie debian CDs). I've contacted the author. Are there any other problems with this? I'll have to check that we can distribute modified versions too. thanks, Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: license query
On Mon, Jan 25, 1999 at 09:54:12PM -0600, John Hasler wrote: Hamish Moffatt quotes: * Permission to use, copy, modify, and distribute this software and * * its documentation for any purpose and without fee is hereby * * granted,... I think the only problem is that it's not clear if the program can be distributed as part of collection which IS charged for... Perhaps they meant that you need not pay a fee to them, but I can easily read it as you may not charge a fee. That's a possibility too. I assumed the latter, but the former is valid. I'll have to check that we can distribute modified versions too. It does say use, copy, modify, and distribute. Since the unrestricted right to copy includes the right to make partial copies, that should suffice. So you think it may be just fine as-is? thanks, Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: license query
On Tue, Jan 26, 1999 at 10:50:21AM -0600, John Hasler wrote: I wrote: It does say use, copy, modify, and distribute. Since the unrestricted right to copy includes the right to make partial copies, that should suffice. Hamish Moffatt writes: So you think it may be just fine as-is? I think that the use, copy, modify, and distribute part is ok as-is, but I would like to see and without fee clarified. The author has since clarified that you may charge as much as you want, as long as the copyright message appears. Looks good to me. thanks, Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: More problems for non-US?
On Fri, Dec 04, 1998 at 10:50:57AM -0600, [EMAIL PROTECTED] wrote: Sven LUTHER wrote: What are the legalities involved in doing cryptography over telnet from a country where crypto is outlawed but on a computer who is in crypto-free country ? Joost writes: AFAIK, this is a problem for people from the United States,... I can see no reason why it would not be perfectly legal to telnet to a foreign host from the US and run a crypto program there. The program isn't crossing the US border. Using it should be okay (because using it inside the US is okay). But it wouldn't be legal (probably) for someone in France to telnet elsewhere to do encryption. Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
