Search Engine on

Jeff Spaleta jspaleta at
Sat Jul 24 18:48:22 UTC 2010

On Sat, Jul 24, 2010 at 5:55 AM, Toshio Kuratomi <a.badger at> 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.

> 6) So one policy could simply trust what upstream tells us about the
> licensing and availability of the code that they are running (we probably
> need to make clear that the code that they are running needs to be
> available, not just under an open license.  That way you can't simply claim
> that your unreleased code is under the BSD license, you also have to release
> that code.)

I guarantee you you will get misinformation because of the complexity
of the codebases to run the services.  We have this problem already
with upstream projects and package generation.  Just last week you
yourself informed me of  a licensing problem with code in one of my
packages that I had to clean up..and its been there for years.   If
somehow we discover a service isn't completely open, or running a set
of patches that are not public (which is far far more likely a
situation than an out and out lie) the vendor has zero legal
requirement to come into compliance with our licensing policy.  And
unlike me as a packager, where if I didn't take action another
packager would have to fix the package i'm primary maintainer on..
there's no way we can fix uncompliant vendors. We get stuck.  It is
exactly this lack of control of the running service that we must hedge
against. Requiring open licensing isn't just a philosophical issue,
there are real practical reasons for wanting the freedoms that open
licensing has traditionally given users. But web services break the
underlying model. Open services don't give users the freedoms to
replicate or fork unless they are using the new breed of AGPL-alike
licensing.  It's simply not enough to require open licensing. We must
guarantee our ability to replicate or fork when we can no longer rely
on an outside vendor. Public API compliance a codebase we can run
locally...those are the two things that we must satisfy to avoid
vendor lockin.  Services that run AGPL give us that automatically.
Services that run apache and BSD codebases do not..even though they
are "open."

If we don't have the ability to audit, then we are not being
intellectually honest about requiring a licensing requirement.  Yes it
would make me feel better to be able to say we rely on a fully open
stack even across the network boundary into other vendors services..
but day-to-day as a workable policy its complete fantasy.  It's like
the US government trying to mandate that all municipal water systems
in Germany have to be fluorinated or US citizen's won't be allowed to
travel there.    Unless you can get an outside vendor to sign a
legally binding agreement (like say the AGPL) which mandates release
of code under penalty of law then its pointless to talk about just
taking their word for it and moving on. Either we require it and make
sure we can verity that the requirement is met.. or we don't require
it and we require something else.. like API compliance with a service
codebase we can run. Anything in the middle is just asking for trouble
down the line.

The reality is, out in the wild, your going to see vendors who are
like 90% open. Vendors like Facebook. Which as a framework is built on
a crapload of open pieces. They even release an open framework version
with the proprietary bits stripped out.  But to use a real service,
you are undoubtedly interacting with proprietary bits behind the
scenes(especially if you play farmville..which I know you all do)

We have to come to terms with that. Relying on _any_ web services
means a lack of control including enforcement of licensing policy (not

Its perfectly fine to say we prefer open codebases. It would be
reasonable to require AGPL-like web services where the license itself
gives us a legal level to get the running source code (even if its
difficult in practise to do it).  But to state as a policy
_requirement_ that we can only interact with "open" services.. without
the ability to audit the codebases involved is folly and will only
lead to more complicated and torturous decision making in the future
when compliance issues come up with a vendor you thought was clean.

More information about the advisory-board mailing list