[oi-dev] Openindiana hipster source code on OI servers to fulfill licensing requirements.

[Nikola M]

On 10/15/15 01:10 AM, Hugo wrote:
> Well put.

Please respond below quotes on public lists. even I make mistakes when 
posting from Gmail's web interface, sorry.

As already explained, obligation per license to provide source with 
binaries is on distributing party.
When distributing aby built binay, one becomes distributing party and is 
obligated to provide source.
Providing link (that might work or not) is not the same as providing the 
source.

Most viable solution to provide source (remember you are opbligated to 
provide source for every upstream package and patches with it for 
_every_ updated binary)
is to have local copy and build from it. It is just the only sane way to 
always provide sources for packages at any time (and to at any given 
time fulfill licensing obligation of providing sources with binaries).

It is just much easier to fulfill source availablility obligations if 
build process itself is done with them in mind.

>
>    Original Message
> From: Bob Friesenhahn
> Sent: Thursday, 15 October 2015 00:08
> To: OpenIndiana Developer mailing list
> Reply To: OpenIndiana Developer mailing list
> Subject: Re: [oi-dev] Openindiana hipster source code on OI servers to fulfill licensing requirements.
>
> On Wed, 14 Oct 2015, Nikola M wrote:
>> It is a good question weither Oi got to have it's own source code
>> repositories to match every Oi hipster 'snapshot' release. it does because
>> source code distribution must be provided together with binary distribution,
>> per licensing requirements of free software.
> I don't recall seeing a definition for how source code must be
> distributed in any free software license. If the server is open for
> all and the source is properly managed (e.g. clear release notes and
> repository tags and or branches), is that necessarily inferior to
> tarballs provided by ftp or http?
>
> There does need to be a precise way to obtain the exact sources used
> to build any binary release and it should be documented.
>
> Regardless, directories of tarballs seem best since they are easiest
> to copy and therefore less likely to be lost.
>
> Bob