[disc] BitKeeper/kernel gemorrel

[Verwijderd]

N.a.v. [url=http://yro.slashdot.org/yro/02/10/06/0518220.shtml?tid=106]dit artikel[url] op Slashdot dit topic. BitKeeper, het closed-source, commerciele CVS-achtige systeem dat gebruikt wordt om de ontwikkeling van de kernel en het inpassen van de vele patches die hiervoor dagelijks worden aangeleverd, schijnt sinds enige tijd in haar EULA een clausule te hebben staan, die het gebruikers van het product verbiedt om, via BitKeeper zelf of anderzijds, een concurrent van BitKeeper te ontwikkelen, of een product met vergelijkbare functies, zelf of via andere personen in hetzelfde bedrijf.

Dit betekent dat een 'bedrijf' als Debian, wat developers in dienst heeft die aan de kernel werken, verboden is om developers in dienst te hebben die aan een concurrent werken van BitKeeper, zoals CVS of SubVersion (de opvolger van CVS, momenteel in ontwikkeling).

Een mailtje op de Debian mailinglist:

It has come to the attention of several Debian developers that any of us
may be exposed to tort claims from BitMover, Inc., the company that
produces BitKeeper, the software that is in wide usage as a
revision-control system among Linux kernel developers.

Specifically, the BitKeeper license states the following:

(d) Notwithstanding any other terms in this License, this
License is not available to You if You and/or your
employer develop, produce, sell, and/or resell a
product which contains substantially similar capabil-
ities of the BitKeeper Software, or, in the reason-
able opinion of BitMover, competes with the BitKeeper
Software.

Note the broad sweep of these terms.

If:

1) you

OR

2) the company you work for

A) develops

OR

produces

OR

C) sells

OR

D) resells

*) anything containing functionality substantially similar to BitKeeper

OR

**) anything which, in the "reasonable" opinion of BitMover, competes
with BitKeeper

...you have no license to use the BitKeeper software. To use the
software legally under any conjunction of the above circumstances, you
will have to pay BitMover for a license.

Take special note that:

* The license on the "anything" containing substantially similar
capabilities to BitKeeper *does not matter*. In other words, if you
or employer develops, produces, sells, or resells anything containing,
say Subversion or CVS, you have no gratis license to use BitKeeper.

* BitMover reserves the right to express its "reasonable opinion" about
what does and does not compete with BitKeeper. The burden is on *you*
to persuade them in *each* and *every* case that the work you do
doesn't "compete" with BitKeeper. Alternatively, you could take
BitMover to court and seek something like a declaratory judgement.

Specifically, this problem has been seen to affect Ben Collins, former
DPL and GNU C Library maintainer, who just happens to work on both the
Subversion project -- a freely-licensed revision control system designed
to supplant CVS -- and the Linux 1394 ("FireWire") Project.

