Re: Packages containing RFCs
On Thu, Apr 27, 2006 at 04:59:07PM +0200, Frank K?ster wrote:
Simon Josefsson [EMAIL PROTECTED] wrote:
Justin Pryzby [EMAIL PROTECTED] writes:
I *swear* that one of the project documents said something highly
relevant, to the effect of nonfree material might be included in a
package in `main' if it is well-separated, and not required for the
operation of the package. I can't find it, so I'd appreciate it if
someone would point it out to me .. Anyway, I'm pretty sure that it
made explicit mention of RFCs and some humour files included with
emacs.
I think the humour files in emacs (that doesn't have a clear and free
license) are being removed, so perhaps that text has gone away.
Anyway, if someone knows about that text, it would be quite
interesting to see where it was written and why (if at all) it has
been changed.
Could it be that what Justin is looking for is actually a statement that:
Packages that contain *contrib* material which is well-separated and not
required for the operation of the package can go into main?
That one is true, I'm sure, although I can't give you a reference,
either.
Strange that nobody on this list knew where to find it:
http://people.debian.org/~bap/dfsg-faq.html
|# Q: Does the DFSG apply only to computer programs?
|A: No, we apply our standards of freedom to all parts of all software
|in Debian. This includes computer programs, documentation, images,
|sounds, etc. The text of licenses themselves in general need not be
|free, although legal wording itself is often not subject to copyright
|and hence effectively in the public domain. Although this is a
|subject of some controversy within the project, in practice sometimes
|tiny little snippets of non-free text, generally of historic or
|humorous or intellectual value, are included (eg
|/usr/share/emacs/21.3/etc/{JOKES,MOTIVATION}). These should not be
|integral parts of the package, nor included in a non-removable
|fashion, nor constitute functional parts of the package such as code
|or documentation. In general we would suggest avoiding such things,
|but you do not have to go to enormous trouble to find and root them
|out. In a similar vein, sometimes relevant scientific papers or
|technical reports of unclear copyright status are included; although
|they are not approved, of there has been no systematic effort to find
|and remove such manuscripts.
|We do not consider any of this a precedent for the inclusion of
|non-free code or documentation.
Though it doesn't specifically mention RFCs..
The emacs files still exist, BTW:
$ PKG MOTIVATION |grep -w MOTIVATION
usr/share/emacs/21.4/etc/MOTIVATION [17]editors/emacs21
usr/share/emacs/22.0.50/etc/MOTIVATION [18]editors/emacs-s
usr/share/xemacs-21.4.19/etc/MOTIVATION [21]editors/xemacs2
$ PKG JOKES |grep -w JOKES
usr/share/emacs/21.4/etc/JOKES [27]editors/emacs21
usr/share/emacs/22.0.50/etc/JOKES [28]editors/emacs-s
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages containing RFCs
On Wed, Apr 26, 2006 at 11:32:30AM +0200, Simon Josefsson wrote: Hi all! I just noticed that heimdal-docs contained copies of RFCs, which I believe are licensed under a non-free license, so I filed bug #364860. Then I looked at what other packages in testing may have the same problem, and the list below is what I found. It is not that large, and better than I would expect. Should we file bug reports for these packages, or is there a better way to handle this? What severity should I use? Some additional filtering should probably be done, some earlier RFC are (I believe) in the public domain. I *swear* that one of the project documents said something highly relevant, to the effect of nonfree material might be included in a package in `main' if it is well-separated, and not required for the operation of the package. I can't find it, so I'd appreciate it if someone would point it out to me .. Anyway, I'm pretty sure that it made explicit mention of RFCs and some humour files included with emacs. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BOLA licence (darcsweb): free or not?
On Sun, Jan 08, 2006 at 08:08:50PM +0100, Stephane Bortzmeyer wrote: It seems DFSG-free to me but who knows? I don't like licenses, because I don't like having to worry about all this legal stuff just for a simple piece of software I don't really mind anyone using. But I also believe that it's important that people share and give back; so I'm placing darcsweb under the following license, so you feel guilty if you don't ;) Uh oh, that may be a claim that not donating is immoral, unethical, illegal or something similar! http://www.debian.org/doc/debian-policy/ch-archive.html#s-pkgcopyright BOLA - Buena Onda License Agreement --- This work is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this work. To all effects and purposes, this work is to be considered Public Domain. Some would complain that this doesn't give explicit permission to modify and/or distribute, and the typical suggestion is to use either the MIT license (liberal) or GPLv2 (copyleft) as per preference. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFH: Non-free files in Emacs
celibacy.1 condom.1 -- Post-1988 (1992). Probably a better fit for the funny-manpages package than the emacs package. sex.6 -- Issued without copyright notice prior to 1988 (1987), so it's in the public domain. Modified since then, according to emacs CVS. In any case, more suited for the funny-manpages package than the emacs package. Actually they are there too, in section 1fun. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please comment on IBPP licensing
On Tue, Mar 07, 2006 at 08:40:16PM +0200, Damyan Ivanov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, The following license is used for IBPP[1] - a library for working with Firebird/Interbase database servers. This library is included (at source level) in FlameRobin[2] - a graphical tool for working with Firebird/Interbase which I intent to package. Flaberobin's license is not yet clear, but is expected to follow IBPP. Either way, I need your comments about DFSG-compatibility of IBPP license. Note that this license is newly accomodated after leaving MPL (partly due to me arguing against MPL), so the intent is to make it free. License can be found at [3], attached here for reference. My humble opinion is that it is almost DFSG-free. The only problem section is 3.1 (requires changes to be sent to upstream). Right, it fails the so-called desert island test. I also note the following spelling errors: functionnalities wether responsability* implicitely * (happens multiple times) Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: MIT License are DFSG complicant ?
On Mon, Feb 06, 2006 at 02:46:58PM -0200, José Carlos do Nascimento Medeiros wrote: Hi,, I have a package (php-netcheckip) that was MIT licensed. Debian suports this license ? This is the typical liberal license recommended by d-l. (Whereas the typical copyleft license is some incarnation of the GPL.) So yes, it is consistent with the dfsg. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#344707: ITP: ispell-et -- Estonian dictionaries for ispell, aspell, myspell
On Sun, Dec 25, 2005 at 01:05:44PM +1100, An?bal Monsalve Salazar wrote: On Sun, Dec 25, 2005 at 01:50:32AM +0200, Martin-?ric Racine wrote: Package: wnpp Severity: wishlist Owner: Martin-??ric Racine [EMAIL PROTECTED] Package name : ispell-et Version : 20030606 URL : http://www.meso.ee/~jjpp/speller/ aspell-et - Estonian dictionary for aspell iestonian - Estonian dictionary for ispell myspell-et - Estonian dictionary for myspell openoffice.org-hyphenation-et - Estonian hyphenation pattern for OpenOffice.org The ispell affix and wordlists, as well as the OOo hyphenation were found as standalone files at the above URL, along with explanations in Estonian about the origin of all files. Everything else is generated by my own debian/rules. The above version is timestamp of the last update produced by Jaak Pruulmann. I already have packages ready to upload. I however need to verify whether the software license of the Institute of the Estonian Language is considered free according to Debian policies, before I proceed with the upload. Copyright: 2003-2005, Jaak Pruulmann [EMAIL PROTECTED] (updated wordlist) 1996-1999, Institute of the Estonian Language [EMAIL PROTECTED] (original wordlist) 1993, Enn Saar [EMAIL PROTECTED] (TeX hyphenation, converted for OpenOffice by Jaak) License: The present Licence Agreement gives the user of this Software Product (hereinafter: Product) the right to use the Product for whatever purpose (incl. distribution, copying, altering, inclusion in other software, and selling) on the following conditions: 1. The present Licence Agreement should belong unaltered to each copy ever made of this Product; 2. Neither the Institute of the Estonian Language (hereinafter: IEL) nor the author(s) of the Product will take responsibility for any detriment, direct or indirect, possibly ensuing from the application of the Product; 3. The IEL is ready to share the Product with other users as we wish to advance research on the Estonian language and to promote the use of Estonian in IT-technology now rapidly developing, yet we refuse to bind ourselves to any further obligation, which means that the IEL is not obliged either to warrant the suitability of the Product for a concrete use, to improve the program, or to provide a more detailed description of the underlying algorithms. (Which does not mean, though, that we may not do it.) 4. Whenever you use the Product, we request that you inform us by writing to the e-mail address [EMAIL PROTECTED] or to street address listed below. Non-free clause. Every time you use it, you will have to send an email or a letter to them. Really? Isn't 'request' the phrase often recommended on -legal for such things? (though I understand that the license isn't the right place). -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a software with moving licence
On Wed, Dec 21, 2005 at 12:00:44PM +0100, Florent Bayle wrote: Hello, At http://www.vanheusden.com/unsort/ you can find a piece of software called unsort, which contains a file named licence.txt with the following contents : The license of this program can be obtained from: http://www.vanheusden.com/license.txt It is actually the GNU Public License. How could this be interpreted ? Does this means that the licence depends of the content of http://www.vanheusden.com/license.txt;, does that mean that the licence of this piece of software can change at any time (even for the same release) ? Is it possible to include it in Debian ? My personal feeling is that we shouldn't include it in Debian as is, because we can't be sure that the licence would remain the same over the time, and thus we couldn't guarantee that it will always remains free. My understanding is that once something is released under such a free license, its not possible to unrelease it. Someone who hypothetically gave me to right to modify+distribute their work can't well pretend to be able to undo that. In practice, I think its probably fine to deal with software that might do this, but, as always, its a bad position to make enemies, especially with the guy who's software you're using/packaging. It would be nice to have healthy communication with the upstream author, and would also be good to be able to demonstrate that, at one point, the contents of /licenese.txt was actually the GPL. Ideally, the source files would have the GPL header and disclaimer, or at least something to the effect of # This file is copyright (C) 2005 Justin Pryzby and released under the terms of the GPLv2 license. You might start by bringing this up with the author(s). -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DFSG compilance of display-dhammapada
On Wed, Dec 21, 2005 at 04:30:50PM +0100, Jakub Nadolny wrote: Hi, there is a package called display-dhammapada which includes some text in Polish language. This text is licensed as follows: This publication is not protected by copyright. One can freely copy it and use any of it's parts mentioning the source. Publishers ask only for information about it. (sorry if my english is not clear enough) I know this publisher and I can ask them to change this license if it is neccessary to do it. Should it be changed to be DFSG compilant? This phrase came up previously: http://lists.debian.org/debian-legal/2005/08/msg00156.html http://lists.debian.org/debian-legal/2005/03/msg00384.html (same package) I don't know what the last phrase is meant to mean publishers ask only for information about it. I agree with MJR's assessment that it is probably intended to discriminate against publishers. http://lists.debian.org/debian-legal/2005/08/msg00157.html Poli also has a point; no permission to modify (except for the claim of no copyright): http://lists.debian.org/debian-legal/2005/08/msg00161.html It would be good to contact the publisher, to ask for clarification. If it turns out that the license (or lack thereof) lacks freedoms required for inclusion into Debian, then you might discuss an alternate license with them (hopefully something which is already translated into English!). -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kleansweep, trademark issue and Debian
On Fri, Nov 25, 2005 at 10:57:31PM +0100, Claudio Moratti wrote: Hi! some weeks ago I sent a message about kleansweeb trademark issue... I recived one aswer (http://lists.debian.org/debian-legal/2005/10/msg00040.html)... thanks :D the problem is... I sent a request to upstream author, but he didn't do anything... Now, I've a open ITP (329020) about kleansweep, and I'd like to close it! I found these solutions: 1) ignoring trademark issue and send a RFS (i'm not a dd)... trademark issue is a 'author' problem, not a Debian problem, right? Yes, the problem exists upstream, but it also exists for Debian, I think, because whoever holds the relevant TM could (try to) hold us accountable. 2) patching the sources changing the name (kleaner for example...) This is a good possibility; then mention in ./debian/control and README.Debian that the name was changed to avoid the TM. 3) closing the bug without packaging the software... Unattractive option. which way do you advise to me? Why don't you keep an unapplied patch in ./debian/ which can be used to change the name? Then, if there is ever a problem, its trivial to fix. AIUI this is the kind of approach that might be taken with firefox.. The patch might be trivial; or, you might initially think that it is trivial, but then keep running into different instances of the TM name. So you might start with such a patch, however small and trivial, but maintain it as you discover hypothetical internal references to the name. I know little of trademarks, and about your specific one, but not packaging the software because of such a problem, when it could be worked around, is still unattrictive. -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: reimplementing mac boot block - reviewer needed
This is somewhat interesting to me, so you could include me in the mailing. I'm not sure that I'm technically competent to comment on it, but I'll try to be helpful :) Why can't you post the spec to a publically available address? You are concerned that it violates copyright? -- Clear skies, Justin On Sat, Nov 26, 2005 at 08:40:32PM +, Piotras wrote: Hi, Sven Luther and myself stared a project to reimplement boot block for Apple Macintosh. Publicly available documentation of the boot block does not contain all the necessary details, so we decided to do clean room implementation. I reverse-engineered the Apple boot block and prepared the specification. Now we are looking for volunteer to review it, before implementation starts. The specification is quite detailed and we would like to make sure it doesn't infringe Apple copyrights. I'll send the draft (about 3 pages) off-list to anyone ready to review it. After the review succeeds, I will mail it on debian-powerpc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed license for IETF Contributions
On Mon, Nov 21, 2005 at 09:39:34PM +0100, Francesco Poli wrote: On Mon, 21 Nov 2005 12:28:48 +0100 Simon Josefsson wrote: Btw, the latest revised license reads: c. The Contributor grants third parties the irrevocable right to copy, use and distribute the Contribution, with or without modification, in any medium, without royalty, provided that unauthorized redistributed modified works do not contain misleading author, version, name of work, or endorsement information. This specifically implies, for instance, that unauthorized redistributed modified works must not claim endorsement of the modified work by the IETF, IESG, IANA, IAB, ISOC, RFC Editor, or any similar organization, and remove any claims of status as an Internet Standard, e.g., by removing the RFC boilerplate. The IETF requests that any citation or excerpt of unmodified text reference the RFC or other document from which the text is derived. s/unauthorized redistributed/redistributed unofficial/ , I would say... The term unauthorized makes me think about a license violation, which is not what is meant here, IIUC. Agree; I considered suggesting not explicitly authorized. I would also suggest to remove the preface This specifically implies, for instance, that, and just use the additional don't imply endorsement phrase. -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Releasing SW under GPL
On Thu, Nov 17, 2005 at 12:12:53AM +0100, Svante Signell wrote: I'm about to release some SW I've been working on for some years under a GPL licence and have a few questions: - Which text to include in the files? Is the following OK? This looks good to me. * Author: xx yy * Copyright : xx yy, 2000-2005 * License : GNU GPLv2 or later * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation; * * * Revisions : 2005-11-16, xx yy, initial GPL release */ - In the top directory is a copy of the GPL text, like gpl.txt for GPLv2. - Should the same text be included in all files? *.c, *.h and various other files like Makefile, README, TODO, Changelog etc. Anything with creative content, including at least *.c. Some argue that *.h, at least for libraries, have no creative content, or are only API, and thus not copyrightable, but it can't hurt. *.h with static inline functions should include such a note, for sure. Nontrivial Makefiles also. I can't recall seeing a copyright statement in any README, TODO or Changelog, but it couldn't hurt. I think it is often assumed that these files are either not creative, or are under a license comparable to the code. Presumably anyone modifying the TODO file is working with upstream anyway.. - Which years should the Copyright cover: All years since the beginning of development (2000-2005) or the current year when the release is made (2005 and subsequent years)? For some code many revisions have been made, not even resembling the original code. All years during which nontrivial changes were made, or a date range including those years (right?). - What is the difference if I write 'GPLv2 or later' or just 'GPLv2'? Consequences when GPLv3 is released? Right; its a matter of whether you trust the FSF. Dynamically changing licenses are potentially bad.. - How to incorporate other peoples contributions, in the copyright statement and/or in the revision part? Just note when people make nontrivial contributions. It is probably best to make the note in the copyright header, as in Copyright (C) 2005 Justin Pryzby and Svante Signell, but it would also be good to note it near the relevent code, as in // This section contributed by Justin Pryzby (where this section is reasonably clearly defined). Of course other people have to agree to license their contributions in a matter consistent with your license. The idea is to make a code audit easy; grep -A4 -B4 -ir copyright can be done on a fairly large source tree without too much trouble, but its crazy disappointing if you later notice all sorts of stuff like This is copied almost verbatim from Foo by Bar..Numerical Recipes seems to turn up lots.. -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Releasing SW under GPL
On Wed, Nov 16, 2005 at 06:47:06PM -0500, pryzbyj wrote: On Thu, Nov 17, 2005 at 12:12:53AM +0100, Svante Signell wrote: The idea is to make a code audit easy; grep -A4 -B4 -ir copyright can be done on a fairly large source tree without too much trouble, but its crazy disappointing if you later notice all sorts of stuff like This is copied almost verbatim from Foo by Bar..Numerical Recipes seems to turn up lots.. Or where there are files without any such information, amidst other files derived from other files without any such information. Or, almost as bad, files which have had copyright headers mass-added in batch, by a third party. -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sourcecode with multiple licenses
On Tue, Nov 08, 2005 at 10:48:55PM +0100, Paul van Tilburg wrote: Hi all, I am package libfacets-ruby[1] for the Debian/Ruby Extras maintainers team. This package bundles of hundreds of small libraries useful as an extra for Ruby's standard library. The authors have all agreed to the bundling, however not everything is under the Ruby license yet, but they are trying to work towards that. Meanwhile, most of the lib files are under the Ruby license (a dual- licensing of Ruby's own and the GPL), but not all. I have read the thread about dual-licensing and other discussions on this list, however I am not sure what to put in the debian/copyright file. Dual licensing is easy, just say foo.c is published under both the RUBY license and the GPL. Multiple authors and licenses are more complicated, just 'cause you have to find them all and there's probably always one that you're missing.. I am currently packaging facets 0.7.2, which I am mirroring myself until I get around to tracking the rework done by the Calibre project. The upstream source is available at http://paul.luon.net/facets--0.7.2.tar.gz of which of most interest probably is the README file. I just put the README at http://justinpryzby.com/tmp/README.facets You'll want to list every copyright holder, and indicate on what files they hold copyright, and the name of the associated license. The best way of doing this depends on how the files are authors are distributed. Probably a 1st order approximation is one-author per file, with some files being written by the same author, so a natural representation is The following files are written by AUTHOR1 [and AUTHOR2]... and are published under the LICENSE: FILES. Then you'll want to include the license text for each license used (only once, preferably). -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dual licensing (was: Re: [no subject])
On Sat, Nov 05, 2005 at 06:47:03AM +1100, Andrew Donnellan wrote: On 11/5/05, Justin Pryzby [EMAIL PROTECTED] wrote: On Fri, Nov 04, 2005 at 06:28:02PM +1100, Andrew Donnellan wrote: On 11/4/05, Nathanael Nerode [EMAIL PROTECTED] wrote: Emmanuel Colbus wrote: My main concern about this was that such relicensed copies could have been considered not free, but undistributable, as the GPL is supposed to apply to software, not to documents. Any collection of bits is software. The GPL works very well for any collection of bits. Some people think that it, particularly the requirement for provision of source code and the nature of permission to distribute in forms other than source code, may have problems when applied to dead-tree printed material. This is easily dealt with by dual-licensing under the GPL and a printing-friendly license of your choice. Well actually no it doesn't solve the problem as you have to comply with both licenses when dual-licensing. Thats not what the phrase dual-licensing is typically used to mean. For example, a thing released under dual GPL/MIT license means that that thing is released under the GPL and under the MIT license. So if you want, you can use it under the terms of the MIT license. And, if you prefer, you can use it under the terms of the GPL license. I mean the *developer* must comply with both licenses, eg if you d/l under the GPL and MIT, then the developer must still put the written offer for source code and meet all the distribution requirements of the GPL, but anyone else can choose between the GPL and the MIT license. In opened software, We are all developers. In something like the proposed mozilla trilicensing scheme, the requirements are extremely loose; something to the effect of: You can do whatever you want, in any one of 3 different ways d/l == download? -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
dual licensing (was: Re: [no subject])
On Fri, Nov 04, 2005 at 06:28:02PM +1100, Andrew Donnellan wrote: On 11/4/05, Nathanael Nerode [EMAIL PROTECTED] wrote: Emmanuel Colbus wrote: My main concern about this was that such relicensed copies could have been considered not free, but undistributable, as the GPL is supposed to apply to software, not to documents. Any collection of bits is software. The GPL works very well for any collection of bits. Some people think that it, particularly the requirement for provision of source code and the nature of permission to distribute in forms other than source code, may have problems when applied to dead-tree printed material. This is easily dealt with by dual-licensing under the GPL and a printing-friendly license of your choice. Well actually no it doesn't solve the problem as you have to comply with both licenses when dual-licensing. Thats not what the phrase dual-licensing is typically used to mean. For example, a thing released under dual GPL/MIT license means that that thing is released under the GPL and under the MIT license. So if you want, you can use it under the terms of the MIT license. And, if you prefer, you can use it under the terms of the GPL license. You get to choose. Its like the gpl version 2 or later clause: at your option. -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dual licensing (was: Re: [no subject])
On Sat, Nov 05, 2005 at 08:50:13AM +1100, Andrew Donnellan wrote: The GPL is not a contract, but one clause states that there must be source code provided, so while a copyright holder can violate the GPL by releasing under a different license, but the copyright holder can't release under the GPL and at the same time violate the GPL. The idea is that the copyright holder doesn't need a license to do anything, so they can do whatever they want, including doing something which doesn't allow other people to do anything because of some inconsistency. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dual licensing
On Fri, Nov 04, 2005 at 10:20:14PM +0100, Henning Makholm wrote: Scripsit Andrew Donnellan [EMAIL PROTECTED] I mean the *developer* must comply with both licenses, eg if you d/l under the GPL and MIT, then the developer must still put the written offer for source code By developer, do you mean copyright holder? He can legally do whatever he pleases. In particular, he can offer the general public a licence under terms that he does not himself comply with. This is my favorite! Oh, wait, no, its better: http://justinpryzby.com/sla/ The fortran version is GPL, but the C source version is proprietary, but the obscured C source (*cough*) is GPL (actually, the GPL header may have been pasted there by a 3rd party to placate me). If I weren't on so many mailing lists I might be able to concentrate and figure out C/Fortran calling conventions to fix this.. -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dual licensing
On Fri, Nov 04, 2005 at 11:30:03PM -0600, Christofer C. Bell wrote: On 11/4/05, Henning Makholm [EMAIL PROTECTED] wrote: Scripsit Andrew Donnellan [EMAIL PROTECTED] I mean the *developer* must comply with both licenses, eg if you d/l under the GPL and MIT, then the developer must still put the written offer for source code By developer, do you mean copyright holder? He can legally do whatever he pleases. In particular, he can offer the general public a licence under terms that he does not himself comply with. Are you saying it's possible for a developer to release GPL covered software in binary form without releasing the source code as long as he's the copyright holder? That sounds awfully bizarre... That's my understanding. The copyright holder can do whatever they want. Yes, doing such a thing is bizarre, and I can't think of a reason why anyone would do it. It doesn't actually grant anyone else any modify+distribute rights, and is arguably suficiently inconsistent to not grant anyone any rights. But it could be done and I don't see that its illegal. If it is, just use a my interpretation of the GPL is that this is not illegal clause. :) Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Releasing software sponsored by an employer
On Wed, Nov 02, 2005 at 09:23:40PM +0100, Arnoud Engelfriet wrote: John Morrissey wrote: I'm wondering what kind of documentation we should have that explicitly authorizes me to release this software (copyright still held by the company) to the public under a DFSG compliant license. IMHO it would be very nice if they could give you a PGP message confirming what the GPL trailer has: Yoyodyne, Inc., hereby disclaims all copyright interest in the program `Gnomovision' (which makes passes at compilers) written by James Hacker. 1 April 1989 Ty Coon, President of Vice -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336982: dh-make: Difficulties with the debian/copyright template
Package: dh-make Version: 0.40 Severity: important File: debian/copyright The problem is with the template ./debian/copyright files created by /usr/bin/dh_make, not /u/s/d/dh-make/copyright. I'm Cc: debian-legal, and I checked the BTS documentation so its going to work right This Time. Please, add comments as necessary; I've tried to do my best to create a sane template, and to dicuss the present problems. Lots of people see and are affected by the dh_make templates, so I think lots of people should comment on changes there. Please keep in mind that lots of new developers will use the New Maint Guide, which essentially has as step 1, Run /usr/bin/dh_make. So it should be easy to understand, and intuitively clear how to do the right thing, even to someone who has no formal education in copyright law. I filed bug #286843: Please use 'Copyright Holder: boilerplate', and dh_make now does so. It looks like: Copyright Holder: put author(s) name and email here This has to include a copyright year, also. Please update the boilerplace to indicate that. Also, the copyright holder is not necessarily the author. This is necessary, I think, in the case that one tries to investigate the trail from authorship, through a list of people between whom copyright may have been transferrred. There is also an issue with the license boilerplace. Consider the developer who notices that their package is apparently (by cursory inspection of a ./COPYING file, or a header in the sources files) under the GPL license. They will be tempted to run: dh_make -c gpl. However, that will cause their packages' copyright file to include the version 2 or later clause, even if it wasn't present in the upstream sources! The same goes for the LGPL. In fact, with the LGPL, there is also the issue of s/package/program/ and s/library/lesser/. I think it is confusing and in bad form to include a modified distribution license covering another's work. Updating the FSF postal address should be okay IMHO. There is another annoyance; .. dh_make -c specifies the license. The -l option is taken by library package. To me, -c means copyright, but then the user is specifying -c gpl, and the gpl is not a copyright holder (which is the most of the motivation behind these bugs). The best solution I came up with involves removing the -c option, thusly removing any implied confusion between copyright and license. Then update the templates, which could become: Upstream Authors: template Include the names and contact addresses of all upstream authors; this is useful, for example, in the case that they need to be contacted regarding licensing issues. It might also make sense to include support addresses here. Example: Justin Pryzby [EMAIL PROTECTED] Support Address [EMAIL PROTECTED] Legal Issues [EMAIL PROTECTED] /template Copyright Statements: template Include the names of all copyright holders here. Also include the range of years during which they made contributions to the package. The copyright holder is not necessarily the same as the upstream author; employers usually hold the copyright on works for hire; other works are placed in the public domain by their authors, which means that copyright is relinquished; other times, copyright is transferred from the author to a publishing agent. All source files must be accounted for; oftentimes, multiple authors are involved in a given software package. You should at least look for evidence of this with a command like: grep -ir copyright . A typical copyright reference will look like: Copyright (C) 2005 Justin Pryzby [EMAIL PROTECTED] /template Distribution Licenses: template Include the licenses of all source files here. Oftentimes, there are multiple licenses involved in a single software package, and each msut be clearly documented. Be particularly careful of such things as the GPL version 2 or later clause; include that clause if and only if the upstream license includes it. /template Lintian should error on m/template/i; I have bug #286842 which is relevant. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#336982: dh-make: Difficulties with the debian/copyright template
I intended to add to the sections on copyright statements and distribution licenses the following text: This should be copied as nearly verbatim as possible from the upstream sources. On Tue, Nov 01, 2005 at 08:17:46PM -0500, Justin Pryzby wrote: Package: dh-make Version: 0.40 Severity: important File: debian/copyright -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: MySQL only useable for GPL clients?
On Tue, Oct 11, 2005 at 08:01:40PM +0200, Martin Koegler wrote: The newer MySQL client libraries are GPL (with the FLOSS exception), older versions were LGPL. So, if you base your non GPL program on the older version, you are in the clear. Right? :) Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL Binary
On Thu, Sep 22, 2005 at 10:16:00PM +0100, Jo?o Pinheiro wrote: A few days ago I developed a small C application which I'd like to distribute (source code included) to help university freshmen this year. The problem is that I'm using some routines and ADTs which I'm definitely going to need in other subjects in the future. Most teachers here have a really strict policy regarding similar pieces of code so I don't really want anyone to have access to those routines yet. The solution for this would be to release those routines in a compiled object file along with the source code for the application itself. Does the GPL allow me to do this or would I have to go with the BDS license for such a release? You, as the author, can do whatever you want. One who modifies the source code (which you aren't distributing) must make it available under the GPL. So, one cannot modify the source code. I don't see anything preventing you from doing this. You are concerned about students being accused of ripping off your code, no? Why don't you just put a header on it (say, the GPL header) with a URL pointing to the canonical online location of the code, and an explanation, targetted towards teachers, explaining that the code is freely available? Of course, teachers might also object to receiving code licensed under the GPL, but .. -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linuxsampler license
On Thu, Sep 15, 2005 at 12:45:41PM +0200, Jacobo Tarrio wrote: El jueves, 15 de septiembre de 2005 a las 13:07:18 +0300, George Danchev escrib?a: That is indeed non-free and fails DFSG #6, the package cannot be in main, but could be in non-free maybe. Probably not, according to some interpretations (the GPL does not allow Right, as explained in #12 h, i, j, k at: http://people.debian.org/~bap/dfsg-faq.html What I meant is that some believe that a piece covered by the GPL+additional restrictions, even if these restrictions were added by the author, is not distributable at all (by anyone other than the author). That's an interesting interpretation. The only such thing that I have heard is that licenses with restrictions not present in the GPL are GPL-incompatible, which makes this license (exception included) GPL-incompatible. I think this is still a consistent license, though perhaps difficult to interpret. Just that you couldn't link linuxsampler with GPL code (according to the FSF). Actually, isn't this sufficient to warrent removal, since linuxsampler is linked against libasound2? (Unless the authors of that code specifically indicate an alternate interpretation). Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems with ntp
On Thu, Sep 15, 2005 at 01:02:51AM +0200, Francesco Poli wrote: On Wed, 14 Sep 2005 00:03:36 -0700 Steve Langasek wrote: What are you going to replace it with? AFAIK, ntp is the only package we have in Debian which supports useful clock synchronization, which is essential for a number of other services (e.g., Kerberos). Isn't chrony a possible replacement? It conflicts with ntp, among other things... I don't think it implements algorithms as sophisticated as NTP does (well, I don't know anything about them, though). It probably conflicts with NTP simply because having two programs setting your clock is disgusting :) -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linuxsampler license
On Tue, Sep 13, 2005 at 05:54:35PM +0300, Harri J?rvi wrote: Hello, Linuxsampler is packaged in debian unstable. It would seem to me that Linuxsampler currently is not compatible with DFSG. Agree. Also it seems to me that Linuxsampler's authors wouldn't be allowed to make the kind of a restriction to the GPL as they do. The copyright holder can do whatever they want. However, its sometimes impossible to use the software in a way consistent with all of their license terms .. see, for example, recent threads on the PHP license, which is used by some software written in php, but not php itself. The php license implies that redistribution of the software includes PHP; but, it does not (well, it could, but it should not have to). So, Debian is taking the stance of we will not distribute this software, because the license is unclear or inconsistent, or just badly implemented (depending on your interpretation). The problem is that the README in linuxsampler says the following thing: This software is distributed under the GNU General Public License (see COPYING file), and may not be used in commercial applications without asking the authors for permission. The part after the comma makes it DFSG nonfree, because it is inconsistent with [0]: | 6. No Discrimination Against Fields of Endeavor | | The license must not restrict anyone from making use of the program in | a specific field of endeavor. For example, it may not restrict the | program from being used in a business The debian copyright-file only says: This software is distributed under the GNU General Public License (see COPYING file), and may not be used in commercial applications without asking the authors for permission. Thats a Debian packaging bug. In summary, I think there is a conflict between the copyright statement in the debian package and the copyright statement in the upstream linuxsampler readme (copyright statement). Debian package maintainer shouldn't have removed the part of the copyright/license statement that made the additional restrictions. Agree (but, it was probably a mistake; I think the GPL bit in ./debian/copyright was probably pasted there by dh_make). Also there seems to be a conflict between the GPL and the Linuxsampler's way to add restrictions. I don't think you are allowed to use GPL and make additional restrictions to it. The copyright holder is allowed to do whatever they want. (However, they are not allowed to modify the GPL; it disallows that). This license, as ammeded, is inconsistent, though. I don't think the upstream version would be DFSG if the restrictions would apply. Agree. I'm filing a grave bug now, hopefully with Cc: -legal the right way, this time. Either upstream needs to be contacted to rectify the situation, or the package needs to be removed. At present, the software can be unknowingly used by a Debian user in violation of the license terms, and that's a problem. Justin References [0] http://www.us.debian.org/social_contract -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linuxsampler license
On Tue, Sep 13, 2005 at 01:02:43PM -0400, pryzbyj wrote: On Tue, Sep 13, 2005 at 05:54:35PM +0300, Harri J?rvi wrote: Hello, Linuxsampler is packaged in debian unstable. It would seem to me that Linuxsampler currently is not compatible with DFSG. Agree. I'm filing a grave bug now, hopefully with Cc: -legal the right way, this time. Nope, I put it in the pseudoheader instead of the SMTP header. This is bug #328121. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Creating a Debtags 'license' facet
On Fri, Jun 10, 2005 at 03:32:14PM -0300, Humberto Massa Guimar?es wrote: * Andrew Suffield :: On Thu, Jun 09, 2005 at 12:17:42PM +0200, Enrico Zini wrote: On Fri, Jun 03, 2005 at 10:06:48PM +0100, Andrew Suffield wrote: On Fri, Jun 03, 2005 at 04:20:05PM +0200, Enrico Zini wrote: You've got a problem with this one, because licenses can be combined conjunctively and disjunctively. So a package might be both entirely under foo and entirely under bar (foo || bar), or it might be partially under foo and partially under bar (foo bar). If that is the only problem, a package can be tagged with more than one tag even from the same facet, which would be good enough to categorise your two examples. Imagine a package that can be distributed if you meet the terms of: - the GPL - both the MIT license and the 4-clause BSD license, simultaneously - both the MIT license and the Artistic license, simultaneously How would you tag this, so as to capture all this information? ( GPL ) || ( MIT 4BSD ) || ( MIT Artistic ) ?? :-) this is the easy one, what if some files are provided under each of those licenses? GPL + (MIT 4BSD) + (MIT Artistic)? Although it is not precise, it might help to have a multiple-license tag. Probably everything more fine-grained has to be manually reviewed, anyway. Just tag each package with every license which is somehow related to the license of that package, and hope that there aren't a bajillion libraries (which are probably the easiest use of this type of tagging: What libraries are compatible with the program I already have or want to have) which do a given thing which also match a semi-complicated license condition (like, !BSD !GPL). Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On Sun, Feb 27, 2005 at 10:50:13AM +0100, Andreas Barth wrote: * Justin Pryzby ([EMAIL PROTECTED]) [050225 22:35]: On Fri, Feb 25, 2005 at 04:23:07PM -0500, David Nusinow wrote: I'll see about taking a closer look at parts to see if it actually makes sense, but so far it looks fine to me. As it is, I don't see any difference between this and any other vendor not releasing hardware specs and yet a Free driver exists. Not a good thing, but not non-free either. Well put. I think it is arguably not source code, however, if the source we are seeing is the result of some sed-like script which converts a sort of custom #defined MAGIC_NUMBERs to id numbers, and then removes the #definitions. Is there some proof that the files are created that way, or is this just your assumptation? Not even an assumption, it was just a hypothetical wandering of my mind (as Don Armstrong said). I was still arguing with myself whether closed-specification was conflicting with open source software. My conclusion: it may be. I was thinking if I were to sit down right now and right a opened driver while actively withholding device details, how would I do it, and the conclusion was that I would have to actively obfuscate the code (make it less easy to modify), and would be possible with a bit of cpp or sed magic. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On Sat, Feb 26, 2005 at 03:10:47AM -0800, Ben Johnson wrote: Hi, Let us consider this: after all, maybe nv is not voluntarily rendered illegible, maybe I was plainly wrong saying so. The outcome of the investigations of the other posters will ascertain this. Obviously, what still strikes me is that, as points out Justin Pryzby, to prefer this coding style Mark Vojkovitch would have had to program the registers and the functions off the top of his head, which if there are many does not exactly sound the preferred means of writing source code. Correct me if I am mistaken. I think this implies enforcement of coding style, and I think its clear that it Wont Work. Vojkovitch defended his use of hardcoded values instead of #defined identifiers, and I can accept that the code is not obfuscated. OTOH, if there were reason to believe that the code was preprocessed (sed, cpp, ...) to a less-easily modifyable form, then the code is automatically not the preferred form for modifications. Even if NV declares that it is open source, and that the preprocessing is simply to protect the closed hardware specification. (I do not presently find such a reason; the code looks unobfuscated to me.) Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On Fri, Feb 25, 2005 at 03:47:32PM -0500, David Nusinow wrote: On Fri, Feb 25, 2005 at 03:25:48PM -0500, Glenn Maynard wrote: On Fri, Feb 25, 2005 at 12:02:50PM -0800, Ben Johnson wrote: Although the DFSG do not envisage the issue, the GPL does tackle it: The source code for a work means the preferred form of the work for making modifications to it. I am aware the DFSG !== the GPL, nevertheless the GPL is obviously as good a definition of free software as any, and whichever your sensibility, open-source or Obfuscated C code is obviously not source, by any sensible definition-- any definition of the word source code that results in obfuscated C code being called source is wrong. Since the GPL's definition of source is reasonable (in fact, it's one of the only robust definitions of the word that I'm aware of), it handles this. Obfuscated code does not satisfy DFSG#2. I hope nobody seriously disagrees with this. Let's not be so fast with this. I haven't taken a look at the driver source yet, but I think there's a big difference between obfuscating the source to your driver and not providing specs to your hardware. It seems, from reading Mike's mail, that the latter is more the case than the former. I'm not sure how I feel about that with respect to the DFSG, but since the hardware is not something that Debian distributes I'm currently leaning towards having it not affect the Freeness of the driver. Good point. Similarly, there is a difference between actively obfuscated source code (which isn't the preferred form of modification), and poorly written code. The latter, although you may prefer to not modify it, is arguably the preferred form of modification. Just because the code doesn't use #defines or enums doesn't necessarily make it obfuscated; it may just be that Vojkovich sees that as too indirect, and prefers to write outb(0x3241, 0x51) because he happens to know the port ID numbers and values off the top of his head. Is it *actively* obfuscated, or just not as clean as you would like? If it is actively obfuscated (has been run through a sed script to remove whitespace, or similar), then someone needs to ask nv for the real source. Is there someplace we can download the code (call it what you like) without also downloading the rest of X11? Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: prozilla: Nonfree
On Thu, Jan 13, 2005 at 04:13:50PM +, Henning Makholm wrote: Scripsit Justin Pryzby [EMAIL PROTECTED] Package: prozilla Version: 1:1.3.6-11 Severity: normal ftpparse.c heading: Commercial use is fine, if you let me know what programs you're using this in. Which I believes fails the desert-island test? Legal, can you confirm? Yes, if this is indeed a licence term. As quoted here it could also be a non-legal notice that the author considers commercial use without notification to be not fine (from a personal moral standpoint) but not necessarily an infringement of my copyright either. Could we have some more context, please? That is the entiretly of the file heading which pertains to copyright/license: /* ftpparse.c, ftpparse.h: library for parsing FTP LIST responses D. J. Bernstein, [EMAIL PROTECTED] 19970712 (doc updated 19970810) Commercial use is fine, if you let me know what programs you're using this in. Its probably ripped from another program. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
prozilla: Nonfree
Package: prozilla Version: 1:1.3.6-11 Severity: normal ftpparse.c heading: Commercial use is fine, if you let me know what programs you're using this in. Which I believes fails the desert-island test? Legal, can you confirm?
Re: prozilla: Nonfree
On Thu, Jan 13, 2005 at 04:13:50PM +, Henning Makholm wrote: Scripsit Justin Pryzby [EMAIL PROTECTED] Package: prozilla Version: 1:1.3.6-11 Severity: normal ftpparse.c heading: Commercial use is fine, if you let me know what programs you're using this in. Which I believes fails the desert-island test? Legal, can you confirm? Yes, if this is indeed a licence term. As quoted here it could also be a non-legal notice that the author considers commercial use without notification to be not fine (from a personal moral standpoint) but not necessarily an infringement of my copyright either. Could we have some more context, please? That is the entiretly of the file heading which pertains to copyright/license: /* ftpparse.c, ftpparse.h: library for parsing FTP LIST responses D. J. Bernstein, [EMAIL PROTECTED] 19970712 (doc updated 19970810) Commercial use is fine, if you let me know what programs you're using this in. Its probably ripped from another program. Justin
prozilla: Nonfree
Package: prozilla Version: 1:1.3.6-11 Severity: normal ftpparse.c heading: Commercial use is fine, if you let me know what programs you're using this in. Which I believes fails the desert-island test? Legal, can you confirm? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ReRegarding iraf
On Mon, Jan 10, 2005 at 11:35:07AM -0500, Glenn Maynard wrote:
On Mon, Jan 10, 2005 at 11:21:24AM -0500, Justin Pryzby wrote:
IRAF has a kind of custom government license which was previously
decided [0] to be free. IRAF wants to link with NCAR which is (now)
available under the GPL. Is that allowed, even though IRAF is not
GPL? IRAF is not a derivitive of NCAR, although the resulting
executable binaries would be, I guess. GPL seems to say so:
[...]
If that is the case, then it seems that I should consider creating a
complementary NCAR package (when you distribute them as separate
works), on which IRAF would have build and runtime dependencies (I
don't know if the upstream NCAR build intends for the libraries to be
shared .so files, or if they even intend for the libraries to be
installed on a runtime-only system, but no matter).
There's no need to split them up if you wouldn't otherwise. That's not
what the above clause is talking about.
It is maybe complicated than I let on; IRAF includes code from NCAR
1.00, but under a nonfree license. NCAR 4.X is GPL, and includes
mostly-minor differences (some bugfixes, I think, and some changes
that the IRAF group made). I contacted NCAR about making a statement
that 1.00 was available under the GPL, but thats an impossibility,
because they don't want the overhead of making source code available
and similar. So, I figure I'll package libncar-graphics, make IRAF
{,build-}depend on it, and include in the library any changes
necessary to make IRAF work (possibly as modifications to the code,
and possibly as separate routines).
Thanks,
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ReRegarding iraf
On Mon, Jan 10, 2005 at 12:25:11PM -0500, Glenn Maynard wrote:
On Mon, Jan 10, 2005 at 12:08:08PM -0500, Justin Pryzby wrote:
It is maybe complicated than I let on; IRAF includes code from NCAR
1.00, but under a nonfree license. NCAR 4.X is GPL, and includes
mostly-minor differences (some bugfixes, I think, and some changes
that the IRAF group made). I contacted NCAR about making a statement
that 1.00 was available under the GPL, but thats an impossibility,
because they don't want the overhead of making source code available
and similar. So, I figure I'll package libncar-graphics, make IRAF
{,build-}depend on it, and include in the library any changes
necessary to make IRAF work (possibly as modifications to the code,
and possibly as separate routines).
If IRAF contains non-free (or rather, GPL-incompatible code, or code
without source), you can't link GPL code against it, even through a
shared library. (I'm not sure if this is what you're suggesting;
if you're just eliminating the non-free code entirely, that's fine,
of course.)
IRAF contains code under a GPL-incompatible license. That code,
however, was relicensed with the GPL (with mostly-minor changes).
IRAF group does not intend to update the code (or, presumably, the
license).
I guess there is exactly one of two problems. IRAF contains nonfree
code. *Alternately*, IRAF needs to link with GPL code. You indicated
that the latter was less of a concern (depending on FSF approval,
contingent on IRAF being GPL compatible).
So, assuming that the *rest* of IRAF (excluding the NCAR graphics
library which it includes) is free, it seems okay.
The only other concern that I have is the nonfree yacc parser (my hope
is that it is no longer implemented as a derivation of yacc (C) 1970
Steven C. Johnson).
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ReRegarding iraf
DISregard for a moment that IRAF seems to include code from a nonfree yacc. IRAF has a kind of custom government license which was previously decided [0] to be free. IRAF wants to link with NCAR which is (now) available under the GPL. Is that allowed, even though IRAF is not GPL? IRAF is not a derivitive of NCAR, although the resulting executable binaries would be, I guess. GPL seems to say so: 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. [...] If that is the case, then it seems that I should consider creating a complementary NCAR package (when you distribute them as separate works), on which IRAF would have build and runtime dependencies (I don't know if the upstream NCAR build intends for the libraries to be shared .so files, or if they even intend for the libraries to be installed on a runtime-only system, but no matter). Justin References [0] http://lists.debian.org/debian-legal/2004/05/msg00338.html
Re: ReRegarding iraf
On Mon, Jan 10, 2005 at 11:35:07AM -0500, Glenn Maynard wrote:
On Mon, Jan 10, 2005 at 11:21:24AM -0500, Justin Pryzby wrote:
IRAF has a kind of custom government license which was previously
decided [0] to be free. IRAF wants to link with NCAR which is (now)
available under the GPL. Is that allowed, even though IRAF is not
GPL? IRAF is not a derivitive of NCAR, although the resulting
executable binaries would be, I guess. GPL seems to say so:
[...]
If that is the case, then it seems that I should consider creating a
complementary NCAR package (when you distribute them as separate
works), on which IRAF would have build and runtime dependencies (I
don't know if the upstream NCAR build intends for the libraries to be
shared .so files, or if they even intend for the libraries to be
installed on a runtime-only system, but no matter).
There's no need to split them up if you wouldn't otherwise. That's not
what the above clause is talking about.
It is maybe complicated than I let on; IRAF includes code from NCAR
1.00, but under a nonfree license. NCAR 4.X is GPL, and includes
mostly-minor differences (some bugfixes, I think, and some changes
that the IRAF group made). I contacted NCAR about making a statement
that 1.00 was available under the GPL, but thats an impossibility,
because they don't want the overhead of making source code available
and similar. So, I figure I'll package libncar-graphics, make IRAF
{,build-}depend on it, and include in the library any changes
necessary to make IRAF work (possibly as modifications to the code,
and possibly as separate routines).
Thanks,
Justin
ITP: libncar-graphics -- scientific visualization suite from UCAR
Package: wnpp Severity: wishlist * Package name: libncar-graphics Version : 4.4.0 and counting, quickly Upstream Author : UCAR, C/O Mary Haley * URL : http://ngwww.ucar.edu/ng/ * License : GPL2 Description : scientific visualization suite from UCAR Graphics and math libraries and utilities for data visualization. UCAR is University Corporation for Atmospheric Research. My interested in this package is restricted to the ability to link with the provided libraries, as necessary for my IRAF package. If someone else is interested in it, feel free to take over the ITP. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (101, 'testing'), (99, 'unstable'), (9, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.10Y Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Re: ReRegarding iraf
On Mon, Jan 10, 2005 at 11:35:07AM -0500, Glenn Maynard wrote: On Mon, Jan 10, 2005 at 11:21:24AM -0500, Justin Pryzby wrote: IRAF has a kind of custom government license which was previously decided [0] to be free. IRAF wants to link with NCAR which is (now) available under the GPL. Is that allowed, even though IRAF is not GPL? IRAF is not a derivitive of NCAR, although the resulting executable binaries would be, I guess. GPL seems to say so: You can always link GPL material with non-GPL material, so long as that other work is GPL-compatible. What defines GPL compatibility? Modify and distribute? Justin
Re: ReRegarding iraf
On Mon, Jan 10, 2005 at 12:25:11PM -0500, Glenn Maynard wrote:
On Mon, Jan 10, 2005 at 12:08:08PM -0500, Justin Pryzby wrote:
It is maybe complicated than I let on; IRAF includes code from NCAR
1.00, but under a nonfree license. NCAR 4.X is GPL, and includes
mostly-minor differences (some bugfixes, I think, and some changes
that the IRAF group made). I contacted NCAR about making a statement
that 1.00 was available under the GPL, but thats an impossibility,
because they don't want the overhead of making source code available
and similar. So, I figure I'll package libncar-graphics, make IRAF
{,build-}depend on it, and include in the library any changes
necessary to make IRAF work (possibly as modifications to the code,
and possibly as separate routines).
If IRAF contains non-free (or rather, GPL-incompatible code, or code
without source), you can't link GPL code against it, even through a
shared library. (I'm not sure if this is what you're suggesting;
if you're just eliminating the non-free code entirely, that's fine,
of course.)
IRAF contains code under a GPL-incompatible license. That code,
however, was relicensed with the GPL (with mostly-minor changes).
IRAF group does not intend to update the code (or, presumably, the
license).
I guess there is exactly one of two problems. IRAF contains nonfree
code. *Alternately*, IRAF needs to link with GPL code. You indicated
that the latter was less of a concern (depending on FSF approval,
contingent on IRAF being GPL compatible).
So, assuming that the *rest* of IRAF (excluding the NCAR graphics
library which it includes) is free, it seems okay.
The only other concern that I have is the nonfree yacc parser (my hope
is that it is no longer implemented as a derivation of yacc (C) 1970
Steven C. Johnson).
Justin
Re: IRAF component relicensed
On Tue, Dec 21, 2004 at 10:45:51AM +, Henning Makholm wrote: Scripsit Josh Triplett [EMAIL PROTECTED] One suggestion: you might be able to make the necessary modifications to BSD yacc, which I think descends from the original UNIX yacc by way of BSD UNIX and the whole ATT vs. BSD issue. In this particular case, the modifications consist of changing the output language from C to something else. That sounds fairly major; the entire parsing engine would have been hand-translated to the new language. Yup, its a pain, I give up.
IRAF component relicensed
Hello, As you may recall, I am (unofficially) maintaining the IRAF data analysis package. IRAF includes NCAR from UCAR (.. Atmospheric Research). It was previously decided [1] that the license from NCAR was very much not DFSG-free. However, the NCAR routines are now available under the GPL. I tried to contact them earlier this year (before I knew it was GPL'd, and possibly before it *was* GPL'd) and got no response. I've since been in contact with an NCAR representative. I asked if they would consider making a statement that version 1.00 of their code was available under the GPL (as well as the latest version: 4.3.1). Failing that, I have begun an audit of the NCAR code included in IRAF. I can delete the tests/ directory, as it is unused. That leaves about 100 files. Half of those differ (v1.00 and v4.3.1) solely in the copyright banner, and are, as such, effectively available under the GPL. As for the remaining files, I'm trying to classify the changes that are made. My goal is to include an explanation of every change in ./debian/copyright. Many of the changes are trivial: + a(b(c)); - a(c); or: + a(b(c)); - a(d(c)); or something like adding a single (trivial) line of code: + fflush(a); It is my understanding that if one understands the *algorithm* a piece of code uses, then one is free to reimplement (and relicense) that algorithm. I think it is clear that the *intent* of NCAR is to make their code GPL'd, and so I'm probably just being pedantic, but seems like a good best practice. Anyway, is this a reasonable course of action? If I explain each and every change between the 1.00 version included in IRAF and the GPL 4.3.1 version, (in english), then it should be clear that I understand what the changes *do*, functionally. And therefor I could implement the equivalent changes to the GPL version to obtain a GPL version equivalent to the IRAF version, but libre. (This also depends on my having the legal right to view the NCAR 1.00 source included in IRAF, which I think was not an issue. Based on replies to [1], the only issues were limits on redistribution). I will then, of course, evaluate the changes, and see if v4.3.1 offers any bugfixes over 1.00. If so, incorporate the changes in the Debian package (as a separate patch .. gotta learn to do that) and send the patches upstream, too. Thanks, -- Justin References [1] http://lists.debian.org/debian-legal/2004/05/msg00338.html
Re: IRAF component relicensed
By the way, I'm not subscribed, please Cc: me. What kind of license is associated with code produced by Yacc? Upstream IRAF apparently has a UNIX source license and uses a modified yacc to produce two of the files. The source includes a README: This directory contains the source for the Yacc compiler compiler (Stephen C. Johnson), as modified to produce SPP language parsers. You should have a UNIX source license to use this software on your machine. Normally, this code is compiled; however it does not appear to be necessary for further compilation or runtime. I could remove this code from the .orig. file, assuming that upstreams *output* is still free.. Iraf source is at: ftp://iraf.noao.edu/iraf/v212/PCIX/as.pcix.gen.gz Current NCAR code: http://ngwww.ucar.edu/ng/download.html Justin On Sun, Dec 19, 2004 at 12:45:37PM -0500, pryzbyj wrote: Hello,
Re: IRAF component relicensed
This is probably hotly debated, but how do math-algorthm copyrights work? There are lots of these: == ./iraf/math/llsq/original_f/qrbd.f == c subroutine qrbd (ipass,q,e,nn,v,mdv,nrv,c,mdc,ncc) c c.l.lawson and r.j.hanson, jet propulsion laboratory, 1973 jun 12 c to appear in 'solving least squares problems', prentice-hall, 1974 == ./iraf/math/ieee/d1mach.f == c c-- c function: d1mach c this routine is from the port mathematical subroutine library c it is described in the bell laboratories computing science c technical report #47 by p.a. fox, a.d. hall and n.l. schryer == ./iraf/math/bevington/pgauss.f == c function pgauss.f c c source c Bevington, page 45. == ./iraf/noao/digiphot/daophot/daolib/quick.f == c subroutine quick (dataum, n, index) c c c A quick-sorting algorithm suggested by the discussion on pages 114-119 c of THE ART OF COMPUTER PROGRAMMING, Vol. 3, SORTING AND SEARCHING, by c D.E. Knuth, which was referenced in Don Wells' subroutine QUIK. This c is my own attempt at encoding a quicksort-- PBS. On Sun, Dec 19, 2004 at 03:06:14PM -0500, pryzbyj wrote: By the way, I'm not subscribed, please Cc: me. What kind of license is associated with code produced by Yacc? Upstream IRAF apparently has a UNIX source license and uses a modified yacc to produce two of the files. The source includes a README: This directory contains the source for the Yacc compiler compiler (Stephen C. Johnson), as modified to produce SPP language parsers. You should have a UNIX source license to use this software on your machine. Normally, this code is compiled; however it does not appear to be necessary for further compilation or runtime. I could remove this code from the .orig. file, assuming that upstreams *output* is still free.. Iraf source is at: ftp://iraf.noao.edu/iraf/v212/PCIX/as.pcix.gen.gz Current NCAR code: http://ngwww.ucar.edu/ng/download.html Justin On Sun, Dec 19, 2004 at 12:45:37PM -0500, pryzbyj wrote: Hello, -- Justin aptitude install task-iraf saods9 eclipse sextractor x11iraf wcstools http://www.justinpryzby.com/debian/ References [1]
Re: IRAF component relicensed
On Sun, Dec 19, 2004 at 08:59:06PM -0800, Josh Triplett wrote: Justin Pryzby wrote: What kind of license is associated with code produced by Yacc? Presuming this modified yacc isn't trivially replaceable with a Free yacc, this would prevent these packages from being uploadable to main. I was afraid you'd say that. I wouldn't know what changes to make to a Free yacc without looking at a (nonfree) diff between IRAF's xyacc and UNIX yacc.. Normal compilation won't require rebuilding this file (as in, I never noticed before I considered the nonfreeness and checked). What about contrib? Depends on non-free component to build (from true source). Thanks, Justin
Re: IRAF package license
On Mon, May 10, 2004 at 03:59:01AM +, Henning Makholm wrote: Scripsit Justin Pryzby [EMAIL PROTECTED] 'Under new guidelines from the National Science Foundation, this NCAR software package is copyrighted and, therefore, not in the public domain. Distribution by NCAR does not include the right of the recipient or user to redistribute this software or to copy this software, except for one copy for archival purposes only. Oops. Very non-free, and, as it stands, not even distributable. Seems to me like I should write to UCAR, no? Hm, couldn't hurt, but the text quoted here does not indicate that they would be friendly towards releasing the software under a free license. If you can get a Debian-specific permission to distribute, it could go into non-free. I'll mail them today. The UCAR/NCAR routines are: Copyright (C) 1986 by UCAR and the LZW compression routine algorithm, which will be allowed in Debian main shortly has: Date of Patent: Dec. 10, 1985 Are the UCAR routines copyright of the type that will expire (this year?)? Justin signature.asc Description: Digital signature
IRAF package license
Greetings, I'm near completion of a Debian package of IRAF, previously packaged by Zed Paubre, who has agreed to sponsor me. I believe this new release has new license issues. Here's the deal. IRAF depends on TABLES (distributed separately, but TABLES depends on IRAF, so I'm preparing a new tarball to be the Debian .orig. There are other reasons, too.) TABLES has the following license: This software was prepared by Space Telescope Science Institute under U.S. Government contract NAS5-26555. Users shall not, without prior written permission of the U.S. Government, establish a claim to statutory copyright. The Government and others acting on its behalf, shall have a royalty-free, non-exclusive, irrevocable, worldwide license for Government purposes to publish, distribute, translate, copy, exhibit, and perform such material. And IRAF has: Copyright(c) 1986 Association of Universities for Research in Astronomy Inc. The IRAF software is publicly available, but is NOT in the public domain. The difference is that copyrights granting rights for unrestricted use and redistribution have been placed on all of the software to identify its authors. You are allowed and encouraged to take this software and use it as you wish, subject to the restrictions outlined below. Permission to use, copy, modify, and distribute this software and its documentation is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that references to the Association of Universities for Research in Astronomy Inc. (AURA), the National Optical Astronomy Observatories (NOAO), or the Image Reduction and Analysis Facility (IRAF) not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission from NOAO. NOAO makes no representations about the suitability of this software for any purpose. It is provided as is without express or implied warranty. NOAO DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL NOAO BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. NCARGRAPHICS Software Copyright Information The IRAF plot package includes four tasks (contour, surface, hafton, velvect) which call subroutines from the NCARGRAPHICS GKS-compatible graphics software package, version 1.0. The source for the NCARGRAPHICS software package has been modified for use within IRAF and is included on our source distribution tapes. Under new guidelines from the NSF, the NCARGRAPHICS software package is not in the public domain. We have been granted permission by UCAR to redistribute the NCARGRAPHICS software by agreeing to inform our users of the following terms and conditions. Under new guidelines from the National Science Foundation, this NCAR software package is copyrighted and, therefore, not in the public domain. Distribution by NCAR does not include the right of the recipient or user to redistribute this software or to copy this software, except for one copy for archival purposes only. Distribution is permitted only under agreement with the University Corporation for Atmospheric Research (UCAR). Requests for redistribution and/or copying of the software must be submitted in writing to: NCAR Contracts Office, Software Distribution, P.O. Box 3000, Boulder, CO 80307. We request that NCAR be acknowledged as the source of software used in any resulting research, publications, or sub-distributions. UCAR does not indemnify any infringement of copyright, patent or trademark through use or modification of this software. Seems to me like I should write to UCAR, no? Also, what defines who is acting on behalf of the goverment. Please Cc: me, Justin signature.asc Description: Digital signature
