Lowlevel
Lowlevel => tyndur => Thema gestartet von: mastermesh am 05. May 2005, 13:43
-
Unsere Team-Einteilung wird wie beim BSD-Projekt sein. Hier ein Zitat aus dem Artikel "Hintergrundwissen zu BSD" von Greg Lehey:
4.2. Wie erfolgt die Weiterentwicklung von BSD?
BSD-Kernel werden nach dem Open Source-Modell weiterentwickelt.
Jedes Projekt unterhält einen öffentlich zugänglichen
Quellcode-Baum, der mit dem Concurrent Versions System (CVS)
verwaltet wird, und alle Quellen des Projekts, die Dokumentation
und andere notwendige Dateien enthält. CVS erlaubt es Anwendern,
jede gewünschte Version des Systems "auszuchecken'' (mit anderen
Worten, eine Kopie des System zu erhalten).
Eine Vielzahl von Entwicklern trägt weltweit zur Verbesserung von
BSD bei. Dabei werden drei Typen unterschieden:
* Ein Contributor schreibt Code oder Dokumentationen. Ihm ist es
nicht gestattet, seinen Beitrag direkt in den Quellbaum
einfliessen zu lassen. Bevor dieser Code in das System
eingebracht wird, muss er von einem registrierten Entwickler,
dem Committer geprüft werden.
* Committer können Code in den Quellbaum einbringen, das heisst
sie besitzen Schreibrechte für den Quellcode-Baum. Um ein
Committer zu werden, muss man zuerst seine Fähigkeiten im
gewünschten Gebiet unter Beweis stellen.
Es liegt im Ermessen des Committers, ob er die Allgemeinheit
befragt, bevor er Ãnderungen am Quellbaum vornimmt. In der
Regel wird ein erfahrener Committer korrekte Ãnderungen
einfügen, ohne sich mit anderen abzustimmen. Ein Committer
des Documentation Projects könnte etwa typografische oder
grammatikalische Korrekturen ohne lange Diskussion
durchführen. Auf der anderen Seite sollten Ãnderungen mit
weitreichenden Konsequenzen vor dem Commit zur Begutachtung
bereitgestellt werden. Im Extremfall kann ein Mitglied des
Core Teams, das als Principal Architect fungiert, sogar die
Entfernung der Ãnderung aus dem Quellcodebaum veranlassen.
Dieser Vorgang wird als backing out bezeichnet. Alle Committer
werden durch eine E-Mail über die erfolgte A:nderung
informiert. Es ist daher nicht möglich, heimlich eine
Ãnderung durchzufu:hren.
* Das Core Team. Sowohl FreeBSD als auch NetBSD besitzen ein
Core Team zur Betreuung des jeweiligen Projekts. Da die Core
Teams erst im Projektverlauf entstanden, ist ihre Rolle nicht
genau definiert. Um ein Mitglied des Core Teams zu sein, muss
man kein Entwickler sein, obwohl dies die Regel ist. Die
Regeln der Core Teams unterscheiden sich von Projekt zu
Projekt, generell gilt aber, das dessen Mitglieder mehr
Einfluss auf die Richtung des Projekts haben als
Nichtmitglieder.
Diese Konstellation unterscheidet sich von Linux in einigen
Punkten:
1. Es sind stets mehrere Personen für das System verantwortlich.
In der Praxis ist dieser Unterschied aber nicht gravierend, da
zum einen der Principal Architect verlangen kann, dass
Ãnderungen zurückgenommen werden, und zum anderen auch beim
Linux-Projekt mehrere Personen das Recht haben, Ãnderungen
vorzunehmen.
2. Es existiert ein zentraler Aufbewahrungsort (Repository), in
dem die kompletten Betriebssystemquellen zu finden sind,
einschliesslich aller älteren Versionen.
3. BSD-Projekte pflegen das komplette "Betriebssystem'', nicht
nur den Kernel. Dieser Unterschied ist aber marginal, da weder
BSD noch Linux ohne Anwendungsprogramme sinnvoll einsetzbar
sind. Die unter BSD eingesetzten Applikationen sind oft
identisch mit denen von Linux.
4. Da beim BSD-Projekt nur ein CVS-Quellbaum gepflegt werden
muss, ist die Entwicklung übersichtlicher, und es ist
möglich, auf jede beliebige Version einer Datei zuzugreifen.
CVS ermöglicht auch inkrementelle Updates: Das
FreeBSD-Repository wird beispielsweise etwa 100 Mal pro Tag
verändert. Viele dieser Ãnderungen betreffen aber nur einen
relativen kleinen Bereich von FreeBSD.
-
Netter Text, aber wofür steht BSD überhaupt?
-
Berkley Software Distribution
BSD wurde an der Berkley Uni in Kalifornien entwickelt und basiert auf Unix. Mittlerweile hat BSD allerdings nicht mehr viel mit der Berkley Uni zu tun und im Source steckt keine einzige AT&T Unix Code mehr. Es gibt wie unter Linux verschieden Derivate, die bekanntesten sind FreeBSD, NetBSD und OpenBSD. BSD steht unter der BSD Lizenz für freie Software. Nicht zu verwechseln mit der GPL, da gibts wie ich annehme ein paar Unterschiede.
Wikipedia hilft weiter ^^
-
Einen ganz wichtigen: Weiterentwicklungen von BSD Code muss man im Gegensatz zur GPL nicht wieder unter der BSD Lizenz veröffentlichen.
-
Auf jeden Fall sollten wir es so machen, dass man den Code nicht wieder OpenSource machen muss. Es gibt ja Lizenzen, da muss man sogar alle Software, die man z.B. mit einem Compiler braut OpenSource oder Freeware machen, was doch sehr von der Benutzung solcher Tools abhält, auch, wenn es net schlecht is an sich.
-
BSD ist so...genau das schrieb Legend auch :D
-
Die LGPL ist auch ziemlich sinnvoll, Weiterentwicklungen am Programm selber muss man offen legen, aber wenn man z.B. als Weiterentwicklung eine Schnittstelle zum Laden von Modulen entwickelt, kann man die Module dann unter eine Closed Source Lizenz stellen.
Z.b. beim GNU Classpath für Java ist die Lizenz sehr unglücklich gewählt mit der GPL, da dies bedeutet das man kein closed source Programm mit diesem Classpath laufen lassen dürfte, d.h. z.b. nicht die freie Java VM kaffee benutzen darf, es sei denn kaffee es gibt noch einen anderen Classpath mit dem kaffee arbeiten kann.
-
wie gesagt, alles, was den user arg zu etwas zwingt, was er nicht will sollten wir unterlassen. wirkt nur negativ... freeware bei programmen ja, aber open source nein. vielleicht sollten wir auch freeware als zwang weglassen. ich will auch mit meinem code machen, was ich will und mich nicht zu etwas zwingen lassen, was ich mit dem zu machen habe...
-
Ich persönliche finde auch hier das Konzept von BSD sehr gut... es schützt die Software, ohne zu sehr zu begrenzen.
http://www.opensource.org/licenses/bsd-license.php
-
Nun hab ich mir den Text schon durchgelesen, ich finde das Konzept auch sehr gut.
Also wenn niemand was dagegen hat, kann man das ja auch so irgendwie umsetzen
-
Oder man nimmt einfach exakt die BSD-Lizenz anstatt das "so ungefähr" umzusetzen ;D