Because the Debian Project distributes revision control tools like RCS,
CVS, and Subversion (and Arch in the near future, if we don't already),
and because we are a large organization with many members who likely
have many different employers, I felt ethically obliged to bring this
issue to the Project's attention.

Until and unless BitMover changes the license on BitKeeper to eliminate
this onerous clause, the wisest course of action may be to refrain from
using BitKeeper altogether. You may also want to bring this problem to
the attention of your employer, if you think it is likely that your
organization may be affected.

To read more about this issue, see your favorite archive of the
linux-kernel mailing list. For example:

http://www.uwsg.indiana.e...x/kernel/0210.0/1496.html

I express no opinion as to whether to the requirements of the BitKeeper
license are legitimate, valid, or enforceable in any particular
jurisdiction. If you are concerned about this issue, please retain
counsel.

Ahum? Het blijkt ook werkelijk in praktijk te worden gebracht, zoals bijvoorbeeld is te lezen in dit bericht op de kernel mailinglist: de licentie om bitkeeper van deze persoon is ingetrokken omdat hij, buiten Bitkeeper om, aan een concurrent werkt:

On Sat, Oct 05, 2002 at 01:54:37PM -0400, Ben Collins wrote:
> Larry, I develop for the Subversion project. Does that mean my license
> to use bitkeeper is revoked?

Yes. It has been since we shipped that license or when you started working
on Subversion, whichever came last.

> I've also been wanting to use bitkeeper to create a Subversion mirror of
> the kernel repository, but I suspect that my usage falls seriously into
> this category, as my reasons for doing so are three-fold; allow access
> to the bkbits repo to folks who don't want to use bk, but with all the
> joys of an SCM (history, changesets, etc.); stress test Subversion
> against a real-world high-activity repo; promote Subversion.
>
> Would it be your intention that your license disallow my type of work? I
> think it does.

You bet it does. The Subversion folks would like nothing better than
to displace BK. That's fine, but they don't get to use BK to do it.
You're absolutely correct that you could use BK to make Subversion better.
It is not our job to help you make Subversion better and we've made that
clear for a long time.

We're a business. We're a business which happens to be committed to
helping the kernel team because we think that the kernel is vital to
the world at large. Helping the kernel absolutely does not translate
to helping people who happen to be our competitors. By your own
description and by our experience with you, you would be a competitor.

And since we're here, I'll take this opportunity to remind you that when I
asked about getting a netwinder so I could support the ARM folks, you were
the guy who sent me mail saying you had some that you weren't using and
that we couldn't have one because you didn't like our license. If I recall
it was either that mail exchange or a subsequent one in which you made it
clear that you were working on Subversion so Subversion could replace BK.

You're the guy that refused to help us help the community. And you made
it clear that you'd be delighted if Subversion was made good enough to
replace BK and you were working towards that goal. I can't imagine a
better example of someone who we absolutely do not want to support and
do not want using BK. I am explicitly stating that it is our view that
your use of BK is violation of our license.

Ik vind het belachelijk dat BitKeeper nog een seconde langer wordt gebruikt en wat mij betreft mag BitKeeper, ondanks haar (volgens de eigenaar) zo goede bedoelingen om de Linux Kernel ontwikkeling van dienst te zijn, nog op dit moment in /dev/null worden gegooid. Dit soort praktijken en/of regeltjes gaan absoluut niet samen met het idee achter Free Software, en moet dus ook niet gebruikt worden om de kernel te ontwikkelen. Gebruik dan gewoon CVS of SubVersion (voor zover dat al bruikbaar is).

Meningen?

[Confusion]

Het betekent domweg dat niemand meer tegelijk aan Subversion kan werken en een kernel developer kan zijn.

Twee van de reacties op /.

In Related News... (Score:2)

Microsoft announce that all Windows licenses held by Open Source developers are null and void.

The BSA will be knocking on the door any minute... follow the white rabbit.

en

Alan Cox? (Score:3, Insightful)

Does Alan Cox use BitKeeper, and if so, does he pay for his copy? I would imagine not, given his stances on free software and intellectual property.

I'd like to point out that Alan Cox works for RedHat, whose operating system includes CVS. I would venture to guess that RedHat hackers have contributed to CVS, at the very least with a 1-line diff here or there. This makes RedHat both a reseller and a developer of CVS, and even if he doesn't personally have anything to do with CVS (doubtful) he is forbidden from using the openlogging version.

I find it ironic that at a time when BitKeeper is trying to sway developers toward their product, they create onerous conditions which prevent a prominent developer and political spokesman from using said product on any sort of trial basis.

Technically, I suppose I'm not allowed to use BitKeeper either, since I've written (and released, I think; I'll have to double-check) an add-on to CVS which parses and cross-references checkin logs.

The really funny thing is that CVS is quite prevalent in the free software world, where it is extremely common to create patches and add-ons. The most effective referrals to BitKeeper would be from CVS hackers or those otherwise extremely experienced with it, but by preventing precisely these people from trying BitKeeper out, the one thing that could help BitKeeper the most -- a public defection from a "pet project" -- is verboten.

It's rare that we get to see such an obvious case of shooting oneself in the foot.

[Ronald]

On Sat, Oct 05, 2002 at 01:54:37PM -0400, Ben Collins wrote:
> Larry, I develop for the Subversion project. Does that mean my license
> to use bitkeeper is revoked?

Yes. It has been since we shipped that license or when you started working
on Subversion, whichever came last.

Als Ben Collins bitkeeper heeft verkregen onder de oude licentie waarin niet staat dat hij niet aan SubVersion mag werken dan mag hij gewoon met bitkeeper blijven werken. Bitmover INC kan niet de nieuwe licentie opdringen aan of de oude afnemen van Ben zonder dat Ben minimaal een update onder de nieuwe licentie van Bitmover gebruikt of de oude licentie overtreed.....

Of snap ik software licenties weer eens niet


Waar het uiteindelijk om gaat is wat er in de tekst staat en niet wat Larry van bitkeeper allemaal belooft. Enige wat ie goed kan is heel vaak in die lmkl draad herhalen hoe goed bitkeeper wel niet is voor Linux

Unisys/GIF ... Texas_Fuckup/JPEG .... straks Thomson/MP3 en Bitmover/Bitkeeper ??

Mijn non-kernel-devver mening:

Lozen dat bitkeeper zolang het nog kan; Subversion moet alles gaan kunnen wat bitkeeper doet als ik het allemaal begrijp..


[toevoeg]

Larry beweerd zeer genereus te zijn door een T1 te hebben en $1600 uit te geven per maand om de bandbreedte die het kernel project verbruikt te kunnen garanderen...
Dat is klinkklare onzin natuurlijk: $1600 is een absoluut lachertje voor een prestige project als de Linux-Kernel. Redhat, Suse, Mandrake en co geven elk veelvouden uit aan mensen om aan de kernel te werken en krijgen er significant minder exposure van.

Larry is een beetje goedkoop ?

[/toevoeg]

[ Voor 0% gewijzigd door Ronald op 06-10-2002 16:39 . Reden: toevoeging ]

[Verwijderd]

Bitkeeper is altijd al een commercieel produkt geweest. Nu zeggen ze alleen dat als je de *gratis* versie wilt gebruiken, dan moet je niet hun produkt na gaan bouwen. Dat klinkt mij niet onredelijk in de oren.

Larry heeft bovendien nog in the thread aangegeven hoe je checkouts kan doen van bk trees zonder bk te gebruiken. Geen probleem dus.

[Verwijderd]

Verwijderd schreef op 06 oktober 2002 @ 16:49:
Bitkeeper is altijd al een commercieel produkt geweest. Nu zeggen ze alleen dat als je de *gratis* versie wilt gebruiken, dan moet je niet hun produkt na gaan bouwen. Dat klinkt mij niet onredelijk in de oren.

... voor een commercieel project.

De Linux kernel is een opensource project, en niet de minste ook. Voor free software zijn dit soort voorwaarden gewoon not done, of het nou om het product zelf gaat, of om de producten die daarbij worden gebruikt (imho).

[u_nix_we_all]

Verwijderd schreef op 06 oktober 2002 @ 17:31:
[...]


... voor een commercieel project.

De Linux kernel is een opensource project, en niet de minste ook. Voor free software zijn dit soort voorwaarden gewoon not done, of het nou om het product zelf gaat, of om de producten die daarbij worden gebruikt (imho).

Helemaal mee eens. En als BitKeeper dan OOK nog eens zulke voorwaarden stelt,
zodat je niet aan bepaalde projecten mag meewerken omdat ze daar schade van
kunnen ondervinden, (wat ze overigens best mogen doen) dan is het duidelijk
dat de Open Source community er alleen maar bij gedient is dat de kernel source
ontwikkelaars er geen gebruik meer van maken.

Ik hoop alleen maar dat dit hele gedoe niet alweer een tweedeling tussen verschillende
groepen veroorzaakt , met enerzijds mensen die bitkeeper wel willen blijven gebruiken
en anderszijds zij die dat niet willen of niet kunnen... Dat zou pas echt kwalijk zijn...

[Confusion]

RonaldH schreef:
Als Ben Collins bitkeeper heeft verkregen onder de oude licentie waarin niet staat dat hij niet aan SubVersion mag werken dan mag hij gewoon met bitkeeper blijven werken. Bitmover INC kan niet de nieuwe licentie opdringen aan of de oude afnemen van Ben zonder dat Ben minimaal een update onder de nieuwe licentie van Bitmover gebruikt of de oude licentie overtreed.....

Bij Bitkeeper schijnt het geval te zijn dat ze zich
a) Voorbehouden de oude license te kunnen revoken, maar ook
b) Verplicht stellen 'free'-gebruikers de nieuwste versie te gebruiken, omdat ze ook de beta-testers zijn.

Als 1 van beide waar is, kunnen ze dus inderdaad iemand een nieuwe licentie opdringen. Daarom wordt de free versie van BitKeeper ook niet bij Debian gedistribueerd: de license is te restricted voor echte 'free' software.

Als a) waar is, dan zijn een heleboel mensen inconsequent dat ze niet net zo moord en brand schreeuwen als ze bij Microsoft deden toen die dezelfde grap met de EULA uithaalde.

[Verwijderd]

u_nix_we_all schreef op 06 oktober 2002 @ 17:48:
[...]

Helemaal mee eens. En als BitKeeper dan OOK nog eens zulke voorwaarden stelt,
zodat je niet aan bepaalde projecten mag meewerken omdat ze daar schade van
kunnen ondervinden, (wat ze overigens best mogen doen) dan is het duidelijk
dat de Open Source community er alleen maar bij gedient is dat de kernel source
ontwikkelaars er geen gebruik meer van maken.

Linus heeft nu meer tijd om de patchen te bestuderen en hoeft minder tijd te verspillen bij het 'source managen'. Dit levert dus een snellere ontwikkeling, er gaan minder patches verloren en het ligt dus in de lijn dat het een beter open source produkt oplevert. De Open Source community is er dus bij gediend dat kernel ontwikkelaars van BK gebruik maken.

[odysseus]

Verwijderd schreef op 06 oktober 2002 @ 19:21:
Linus heeft nu meer tijd om de patchen te bestuderen en hoeft minder tijd te verspillen bij het 'source managen'. Dit levert dus een snellere ontwikkeling, er gaan minder patches verloren en het ligt dus in de lijn dat het een beter open source produkt oplevert. De Open Source community is er dus bij gediend dat kernel ontwikkelaars van BK gebruik maken.

Op de korte termijn wel. Maar op langere termijn is het uitsluiten van mensen bij de ontwikkeling iets dat absoluut niet mag gebeuren. GNU - en dus de GPL - is nu net ontstaan *omdat* iemand (Stallman) niet aan de ontwikkeling van een stuk software kon meewerken, als je dat in stand wilt houden dan moet je ervoor zorgen dat iedereen aan de ontwikkeling van een stuk software kan meewerken. Je moet dan dus geen hulptools gaan gebruiken die bepaalde mensen van deelname uitsluiten, zoals dat nu door het gebruik van BitKeeper gebeurt.

[Verwijderd]

odysseus schreef op 06 oktober 2002 @ 19:59:

[...]

Op de korte termijn wel. Maar op langere termijn is het uitsluiten van mensen bij de ontwikkeling iets dat absoluut niet mag gebeuren. GNU - en dus de GPL - is nu net ontstaan *omdat* iemand (Stallman) niet aan de ontwikkeling van een stuk software kon meewerken, als je dat in stand wilt houden dan moet je ervoor zorgen dat iedereen aan de ontwikkeling van een stuk software kan meewerken. Je moet dan dus geen hulptools gaan gebruiken die bepaalde mensen van deelname uitsluiten, zoals dat nu door het gebruik van BitKeeper gebeurt.

Maar dit is helemaal niet aan de orde. Niemand wordt uitgesloten uit het ontwikkelingstraject. Je wordt uitgesloten van het gratis verkrijgen van een hulpmiddel bij de ontwikkeling als je bezig bent met het maken van een vergelijkbaar hulpmiddel.

Je kan nog steeds de patches downloaden zoals voordat Linus BK ging gebruiken.

[Verwijderd]

Verwijderd schreef op 06 oktober 2002 @ 20:18:
Maar dit is helemaal niet aan de orde. Niemand wordt uitgesloten uit het ontwikkelingstraject. Je wordt uitgesloten van het gratis verkrijgen van een hulpmiddel bij de ontwikkeling als je bezig bent met het maken van een vergelijkbaar hulpmiddel.

Je kan nog steeds de patches downloaden zoals voordat Linus BK ging gebruiken.

Patches submitten gaat voornamelijk via BK - BK gebruiken is dus zo ongeveer een vereiste. Bovendien is het ook een principekwestie.

[Ronald]

Verwijderd schreef op 06 oktober 2002 @ 20:32:
[...]


Patches submitten gaat voornamelijk via BK - BK gebruiken is dus zo ongeveer een vereiste. Bovendien is het ook een principekwestie.

Wat ik las op lmkl vereist BK-gratis iets wat akelig dicht bij spyware licht.... Onder windows wordt daar stennis over geschopt, maar de linux kernel wordt het geaccepteerd... heel vreemd.

Waar het gewoon op neerkomt is dat een alternatief source management systeem nodig is kwa functionaliteit even goed als BK, maar zonder de idioterie licence van BK.
Zo goed als elke major kernel contributer (IBM SGI Suse Redhat .... ) moet nu bedelen bij Bitmover of ze alsjeblieft Bitkeeper mogen gebruiken ook al hebben ze te maken met development van CVS en SubVersion... Compleet belachelijk?

[Verwijderd]

Hmm, ik sta geloof ik alleen.. nog 1 keer dan..

RonaldH schreef op 06 oktober 2002 @ 20:40:
[...]
Zo goed als elke major kernel contributer (IBM SGI Suse Redhat .... ) moet nu bedelen bij Bitmover of ze alsjeblieft Bitkeeper mogen gebruiken ook al hebben ze te maken met development van CVS en SubVersion... Compleet belachelijk?

Lees: een major kernel contributor in dienst van een bedrijf als SGI Suse Redhat en ook gebruik wil maken van een handige tool om zijn werk sneller te doen moet in principe betalen voor de tool (hoewel ze niet zo strikt zijn als je even een emailtje stuurt) .. Compleet belachelijk?

[odysseus]

Nee, dat is niet compleet belachelijk. Het is wel onaanvaardbaar voor de Linux-kernelontwikkeling, aangezien het in strijd is met alle principes waardoor Linux groot is geworden. Larry wens ik heel veel succes toe met de verkoop van zijn software - en ik geloof best dat het goede software is, maar als het aan mij ligt dan heeft hij geen Free Software-ontwikkelaars in zijn klantenbestand zitten.

[Verwijderd]

Dit is niet de eerste dicussie over de licentie van Bitkeeper op de LKML. En als ze het blijven gebruiken zal het ook niet de laatste zijn denk ik. Deze voorwaarden gaan inderdaad veel te ver en maken daardoor het gebruik van BK mijns inziens voor de Linux kernel onmogelijk.

[XTerm]

Ik ben altijd al tegen BK geweest , maar heb er nooit over gesproken omdat uiteindelijk de kernel developers zelfs moeten weten waar ze in ontwikkelen.
Echter, deze licentie begint gevaarlijk te worden voor een zeer belangrijk project in de Free software gemeenschap. Daarom denk ik, en dat is waarschijnlijk ook wat er zal gebeuren, dat het best is om Bitkeeper niet meer te gebruiken.

Echter, dit is gemakkelijker gezegd dan gedaan. Atm is er geen Vrij, volwassen pakket dat de kernelcode kan beheren. Downgraden naar CVS is een mogelijkheid, maar ik denk niet dat de devvers dat leuk gaan vinden.

Ik denk dat het zeer goedkoop is van de producent van BK, spijtig genoeg heeft hij hiermee zijn bedrijf ook quasi vernietigd, iets wat ik jammer vind voor z'n werknemers.

[odysseus]

Zijn bedrijf vernietigd? Hij heeft nog wel meer klanten dan die niet-betalende kerneldevelopers . Hij kan zijn software nog makkelijk kwijt aan commerciële software-ontwikkelaars die geen last van licentieproblemen zullen hebben.

[Verwijderd]

Verwijderd schreef op 06 oktober 2002 @ 21:14:
Lees: een major kernel contributor in dienst van een bedrijf als SGI Suse Redhat en ook gebruik wil maken van een handige tool om zijn werk sneller te doen moet in principe betalen voor de tool (hoewel ze niet zo strikt zijn als je even een emailtje stuurt) .. Compleet belachelijk?

Ja, want Linux is vrijheid, en die ben je nu (deels) kwijt. De rest doet er niet toe, weg met BK dus. Mag hard klinken, maar free software is dan maar hard. Je moet voor je principes blijven staan...

[bultoog]

het gene dat ik gek vind dat een bedrijf die een closed source programma ontwikkeld, de dienst gaat uit maken binnen een wereld waar open source en vrijheid hele belangrijke punten zijn.

