Open Source macht die Vergebührung des direkten Warenwerts von Software schwierig. Das Problem ist kein technisches. Quellcode ist nicht weniger leicht zu kopieren als Binärdateien, und das Exekutieren der Gesetze für Lizensierung und Copyright wären nicht notwendigerweise komplizierter als für Closed Source-Produkte.
Die Schwierigkeit liegt mehr in der Natur der sozialen Abkommen, die Open Source-Projekte ermöglichen. Aus drei einander bestärkenden Gründen verbieten die Open Source-Lizenzen die meisten Einschränkungen beim Gebrauch, der Weitergabe und Veränderung, die eine Einhebung direkter Gebühren für den Verkauf bedeuteten würde. Um diese Gründe zu verstehen, müssen wir den sozialen Kontext untersuchen, in dem sich diese Lizenzen entwickelt haben; die Rede ist von der Internet-Hackerkultur.
Trotz der Mythen, die es auch 1999 noch über die Hackerkultur gibt, hat keiner dieser Gründe mit Marktfeindlichkeit zu tun. Während tatsächlich nur eine Minderheit Gewinnmotiven feindlich gegenüber steht, demonstriert die allgemeine Bereitschaft der Gemeinde, mit gewinnorientierten Vertriebsfirmen wie Red Hat, SUSE und Caldera zu kooperieren, daß die meisten Hacker gerne mit der Geschäftswelt zusammenzuarbeiten, wenn es ihnen nützt. Der wahre Grund, aus dem Hacker direkte Erträge aus dem Verkauf von Lizenzen ablehnen, sind subtiler und interessanter.
Ein Grund hat mit Symmetrie zu tun. Während die meisten Open Source-Entwickler nicht grundsätzlich Einwände erheben, wenn andere von ihren Spenden profitieren, verlangen die meisten, daß niemand in einer privilegierten Position sein darf, zu Profiten zu kommen. Otto Normalhacker ist einverstanden, daß Firma Beutelschneyder & Bluffer durch den Verkauf der Software Gewinn macht, aber nur solange, wie auch Otto selbst diese Möglichkeit hat.
Ein weiterer Grund hat mit unbeabsichtigten Folgen zu tun. Hacker konnten beobachten, daß Lizenzen Einschräkungen und Gebühren für den 'kommerziellen' Gebrauch oder den Verkauf (eine sehr übliche Form der Einhebung des direkten Warenwerts, und keine, die so unangemessen ist, wie es auf den ersten Blick aussieht) einige ernstzunehmende Auswirkungen hat. Eine sehr konkrete ist der juristische Schatten, der dadurch über Aktivitäten wie den Vertrieb durch günstige CD-ROM-Anthologien geworfen wird, zu denen wir aber eigentlich ermuntern sollten. Allgemeiner ausgedrückt, führen Einschränkungen für die Verwendung, Veränderung, Verkauf und Vertrieb zu Unkosten für die Kontrolle und Exekutierung dieser Einschränkungen und zu einem Klima der Angst vor juristischen Risken.
Diese Wirkung wird zu Recht als schädlich angesehen, und es gibt daher einen starken sozialen Druck in Richtung simple gehaltener Lizenzen, die frei von Einschränkungen sind.
Der letzte und wichtigste Grund hat mit der Dynamik der Geschenkekultur (beschrieben in [HtN] zu tun, die ja ständige Kritik und Verfeinerung durch Kollegen (peer-review) ermöglicht. Einschränkungen in den Lizenzen, die geistiges Eigentum schützen oder den Warenwert erhalten sollen, haben oft den Effekt, daß es juristisch unmöglich wird, unabhängige Entwicklungszweige für ein Projekt einzurichten (ein Beispiel dafür ist Suns sogenannte "Community Source License" für Jini und Java). Obwohl so ein "forking" allgemein unbeliebt ist und nur als ein Notbehelf gesehen wird (aus Gründen, die in [HtN] ausführlich erörtert werden), gilt es als wichtig, auf diesen Notbehelf zurückgreifen zu können, wenn sich der Betreiber des Projekts als inkompetent herausstellt oder einen Rückzieher macht (also zu einer weniger öffentlichen Lizenz übergeht).
Die Hackergemeinde hat Einfluß bei der Symmetrie, daher toleriert sie Lizenzen wie Netscapes NPL, die dem Urheber des Codes einige Gewinn-Privilegien einräumen (was bei NPL besonders ausgeprägt ist: es beinhaltet das exklusive Recht, den öffentlichen Mozilla-Quellcode für davon abgeleitete Produkte zu verwenden, darunter eine Closed Source-Version). Sie hat weniger Einfluß bei den ungewollten Konsequenzen und gar keine bei der Möglichkeit, einen neuen, unabhängigen Entwicklungszweig ("fork") zu schaffen und zu verfolgen (was der Grund für die Ablehnung von Suns "Community License" (Geimeindelizenz) für Java und Jini ist).
Diese Gründe erklären die Klauseln der Open Source-Definition, die geschrieben wurde, um dem Konsens der Hacker-Gemeinde über die zentralen Merkmale der Standardlizenzen (GPL, BSD-Lizenz, MIT-Lizenz und Artistic License) zu entsprechen. Diese Klauseln haben den Effekt (aber nicht die Absicht) das Einheben des direkten Warenwert sehr schwierig zu machen.