Oops, several misunderstandings, and perhaps on my side, too. First of all: my intention is to lower the current overall complexity, certainly not to increase it ...
My understanding is that "everything" that a new spkg "foo" adds to the current Sage installation that it is added too, will be done resp. triggered by its sage-install script which comes with "foo" (in its top-level directory). I may be mistaken here, but a modular build concept would definitely imply this. If it is so, and "foo" knows nothing about a license/ subdirectory --- well, simply nothing happens. So the spkg "foo" installs cleanly. And for gap_packages* (or other spkgs which themselves consist out of a load of contibutions with different licenses), the maintainer could say just that in a to-be-copied textfile in the license/ subdir,. e.g.: """The spkg gap_packages_foobar consists out of quite a number of bundled Gap packages, with varying licenses (mostly GPL but nauty is there too). Please see the respective individual license files.""" Of course one *could* invest more effort, e.g. explicitly list up the license files. If time allows :-) It is certainly not my intention to go for water-proofness in the sense of lawyers, but to increase maintainability and ease-of-use by adding this "default license locations" in the Sage (spkg) build/directory structure. (I myself try to create something like a "example_clib_spkg" for quite some now, and the licensing is too important to just ignore it. But it should not be a cause for any waste of time.) Cheers, gsw On 9 Sep., 13:43, "David Joyner" <[EMAIL PROTECTED]> wrote: > I like this idea but it provides another layer of complexity. What if > someone simply > forgets to add a license subdirectory? Does that make their package invalid > or does sage -i foo.spkg fail? > > In the case of gap_packages*, a number of Gap packages are bundled, > with varying > licenses (mostly GPL but nauty is there too). The maintainer (me, I > guess) would have > to add all these individual license files together into a single > license subdirectory? > > ++++++++++++++++++++++++++++++++++++++ > > On Mon, Sep 8, 2008 at 4:00 PM, Georg S. Weber > > <[EMAIL PROTECTED]> wrote: > > > Hi Sage-Devel, > > > What do you think of adding a license/ subdirectory to each spkg? > > When the spkg, say foo-1.2.3.spkg is installed, the directory > > > SAGE_ROOT/license/packages/foo > > > would be a copy of that license/ subdirectory. > > > (The above is shamelessly copied from the start of Williams "doc/" > > proposal and only slightly modified ...) > > There are several reasons for this new proposal: > > > 1. The original proposal about doc/ was received positively. > > 2. I have optional and experimental spgks in my mind, which are not > > covered by the current one big "license" file for the standard sage. > > But Sage is designed and made for ease of plugging new spkgs in. Which > > have to be developed. > > 3. Any move to a more modular structure like this increases > > maintainability. If this proposal receives a positive feedback, my > > next proposal in this direction would be to "modularize" the license > > information for the "standard" Sage, too. (Not to mention > > "SageLite" ...) And I'd volunteer to do this :-) > > 4. Should we end up with 75 or even more than 100 copies of the GPL > > --- who really cares? These are text files with uncompressed only a > > very few KB, so are sizewise negligible (for downloads e.g.), > > especially after bz2-ing. > > 5. For convenience, one might go one step further and have an > > additional "short version" of the license information in each spgk's > > license/ subdirectory, and the build process compile those together to > > a single "overview" file ... a slicing up of the current file being a > > good starting point. > > > I see only pro's but no con's. Am I missing something? > > > Cheers, > > gsw --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---