Wie code teilen ohne alles zu zeigen?

Dazu nutzt man Konfig-Parameter welche dann in einem nicht flüchtigen 
Speicher gespeichert werden. Warum soll der User was am Code selber 
ändern?

Ansonsten, kannst du natürlich deinen Code als lib rausgeben, mit 
definierten Schnitstellen. So wie alle libs halt.

Das ist aber eine Frage der Anwendung. Geht es um normale User, dann ist 
es eine Konfiguration von ein paar Paramentern. Geht es um Entwickler, 
die deinen Code nutzen sollen, dann nimmst die lib.

gruß cyblord

Verwunderter schrieb:
> Warum wollen alle immer nur ihren Code verstecken?

Ein Beweggrund kann sein, daß man glaubt, ein "Geschäftsgeheimnis" 
schützen zu wollen, oder so genialen Code geschrieben zu haben, daß den 
kein anderer für sich nutzen können soll.

Ein anderer Beweggrund kann in der abgrundtiefen Qualität des Codes 
liegen, der zwar irgendwie funktioniert, aber so grottig schlecht 
geschrieben ist, daß es dem Nicht-Veröffentlicher peinlich wäre, würde 
das jemand zu Gesicht bekommen.

Böse Unken unterstellen einem großen nordwestamerikanischen Softwarehaus 
die zweite Variante.

Rufus Τ. Firefly schrieb:
> Ein Beweggrund kann sein, daß man glaubt, ein "Geschäftsgeheimnis"
> schützen zu wollen, oder so genialen Code geschrieben zu haben, daß den
> kein anderer für sich nutzen können soll.

Ja, das geben die meisten vor, auch wenn das hier:

Rufus Τ. Firefly schrieb:
> Ein anderer Beweggrund kann in der abgrundtiefen Qualität des Codes
> liegen, der zwar irgendwie funktioniert, aber so grottig schlecht
> geschrieben ist, daß es dem Nicht-Veröffentlicher peinlich wäre, würde
> das jemand zu Gesicht bekommen.

.. meistens sicherlich der echte Beweggrund sein duerfte.

Oft vergisst der Author dass er die komplette GNU Toolchain nutzt und 
was die Idee dahinter war.

Wieviele "Verstecker" sind sich eigentlich der Lizenz bewusst die ihre 
SW hat?
zB. mal eben hier und da ein paar GCC spezifische Compiler-Erweiterungen 
verwendet, mal die eine oder andere GPL lizensierte Lib eingebunden.. 
das muesste einem doch die GPL aufzwingen?

ich sag immer:

Wenn die Konkurrenz den Quellcode in die Hand bekommt, das wirft die um 
Jahre zurück ;)

Bei einer Library ist normalerweise nur die Schnittstelle aber nicht die 
Implementierung als Quellcode sichtbar.

Jochen schrieb:
> Das ist echt lästig ich arbeite sehr gerne mit Preprozessor Anweisungen
> wie defines und ifdef Anweisungen.
> Das ist gerade der Grund warum ich gefragt habe, der Code ist sehr
> leicht anpassbar, aber niemand müsste alles sehen können um ein paar
> Details zu verändern.
>
> Da die Änderungen nur während der Inbetriebnahme nötig sind, ist eine
> Veränderung zur Laufzeit unnötig kompliziert.

INterne statische Funktionen umbenennen, Alle Variablen, die ein 
Benutzer normalerweise nicht sieht und die auch keine Funktionsargumente 
an der Schnittstelle sind auf i00 bis i99 umbenennen. Alle Leerzeichen 
aus Nicht-Strings raus. Zeilenumbrüche manachmal raus. Alle Anweisungen 
beginnen am linken Bildschirmrand - Einrückung was ist das?

So 'aufbereitet', dürftest du schon mal den größten Teil der 
Programmierer aus deinem Source Code fernhalten. Wenn du dann auch noch 
die nicht-abhängigen Teile vorkompiliert in einer Library lieferst, 
dürfte auch dem letzten die Lust vergangen sein, deinen Code zu 
analysieren. Da geht er lieber zur Konkurenz von der er sicher sein 
kann, auch in ein paar Jahren noch was geliefert zu bekommen und zur Not 
auch mal selbst einen Mann im eigenen Haus dran setzen zu können.

Jochen schrieb:
> Das ist echt lästig ich arbeite sehr gerne mit Preprozessor Anweisungen
> wie defines und ifdef Anweisungen.

Die kannst du natürlich nicht direkt in einer Bibliothek benutzen.

Man kann aber von #defines abhängig globale Variablen (Arrays) anlegen,
die die Bibliothek dann als extern deklariert bekommt.  Auf diese Weise
wurden vor 20 Jahren die ganz geheimen closed-source-Unixe parametriert:
zu jedem Treiber gab es noch so einen C-Stub, der dann entsprechend
compiliert worden ist.  Am Ende wurde dann alles gelinkt.

Aus heutiger Sicht unglaublich, welch Aufwand man dafür getrieben hat.
Letztlich hat ja $KUNDE all diesen Aufwand mit bezahlen müssen.

Oliver schrieb:
> Jochen schrieb:
>> und so.
>
> Ganz ehrlich - nee, sag ich lieber nicht.
>
> Wie Karl-Heinz schon schrieb, in den allerseltensten Fällen ist Code so
> einzigartig und wertvoll, daß sich dafür irgend jemand das Gehampel mit
> solchen Verschlüsselungen antut.

Ist letzten Endes ja auch eine Kostenfrage.
Hast du eine wirklich gute Funktionalität in einer komplexen Lib, dann 
kannst du dafür ein paar Tausender verlangen. Je komplexer desto teurer.
Ist die Funktoin nicht so komplex, dann eben etwas billiger.

Aber letzten Endes ist die Kardinalfrage für jede Firma immer: Was hätte 
ich an internen Kosten, wenn ich das Zeug nicht zukaufe sondern in Haus 
selbst entwickeln lasse. Und mit ein paar Tausend Euro hüpft man in 
einer Firma nicht weit. Sitz einen Mann eine Woche dazu, damit der das 
programmiert (nachprogrammiert) und du hast intern schon ganz erhebliche 
Kosten dafür. Da kann man um dieses Geld schon einiges zukaufen, WENN 
der Lieferant zuverlässig ist. Macht der aber auf Geheimniskrämer, dann 
überleg ich mir das 2-mal. Denn ich hab ja auch nichts davon, wenn der 
Programmierer nicht mehr greifbar ist mit Code dazusitzen, den keiner 
mehr warten kann, den ich aber dringend brauche und dann muss ich erst 
recht in die Eigenentwicklung.

Ab einer gewissen Komplexität ist dann genau diese Komplexität sowieso 
schon mal ein gewisser Schutz. Denn das Zusammenspiel von 15000 Lines of 
Code in 248 Klassen muss man auch erst mal rauskriegen.

Sven schrieb:
> Naja und wenns unbedingt sein soll, einen buidlserver aufsetzten, der
> eine lib rausspuckt, den kann der Kunde dann anwerfen und bekommt eine
> lib. Der Code ist nur auf dem Buildserver. Mit jenkins oder was
> vergleichbaren ist das einfach zu machen.

Und das ganze für ein paar wenige Variablen? Warum sollte der Kunde 
dafür selber kompilieren wollen? Jetzt noch externes Build-System dafür 
vorhalten.
Die Anforderungen machen doch alle keinen Sinn.

Bei dem gezeigten Wissenstand bezweifle ich auch irgendwie, dass Jochen 
Code schreibt welcher derart einzigartig und schützenswert sein soll.

gruß cyblord

Jochen schrieb:
> Also der Nutzer kann beispielsweise ein paar #defines festlegen sieht
> aber vom eigentlichen Code nichts...?

Beschreib doch mal, was der Kunde eigentlich konkret ändern können soll:

-sind das ein paar Parameter, die vielleicht physikalischen Größen 
entsprechen?
-oder soll bestimmter Code zum Debugging, Logging etc. nur während der 
Inbetriebnahme ausgeführt werden, ansonsten nicht?
-oder noch was anderes?

