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

[Markus Neteler]

(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
<[hidden email]> 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
_______________________________________________
grass-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-psc

[Glynn Clements]

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 <[hidden email]>
_______________________________________________
grass-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-psc