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

[Nikola M]

On 10/15/15 01:08 AM, Bob Friesenhahn wrote:
> 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?
It is true, but also it gives obligation of biinaries distributor to 
_provide_ sources with it's release.
The most viable to ensure you can provide source for binaries is to have 
copy of exact source from whom binaries are made - on your own project 
server.

If you are obligated to fullfil obligation it is not fulfilled with 
pointing at someone else and posting a link is not the same is giving 
the source on request.
If source repositories on OI servers and tagging before update on both 
packages and sources side, are part of OIregular process, that can be 
efortlessly done with an ease.

Also putting external sources link is not a bad thing but the point is 
that source is available locally on OI servers and those are 2 things.
if one maybe wants to lower badwith requirements on server would think 
just putting a link is easy. But if that is done on every build, it puts 
strain and bandwith reqirement on every upstream package available on 
http, that could filter OI form downloading because not having it on 
local servers.

>
> There does need to be a precise way to obtain the exact sources used 
> to build any binary release and it should be documented.
It is exactly the point and that is why locking version updates with 
entire , having local sources and tagging them in same way is what 
solution is.
One can that way get exact binaries state at exact moment, that makes 
testing easier and pinpoint the moment bug(s) are introduced and at the 
same time solve source availablility for every package release.
>
> Regardless, directories of tarballs seem best since they are easiest 
> to copy and therefore less likely to be lost.
I think that if current build process uses upstream binaries,
then it can continue by building from the copy on OI servers instead and 
using GIT on OI servers for build and tagging source before publishing 
packages on sucsess build.