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
-~----------~----~----~----~------~----~------~--~---

Reply via email to