Providing source code along with binaries - was Re: [GRASS-dev]
WinGRASS-6.3.0RC5 Self Installer
glynn at gclements.plus.com
Wed Mar 26 04:23:46 EDT 2008
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
You only need multiple source packages if you have multiple GRASS
> > > 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
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 at gclements.plus.com>
More information about the grass-dev