Alan, My reading of the bug report was different to yours. There are a number of files (e.g. examples which contain licenses different to the LGPL. The debian/copyright file is supposed to contain mention of ALL licenses which are applied to any part of the software. Some (but not all) of the examples are GPL rather than LGPL.
The issue with the copyright of the doxygen .js files will be avoided as I am repackaging the plplot source for debian without this pre-generated code. The reason is that Debian won't allow shipping of obfuscated source code as it is in breach of the Debian free software guidelines. I don't currently include them in the binary packages as I'm not quite sure they are ready for prime time. When I do I can just regenerate it all anyway, which is fine. Andrew On Wed, Sep 17, 2014 at 02:59:48PM -0700, Alan Irwin wrote: > As I have made clear in a response at > <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761057>, I think > this Debian packaging bug concerning a very minor PLplot licensing > issue is trivially easy to answer with a non-controversial change to > our Copyright file that all files in the source tree which are not > explicitly mentioned as having non-LGPL licensing in the Copyright > file have the LGPL copyright terms that are explicitly mentioned in > that file.) (Yeah, I know it is obvious, but some tweak to the wording > like that is probably necessary to prevent more "licensing police" > style bug reports that PLplot packagers have to put up with.) Anyhow, > I have asked Andrew to deal with that wording tweak since he probably > is most aware of the correct LGPL-style wording to use to deal with > this default case. > > It likely has nothing to do with the bug report, but the bug reporter > did have some plausible points about missing explicit licensing terms > for the man pages and generated doxgyen files which is definitely not > an ideal situation. The former are Rafael Laboissiere's business > since he wrote those man pages, (which is why I CC'd him in that bug > report), but the latter are our business since a number of you are > helping out with the doxygen effort by adding appropriate > doxygen-style comments in our source code. Those doxygen-style > comments will continue to be licenced under the LGPL, of course, > because they are part of LGPL-licensed source code. > > However, because we include the doxygen-generated results in our > source tree (and also display them on our website) a decision is > needed about what licensing terms we should adopt for those > doxygen-generated (html) documentation files and associated display > results (e.g., licensing terms inside an HTML comment and the same > licensing terms written in HTML that an HTML-browser will render.) > > I strongly lean (for documentation result consistency) toward using > the exact licensing wording (i.e., freeBSD documentation licensing > terms modified for PLplot) in those doxygen-generated HTML files that > we currently use for all our docbook files and results generated from > those docbook files. Does anybody here who has been working on our > doxygen-based documentation have any strong objections to that > doxygen-generated file licensing approach? If not, and assuming I can > find the time to deal with this, I hope to make this change some time > this week. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > ------------------------------------------------------------------------------ > Want excitement? > Manually upgrade your production database. > When you want reliability, choose Perforce > Perforce version control. Predictably reliable. > http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk > _______________________________________________ > Plplot-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/plplot-devel ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
