[Samba] Re: [proposal] Samba Software Foundation

[Gémes Géza]

Charles N Wyble írta:

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

Yes it realy sounds wonderful, and the basic idea probably is, but I 
dislike the reiteration of personal tastes, and dislikes.
Imposing "if xy would say something negative about me I'll take my ball 
with me and won't play again with you until you would force him to 
leave" IMHO sounds too childish in an OSS software organizations ruleset :-(

Cheers,

Geza Gemes

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

-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba