fsfe-uk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fsfe-uk] BECTA discriminate against FLOSS?


From: Robin Green
Subject: Re: [Fsfe-uk] BECTA discriminate against FLOSS?
Date: Mon, 22 Dec 2003 00:49:49 +0000
User-agent: Mutt/1.5.4i

On Sat, Dec 20, 2003 at 10:30:49AM +0000, ian wrote:
> On Fri, 2003-12-19 at 22:56, Simon Waters wrote:
> 
> <SNIP>
> > In free software it is inevitable that the earlier projects will be
> > relatively more expensive than later projects,
> 
> It surprises me that the "investment" angle is never highlighted much.
> Most companies will invest say double in year one if it means year 2 to
> 10 give even a 20% pa payback in return. Its pretty obvious that it
> doesn't take 10s of billions to maintain and distribute an Office suite
> so taking those 10s of billions out of the equation simple reduces the
> global cost. You don't need a TCO study to work that out. In fact it
> would be more efficient for BECTA to do a specific analysis of what it
> is in OO.o that is missing that is vital to schools and then for the
> DfES to pay for the necessary development to fill the gaps (if any).

That's an interesting point. (Apologise, over-verbose post ahead.)

A pro-private-sector bureaucrat is, I would guess, likely to reply along
the lines of "Assuming what you say is true, why won't/hasn't some corporation
do/done that already - they could then sell it to us to recoup their
investment?"

My thoughts: Well, it could happen, but I cynically suspect that the kind
of large IT corporates who typically bid for large government contracts would
(if they were enlightened enough to risk investing in an open source dev project
in the first place) see it as an opportunity to over-charge for development,
over-charge for support and lock schools in to support contracts. Support
contracts which might, in fact, lock out the ability to do just what 
makes Free Software Free - i.e. change software, or hire a random
contractor to change it.

The reader may at this point wonder how Corp XYZ would force whoever downloaded
the code to buy a support contract. They couldn't, if - as we're assuming here -
it was all FLOSS code - but they might invest in the project on the basis of:

 (a) making a sufficiently large initial sale, in which the code is "ransomed"
 - no sale, no code released (fair enough, if the price is reasonable)
 
 and/or
 
 (b) providing a "source only" version - no binaries - to comply with the
 GPL, then trademarking their "distro", rigorously enforcing their trademark,
 and subtly spreading FUD about the so-called "unsupported" nature of white-box
 compiled versions - i.e. their own "product", compiled by someone else and
 without a support contract. This, amusingly/bizarrely enough, seems to be what
 Red Hat kind of does with its Red Hat Enterprise. The fact that it involves
 effectively spreading FUD against nearly-bit-for-bit identical copies[*] of
 your own "distro" is what seems so bizarre to me, but it seems to work
 moderately well for Red Hat within their market.
 
[*] The only thing you have to change if you release your own copy of RHEL
is the trademarked items, e.g. the images and text. None of this should cause
the code to behave differently.

For example the Red Hat Enterprise support contracts, which appears
to constrain users from changing GPLed software. (I haven't read it in detail.)

I believe that what happens in practice if you "run an unsupported
configuration" (i.e. change the code that you're running if any part of it
forms part of the Red Hat Enterprise distro) and they find out,
is that you don't get sued for breach of contract, but they just terminate
your support contract.

Or they at least tell you off and threaten not to support you any more.
Someone correct me if I'm wrong.

Because actually attaching penalties (beyond the penalty of "your support
contract is terminated") or treating it as a copyright violation would
be against the spirit (and in the latter case the letter) of the GPL.
So I would think their support contract would be framed, and enforced,
in a way that doesn't technically breach the GPL. ("We're not preventing
you from exercising your rights, we're only refusing to support code
that's been modified" - which is a fair enough, if slightly ostrich-like,
position.) Again, someone correct me if I'm wrong. The signals coming out
of Red Hat on this have been somewhat mixed.

Anyway, getting back to the original point.

Based on my thoughts above I don't think that waiting for the private sector
to make FLOSS solutions "acceptable" to schools (which is kind of based on
the flawed assumption that it isn't already acceptable in many cases)
is going to be an efficient or cost-effective route.
Because either

  (i) The private sector won't risk it, leaving it up to volunteers to do it
  (or perhaps enterprising contractors to do it bit by bit as part of support
  contracts).
  
  or (ii) A big corporate will risk it, but end up with some so-called
  "Free Software" solution that isn't. Something like Red Hat Enterprise.
  
  or (iii) Some other government might pay for a large fraction of the work
  itself - but that still means more time wasted in the meantime for MS to
  gouge schools on price.
  
More efficient would be for BECTA and/or the DfES (or whatever it's called this 
week)
to take a more proactive role by:

  A. explicitly endorsing Free Software as a valid and valuable option in
     software procurement for education. Or at least valid. This is the 
essential part.
     
  B. employing people to improve FLOSS, or (more likely with this 
pro-privatisation
     government), put it out to tender but set down the terms of the contract
     from the outset so that the contract is primarily paying for the 
_development_,
     and all the direct and indirect Freedoms of Free Software are retained - 
ability to
     change code, ability to freely select support contractors, etc.
     
     Who knows, instead of giving it all to one monolith like EDS and wasting 
millions
     they might actually have the insight to farm it out to multiple smaller 
development
     shops with pre-existing FLOSS expertise, no wasteful airhead salespersons 
calling
     themselves "consultants", and an ability to produce what is actually 
required
     (close to) on time and on budget?
     Nah, maybe that's too much to hope for!
    
But while BECTA waits for open source to become "ideal" by the "magic of free
markets" (which for sufficiently perfectionistic values of "ideal" is never
going to happen), MS and others will continue to gouge massive profits out of
the education sector. The NHS and many other governmental institutions around 
the world are starting to wake up to the power of Free Software - BECTA needs
to get with the program.

The major challenge would be communicating that kind of argument without coming 
off
as not _only_ Free Software partisans, but politically anti-big-business as 
well.
Needs some reworking I suspect.

(Of course they might actually listen to that kind of argument and think 
that it's politcally biased _but_ still likely to be true ;-)

> I suspect that the reason they don't think like this is that they can't
> get their heads round the fact that the conventional commercial market
> models are not automatically the most efficient or effective.

OK, I would summarise my argument as follows: The nature of FLOSS means that
businesses can't do the standard thing of selling software per se to recoup
their investment. Therefore, the risk is that either they won't/can't risk doing
these improvements (which could be quite marginal in some cases) due to lack
of profitability or lack of ability to raise capital for the project
- or they will but they'll try and attach conditions to make it profitable 
which work
against the Freeness of Free Software. If, OTOH you invest in the development
yourselves, you have a better chance of getting it done in a reasonable time
and budget and with _no_ strings attached.

I should note that the option of putting open source dev work out to tender
isn't really that unconventional of a model, of course - it's only 
unconventional
in the _software_ context. Think of it like an old-school _non-PFI_ construction
project where the government owns the resultant road/building/etc. lock stock
and barrel and doesn't have to pay a single penny more to the company in future.
(But then, as a bonus, copies of the product magically become
available to others for merely the cost of a download and possible a compile
;-) You don't get that when you commission a new hospital!)

-- 
Robin

"it's FREE and we get the ability to modify the source code ourselves,
something that is extremely dangerous to do, was discredited decades ago..."
 - Howard Strauss writing in Syllabus magazine
  http://www.syllabus.com/article.asp?id=8460
  




reply via email to

[Prev in Thread] Current Thread [Next in Thread]