The modifying interventions on the source code of a software programme can be traced back to three large categories: code recombination, the addition of plug-in modules, and linking. While the latter category is generally limited to function libraries, the other two options can occur in any type of modifying intervention concerning the source code.
This article addresses the categorisation of modifications in the latter two cases, leaving the analysis of linking to another article. It is premised that the topic discussed is the ownership of modifications made directly to the original code and of modules associated via plug-in. The ownership of derivative works resulting from the modification of the original source code, according to copyright law, depends instead on the level of creativity of the derivative work.
Analysing the business model underpinning the logic of open source software development, the following pattern can be recognised: the project draft, made up of a substantial number of code lines whose order, organisation and interaction constitute the programme’s skeleton, is placed online in a shared space (e.g. sourceforge.net). In most cases the published and shared code is functional to a purpose and in this sense may be said to be created, but it is still in a larval state and requires continuous corrective and improving interventions. Sharing aims precisely at this result. The community intervenes in a diffuse manner according to the Bazaar development model (The Cathedral & the Bazaar, Raymond); there is no stringent task assignment as in the classical development model (the so-called Cathedral model): the best solution arises from the sharing and integration of the proposed and elaborated solutions.
The solutions obtained, however, need order: someone must play the role of coordinator, supervising the work, perhaps without intervening directly in the development. The system is similar to that applied in a newspaper editorial office, where the editor-in-chief composes the paper based on contributions from individual journalists. Continuing the analogy, in the bazaar model no title is assigned to the single journalist, who is free to develop any topic provided it is connected to the area of interest of the publication itself.
An analysis of open projects deemed successful (Mozilla above all) shows that, even though the Bazaar model is used, the presence of a kind of authority (generally a foundation) is nonetheless required to coordinate the community’s contributions and keep them in order.
The described process culminates in the software release phase. In the classical model the product is released at the end of the production process: there can be various versions, but generally the software does not need further interventions.
In the Open model, on the contrary, there is never an immovable version: the project is constantly in Beta, continuously improved thanks to the possibility of accessing and modifying the source code.
For the project to maintain its coherence, the continuous interventions need to be disciplined: this is normally done by imposing a licence that regulates distribution and the possibility of modification. But that is not enough.
For example, equipping the licence with copyleft has the certain advantage of preventing closure of the code by the users/licensees, but says nothing about the ownership of the modifying interventions on the code.
Who should be considered the author of the lines of code inserted for improvement/correction in the initial programme?
The matter must be addressed starting from the analysis of some articles of Italian Law l. 633/1941 (L.D.A. — copyright law):
Art. 4 of the LDA governs the contributions which, if sufficiently creative, may constitute a derivative work, to be protected independently of the original work and without prejudice to the rights existing on the latter.
Art. 7 of the LDA governs the contributions which, when the requirements for constituting a derivative work do not exist but are distinguishable and separable from the original work, are subject to the discipline of collective works, by virtue of which each contribution may have autonomous protection, while the author of the work resulting from the union of the various contributions will be the one who organised and directed the creation of the work itself.
The business model outlined above seems to be recalled more by the rule of art. 7 than by that of art. 4: under this interpretation, the continuous improving/corrective/integrative interventions, since they are not characterised by substantial creative autonomy, may be inserted and organised among each other in the single project on which they depend. Ultimately, the coordinator will have ownership of the work and be able to decide under which licence(s) to release the product.
A slight distinction is needed in the case where the contributors’ intervention in the project occurs through the association of modules via plug-in.
In this case, the project coordinator will indeed be the owner of the rights on the work, but the individual contributions may still be used autonomously by their material authors. As a result, it might well happen that the plug-in is covered in the work by a licence (the one set by the owner of the rights on the collective/composite work) and, at the same time, is autonomously released by its material author under another licence, or in another independent work. In any case, the project coordinator retains the choice as to the release of the composite collective work made through the elaborations of the various contributors.