Open Source Projekt mit Closed Source Bestandteilen

Moin,

interessante Frage, habe mich darüber schon länger mit Anwälten 
unterhalten, und fürchte, das Problem ist juristisch ein gordischer 
Knoten.

Was schon mal nicht geht, ist GNU Public License, soifern du Teile 
deiner Arbeit komplett closed halten willst.
Du kannst aber DEINEN Code unter zwei Lizenzen stellen ("Dual license"), 
sagen wir "Open" und "Closed".

Das Problem ist aber grundsätzlich folgendes: Wenn einer an Deinem 
Projekt mitmacht, und Code liefert, nimmt er die "Open" Lizenz an, und 
nicht deine "Closed". D.h. du darfst seinen Code nicht für deine 
kommerziellen Zwecke nutzen, und im Nachhinein Lizenzbedingungen ändern, 
geht schon mal gar nicht.

Heisst, du musst zwei Codebäume unterhalten und für jedes Einpflegen von 
Code der Drittpartei im "Open"-Baum in deinen "Closed" um Erlaubnis 
fragen und u.U. den Autor entschädigen, wenn Du damit einen Gewinn 
erzielst. Das dürfte kaum einer mitmachen...

Ansonsten gibt es in der Linux-Welt durchaus eine Menge Möglichkeiten, 
sein IP geschlossen zu halten, entweder als Kernelmodul oder im Sinne 
eines Daemon, der mit GNU-Software über Sockets kommuniziert. Das ist 
elegant und legal.

Die HW-Seite wird kniffliger. Da gibt es IMHO kein effektives 
"open"-Prinzip, da kannst Du es vergessen, dass sich jemand daran hält. 
Du kannst nur dein IP in einem FPGA verstecken.

Gruss,

- Strubi

>Ich würde gerne ein OpenSource Projekt starten (Hard- + Firm- +
Software), allerdings würde ich die Quelltexte für die Firmware ungerne
vollständig veröffentlichen, ich wäre allerdings bereit die Firmware
soweit zu veröffentlichen das sich eine offene Firmware für die Hardware
entwickeln lässt und die Hexfiles für die Closed Source Firmware.

Wenn alles von Grund auf gemacht wird, weshalb sollte das nicht so 
gehen. Jeder baut seine eigene Hardware, und die Software bis auf den 
Inhalt einiger Templates ist Opensource...

Das bedeutet, dass das bestehende Framework soviel bringen muss, dass es 
anderen Arbeit erspart.
Es muss einfach zu beginn weg klar sein, was dabei ist, was es bringt, 
dh was es erspart.

Ein Opensource Framework, muss fast alle vorhersehbaren Aspekte und 
Moeglichkeiten abdecken, sonst ist es wertlos. Wenn die bereits 
implementierten Vorleistungen zu restriktiv sind macht man's besser 
selbst neu.

Ich hab eher den Eindruck, dass es darum geht, sich den Opensource 
Mantel aufstuelpen zu koennen, und es Nachbauern nichts hilft, ich kann 
mich aber taeuschen.

Ein PC ist aehnlich. Die Treiber zu Grafikkarten oder sonstwas sind 
Closed source.

Ich möchte keineswegs etwas von der Community in den Closed Source Zweig 
einfließen lassen oder Pseudo "Open Source" vortäuschen.

Es geht um ein USB Interface zur Kommunikation mit verschiedener 
Hardware.

Ich habe eine Hard-, Soft-, und Firmware, ich würde auch gerne alles 
davon veröffentlichen bis auf die Datenbank die in der Software steckt 
und verschiedene Bestandteile der Firmware.

Weil diese monatelange Arbeit gekostet hat.

Ich würde aber zum Quelltext eine Dokumentation veröffentlichen wie die 
Datenbank mit anderen Inhalten gefüllt werden kann und eine lauffähige 
Firmware veröffentlichen welche nicht alle Protokolle beherrscht, 
sondern nur standardisierte und nicht meine spezifischen.

Hallo,

