dear samba users and developers,
i'd like to put to you a proposal for your respectful
consideration: it is an idea that i believe has strategic
merit for the open source community and OS users as a whole.
these words are chosen carefully and the reasons will become
apparent later: that i begin as an example.
as you are no doubt aware, there have been some seriously
damaging (but not obviously so) decisions made for which the
parties involved, myself included, owe you quite a debt,
because the down-side of those decisions has led, in my
opinion, to significant delays in "opening windows to a
wider world".
what i am proposing is the introduction of a "Samba Software
Foundation", which would be modelled on the well-known "Apache
Software Foundation"'s charter.
to kick-start that process - to bring some incentive to carrying
it forward, what i propose to do is: if the SSF is set up in
line with the way i envisage here, i promise to assign all
samba-related code that i have ever written _to_ the SSF -
with some conditions that will be aimed at protecting YOU -
the samba community - not me, as i will point out later.
now, as you are no doubt aware, i believe the ASF charter to
have the following key points:
1) that all contributors treat each other with mutual
respect.
2) that all code contributed is DUAL copyrighted
assigned: one copy is kept by the contributor, and
one identical copy is kept by the ASF
3) that acceptance of contributions are judged on TECHNICAL
merit.
4) voting and karma.
note the contrast between 2) and what i propose to contribute,
above: namely that i will assign _all_ my samba-related code to a
newly formed SSF (without holding dual copyright myself).
one of the key conditions on that happening as follows:
that 3) above, for the Samba Software Foundation, would need to be:
3) that acceptance of contributions are considered
for STRATEGIC as WELL as technical grounds.
for example:
if some code is dog-slow and therefore would normally
be rejected on technical grounds, if it opens up some
strategically important area, then despite its technical
abominability, it would STILL go ahead and be included.
... and probably given a high priority for optimisation
and/or replacement with a better solution, should
some poor sucker turn out to be actually using it and
suffering greatly, but having no other choice, they carry
on regardless.
you get the idea, i am sure.
now, here comes the difficult bit for me - namely that i
have to give you some reasons as to _why_ i am advocating the
introduction of an SSF, because i have to write about matters
that i have written about many times, initially because i was
very very hurt by what happened, later because i was concerned
that the things that happened to me would happen to other
people, and later _still_ because i was concerned that the samba
project, despite its progress in so many ways, has not, in my
opinion, progressed in any _really_ new or innovative areas
that make a significant difference to Open Source OS users.
particularly business users who are still totally dependent on
windows environments to do day-to-day activities, in constant
fear of wrecking their career or business prospects not because
of something they did but because of something they _didn't_
do and didn't _know_ could happen or didn't believe it would
happen to them, today - a virus or a spyware attack.
[you only have to look at the two or more open source exchange
projects which have been initiated on sf.net in the past four
years and have both stalled, and the fact that they are based on
samba tng not samba 3, to recognise that samba's usefulness is
seriously curtailed.
and also the sf.net freedce project which has had DCOM
development environment support since 2000, but no integration
with NT security or _any_ version of samba, and so consequently
is completely useless.]
so i am going to outline, under each of the headings above
(1, 2 and 3) what _has_ happened - briefly - and i think you
will see very clearly that if the SSF _had_ been in place,
history would be totally totally different.
1) that all contributors treat each other with mutual respect.
for the people who know their samba history,
it is an understatement for me to say that i
do not need to say _anything_ more on this one.
2) that all code contributed is DUAL copyrighted
assigned: one copy is kept by the contributor, and
one identical copy is kept by the ASF
this one _does_ need some background explanation.
i began working on samba's nt domain code
in august 1997 with paul ashton (mr "welcome
to the samba domain"). i was _delighted_ -
and a little scared.
paul and i had begun to take a swing at
microsoft (nyer, nyer) and yet, strangely,
they were quietly encouraging. i found a
question the other day in the september 1997
ntbugtraq archives from paul leach, asking if
we'd considered such-and-such a case.
as the amount of exploration and coding
increased, my concentration on wholesale
cut-and-paste of previously written header files
and c files decreased - and the original files
i cut/paste from, even though they contained
no code contributions from andrew or jeremy:
due to a misunderstanding, i often included
their names at the top of the Copyright notices.
100,000 extra lines of code, spread across
over sixty or eightly extra source code files,
and over three years later, code that i had
written, a large number of which i own exclusive
copyright over, contained copyright notices
of people who had not contributed a single line.
against this background, when as you know
things started to turn a bit nasty, at the
third CIFS conference andrew mistakenly said
"jeremy's code" in connection with my first
six months experimental work on the samba ntdom
project - code which saw first production usage
in samba 2.0 for the Domain Membership functionality
and _reeaaally_ basic PDC functionality,
amongst other things.
as you can imagine, i was pissed.
so pissed that, in about 2001 i conceived the
idea of "Disputing" copyright of the samba
source code - and in my opinion, with good
grounds, too.
now, the consequences of _that_ would be
that all users of Samba source code would
need to cease and desist use and distribution
until the matter was resolved!
due to a former case, as far as i am aware,
i am still registered with a US civil
department as one of the joint copyright
holders of samba's source code [it's a long
and completely different story where some
bastards tried to steal samba and sell it
for $USD 10k a shot to sun microsystems, and
the reason why none of the copyright holders
could claim compensation from the bastards was
because in order to make a copyright claim in
the U.S. you have to _register_ the product
and its copyright holders!! no other country
that respects copyright law requires this bloody
stupid registration]
so you see now why i promise to assign all
copyright of all samba-related code i have
ever written to a Samba Software Foundation,
should it ever come into being in the form
that i outline here.
the purpose of 2) is to protect the community
and the foundation from creating exactly these
kinds of purple nasties.
[a purple nasty is what you get if you
mix a blue-coloured aniseed liqueur with
a red-coloured cream liqueur. the cream
happily curdles and also goes purple. sadly,
purple nasties are also undrinkable: i did try
because i didn't want an entire glass of 40%
cocktail to go to waste without knowing what
it tasted like. pfh.]
3) that acceptance of contributions are considered
for STRATEGIC as WELL as technical grounds.
i've hinted at some examples in the form of
the two stalled exchange for unix projects and
the freedce project (all are on sf.net), but i
haven't given any details or justifications as
to why i believe 3) is really, REALLY important.
this is going to be difficult: andrew, jeremy,
please bear with me while i work out how to
say this, and PLEASE, PLEASE think just as
carefully should you choose to reply.
i'll start with things that i know, with
something that jeremy once said to me: i
believe that will help.
jeremy once said to me, in 2000 - about march or
so - at one time when i was having particular
difficulties in communicating a number of
complex issues - that both he and andrew are not
managers, they're strongly technically minded.
he also said that he, too, had difficulties
convincing andrew of key issues, and that
he had to stick to his guns and simply say,
"andrew, you're wrong".
also, recently, andrew reiterated that he makes
decisions based on technical merit, and that the
standards set are being continuously raised.
the trouble with that approach is that,
in combination with the level of technical
expertise required to even BEGIN to contribute
to the samba project, the standards that andrew
has set appear _extremely_ intimidating.
it also leaves andrew in the unfortunate
position of having to make all the decisions,
and the bar _can_ be raised, and moved sideways,
and moved again... i'm sorry to have to raise
this, but you see what i am hinting at _could_
happen, and, unfortunately, difficult as it is
to believe because andrew is so well respected,
there were times in 2000 where i felt that
the bar _was_ being moved sideways, upwards,
crossways and any way possible.
to mitigate against the down-side of such high
expertise and standards and risks, something
has got to give, but also in such a way that
the quality of work that reaches production
environments is not adversely affected (except
where admins or developers actively CHOOSE to
deploy potentially foot-shooting code!)
so, i believe i've laid out enough for people
to be able to draw the obvious conclusion:
namely that by allowing code contributions
based on "strategic" grounds, there at least
exists the possibility to add in experimental
or radically innovative work that suffers from
technical warts and down-right stupidity,
working happily alongside and often using
services and components that have been in
production use for nearly a decade, with
distribution measured in millions of units.
3) is about future-proofing, opening up
possibilities that would otherwise be closed -
and remain closed on "technical" grounds - and
it's about weighing and balancing ease-of-use
(for developers and users) against potential
"technical optimisation and innovation".
a simple example that is easily understood is
that a potential coding optimisation which
is technically brilliant could be delayed
indefinitely under 3), due to the optimisation
somehow making life genuinely difficult for
new developers to _begin_ to understand how
to get their new project up-and-running using
the samba4 runtime developer environment,
as opposed to requiring a few weeks or even
months preparatory learning, should this
"brilliant" technical optimisation be added.
4) voting and karma.
i'm not _entirely_ sure exactly how ASF
karma works, but from empirical observation,
i believe voting to be involving project
developers sending a digitally signed +1,
0 or -1, and karma to be involved with "who
breaks the automated builds on checkins".
the thing is that both these things are
actually ingrained into the checkin scripts
of the source repository, with an automatic
link [cvs blame] back to the "karma" thing.
i'm simply mentioning 4) for completeness but
i am not sufficiently clued up on its details
to be able to advise on it or advocate its use.
so.
as you can see, if a Samba Software Foundation _had_ been in place in
1996, the following things would almost certainly not have happened:
1) my code checkins would had to have improved because my
karma would be absolute mud otherwise.
2) i would have been able to propose the TNG named pipes architecture
for inclusion in samba 2.0, in order to open up a really important
strategic avenue - for:
a) in 1999 / 2000, Sun Microsystems to be able to drop
the crap bits (the file server) of the AFPS code they
bought from AT & T for $USD N million, and use smbd
along with all the _working_ NT Domain services they
bought that didn't rely on anything to do with POSIX.
b) the exchange for unix project to proceed using a
stable production environment samba - without any
code modifications.
c) cliffs, samba 3, samba 4 and samba tng's services
to be able to progress and help bootstrap each other
in an accelerated manner
d) other people wishing to get an introduction to
samba to be able to bite off a small self-contained
30,000 line project instead of being intimidated by
350,000 lines of GPL code
e) FreeDCE and other MSRPC-compatible projects to
utilise the best components of all worlds.
f) the Wine team to be able to hook in to the samba
project at some critical interface points _without_
having to worry about licensing issues, instead of
having to consider writing their own non-GPL'd version
of smbd!
3) it would have been impossible for me to swear in quite
so much frustration - not least because the reasons _why_
i was getting so agitated would have been tempered, but also
because it demonstrates lack of respect, and that would, if
it had continued, resulted in me being banned from contributing.
4) all my code contributions would have been dual-copyrighted
owned, just like everyone else, to the SSF, and the issue of
getting pissed off _at all_ at things like "this is jeremy's
code" simply would be moot [i would likely have said "oi!" and
left it at that]
as you can clearly see, history would be radically, _radically_
different had there been an SSF in place.
now.
there is one thing left for me to outline: it's the conditions
that i seek for the samba-related code i own to be assigned
to the SSF, should it be created. on careful consideration,
i believe that they make a lot of sense and the reasons why
i am proposing them are pretty abundantly obvious.
1) the strategic thing.
2) that if any SSF project developer even _thinks_ of breaking
the charter's conditions of the SSF (especially the one about
mutual respect), copyright of the code i assign AUTOMATICALLY
reverts unconditionally to dual-ownership (to me and to the SSF,
from being owned wholly by the SSF).
3) if it's either andrew or jeremy who does the breaking
(privately, publicly or to _any_ third party),
then copyright AUTOMATICALLY reverts unconditionally to me
(i.e. _from_ being owned wholly by the SSF, _to_ being wholly
owned by _me_)
4) if _i_ ever break the charter's conditions, 2) and 3)
AUTOMATICALLY become null and void conditions (but 6) remains
still in effect, always)
5) condition 4) cannot become null or void at any time - ever.
not even if there's some stupid dickhead country, planet
or universe under which agreements and conditions like the
one's outlined here don't apply.
6) if a full-blown bun-fight occurs, and both myself AND
either andrew or jeremy or both break the charter's conditions
(not necessarily at the same time), then on permanent and
irrevocable resignation of the party / parties that did the
breaking, the code will again become assigned ownership of the
SSF [and, obviously, lose it again if the breaker(s) is(are)
allowed to rejoin the SSF].
7) if another project has an OSI-approved license that happens
to be incompatible with the SSF's license, the board of the
SSF will, if it proves significant and relevant, give serious
consideration to licensing relevant parts of the code assigned
by me under an alternative OSI-approved that _is_ compatible
with that projects's license - _or_ - the developers associated
with SSF projects will give priority to writing code and
putting in place strategically designed interfaces that will
help accomodate the OSI-approved-license-conflicting project.
it should be made absolutely clear, because it isn't made
explicitly clear above, that one of the conditions is most
definitely NOT that i must be made a member of the SSF board.
all of these conditions are open to negotiation.
if you grok the concept i'm trying to put across, and can
think of some better way to achieve it, i'm all ears.
good grief. over three hours later.
anyway.
as is probably abundantly clear by now, this isn't about me
(as i have often been accused of in the past, which hasn't been
the case for quite some time now).
this is about moving forward, and ensuring a framework in
which progress can be made.
i'm fed up with the arbitrary way in which critical open source
projects aren't, if you look at it critically, really making
any _significant_ progress in _significant_ leaps or bounds
to further _real_ business needs and problems, at a time when
windows is moving inexorably further up its own behind, and
people are just ... lapping it up because they don't BELIEVE
they have any CHOICE [or they actually don't: e.g. where is
the Open Source Passport clone for Mono to use?].
windows is getting more insidious, providing more and more
"features" enabled by default that hackers can count on
being available on 90 to 95% of all computers in homes and
businesses today.
my favourite virus which, should it become a reality i almost
certainly literally _will_ fall on the floor with laughter
about, will be when "Longhorn" gets - as a standard component
that is activated all the time - the long-awaited clued-up
and mega-fast document "search" capability.
and a convenient Win32 and .NET API for virus writers to use it.
industrial espionage made easy.
"build your own virus" kit, available from lithuania for only
$99 euros [dollar having fallen through the floor due to too
much unexplained IP leakage to russia, china, iraq, india and
the far east.]
download a free demo _NOW_ from smb://295.128.53.29...
l.
--
--
<a href="http://lkcl.net";>http://lkcl.net</a>
--
