Search Engine on start.fedoraproject.org

[Toshio Kuratomi]

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.

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.

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?
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).

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/advisory-board/attachments/20100724/aa5aac83/attachment.bin