Über das Thema habe ich mir ebenfalls schon ausgiebig Gedanken gemacht, 
da ich in einer ähnlichen Situation bin: Ich entwickle privat und 
geschäftlich Software; von dem privaten Kram möchte ich gern einiges 
veröffentlichen können. Zudem gibt es inhaltliche Überschneidungen auf 
Low-Level-Basis.
Meine Lösung ist aktuell, eine Source-Bibliothek unter LGPL zu stellen 
und diese dann privat zu pflegen.

Hardwareseitig kann man sich u.U. auch bei Creative Commons umschauen.

Ansonsten finde ich den Vorschlag von Dave Jones interessant:
https://www.youtube.com/watch?v=5wrSXCBdalc

Hintergedanke: Es ist immer besser, etwas zu veröffentlichen als gar 
nichts.
Wobei das OSHW-Logo natürlich nichts über die verwendete Lizenz aussagt 
sondern quasi nur "hier ist irgendwas veröffentlicht"...

Das mit dem Lizenzieren ist doch nicht besonders schwierig. Man muss 
dabei keine Romane schreiben, das sieht, man an Lizenzen wie der MIT 
License (1) oder der WTFPL "Do what the fuck you want to public license" 
(2). Normalerweise ist es überhaupt nicht nötig, neue Lizenzen zu 
schreiben. Unterteile den Code einfach in mehrere Projekte. Mache z.B. 
eine "Firmware core library", welche nur eine statische library und 
headerfiles als schnitstelle liefert. Dann nimmst du dafür eine closed 
source lizenz, die das Kopieren und Verwenden in OpenSource Projekten 
erlaubt, aber das Disassemblieren und sublizenzieren verbietet. Dann 
kannst du eine "OpenSource Extended Firmware" machen, die die "Firmware 
Core Library" benötigt. Eventuell macht es sinn, die "Firmware Core 
Library" nicht als bestandteil der "OpenSource Extended Firmware" zu 
bezeichnen, sondern als eine Implementation des "Firmware Core Library" 
Interfaces. Das Interface kann nicht Patantiert oder Lizenziert werden, 
andere könnten eine eigene Implementierung entwickeln. Bei der 
"OpenSource Extended Firmware" nimmst du einfach eine gewönliche 
OpenSource lizenz. Gleiches kannst du auch mit Libraries machen, eine 
ClosedSource für ClosedSource libraries, eine OpenSource Lizenz für 
OpenSource libraries. Passe einfach auf, das die Lizenzen bei dieser 
Verwendungsart nicht Inkompatibel sind.

Solltest du wirklich etwas komplexeres brauchen, kannst du auch einfach 
selbst eine Lizenz schreiben. Etwas wasserdichtes zu schreiben ist 
schwierig, und sollte eventuell von einem Anwalt gemacht werden. Dennoch 
ist eine selbstgeschriebene Lizenz nicht weniger gültig, als eine von 
einem Anwalt geschriebene. Stelle einfach sicher, das du genau 
festhällst, was erlaubt ist und was nicht. Schaue auch, das du den 
Copyright holder angiebst, festhällst inwiefern sublicensing erlaubt 
ist, was wo und wie verwendet werden darf, etc. Ok, man sollte dabei 
schon wissen, was man tut.

Ich sehe das Hauptproblem nicht beim Lizenzieren, sondern bei der 
Durchsetzung der Lizenzen. Das verfahren kann sich doch keiner leisten.

Wenn man es sich leisten kann, kann man mit Lizenzen allerhand von 
schweinereien anstellen. Siehe z.B. das React framework und Facebook (3)

1) https://de.wikipedia.org/wiki/MIT-Lizenz
2) https://de.wikipedia.org/wiki/WTFPL
3) 
http://react-etc.net/entry/your-license-to-use-react-js-can-be-revoked-if-you-compete-with-facebook

Marc X. schrieb:
> Ich habe eine Hard-, Soft-, und Firmware, ich würde auch gerne alles
> davon veröffentlichen bis auf die Datenbank die in der Software steckt
> und verschiedene Bestandteile der Firmware.
>
> Weil diese monatelange Arbeit gekostet hat.