Ich neige dazu den Leuten Recht zu geben, die sagen dass man das Ganze 
mit einer Parameter-Datei abhaken kann. Diese muss nichtflüchtig 
gespeichert werden und wird vom System beim Hochfahren ausgelesen. 
Natürlich muss der Kunde die Möglichkeit haben, diese Parameter ändern 
zu können --> Er braucht eine Dokumentation/Anleitung dafür, die ihm zu 
liefern ist. Außerdem sollten die Parameter natürlich auf Plausibilität 
geprüft werden. Fünfzigtausend Grad als unteren Wert für die 
Außentemperatur sollte man eher nicht akzeptieren ;-)

@TO

Siehe hier, gerade diskutiert worden...

Beitrag "Re: Quell-Code verstecken/verschleiern"

900ss D. schrieb:
> @TO
>
> Siehe hier, gerade diskutiert worden...
>
> Beitrag "Re: Quell-Code verstecken/verschleiern"

Das kann man zwar machen, aber ich bezweifle dass es in diesem Fall die 
passende Lösung für den Themenersteller ist.

Im übrigen habe ich solche Aussagen hier:

Jochen schrieb:
> Mich selbst ein bisschen unabkömmlich zu machen für größere Änderungen
> und so.

in meinem Berufsleben noch nie von einem guten Entwickler gehört. Gute 
Entwickler bestechen durch die Qualität ihrer Arbeit. Irgendeinen 
kryptischen Quatsch abzuliefern hat mit Qualität nichts zu tun.

Rolf Magnus schrieb:
> Karl Heinz schrieb:
>> INterne statische Funktionen umbenennen, Alle Variablen, die ein
>> Benutzer normalerweise nicht sieht und die auch keine Funktionsargumente
>> an der Schnittstelle sind auf i00 bis i99 umbenennen. Alle Leerzeichen
>> aus Nicht-Strings raus. Zeilenumbrüche manachmal raus. Alle Anweisungen
>> beginnen am linken Bildschirmrand - Einrückung was ist das?
>
> Das einzige, was da halbwegs effektiv wäre, it die Umbenennung. Den Rest
> macht ein simpler indent-Aufruf rückgängig.

Nicht, wenn der Obfuscator (so heißt der Typ Software, der einen 
Quellcode derart verunstaltet) etwas kreativ geschrieben ist. Z.B. kann 
man Funktionsnamen oder sogar Schlüsselworte in #defines packen, z.B.

1

#define if while

2

#define pferd k++ muh

3

#define muh ;

4

#define emit return

5

6

int main (void) { int i,k,l muh if (i<l){pferd} emit 1 muh }

Aber um nochmal auf die Frage des TE zurück zu kommen: Der Betreff 
spricht von "Code teilen". Wenn man wirklich teilen will, dann stellt 
sich die Frage nach einem Obfuscator gar nicht. Auf jeden Fall würde ich 
derart verunstalteten Code nicht mit der Kneifzange anfassen. Und in 
allen Firmen in denen ich bisher gearbeitet habe, wurde von extern 
entwickeltem Code, der in eigene Projekte einfließen sollte, natürlich 
der originale Quellcode verlangt. Reine Binärmodule sind was anderes, 
aber soweit unsere Abteilung (Entwicklung) mitzureden hatte, wurde auch 
da Quellcode verlangt.


XL

Muss es nicht heißen:

1

if(kuh)

2

    emit 1 muh;

3

if(pferd)

4

    emit 1 wieher;

:-)

Jochen schrieb:
> Das ist echt lästig ich arbeite sehr gerne mit Preprozessor Anweisungen
> wie defines und ifdef Anweisungen.

Man kann auch mehrere Link-Libraries rausgeben. Jede mit einer anderen 
Kombination von Präprozessor Anweisungen übersetzt.

Axel Schwenke schrieb:
> Und in
> allen Firmen in denen ich bisher gearbeitet habe, wurde von extern
> entwickeltem Code, der in eigene Projekte einfließen sollte, natürlich
> der originale Quellcode verlangt.

Ich gehe davon aus, dass dieser dann auch entsprechend bezahlt wurde.

Nach meinem Kenntnisstand sind bei Closed Source Libraries weit 
günstiger als Sourcecode. Und aufs Geld schauen viele Firmen dabei ...

Manchmal ist es aber auch viel banaler. Der Kunde möchte die Performance 
o.ä. vor dem Kauf testen. Da gibt man schon mal schnell die Objektfiles 
raus. Sourcecode gibts dann nach der Kaufentscheidung.

