Linkbar

25 June 2011

Software Development on an OS Base

The development of software on an open source (OS) platform presents some interesting issues from the point of view of a copyright contract. Right at the outset, it is important to note that even if the software has an open source code, that does not automatically necessarily mean that it is governed by a copyleft licence which allows for free use, either from the point of view of payments or the freedom to create derivative works.

Assuming that the "OS base" is in fact governed by a copyleft licence, the parameters within which any negotiations in relation to the software would be conducted could be extremely different from those which would have applied in the absence of copyleft terms. For example, with regard to traditional proprietary software, issues such as employee confidentiality could be of vital importance. However, with regard to software developed using an OS base, such issues could become completely irrelevant, depending on the terms of the copyleft licence. This is because if the OS base were, for example, governed by terms which included a share-alike obligation in relation to derivative works, attempting to force confidentiality obligations on those who created such derivative works would be meaningless, as there would in any case be a legal obligation to make publicly available the source code of the derivative software.

Further, if one were to acquire "derivative software" which had an OS component in it, and then had the derivative software customised, from a copyright perspective, there would be three kinds of software which would come into play:

the OS base software;

the derivative software which was developed using the OS base;

the "customised software" which would be derived from the derivative software, and which would be a form of derivative software in its own right.

Any contract in such a scenario would have to take into account all three kinds of software, and consider not only ownership issues with regard to all of them but also licence terms. This could be complicated because each of the components could be owned by different persons. For example:

the owner of the OS software;

the owner of the derivative software;

the owner of the software used to customise the derivative software; and

the owner of the final product i.e. the customised software.

The customised software could, depending on what the relevant contracts said, be jointly owned by the owners of the OS software, the derivative software and the software used for customisation. Also, although it may appear to be counter-intuitive to require the owner of the customised software to be specifically designated by contract, it is important that this be done for the sake of clarity. If not anything else, it may not be possible to separate components in the customised software, and as such, it is possible that the customised software would not be: "a+b" but "ab", where "a" represented the derivative software, and "b" the customisations. In such a scenario "ab" would be a distinct product, and if ownership were not clearly defined, it could easily lead to a situation where none of the purported owners would easily be able to further deal with the customised software, and where shares of payments accrued through the exploitation of "ab" would be extremely murky.

As far as licence terms were concerned, the grants of rights in relation to each of the various software components could be different. Although it would be necessary for the derivative software and the customised software to comply with the terms of the original OS base software, it would not be necessary for the customisations used to create the ultimate customised software to do so. That being said, the customisations would, in all probability, be hit by the terms governing the the OS base the moment they were used to customise the derivative software. As such, it would be necessary to assess the impact of the OS licence on the customisations prior to use, to ensure the consequences would be acceptable to the owner of the customisations.

At the end of the day, OS software may be intended to be "free" but that does not mean that it is either inert or incapable of affecting any works derived from it. As such, even if an OS base is governed by a copyleft contract, it is vital to check what the terms of that contract are before proceeding with the development of derivative software. All copyleft contracts do not simply say: "Do anything, don't pay!"

Credit

Author

Subscribe in a Reader

Archives

Art and Indian Copyright Law: A Statutory Reading

A look at how the Indian Copyright Act, 1957, as amended in 2012, interacts with art (other than films and sound recordings), and, in particular, with Indian art. The first part of this text comprises a feminist and post-colonial reading of the Indian copyright statute while later parts focus on interpreting the provisions of the statute in relation to art.

The Bollywood Amendments (2010-2012)

An examination of the provisions of the 2012 amendments to the 1957 Indian Copyright Act which affect the film and music industry. The paper takes into consideration the factual background in which the amendments were made and explores whether they are likely to realise their objectives.

"IN Content Law" is a personal blog which contains the views of its author, Nandita Saikia, alone unless otherwise explicitly stated. The author of the blog may have advised clients on subjects relating to those dealt with in this blog. However, the contents of this blog are not intended to reflect the opinion or position of any person (other than the author) unless otherwise explicitly stated.

The posts on this blog relate to copyright and content law from an Indian perspective. They are not professional advice, and should not be considered or construed as such. No action should be taken or omitted on the basis of the contents of this blog.

This blog neither creates an attorney-client relationship between the author and any visitor(s) or any other person(s), nor does it seek to do so. The material contained herein is solely for the purpose of academic discussion and is accessible on an as-is basis.

No representations or warranties are made as to accuracy, impartiality or fitness of the material on this blog for any use, and the author shall not be liable in any manner to any extent for the consequences of any action taken on the basis of any material herein. Further, no representations or warranties of any nature are made regarding any material which may be linked to from this blog, and the author shall not be responsible for the contents thereof.Revisions: The posts on this blog may be revised from time-to-time for editorial or other purposes without each revision being marked in the post itself.

Privacy: No comments made on this blog OR mail or documentation sent to the author by any person in connection with this blog (i.e. "Information") shall be treated as being private or confidential, with the exception of the eMail address of the sender. By sending / transmitting any Information directly to the author or by way of a blog comment, the sender authorises the author to use and/or reproduce it for ANY purpose she desires at any place or time. All senders / potential senders are requested to contact the author if they have any privacy concerns, preferably, before sending / transmitting any Information.