[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Asking for maintainer for astronomical packages and some important (and related) issues

Sorry for the late answer.. you will see in a minute why I took some more 
time to answer on this.

> > 1.- Copyright issues, these impact on quite a number of 
> > astronomical-related packages. 
> > 
> > I made the decision of breaking the star catalogs into packages 
> > into non-free but others have not (see bug #174456 - which details 
> > some of the copyright issues).
>     Okay, after reading that, I'm not only worried about the data
> files being non-free, but them being completely unredistributable, in
> main or otherwise.

No, they _are_ redistributable, they just can't be modified. I would 
suggest you read the copyright info in the yale/gliese packages as well as 
the copyright info in the data/ dir of the spacechart package (which 
provides the Hipparcos data set)

> > This issue should be pursued to:
> > 
> > 	- determine wether or not the star data can be distributed in
> > 	  main (I have a number of mails that need pursuing)
> > 
> > 	- contact maintainers to coordinate the use of a single data
> > 	  package instead of having the same star catalogs in every
> > 	  astronomical packages (maybe even ask for a 
> > 	  'star-catalog' virtual package that all could provide)
> > 
> > This issue needs to be coordinated with other maintainers since other
> > packages (like kstars?) might be affected.
>     Well, other packages might be able to *make use of* a central star
> catalog, but only if it contains all the formats that all the packages
> need.  This is probably best handled by simply making such a package,
> and then asking everyone else what they would need it to provide in
> order to use it.  However, this may well involve fairly invasive code
> changes that might be difficult to keep in sync with upstream changes.

Not really, if you see how the (new) starplot package manages it is quite
easy.  If it finds star data under /usr/share/stardata it converts it to 
its format and places it in /usr/share/starplot. That way you can remove 
dependancies. Also, the gliese/yale packages call the conversion routine (a 
simple program) if they are installed _after_ the starplot package.

The current status (with the new uploads I've made) is that gliese/yale are 
indepent packages that provide the star catalogue in the format provided 
upstream (which is a standard format in which all catalogues are provided 

>     Kstars got its information from the ADC, which has since been
> terminated by NASA as as project.  I poked around their FTP site for a
> while, and while the data files are there and I found a request to
> cite use of the data in any paper, I couldn't find any permission to
> redistribute the data as is.  A couple of contact e-mails were
> listed.  I suppose if I take everything I can start writing to
> everyone to ask about the status.  It'd fit in with the writing I have
> to do to Tulip, anyway.

Ok. Great. Please read the (updated) debian/copyright of yale/gliese, there 
are alternatives to ADC which provide the same catalogues.

As a matter of fact I believe all of these star catalogues are in the 
public domain (like the Hipparcos dataset is), but it does not hurt to be 
cautious. It would be a good idea to contact an astronomer which might help 
clarify this.

> > 2.- New releases (bug #169603 - startplot new version and
> > bug #172203 - spacechart new release mainly) although the data files
> > might need to be updated (haven't checked)
>     Easily fixed.

Well. I already fixed it (for both), and I have sent new upstream.

> > 3.- The issue on wether to keep or remove openuniverse
> > (its no longer maintained upstream, and maintainers have moved to
> > improve celestia but it's not a full replacement for it). The 
> > relevant thread in debian-devel starts here:
> > http://lists.debian.org/debian-devel/2002/debian-devel-200212/msg01597.html
>     Heck, I'm still maintaining ssystem (the predecessor to
> openuniverse, and I just recently uploaded a package pointing ssystem
> users at openuniverse unless they have ancient hardware), so if
> nothing else, I should probably pick this one up.  It's more a toy
> than a scientific tool, though.


> > 4.- Determine if a new section should be created for astronomic-related
> > packages. Some are in section 'science' some in section 'math'...
>     Much of physics works out to be applied mathematics.  I'd move
> anything not directly used for direct computation out of math and into
> science.


> > So, after all this rant, any takers? (I hope somebody raises his hand) :-)
>     I'm a little nervous about picking up a heavy load until I'm
> finished cleaning house on my own packages, but I have sufficient
> interest in keeping astronomy-related software in Debian that if
> nobody takes you up on your offer by June 15, I will take:
> openuniverse
> starplot
> spacechart
> gstar

Great. I have made new uploads of starplot/spacechart in order to fix many 
of the lintian bugs and provide the latest versions. I've also made uploads 
of gliese/yale further clarifying where to obtain the upstream version and 
the copyright issues, as well as notes on how should they be used by other 
packages (I believe the way starplot handles them is the best). 

Please do take a look at them and send me any comment you might find  
useful. Maybe you can prepare uploads for the currently unmaintained 
packages (gstar) and contact the upstream maintainers of starplot, 
spacechart, openuniverse, etc..

> and start e-mailing about the licensing conditions for the others.  If
> the data turns out to be redistributable, I will generate a single
> package, starcatalogs, containing everything I can legally
> redistribute in a logical way, and see if I can keep the ftpmasters
> and mirror operators from lynching me.

I would rather distribute each catalogue in its own and have them Provide a 
virtual package 'star-catalogue'.

>     Please send me direct mail on June 15 to remind me if you haven't
> had any other offers.

I've had one of co-maintainership. I believe that these packages should be 
better be co-maintained since it's too much work to have them all be 
handled by a single person.



Attachment: pgpUA1Tj0ao4_.pgp
Description: PGP signature

Reply to: