[Sugar-devel] Building a customized image of Sugar .100

[James Cameron]

On Wed, Sep 03, 2014 at 09:37:23PM -0500, Jerry Vonau wrote:
> > On September 3, 2014 at 6:17 PM James Cameron <quozl at laptop.org> wrote:
> > +CC devel@
> > http://dev.laptop.org/ticket/10918
> >
> > On Wed, Sep 03, 2014 at 06:04:21AM -0500, Jerry Vonau wrote:
> > > Hi James,
> > > On September 2, 2014 at 10:25 PM James Cameron <quozl at laptop.org>
> > > wrote:
> > > > On Thu, Aug 21, 2014 at 06:17:48PM -0500, Jerry Vonau wrote:
> > > > > What is really handy to have for debugging is a copy of the
> > > > > master kickstart file used at image creation time. This file has
> > > > > the order of the scriptlets that are used in os-builder, and
> > > > > presents a nice play by play of the whole build process. There
> > > > > is a patch to keep it around for inspection[1]
> > > >
> > > > Agreed, very useful.  It exposes private repositories though, so
> > > > I'm none to keen on having the output go to the same directory
> > > > used for publishing the build files.  What do you think?
> > >
> > > Don't think that it really matters if one has made the ini file for
> > > OOB public, the same information is available there. I think this
> > > file should be made public in the same way as packages.txt and
> > > friends are handled now.  One could always later delete or not
> > > upload the build.ks file should one want to. Not making all the OOB
> > > output files public is something less than full disclosure IMHO and
> > > should be avoided.
> >
> > I agree, it should be made public, but it can't.  So we only commit
> > the .ini file changes that don't list the hidden repositories.  Full
> > disclosure is incompatible with licensing agreements.  While it would
> > be nice to be free of them, that's not achievable; a nirvana fallacy.
> >
> > It's one all.  I'd like to hear what others think.
> 
> I have to ask "what licensing agreements"? Are we talking Vmeta[1]
> support now?  Are you implying there are two levels of hardware
> support for some XO variants?  One level that is available with the
> standard released build, and a second level only available via
> custom builds or later installation? 
> 
> Think I might know the answers but I would like to read the reply,

Yes, you are quite correct.  Vmeta (XO-1.75, XO-4) and an Adobe Flash
Player plugin (XO-1.5, XO-1.75, XO-4).

None of our larger deployments use OLPC OS unchanged without adding
these components.

I don't think we could have done better unless we had secured more
permission licensing.

There are also deployments that have their own license agreements for
fonts or other content, squirrelled away in their repositories, but I
don't have those details.

-- 
James Cameron
http://quozl.linux.org.au/