This blogger could not cover all of the sessions since many of them were offered in parallel, but he was fortunate that Aner Rabinovitz (a lawyer with the Tel Aviv firm of Gross, Kleinhendler, Hodak, Halevy, Greenberg & Co.) was able to capture enough notes on the session entitled "Copyright and the Future of Open Source" to be able to convert them into a blog post -- so here they are (thanks, Aner!):
This session, chaired and moderated by Professor Michael Birnhack of the Tel Aviv University Law Faculty, addressed the hot topic of using and incorporating open source software (OSS) and code in companies' proprietary products. As Professor Birnhack adequately put it in his opening remarks, open source is no longer (just) the "hippy" way of producing and circling code, as nowadays it is considered a legitimate alternative for code conduct and policy, and companies should approach it appropriately.
First to speak was Adv. Haim Ravia (a partner in Pearl Cohen Zedek Latzer Baratz), on "Open & Closed: Combining OSS and Proprietary Software". Adv. Ravia gave a run-down on the basic elements of OSS compared to "closed" copyright software, first and foremost challenging the common misconception that OSS, advocated as being all about "freedom", is actually free to use however we want. Unlike "free beer", the OSS concept of "freedom" actually comes with a price and is actually quite limiting on its users, and in most ways it is much more similar to "closed" copyright software rather than public domain software (e.g., the HyperText Transfer Protocol which most of us know simply as HTTP).
True, while closed copyright software owners maintain exclusive rights for, inter alia, copying, making derivative works and distributing their works, and more often than not are prohibitive with regards to allowing access to the source code as well as using the work for any purpose whatsoever – OSS licensing is usually much more permissive by nature. However, there are a handful of OSS licensing options and regimes, each based on a different concept of "free", and each complemented with a very different set of legal do's and don’ts.
Adv. Ravia pointed out the two major classes/ideologies of OSS licensing:
1. Permissive licences, which refer to basic copyright principles, but express the owner's wishes to waive most of its exclusive rights with simple and usually non-intrusive provisions, such as simply requiring the licensee to attach a short notice to his OSS-incorporated software. This licence class includes such simple and often short OSS standard licences as BSD, MIT, Apache 2.0 and the ever so gladdening WTFPL (Do What The F*** You Want to Public Licence); and –Moving from the basics to practice, second to speak was Ms Suzanne Erez (in-house IBM IP Counsel) on the topic "A smarter way to use open source". As Ms Erez pointed out, with OSS' sbusiness benefits (to name a few, open standards which allow companies and developers to skip "re-inventing the wheel" and build on previous efforts, and benefiting from future modifications by the open source community), the question is no longer "SHOULD we use open source", but HOW.
2. Reciprocal (or "Copyleft") licences, which are based on the notion that "freedom" is best maintained and spread if those enjoying this "freedom" will be bound to allow others to enjoy the same with their own OSS-incorporated works. This condition of reciprocity (commonly referred to as the "Viral Effect") usually entails having to make your proprietary code and your modifications to the Copyleft OSS code available, as well as several other conditions based on the specific Copyleft licence. Unfortunately, the standard licences associated with this class (to name a few, the GPL, LGPL, MPL and Eclipse) are usually quite long and complicated, which often creates challenges for legal professionals advising their clients on the scope and implications of each licence's virality towards the client's proprietary works. As OSS is "open" and community-based by nature, certain OSS have benefited from a number of contributors and different collaborations and integrations with other OSS components, and are often hard to attribute to each of their contributors and may be subject to different licenses than the principal software, which obviously creates even more challenges for users and legal advisers alike.
As in-house IP Counsel, Ms Erez shared her own process when asked to set the terms for using a certain OSS in IBM's developments. First is the OSS licence review, specifically for any reciprocity provisions. Second is pedigree review – namely, who were the contributors to the OSS? If these include developers who were employed as such in software companies or conducting research in certain institutions while privately working on the OSS, then perhaps the code was not theirs to license as OSS in the first place. Third is performing a code scan, namely looking and making a list of what's in the OSS package. Fourth – performing an internet search for the OSS and its different components, mainly to see when they were published, and whether or not they have been litigated before. Fifth and last is reviewing the outbound licence terms – namely, the license of the proprietary software designated to include the OSS in question, and advising on the necessary adjustments with regards to the OSS.
Ms Erez continued to emphasize the importance of creating awareness to open source throughout the company (and not just in the legal department), and having a strict company "Open Source Policy" which balances the risks and benefits of using OSS, and considers the different stages of use. For instance, while internal use of OSS during developmental stages may be okay according to most OSS licences (although in some cases may still expose the company to patent infringement claims, especially if the company has a high-profile and is considered to have "deep pockets"), it is important to spread awareness to everyone involved in order to avoid having to take hard decisions or take on unfavorable warranties later on. As open source today is an essential part of the business of most software companies, it is important to learn to use it for your benefit, while avoiding unwanted and unnecessary outcomes.
On that positive and practical note, third speaker Mr Muli Ben-Yehuda (owner of Hypervisor Consulting and Linux Kernel Maintainer) took the stage, to discuss "The Top Three Reasons Open Source Makes (Business & Development) Sense".
From a developer and a researcher point of view, Mr Ben-Yehuda argued that companies should definitely use, build upon, embrace and contribute to open source projects. As an example, Mr Ben-Yehuda argued that today there are very few companies which can sustain the amount of changes and modifications Linux undergoes every day (over 170), which makes it is clear that open source can lead to better software. There are several reasons and incentives explaining that, to name a few – open source contributors are passionate about what they do, while being constantly subject to review and criticism by their peers, as everyone can check you up on your mistakes (similar to peer-review in academia). The diversity of contributors may also create a multicultural effect, especially in medium and large sized project, which usually leads to better results. Also, as open source is not controlled by a single management (as is usually the case in software companies), the better ideas usually get through with no regard to organizational politics and constraints. Lastly, existing open source saves developers from having to keep "re-inventing the wheel" and writing everything from scratch, thus freeing them to focus on their own innovative contributions.
As for the companies and business perspective, Mr Ben-Yehuda pointed to the fact that an organization releasing its proprietary software under an open source licence can gain happier customers, as OSS is open to more and better updates and upgrades than "closed" software, and basically is expected to last longer.
Last to speak was Dr Ron Rymon (founder of White Source Software), on the topic "Enjoying Open Source without Compromising Business". As a novice software entrepreneur, Dr Rymon has experienced the uncomfortable situation where a previous company of his underwent a due diligence process in which it unexpectedly discovered hundreds of open source libraries and licenses used by its developers in connection with the company's proprietary software. This helped him appreciate the need for tools for OSS management, which can enable companies to better enforce their OSS policies, keep in order all OSS licensing documentation, and keep their finger on the pulse with regard to changes and updates for each OSS they used in their product. As Dr Rymon pointed out, while open source is likely to contain security vulnerabilities and other bugs just as any other software, and even though open source communities are often quick to fix those – OSS users are slow to update, as it's difficult and out of scope for developers to be in the know of every such constant updates. Considering that vulnerabilities and restrictions in OSS you use are your responsibility, it is of extremely high importance to keep all of these under control.
In order to do that, Dr Rymon recommends OSS users to adopt a "lifecycle" approach – namely, dealing with issues "at the door" and not post-hoc when it is difficult to discover and expensive to fix, and keeping track of OSS "inventory" and risks in real-time (which can be done using Whitesource's solutions).
No comments:
Post a Comment