en wat beelzebubu zegt kan heel goed mee in komen.

[Wilke]

Okay, Bitkeeper is een bedrijf, en ze willen winst maken op een gegeven moment. Door de concurrent te helpen doe je dat niet.

Tot zover de volledig terechte motivatie van de Bitkeeper-developers/eigenaar.

Dan denk ik: leuk en aardig allemaal, maar als het er nu dus zo bijstaat, dan is er maar 1 conclusie mogelijk: Bitkeeper is niet te gebruiken om de Linux Kernel Repository in bij te houden.

Dan wens ik Bitkeeper verder onnoemelijk veel succes met hun product, maar als ze (voor een bedrijf op zich vrij logische) eisen stellen die helaas voor een open source project als dit echt Totaal Niet kunnen, dan moet het maar in de bit bucket!

[Wilke]

Verwijderd schreef op 07 oktober 2002 @ 00:25:
Ja, want Linux is vrijheid, en die ben je nu (deels) kwijt. De rest doet er niet toe, weg met BK dus. Mag hard klinken, maar free software is dan maar hard. Je moet voor je principes blijven staan...

Precies, ik hoop dat de mensen om Linus heen hier nu ook weer (want dit is al eerder gedaan) flink over doorzagen en hem ervan weten te overtuigen dat ze een alternatief moeten zoeken, ook al gaat daardoor wellicht een maand tijd verloren. Da's dan gewoon erg jammer, maar dit kan zo gewoon niet langer (hoe lang heeft het nu al met al geduurd, een half jaar ofzo?)

Het is precies de MS-strategie: eerst klant zo ver krijgen dat 'ie iets nodig heeft, dan de license screwen om te zorgen dat dit zo blijft (door het de concurrentie onmogelijk te maken). Dat kunnen we met de Linux kernel gewoon pertinent niet riskeren.

[Verwijderd]

BK zorgt er bij niemand voor dat vrijheden worden afgenomen. Juist de mensen die beweren dat je developers flink moet lastig vallen om ervoor te zorgen dat ze BK niet meer gebruiken zijn bezig om een vrijheid van de programmeur af te nemen: de vrijheid om de ontwikkeltools te gebruiken die je wilt.

Overigens is het beweren dat de ontwikkelaars nu opeens BK nodig hebben FUD. Er zijn nog genoeg ontwikkelaars die prima zonder BK hun werk kunnen doen. Deze licentie zou juist een zegen moeten zijn. BK is niet voor iedereen gratis, dus het schrikbeeld dat bijv. Linus alleen BK patches gaat aannemen is er alleen maar kleiner op geworden.

[Wilke]

Verwijderd schreef op 07 oktober 2002 @ 14:47:
BK zorgt er bij niemand voor dat vrijheden worden afgenomen.

-1 Clueless BK zorgt hier dus wel voor - ik hoop dat ik niet het artikeltje moet gaan quoten om aan te geven hoe, maar omdat het dan lijkt alsof ik flame zal ik het even letterlijk aanhalen:


> Would it be your intention that your license disallow my type of work? I
> think it does.

You bet it does.

Juist de mensen die beweren dat je developers flink moet lastig vallen om ervoor te zorgen dat ze BK niet meer gebruiken zijn bezig om een vrijheid van de programmeur af te nemen: de vrijheid om de ontwikkeltools te gebruiken die je wilt.

Deels waar, maar helaas moet je het hier iets groter zien. Door een bepaalde tool te gebruiken kan bv. Debian a. niet verder gaan met het ontwikkelen van soortgelijke programma's als BK, of b. het risico lopen dat Linus hun patches (vaker dan normaal) negeert omdat ze niet netjes in het BK-systeem zitten (dat was nl. het probleem waarom ze in de eerste plaats zo'n systeem hebben opgezet).

Overigens is het beweren dat de ontwikkelaars nu opeens BK nodig hebben FUD.
Er zijn nog genoeg ontwikkelaars die prima zonder BK hun werk kunnen doen.
Deze licentie zou juist een zegen moeten zijn.

Wat jij zegt is 'er zijn genoeg mensen die zonder BK hun werk kunnen doen -> dus deze licentie is een zegen'. Het causale verband is iets wat ik even volstrekt mis (a.k.a. wat jij schrijft is eerder FUD), maar dat zal wel aan mij liggen

