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 AT&T 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.
Re: IRAF component relicensed
Scripsit Andrew Suffield <[EMAIL PROTECTED]> > On Tue, Dec 21, 2004 at 10:45:51AM +, Henning Makholm wrote >> 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. > It's probably not that hard. I wasn't saying it was hard. "Major" is an orthogonal dimension. > The manner in which a yacc-generated parser operates is not obvious > to somebody who does not understand it, but it really isn't > complicated. That doesn't prevent replacing it (and the various constant-generating parts of the generator proper) from being a relatively major change to the parser generator. -- Henning Makholm "Han råber og skriger, vakler ud på kørebanen og ind på fortorvet igen, hæver knytnæven mod en bil, hilser overmådigt venligt på en mor med barn, bryder ud i sang og stiller sig til sidst op og pisser i en port."
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 AT&T 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. It's probably not that hard. The manner in which a yacc-generated parser operates is not obvious to somebody who does not understand it, but it really isn't complicated. I'd be surprised if it was more than a day's work. The hardest part is probably figuring out what they actually did, so as to create something compatible. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: IRAF component relicensed
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 AT&T 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. -- Henning Makholm "Al lykken er i ét ord: Overvægtig!"
Re: IRAF component relicensed
Justin Pryzby wrote: > 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.. Right; to do such reimplementation safely typically requires one person to read the non-free source and document, and another person who has never seen the non-free source to implement the Free version based on the documentation. > 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). No, because the yacc output itself contains portions of the non-free UNIX yacc code (specifically, the parser). 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 AT&T vs. BSD issue. Unless it has been drastically rewritten, its internal structure is probably far closer to what the IRAF team used as a basis for their modified yacc. - Josh Triplett signature.asc Description: OpenPGP digital signature
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 component relicensed
Justin Pryzby wrote: > What kind of license is associated with code produced by Yacc? Well, code produced by yacc is derivative both of the yacc input file and the yacc parser being used. > 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. This means that 1) the yacc implementation isn't Free, and 2) the yacc output isn't free either. > 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.. No, the output isn't free either. Furthermore, even if it were, it wouldn't be source, and the source (the yacc input file) wouldn't be compilable into the output file without this non-free yacc. It isn't acceptable to have compiled files in the .orig.tar.gz in lieu of being able to compile from source. Normally, it would be acceptable to have yacc-produced parsers in the .orig.tar.gz (presuming upstream shipped them), along with the yacc source. However, since it sounds like this modified yacc is based on a non-free yacc implementation, that won't work here. Presuming this modified yacc isn't trivially replaceable with a Free yacc, this would prevent these packages from being uploadable to main. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: IRAF component relicensed
On Sun, Dec 19, 2004 at 11:29:47PM +0100, Måns Rullgård wrote: > And this is probably the reason we have thousands of (probably > invalid) software patents instead. Copyright law is only a minor part of that issue. -- Raul
Re: IRAF component relicensed
Raul Miller <[EMAIL PROTECTED]> writes: > On Sun, Dec 19, 2004 at 03:45:40PM -0500, Justin Pryzby wrote: >> This is probably hotly debated, but how do math-algorthm copyrights >> work? > > Articles about mathematics, and specific expressions of algorithms, > are copyrightable, but the concepts aren't. > > In the U.S. 17 USC 102 states: > >In no case does copyright protection for an original work of authorship >extend to any idea, procedure, process, system, method of operation, >concept, principle, or discovery, regardless of the form in which it >is described, explained, illustrated, or embodied in such work. > > In international law, article 2 of the Berne convention states: > >It shall, however, be a matter for legislation in the countries of the >Union to prescribe that works in general or any specified categories >of works shall not be protected unless they have been fixed in some >material form. > > Which I think meant that the rules could vary from country to country. > However, WIPO has since come out and stated (in article 2 of the treaty): > >Copyright protection extends to expressions and not to ideas, >procedures, methods of operation or mathematical concepts as such. > > Is that clear enough? And this is probably the reason we have thousands of (probably invalid) software patents instead. -- Måns Rullgård [EMAIL PROTECTED]
Re: IRAF component relicensed
On Sun, Dec 19, 2004 at 03:45:40PM -0500, Justin Pryzby wrote: > This is probably hotly debated, but how do math-algorthm copyrights > work? Articles about mathematics, and specific expressions of algorithms, are copyrightable, but the concepts aren't. In the U.S. 17 USC 102 states: In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work. In international law, article 2 of the Berne convention states: It shall, however, be a matter for legislation in the countries of the Union to prescribe that works in general or any specified categories of works shall not be protected unless they have been fixed in some material form. Which I think meant that the rules could vary from country to country. However, WIPO has since come out and stated (in article 2 of the treaty): Copyright protection extends to expressions and not to ideas, procedures, methods of operation or mathematical concepts as such. Is that clear enough? -- Raul
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
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,
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
