Providing source code along with binaries - was Re: [GRASS-dev] WinGRASS-6.3.0RC5 Self Installer

GRASS GRASS developer
,
1

(cc PSC,
thread: http://lists.osgeo.org/pipermail/grass-dev/2008-March/036460.html
)

On Tue, Mar 25, 2008 at 1:18 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 25/03/08 10:13, Markus Neteler wrote:
> Moritz Lennert wrote: ...

...

>> Everything is available at
>> http://geog-pc40.ulb.ac.be/grass/wingrass/wingrass_sources/
>> including the version of the GRASS sources you used (don't think
>> this is necessary, but just to be complete). All packages are
>> available individually, and there also is a wingrass_sources.tar
>> which contains them all.
>>
>> Maybe Markus can just get the tar and put it on the download site
>> next to the installer ?
>
> you mean: wingrass_sources.tar 13-Mar-2008 11:48 45M ?
>
> I am not sure if we should really store that on the OSGeo server.
> Then we have to do the same also for all the other binaries and fill
> up the server space with overhead. If you insist, I suggest to
> discuss this on the GRASS-PSC list.

What do you mean by "all the other binaries" ?

Perhaps Linux, Mac, Ultrix, DEC, ...? binaries require different
source packages. So we would accumulate a lot once we start to
provide more binaries (as soon as the OSGeo buildbot is open for
us).

> We could store the hard-to-get sources, but why host PROJ4, GDAL and
> such?

Here is what Glynn wrote a bit earlier in this thread:

> Please note that, if you provide binaries which are covered by the
> GPL, you must provide the corresponding source code for download
> *from the same place*. It isn't sufficient to point to the source on
> a different site.

Just curious why this didn't came up earlier (GPL change in 1999).
?

From the same place would cover

gdal.osgeo.org
?

> Alternatively, you can provide a written offer to supply the source
> code upon request, but that means that you have to keep those exact
> versions of the source code handy for the next 3 years (the website
> where you obtained it may cease to provide it when a new version is
> released).

If we/us/PSC decides that we want to provide all (!) the needed source
code packages, we need a systematic approach. I still don't think that
we should just throw stuff into the mswindows/ directory.

Markus

2

Markus Neteler wrote:

> > I am not sure if we should really store that on the OSGeo server.
> > Then we have to do the same also for all the other binaries and fill
> > up the server space with overhead. If you insist, I suggest to
> > discuss this on the GRASS-PSC list.
>
> What do you mean by "all the other binaries" ?

Perhaps Linux, Mac, Ultrix, DEC, ...? binaries require different
source packages.

There's no reason to use different source packages for different
platforms.

You only need multiple source packages if you have multiple GRASS
versions.

> > We could store the hard-to-get sources, but why host PROJ4, GDAL and
> > such?
>
> Here is what Glynn wrote a bit earlier in this thread:
>
> > Please note that, if you provide binaries which are covered by the
> > GPL, you must provide the corresponding source code for download
> > *from the same place*. It isn't sufficient to point to the source on
> > a different site.

Just curious why this didn't came up earlier (GPL change in 1999). ?

It has only really become an issue since people started creating their
own "binary package" projects with the dependencies included.

>From the same place would cover
gdal.osgeo.org
?

IANAL, but it's probably good enough. They're both subdomains of
osgeo.org and on the same IP address and protocol.

AIUI, the main reasons for the "same place" rule are:

1. To ensure, so far as practical, that anyone who can get the
binaries can also get the source.

If binaries are available via HTTP but source is only available via
CVS/SVN/etc, users behind corporate firewalls which only allow
HTTP/FTP/Email can't get the source.

Also, if both are available by HTTP but the two are on completely
different servers, the source may be unavailable to users behind
content filters (NetNanny, Great-Firewall-of-China etc), particularly
if the binaries are on a strictly-controlled corporate site while the
source is on a more "open" site.

2. To prevent developers from having their bandwidth abused.

Suppose a lone developer writes a useful program and hosts it on their
ISP-supplied webspace. A large corporation actively promotes the
program, putting the binaries on their servers and providing a link to
the developer's site for the source code. 5 minutes later, the
developer has exceeded their monthly bandwidth quota.

--
Glynn Clements <glynn@gclements.plus.com>

3

On 25/03/08 16:42, Markus Neteler wrote:

(cc PSC,
thread: http://lists.osgeo.org/pipermail/grass-dev/2008-March/036460.html
)

On Tue, Mar 25, 2008 at 1:18 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 25/03/08 10:13, Markus Neteler wrote:
> Moritz Lennert wrote: ...

...