m.n. schrieb:
> Zu bedenken wäre auch, wenn Dein Kunde den Programmablauf durch seine
> Einstellungen vermurkst, dass vermutlich Du dafür verantwortlich sein
> wirst.

Eingangsparameter, die von einem Menschen per Hand eingegeben werden, 
müssen in der Software auf Plausibilität geprüft werden. Immer. Bzw. man 
lässt von vornherein Fehleingaben gar nicht zu, indem z.B. eine 
grafische Benutzeroberfläche zu kleine oder zu große Werte gar nicht 
erst akzeptiert (und den Benutzer darüber informiert, dass seine Eingabe 
fehlerhaft ist).

Des weiteren gibt es sowas wie einen Haftungsausschluss oder eine 
Haftungsbeschränkung. Natürlich ist man als Lieferant nicht für 
sämtliche Fehler verantwortlich, die beim Kunden im Betrieb passieren. 
Wenn das so wäre, würde niemand mehr Software ausliefern können.

Steht üblicherweise in den Allgemeinen Geschäftsbedingungen so drin:
"Die Firma XYZ haftet nicht für Schäden, die durch unsachgemäße 
Verwendung, fehlerhafte Bedienung, ... et cetera pp. bla bla entstehen."

m.n. schrieb:
> Und Du meinst nun, dass der Kunde im Fehlerfall seinen eigenen Fehler
> sucht

Der Kunde meldet Fehler. Der Lieferant sucht und behebt diese. So wie 
überall auf der Welt eben.

> oder die Bedienungsanleitung liest?
> Gratuliere!

Unsere Kunden lesen die Bedienungsanleitung und beschweren sich, wenn 
diese nicht gut genug ist. Zu Recht. Weiß nicht was Ihr für komische 
Kunden habt ;-)

Martin schrieb:
> Ich mach immer alles Opensource und geb's dann den Kunden
>
> Hier ein Beispiel:
> http://pastebin.com/c9aUjyJY
>
> Schlussendlich wagt niemand das Kunstwerk zu zerstören.

Doch. Ich! :P

Die zweite Version ist noch besser :)

Und noch eine dritte handoptimiert (ups, jetzt hab ich mich verraten) :P

calloc() ohne free() am Ende?
Kein Wunder, dass das so versteckt wird. :P

Als "uberzeugter Open-Source-Bef"urworter in einer Firma, die "Closed 
Source" verkauft tue ich mein Bestes und lasse dem Kunden maximale 
Freiheit beim Konfigurieren der Firmware und schreib ein Manual dazu. 
Die Firmware hat einen Interpreter, mit dem man sich per COM/TTY 
unterhalten kann und der gibt auch noch Hilfe aus! Im Manual ist die 
Funktionsweise des Systems erkl"art.
So. Und wie l"auft's? Ich darf beim Kunden antanzen und einstellen, 
weil LESEN und EINSTELLEN schon viel zuviel verlangt ist!
Und Du machst Dir Gedanken, dem Kunden zuviel zu geben? Den interessiert 
dein Code gar nicht!

Ein Programm oder Controller-Image kann der Kunde - ohne viel zu 
verstehen - hingegen duplizieren. Hardware kann er nachbauen. D.h. um 
einer Firma zu schaden muss man gar nichts k"onnen ausser Hardware 
kopieren einen Controller zu flashen. Ich w"urde dem Kunden lieber den 
Source-code geben als ein (nicht menschenlesbares) Image.

Der Beste Schutz best"unde meiner Meinung darin, wie cyblord im 2 Post 
vorschl"agt - eine Konfiguration zu integrieren und zwar am besten 
gleich so, dass bei wildem Rumprobieren ohne Hirn gleich mal ein paar 
Endstufen abrauchen. Und dann erkl"aren lassen, wie das passieren 
konnte...?

Aber im Grunde sollte man mit Leuten, denen man nicht trauen kann 
"uberhaupt keine Gesch"afte machen. Wenn der Gesch"aftspartner nicht 
mehr hergibt als die eindimensionale Gr"osse 'Geld', dann sollte man 
sich auch nicht in seinem Universum von der r"aumlichen Ausdehnung einer 
Linie bewegen wollen.