namespace protection compatible with the OSD?

[Dave Gilbert]

On Thu, 19 Apr 2001, Brian Behlendorf wrote:

> OK, so we have two new analogies to implementing an API, that of "baking a
> cake from a recipe" and "that of building a house from blueprints".  I
> still think the line between that and "write a novel based on a
> Shakespeare play" is not defined. 

Unfortunatly none of these analogies are correct; they all give a false
sense of apparent correctness which leads people to apply the wrong sort
of laws to them.

In terms of an API it is important to separate out the definition of the
API from its implementation and to realise that neither can be made from
the other directly without work and thought.

A skilled craftsman can, using his skill, knowledge and experience without
being inventive, build a house purely from the plans.  This is not
necessarily true of an API implementation; i.e. a skilled, but uninventive
programmer or system designer can NOT implement all APIs just from their
interface definition. Some APIs can be implemented purely from definition
without inventiveness, but there is almost always the opportunity for an
inventive implementer to entirely meet the API definition but produce a
different implementation from another implementer with possible benefits
such as speed, size etc.

Again, using an analogy which is probably a bad one I'd consider a car
wheel.  The API is the definition of what shape the axel/wheel/break disc
etc have to be for them to fit together.  A wheel maker may make a wheel
that 'implements the API' by ensuring that certain parts of it happen to
fit the car.  Similarly a car maker can use the API by making a car with
that shape fittings.

In an ideal world there is no requirement on either the car maker or the
wheel maker to use any particular technology in their products - they can
use wacky structural designs for better safety etc - without altering the
fact that they meet the API.

Given this API you can't design a car (hence its not like the house
blueprint analogy) and by looking at the wheel you can't design a car.

Now a car manufacturer might team up with a wheel manufacturer and decide
to change the interface between car and wheel - there are at least
two reasons he might want to do this:

  1) To generate an unfair monopoly so that no one else can sell cheaper
spare parts for the car.
  2) Becuase they have some improvement which provides some tangable
benefit to the consumer. This may involve some inventiveness e.g. some
clever mechanical arrangment between the two.

Taking case 1) it would seem that a third part wheel manufacturer could
buy a car and take one of the wheels off and look at the way it fixes to
the car and make another wheel that fits in the same place.  It would be
important that he only made something that fitted in the same way and
did not copy the actual wheel design.  Obviously the car manufacturer can
claim this is not an autharised part and may not meet various of its
specs.  Indeed it is the 3rd part wheel makers skill and inventiveness 
and trustworthy ness that people can use to guage whether it is a safe 
and good wheel and whether it has tangible benefits. What is the law in
this type of case?

Now what about number (2) - if they really do do something clever then
perhaps there is something patentable in there - but it would still be
monopalistic.

The real danger is people making small changes as in (1) which convey some
notional but misleading benefit and then claiming it is actually (2).
 
Dave

-- 
 ---------------- Have a happy GNU millennium! ----------------------   
/ Dr. David Alan Gilbert      | Running GNU/Linux on Alpha, | Happy  \ 
\   gro.gilbert @ treblig.org | 68K,MIPS,x86,ARM and SPARC  | In Hex /
 \ ___________________________|___ http://www.treblig.org   |_______/