BK is niet voor iedereen gratis, dus het schrikbeeld dat bijv. Linus alleen BK patches gaat aannemen is er alleen maar kleiner op geworden.

BK is niet
Mis ik 'm nou, of....wat bedoel je daar mee? Waarom denk je dat Linus BK gebruikt: juist ja, om handig het overzicht te bewaren over alle patches. Wat ligt er dan voor de hand als mensen patches niet met BK gaan inleveren: juist ja...zoals voorheen helaas nogal eens gebeurde verdwijnen ze in /dev/lange-baan. Om dat op te lossen is BK aangeschaft!

Wat je dan dus zou krijgen is dat mensen voor BK moeten betalen om het voorrecht te krijgen dat hun patches met een grotere waarschijnlijkheid cq. eerder in behandeling worden genomen. Dat kan nooit de bedoeling zijn.

[bultoog]

bultoog schreef op 07 oktober 2002 @ 10:21:
het gene dat ik gek vind dat een bedrijf die een closed source programma ontwikkeld, de dienst gaat uit maken binnen een wereld waar open source en vrijheid hele belangrijke punten zijn.

en wat beelzebubu zegt kan heel goed mee in komen.

ik vraag dit (bovenstaande) me voornamelijk af, hoe denk iedereen daar over?


ik vindt BK moet opzouten uit de open source wereld. dat is alleen maar mij mening.

[Verwijderd]

Wilke schreef op 07 oktober 2002 @ 20:51:
[...]

-1 Clueless BK zorgt hier dus wel voor - ik hoop dat ik niet het artikeltje moet gaan quoten om aan te geven hoe, maar omdat het dan lijkt alsof ik flame zal ik het even letterlijk aanhalen:


> Would it be your intention that your license disallow my type of work? I
> think it does.

You bet it does.

Waar wordt in hemelsnaam een vrijheid afgenomen? BK geeft je een vrijheid onder bepaalde voorwaarden. Namelijk het gratis gebruiken van de software onder de licentie voorwaarden. Ik zie hier geen afname van vrijheden.

[...]

Deels waar, maar helaas moet je het hier iets groter zien. Door een bepaalde tool te gebruiken kan bv. Debian a. niet verder gaan met het ontwikkelen van soortgelijke programma's als BK, of b. het risico lopen dat Linus hun patches (vaker dan normaal) negeert omdat ze niet netjes in het BK-systeem zitten (dat was nl. het probleem waarom ze in de eerste plaats zo'n systeem hebben opgezet).
[...]

Ach, ik ben geen kernel developer, maar ik begreep dat Linus negeert omdat hij geen tijd heeft om alles goed te bekijken.. dat vermindert nu juist.

Wat jij zegt is 'er zijn genoeg mensen die zonder BK hun werk kunnen doen -> dus deze licentie is een zegen'. Het causale verband is iets wat ik even volstrekt mis (a.k.a. wat jij schrijft is eerder FUD), maar dat zal wel aan mij liggen

Sorry, dat is wat onduidelijk, ik bedoelde dat de licentie het aannemelijker maakt dat er niet alleen BK patches worden geaccepteerd (dat laatste doelde meer op je volgende quote).

[...]

BK is niet
Mis ik 'm nou, of....wat bedoel je daar mee? Waarom denk je dat Linus BK gebruikt: juist ja, om handig het overzicht te bewaren over alle patches. Wat ligt er dan voor de hand als mensen patches niet met BK gaan inleveren: juist ja...zoals voorheen helaas nogal eens gebeurde verdwijnen ze in /dev/lange-baan. Om dat op te lossen is BK aangeschaft!

Wat je dan dus zou krijgen is dat mensen voor BK moeten betalen om het voorrecht te krijgen dat hun patches met een grotere waarschijnlijkheid cq. eerder in behandeling worden genomen. Dat kan nooit de bedoeling zijn.

Tsja, je kan het ook omdraaien. Omdat hij nu meer tijd heeft, kan hij beter kijken naar de GNU patches. Ik vind het ver gezocht dat hij een goede GNU patch nu eerder zou gaan droppen om te wachten op een vergelijkbare BK patch.

[bultoog]

