[Samba] Re: [proposal] Samba Software Foundation

[Charles N Wyble]

i like it. i like it a lot. sounds wonderful. lets get this going. the 
time is NOW to kill exchange.

-charles
http://www.thewybles.com/~charles
www.oserproject.org


Luke Kenneth Casson Leighton wrote:

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