[proposal] Samba Software Foundation

[Luke Kenneth Casson Leighton]

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>
--