[Samba] Re: [proposal] Samba Software Foundation
Charles N Wyble
charles at thewybles.com
Wed Dec 15 18:45:40 GMT 2004
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>
>--
>
>
More information about the samba
mailing list