Dann laß es ganz. Ernst gemeint.

Mit einem halb öffentlich gemachten Projekt hilfst du niemandem. Im 
besten(!) Fall wird es ignoriert. Genauso gut kannst du dich als Ziel 
eines Shitstorms wiederfinden.

Auch deine Motivation ist mir nicht klar. Es hat Arbeit gemacht? Das hat 
jede Software die unter OS Lizenz veröffentlicht wird. Na und?

Wenn du glaubst, deine Arbeit kommerziell vermarkten zu können, dann 
mach das. Wenn du nicht daran glaubst und eher auf freiwillige 
Mitstreiter aus bist, dann mach alles öffentlich. Denn sonst wird dir 
niemand helfen wollen. Warum auch?

Die Mittelwege zwischen OS und Kommerzware sind alle mehr oder weniger 
problematisch. Sei es nun Open Core oder BSL oder sonst was.

Ich beobachte das bei meinem Arbeitgeber schon länger und es macht mich 
auf Dauer ganz schön depressiv ... :(

>
> Solltest du wirklich etwas komplexeres brauchen, kannst du auch einfach
> selbst eine Lizenz schreiben. Etwas wasserdichtes zu schreiben ist
> schwierig, und sollte eventuell von einem Anwalt gemacht werden.

Und:

Daniel A. schrieb:
> Ich sehe das Hauptproblem nicht beim Lizenzieren, sondern bei der
> Durchsetzung der Lizenzen. Das verfahren kann sich doch keiner leisten.

Die einzigen, die sich möglicherweise für Dich einsetzen werden, sind 
die Anwälte von der FSF, wenn Du Deine Rechte am Code vollständig an die 
FSF abgibst. Dann wird aber witzigerweise auch deine "Copyright"-Notiz 
im Code entfernt.
Ansonsten haben nach meiner Erfahrung nur wenige Anwälte Ahnung in dem 
Fachgebiet, dementsprechend die Honorare die eines Patentanwalts. Mit 
einem 1000er bist du da ev. aber dabei.

Aus meiner Erfahrung ist den meisten grossen Firmen in Übersee 
Verletzung der GPL oder deiner eigenen Lizenz schnurzegal. Aktuelles 
Beispiel ist Espressif, die man hier wohl ruhig anprangern darf. Aber 
auch namhafte Halbleiterhersteller, die auch Software machen, verletzen 
seit Jahren die GPL munter, davon könnte ich ein Lied singen. Mach ich 
nur nicht, denn: Schlau sind sie schon, und legen Dir früh genug nen NDA 
hin. Schlussendlich bist du selbst derjenige, der eigentlich die GPL 
verletzt...toll.

Die Frage, die sich der TO stellen sollte:

a) Ist der Code attraktiv für die Community?
oder:
b) Könnten Firmen dein IP schamlos ohne Entschädigung nutzen wollen?

Dann gäbs folgende Möglichkeiten:

1) Opensource ganz lassen, und drauf warten, bis Leute dein Produkt 
interessant genug empfinden, um darauf rumzuhacken (in beiderlei Sinn 
:-) ). Dann kannst du immer noch Teile opensourcen.
2) Gleich GPL für alle SW hernehmen und dein Firmware/HW-IP klar davon 
trennen.

In der Vergangenheit habe ich mit OpenSource im industrielle/Tool-Umfeld 
eigentlich nur folgende Erfahrungen gemacht:

- Es wird schamlos geklaut, und seltenst was zurückgegeben
- Manchmal findet man seinen Code bei github unter einem anderen 
Maintainer wieder
- Es interessiert kein Schwein, weil du keine/nicht genug Werbung 
gemacht hast
- Die Mitarbeit an OpenSource-Projekten kann sehr anstrengend sein, wenn 
Egos oder Programmier-Religionen kollidieren

Du brauchst also gleich von vornherein eine passende Community. Und dazu 
müsste man nun mehr über den potentiellen Allgemeinnutzen Deines 
Produkts wissen, bzw. ob Deine Interessen mit der grosser Firmen 
überlappen.