On Tue, Sep 9, 2008 at 6:20 AM, Georg S. Weber <[EMAIL PROTECTED]> wrote: > > 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
[...] I think this proposal is very similar to having docstrings be part of functions definitions, in that it keeps relevant information where it should be, so it gets updated when it should get updated, etc. And, it is very much in the spirit of the doc/ proposal. So I vote +1. All the questions about what is technically possible below have a "yes, that is possible" answer. william > 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 > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
