Search Engine on start.fedoraproject.org

[Mike McGrath]

On Sat, 24 Jul 2010, Toshio Kuratomi wrote:

> On Sat, Jul 24, 2010 at 10:48:22AM -0800, Jeff Spaleta wrote:
> > On Sat, Jul 24, 2010 at 5:55 AM, Toshio Kuratomi <a.badger at gmail.com> wrote:
> > > 5) I don't think that we *must* audit an upstream installation to be in
> > > compliance with a free software policy.  There are certainly services which
> > > claim to be free software and services which claim to be proprietary (or at
> > > least, make no claims to being free software).  With the question of whether
> > > google search is allowable, google has, to the best of my knowledge, never
> > > claimed that their search is free software so it seems a rather obvious
> > > thing to scratch off the list.
> >
> > And when someone challenges the claim that a provider makes, we
> > continue to take the providers word? We are stuck in exactly the
> > position we don't want to be in.  This goes back to my comment about
> > underlying guarantees. What do we need to guarantee for ourselves? An
> > escape route from one particular vendor if for whatever reason we no
> > longer want to work with that vendor.  What you just said about
> > trusting vendors does nothing to solve the practical problems about
> > running infrastructure that relies on outside vendors. A vendor can
> > claim its open, they get caught in a lie, there's no actually
> > copyright violation so there's no legal lever to force them to open
> > the codebase, and where are we then? Stuck...just as if it were
> > proprietary from the start.
> >
> > Trust but verify.
> >
> We could default to trust, default to not trust, or default to evaluate when
> the issue arises.
>
> As far as I know we have yet to run into this issue.
>
> I think, however, that you're really asking about the worry that the FSF
> outlines as its reason for taking copyright assignment from people -- what
> recourse is there when something that has a licensing problem has been
> contributed and become an integral part of gcc?
>
> In our case this is what happens when something that has an unknown
> licensing issue becomes an integral part of Fedora Infrastructure and we
> find out after the fact?
>
> Perhaps we need to say that we cannot let any external service become
> essential to the running of Fedora Infrastructure.
>

Naw, keep in mind the CSI standards are supposed to be written not just
for us but also in a way that others can use them.  I think the above
would be a blocker.  It can also inefficient to run all your own stuff.

Plus, look at stuff as simple as our resolvers.  We resolve using each
hosting facilities resolver since, for example, we don't want our German
servers needing to resolve to hosts across the ocean.

> Perhaps we need signed contracts with any third parties that guarantee for
> us the open sourceness of their code with monetary damages if there is
> a violation.  Perhaps we do need the right to audit the third parties.
>

We'd never get that for services we don't pay for (like resolvers).


> I do not think that API compliance is a really worthwhile definition.  If
> all it takes is API compliance why aren't we running the service ourselves?

Usually cost.  Rsync.net would be a good example, they probably buy
storage on a scale we won't ever come close to so they likely get heavy
discounts.  The resale pricing I saw when I was comparing it to running
our own was significantly cheaper and that was before our facilities costs
were included.

Also cost in terms of not having our people run it.  Frees us up to work
on other things.

> Saying that we avoid the problems of having to switch off something integral
> to our sites because we can spin up a program that implements the same API
> locally doesn't mean that it will be easy, instantaneous, or even possible
> to do so within Fedora Infrastructure.  The setup of the application could
> be torturous or the hardware requirements could be out of our budgetary
> reach.  The proprietary bits of code that force us to switch away from
> a vendor could be precisely the bits that are needed to make the service
> viable for our purposes (through bugfixes, efficient use of resources, etc).
>

I don't think we can ever remove the risk you're discussing but I think we
can manage and mitigate it a bit.  In the case of needing proprietary bits
being the free bits that make it useful to us, I say we just don't
implement that system.  We've said no to stuff like that in the past.
Obviously if it was super critical to the Fedora Project as a whole, a
board override would take care of it.

I'm generally leaning towards wording that is something like this:

 * Must: An open API/Protocol
 * Must: A free implementation of that API is available (IE: something we
     could actually download today and use)
 * Must not: Directly depend on any externally detectable changes that
     don't comply with the free implementation.  (IE: things that are not
     freely available or implemented)
 * Should: Due diligence to ensure the use of the remote service could be
     duplicated locally in such a way to not put $ORGANIZATION at risk.
 * Should not: Knowingly depend on a 3rd party service that is using a
     mostly non free implementation of the service.  (Seems like some
     forks and changes (like branding even) will happen no matter what.
     The focus here is on the bulk.  And this leaves interpretation for
     the standards police at $ORGANIZATION (like me) to make an informed
     decision while helping guide people as they're looking to design /
     implement new decisions.

With a proper explanation before these are written I think the general
point can be made about the dangers of 3rd party web services.  This is
still flexible for us to rely on proprietary network services if we need
to (for things like performance of a local DNS resolver compared a remote
one).

As long as pkgdb doesn't rely on the non-free bits of bugzilla we're also
generally OK there.  Even if we're not, in bugzilla's case, it got
grandfathered in.  In the future though when implementing a similar system
we could just install our own bugzilla, test against it and see if pkgdb's
functionality still works.

Yes there can be exceptions made.  We certainly do already for software we
run locally (for example some raid configuration utilities or bios
updaters).  But I think the above must's and should's will help people
make informed decisions.  Hopefully over time as we and others think about
the pitfalls and dangers of 3rd party web services and a better path can
be made clear.  For now though I suspect the above is the closest we'll
get to freedom we value and feasibility and functionality we desire.

	-Mike