Verwijderd schreef op 08 oktober 2002 @ 00:38:
[...]
Waar wordt in hemelsnaam een vrijheid afgenomen? BK geeft je een vrijheid onder bepaalde voorwaarden.

beelzebubu:

itKeeper, het closed-source, commerciele CVS-achtige systeem dat gebruikt wordt om de ontwikkeling van de kernel en het inpassen van de vele patches die hiervoor dagelijks worden aangeleverd.

ik zie persoonlijk closed source als vrijheid vermindering(en beelzebubu ook, toch)(of heb ik het mis?), of heb heb ik het nu aan het verkeeerde eind.

[Verwijderd]

Er is imho alleen sprake van een vermindering van de vrijheid als je wordt gedwongen om een produkt te gebruiken waar je niet de gebruikelijke free software vrijheden over hebt. Bij bitkeeper is dit niet het geval. Je kan nog steeds aan de kernel ontwikkelen zonder bitkeeper. Dat er tools zijn die je mogelijk zou willen gebruiken maar niet vrij zijn, perken niet noodzakelijkerwijs jouw vrijheden in.

[bultoog]

Verwijderd schreef op 08 oktober 2002 @ 00:59:
Er is imho alleen sprake van een vermindering van de vrijheid als je wordt gedwongen om een produkt te gebruiken waar je niet de gebruikelijke free software vrijheden over hebt. Bij bitkeeper is dit niet het geval. Je kan nog steeds aan de kernel ontwikkelen zonder bitkeeper. Dat er tools zijn die je mogelijk zou willen gebruiken maar niet vrij zijn, perken niet noodzakelijkerwijs jouw vrijheden in.

bultoog schreef op 07 oktober 2002 @ 10:21:
het gene dat ik gek vind dat een bedrijf die een closed source programma ontwikkeld, de dienst gaat uit maken binnen een wereld waar open source en vrijheid hele belangrijke punten zijn.

ik vindt het toch een vreemde zaak

[Verwijderd]

bultoog schreef op 08 oktober 2002 @ 00:17:
ik vraag dit (bovenstaande) me voornamelijk af, hoe denk iedereen daar over?

ik vindt BK moet opzouten uit de open source wereld. dat is alleen maar mij mening.

Ben ik grotendeels met je eens. Closed-source stuff is best, maar niet als basis van de opensource ontwikkeling. Dus als IDE MSVC++ gebruiken voor de kernel zou bij mij er niet in gaan, net zomin als Borland Builder of wat dan ook. En datzelfde geldt dus ook voor BK.

[Verwijderd]

/me *

Woei! Onze grote dorpsdwaas RMS heeft ook weer wat gezegd:

http://slashdot.org/articles/02/10/14/0216256.shtml?tid=117
http://www.linuxandmain.c...News&file=article&sid=253

Gaat dit nog ergens over? .

And within a 90 minutes, Larry McVoy of BitKeeper added his view:
"Our position:
"1) No free licenses for our competition, they can buy them if they like.
"2) The software is not open source because the open source business model doesn't have a prayer of supporting the development costs.
"3) If you had built a decent system instead of sitting around and whining, we could be doing something else instead of sitting around listening to your whining."

Daar wordt je gewoon blij en triest tegelijk van, je zou Larry bijna gelijk geven vanwege punt (3). .

[Verwijderd]

Heeft iemand een mirror van dat linux&main artikel? Ik krijg al (sinds gisteren) "Sorry, this Module isn't active!" op die link.

Over de reactie van McVoy:
1) Hij wil concureren met open-source initiatieven, dus hij moet niet raar opkijken als de open-source beweging zich op zijn pik getrapt voelt.
2) Zoals het nu is, zullen kernel-developers die door dit licencie-geouwehoer moeten betalen voor BK zich het zelfde moeten afvragen als BK: is het nog wel rendabel linux op BK te ontwikkelen, of wordt het te duur? (En moeten wij evt. BK voor linux laten betalen?)
3) Op deze manier ad hominem gaan tegen RMS heeft vrijwel zeker een averechts effect. RMS heeft genoeg invloed om dit inderdaad waar te maken, en als hij een gratis versioning-system produceert dat even goed is als BK, is BK history.

[Verwijderd]

Linuxmain is een beetje kapoet momenteel. .