(Ich doziere doch so gerne, sorry ;)
Bytecode heißt so, weil die Maschinenbefehle typischerweise jeweils 1 Byte groß sind. Das ist sehr kompakt. Ein traditioneller Forth-Interpreter beispielsweise hat Befehle (eigentlich Sprungadressen), die ein Maschinenwort (z.B. 2 Byte auf einer 16-bit-Maschine) groß sind. Ein CISC-Prozessor wie der 80x86 hat's gemischt, ein RICS-Prozessor (etwa SPARC) hat meist einheitliche und große Befehle. Mit Bytecode meint man außerdem meist einen Befehlssatz für einen virtuellen Prozessor. Eigentlich ist auch der x86-Befehlssatz für einen virtuellen Prozessor, den längst haben die modernen Intel-Prozessoren intern einen anderen Befehlssatz und interpretieren die traditionellen Befehle durch Microcode-Makros. Man spricht hier dennoch auch von Maschinencode.
Assembler ist übrigens eine für Menschen lesbare textuelle Umschrift der Maschinenbefehle, also z.B. `LD HL, 1234H` statt der Bytefolge `213412`. Makro-Assembler fügt dann da noch einfache Abstraktionen wie das Benennen von Sprungmarken und Codeblöcken hinzu.
GCC spukt kein "Opensource" aus. GCC spuckt Maschinencode aus, im Fall von gcj auch Bytecode für die Java virtuelle Maschine (JVM). Möglicherweise gibt es andere Endstufen, ich meine mich an eine für die LLVM zu erinnern.
Eine Opensource-Lizenz kann es nur für den Quelltext geben, den man mit GCC verarbeitet hat. Diese Lizenz kann der Urheber (also Schreiber) des Quelltexts ausgeben. Was der GCC damit macht, ist unerheblich.
.dll- oder .exe-Dateien enthalten neben diversen Verwaltungsinformationen für einen Linker, der symbolische Adressen zu Betriebssystemfunktionen beim Laden automatisch auflöst, auch nur Maschinencode und diesen kann man mehr oder weniger einfach analysieren. Wer etwa in seinem Programm einen Kopierschutz einbauen will, der ungefähr so funktioniert, hat schon verloren:
Code: Alles auswählen
gültig = komplizierteLizenzBerechnung()
if not gültig:
showDialog("Lizenz ist ungültig")
exit(1)
So was ist leicht zu finden und man muss nur ein Byte tauschen, nämlich das von dem "jump-zero"-Befehl in einen "jump-non-zero"-Befehl, denn meist haben Prozessoren beides. Anders gesprochen: Man muss das "not" entfernen, vielleicht kann man auch diesen Befehl mit einem "no-op"-Befehl überschreiben.
Ich halte es in dem Wikipedia-Artikel für sehr unglücklich, Compiler zu erwähnen. Denn ob und wie eine Programmiersprache kompiliert wird, ist in der Regel ein Implementierungsdetail. Ob Python kompiliert wird oder nicht spielt keine Rolle, Hauptsache, das Verhalten ist wie es sein muss. Die meisten Programmiersprachen nutzen eh Mischformen, etwa in dem sie in einen Zwischencode kompilieren, der dann leider interpretiert werden kann.
Das beliebige Kopieren leitet sich IMHO nur aus dem Fakt ab, dass der Quelltext verfügbar sein muss. Da ich damit theoretisch ein neue Binärversion erstellen könnte, kann ich auch gleich diese kopieren. Es ist aber keine eigenständige Forderung. Und natürlich darf ich die Software verkaufen. Es macht eventuell nur nicht so viel Sinn, da sich mein Kunde die Software aus dem Quelltext auch selbst erstellen könnte oder dies einen dritten machen lassen kann, der es billiger oder kostenlos macht.
Übrigens: Es gibt keine Sicherheit. War das Überwinden des Xbox-Schutzes noch recht einfach, weil die Entwickler einen dummen Fehler gemacht hatten, der die "chain of trust" unterbrach, musste man für die Xbox-360 schon mal einen Prozessor Schicht für Schicht unter einem Elektronenmikroskop betrachen (wenn ich das richtig in Erinnerung habe) um so an Schlüssel zu kommen. Denn eigentlich treibt die Xbox-360 einen sehr hohen Aufwand damit etwa der Startcode niemals den Microprozessor verlässt - würde er im Hauptspeicher liegen, könnte man den Bus zwischen Prozessor und Speicher abhorchen. Am besten macht man seine Software so unattraktiv oder so günstig, dass niemand sich die Mühe macht, da einen Schutz zu umgehen. Oder aber, man hat so ein Ansehen, dass die Leute sich moralisch verpflichtet fühlen, die Software auch zu bezahlen. Das ist der IMHO beste Weg.
Schließlich: Python ist natürlich geeignet für Opensource-Projekte. Auch Microsofts C++-Compiler ist es. Wie kommst du, Hannes-Spz, zu dieser Schlussfolgerung. Die Lizenz des Compilers oder Interpreters färbt in der Regel nicht auf das ausgeführte Programm ab - oder umgekehrt.
Stefan