>> Everything is available at
>> http://geog-pc40.ulb.ac.be/grass/wingrass/wingrass_sources/
>> including the version of the GRASS sources you used (don't think
>> this is necessary, but just to be complete). All packages are
>> available individually, and there also is a wingrass_sources.tar
>> which contains them all.
>>
>> Maybe Markus can just get the tar and put it on the download site
>> next to the installer ?
>
> you mean: wingrass_sources.tar 13-Mar-2008 11:48 45M ?
>

Note that a big chunk of that is the GRASS source which is already on the site, so it doesn't need to be replicated. Just took that out and now we are down to 29M.

> I am not sure if we should really store that on the OSGeo server.
> Then we have to do the same also for all the other binaries and fill
> up the server space with overhead. If you insist, I suggest to
> discuss this on the GRASS-PSC list.

What do you mean by "all the other binaries" ?

Perhaps Linux, Mac, Ultrix, DEC, ...? binaries require different
source packages. So we would accumulate a lot once we start to
provide more binaries (as soon as the OSGeo buildbot is open for
us).

Well, strictly speaking GRASS as a team only has to cover those binaries which are published on the GRASS site, so the MacOSX binaries are the responsibility of the respective maintainers. Debian and Ubuntu packages already provide sources, I suppose that Gentoo does so also by definition, SUSE does as well, don't know about Mandriva.

This leaves us with the "Generic" GNU/Linux binaries which lead to the same page as the Fedora Core link on the download page (why is this so - I wouldn't consider Fedora binaries as being generic ?). Both of these seem quite out of date...and only the Fedora directories provide other binaries than GRASS (are they still needed on this server ?).

So, unless we think that Fedora binaries of other dependencies of GRASS should be hosted on the server, the only binary package where this is an issue is the MS Windows installer...

> We could store the hard-to-get sources, but why host PROJ4, GDAL and
> such?

Here is what Glynn wrote a bit earlier in this thread:

Please note that, if you provide binaries which are covered by the

> GPL, you must provide the corresponding source code for download
> *from the same place*. It isn't sufficient to point to the source on
> a different site.

Just curious why this didn't came up earlier (GPL change in 1999).
?

From the same place would cover

gdal.osgeo.org
?

> Alternatively, you can provide a written offer to supply the source
> code upon request, but that means that you have to keep those exact
> versions of the source code handy for the next 3 years (the website
> where you obtained it may cease to provide it when a new version is
> released).

If we/us/PSC decides that we want to provide all (!) the needed source
code packages, we need a systematic approach. I still don't think that
we should just throw stuff into the mswindows/ directory.

No, if we use the same sources for different platform binaries then it should be enough to host them once, including possible platform-specific diffs. But at the current state, I don't think we are in that situation, except for the outdated Fedora binaries.

What exactly is the issue: is it limited disk space on the OSGeo servers ?

Moritz

4

On Mar 26, 2008, at 2:53 AM, Moritz Lennert wrote:

If we/us/PSC decides that we want to provide all (!) the needed source
code packages, we need a systematic approach. I still don't think that
we should just throw stuff into the mswindows/ directory.

No, if we use the same sources for different platform binaries then it should be enough to host them once, including possible platform-specific diffs. But at the current state, I don't think we are in that situation, except for the outdated Fedora binaries.

What exactly is the issue: is it limited disk space on the OSGeo servers ?

Greetings,

If it would be helpful, I would be happy to host the source and binaries at <http://OpenOSX.com>. I have "spare" hard disk space and bandwidth.

I would have to post a disclaimer that we did not create the binaries and are in no way responsible for any issues or support for them.

If you are interested, contact me (off list) and I can create a directory and FTP login for the directory...

Cheers,

Jeshua Lacock, Owner
<http://OpenOSX.com>
phone: 877.240.1364

5

What exactly is the issue: is it limited disk space on the OSGeo servers ?

Folks,

I would note that the past space constraints on download.osgeo.org are
now largely relaxed. There is roughly 70GB of space available now.

This space will be used over a number of projects (hopefully over a number
of years) so some prudence is a good idea, if only to keep the amount of
stuff needing to be managed, backed up, rsynced and so forth managable.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org

6

Frank,

On Wed, Mar 26, 2008 at 3:27 PM, Frank Warmerdam <warmerdam@pobox.com> wrote:

>> What exactly is the issue: is it limited disk space on the OSGeo
>> servers ?

Folks,

I would note that the past space constraints on download.osgeo.org are
now largely relaxed. There is roughly 70GB of space available now.

please note that grass.osgeo.org is on a different machine:

[neteler@xblade14-2 mswindows]$ df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/hda1 25G 18G 5.7G 76% /

Best
Markus

This space will be used over a number of projects (hopefully over a number
of years) so some prudence is a good idea, if only to keep the amount of
stuff needing to be managed, backed up, rsynced and so forth managable.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Open Source Geospatial Foundation
http://www.osgeo.org/
http://www.grassbook.org/