| Topic : businesses using open source |
|
|
|
||
|
Source : http://www.llrx.com
Activity:
3 comments
373 views
last activity : 07 06 2010 20:18:04 +0000
|
||
|
|
The main advantage for business is that open source is a good way for business to achieve greater penetration of the market.
It has also helped build developer loyalty as developers feel empowered and have a sense of ownership of the end product. Moreover less costs of marketing and logistical services are needed for OSS. It also helps companies to keep abreast of all technology developments. It is a good tool to promote a companies’ image.
The OSS development approach has helped produce reliable, high quality software quickly and inexpensively. Besides, it offers the potential for a more flexible technology and quicker innovation. It is said to be more reliable since it typically has thousands of independent programmers testing and fixing bugs of the software.
The Open Source licenses represent a very different approach to licensing than most businesses, and their lawyers and legal departments, have become accustomed to in the commercial software setting. Research on the Open Source licenses will often turn up conflicting interpretations, misinformation, philosophical arguments and diametrically opposed points of view.
Here are some tips that wil help in dealing with legal issues relating to using opensource software in business
1. Understand the Different Approaches That the Open Source Licenses Take.
It is important not to think about the Open Source licenses in monolithic terms.Open Source licenses can fall into four families:
GPL, BSD, Netscape/Corporate, and Custom. That's not an "official" taxonomy anyways.
Different licenses can have very different consequences. It also makes sense that everyone, including your lawyer, understands the technology, business and legal aspects of the decision.
2. Pay Special Attention to the General Public License.
The General Public License represents a unique approach to software licensing. Many other Open Source licenses do not have the same terms. Most of the heated discussion and controversy you will hear about Open Source involves the General Public License.
If you choose only one thing to have policies about and require special review of, it should be the General Public License.
3. Remember the Source Code.
In simplest terms, the biggest difference between Open Source software and commercial software relates to the source code of the program. In nearly every commercial software license, you receive only the object code of the program – the machine-readable executable version of the program. You do not get the source code – the "programmer's version" – and you are likely to be restricted from even trying to produce or reverse-engineer the source code. In Open Source programs, you are entitled to the source code and can view it, fix it, modify it and improve it.
4. Make Reasonable Comparison with Commercial Software.
It's easy to find frantic concerns about Open Source software over reasons that apply just as easily to commercial software. In 2004, the threat of software patents to Open Source has been widely discussed. At the same time, we've seen Sun lose a patent infringement case involving its Java programming language to Kodak, with a settlement of $90 million dollars. Eolas won a patent infringement judgment against Microsoft. Is your comfort level, when you really think about, any better when you consider whether commercial software vendors can prove they own every bit of the code of their programs than it is for Open Source programs? Many of the same questions about contract enforceability of the Open Source licenses apply to all software licensed on a clickwrap or "clickthrough" basis. Analyze Open Source licenses in the same way you analyze commercial software licenses.
5. Think in Terms of Choosing, Rather Than Negotiating, Open Source Licenses.
In a certain sense, Open Source licenses just "are." They are a classic example of the clickwrap license agreement. You take it or you leave it. As a practical matter, there may be no one to negotiate with. The community development model also drives people toward the common standard licenses. Even if you are a developer, you will find few incentives to create your own custom Open Source license. As frustrating as it can be to lawyers, the best approach is to evaluate the available choices and weigh the consequences, not to think in terms of ways to tinker with or improve the terms of agreements. The focus becomes legal risk management and valuating legal risk in the context of business decisions.
6. Do Not Confuse Open Source with Public Domain.
Make no mistake – Open Source software is real intellectual property that is governed by a real license that puts limits on your rights and imposes certain obligations. The obligations may not be all that onerous in comparison to commercial licenses, but they do exist and you ignore them at your peril.
7. Inventory and Assess What You May Already Be Using.
Be aware that many standard programming tools are Open Source programs. There are many stories of programmers and IT staff "smuggling" in Open Source programs that they prefer to work with or selling unsuspecting management on the basis of cost savings. You may find that both internal IT staff and third party contractors are using or have used Open Source code, tools or programs without your knowledge. You need to know what you have before you can determine what issues to address and how. It has become very important for both business decision-makers and lawyers to have a good understanding of the technology issues, including what the software does and the alternatives available. Many companies are moving toward Open Source because IT staff can paint a rosy picture on security issues to justify a move to programs they like or want to try. It is important not to take those arguments at face value and at least be able to ask the right questions.
8. Open Source Use Requires Open Source Training.
There are many myths and misconceptions about Open Source programs and Open Source licenses. Many programmers incorrectly believe that Open Source code and tools may be freely incorporated into their work. Knowing the right questions to ask is half the battle, but IT staff, contract negotiators and legal personnel, including outside lawyers, must be trained on the legal issues involved with Open Source as well as on the policies and procedures that you decide to take.
9. Reasonable Policies and Procedures Are Not Optional.
Many business people believe that if you give a lawyer a look at a business process and he or she will find the need for a written policy. In fairness, there are regulatory and other requirements that may dictate the need for a policy, but, in other cases, policies and procedures are good tools for legal risk management. Often existing policies and procedures can be revised to cover Open Source issues. With questions about security in Microsoft products, the business prospects of software companies and the evolution of subscription, on-demand and other models, there is no question that Open Source software will be an option in many software decisions. A ban on Open Source software will probably be as impractical and unwise as an "anything goes" or "Open Source only" policy. A reasonable, evolving set of policies and procedures crafted to fit the business needs and corporate risk comfort level of your company will invariably be the best approach to take.
10. Treat Open Source Policy as a Team Game.
It has become very clear in the last few years that IT policy should not be made in a vacuum. Consider the privacy example. Companies that left privacy policies to the IT department or the legal department quickly found that "standard language" had enormous implications for the marketing department, executives, sales staffs and others. Nothing turned out to be simple or standard until all constituents got involved and worked through the ramifications. Similarly, Open Source usage, especially if development projects are contemplated, creates a wide range of legal and business issues that should not be handled in isolation. Theory has to meet practice to get the best results. If the lawyer only looks at the legal issues and the CIO looks only at the IT issues, you increase the likelihood of finger-pointing when an unexpected, but quite predictable, bad result occurs. No one, especially me, likes the idea of yet another committee meeting, but Open Source is a good example where time and effort spent on the front-end will pay off substantially over the alternative of cleaning up potentially messy and expensive situations in which you may one day find yourself.
It has also helped build developer loyalty as developers feel empowered and have a sense of ownership of the end product. Moreover less costs of marketing and logistical services are needed for OSS. It also helps companies to keep abreast of all technology developments. It is a good tool to promote a companies’ image.
The OSS development approach has helped produce reliable, high quality software quickly and inexpensively. Besides, it offers the potential for a more flexible technology and quicker innovation. It is said to be more reliable since it typically has thousands of independent programmers testing and fixing bugs of the software.
The Open Source licenses represent a very different approach to licensing than most businesses, and their lawyers and legal departments, have become accustomed to in the commercial software setting. Research on the Open Source licenses will often turn up conflicting interpretations, misinformation, philosophical arguments and diametrically opposed points of view.
Here are some tips that wil help in dealing with legal issues relating to using opensource software in business
1. Understand the Different Approaches That the Open Source Licenses Take.
It is important not to think about the Open Source licenses in monolithic terms.Open Source licenses can fall into four families:
GPL, BSD, Netscape/Corporate, and Custom. That's not an "official" taxonomy anyways.
Different licenses can have very different consequences. It also makes sense that everyone, including your lawyer, understands the technology, business and legal aspects of the decision.
2. Pay Special Attention to the General Public License.
The General Public License represents a unique approach to software licensing. Many other Open Source licenses do not have the same terms. Most of the heated discussion and controversy you will hear about Open Source involves the General Public License.
If you choose only one thing to have policies about and require special review of, it should be the General Public License.
3. Remember the Source Code.
In simplest terms, the biggest difference between Open Source software and commercial software relates to the source code of the program. In nearly every commercial software license, you receive only the object code of the program – the machine-readable executable version of the program. You do not get the source code – the "programmer's version" – and you are likely to be restricted from even trying to produce or reverse-engineer the source code. In Open Source programs, you are entitled to the source code and can view it, fix it, modify it and improve it.
4. Make Reasonable Comparison with Commercial Software.
It's easy to find frantic concerns about Open Source software over reasons that apply just as easily to commercial software. In 2004, the threat of software patents to Open Source has been widely discussed. At the same time, we've seen Sun lose a patent infringement case involving its Java programming language to Kodak, with a settlement of $90 million dollars. Eolas won a patent infringement judgment against Microsoft. Is your comfort level, when you really think about, any better when you consider whether commercial software vendors can prove they own every bit of the code of their programs than it is for Open Source programs? Many of the same questions about contract enforceability of the Open Source licenses apply to all software licensed on a clickwrap or "clickthrough" basis. Analyze Open Source licenses in the same way you analyze commercial software licenses.
5. Think in Terms of Choosing, Rather Than Negotiating, Open Source Licenses.
In a certain sense, Open Source licenses just "are." They are a classic example of the clickwrap license agreement. You take it or you leave it. As a practical matter, there may be no one to negotiate with. The community development model also drives people toward the common standard licenses. Even if you are a developer, you will find few incentives to create your own custom Open Source license. As frustrating as it can be to lawyers, the best approach is to evaluate the available choices and weigh the consequences, not to think in terms of ways to tinker with or improve the terms of agreements. The focus becomes legal risk management and valuating legal risk in the context of business decisions.
6. Do Not Confuse Open Source with Public Domain.
Make no mistake – Open Source software is real intellectual property that is governed by a real license that puts limits on your rights and imposes certain obligations. The obligations may not be all that onerous in comparison to commercial licenses, but they do exist and you ignore them at your peril.
7. Inventory and Assess What You May Already Be Using.
Be aware that many standard programming tools are Open Source programs. There are many stories of programmers and IT staff "smuggling" in Open Source programs that they prefer to work with or selling unsuspecting management on the basis of cost savings. You may find that both internal IT staff and third party contractors are using or have used Open Source code, tools or programs without your knowledge. You need to know what you have before you can determine what issues to address and how. It has become very important for both business decision-makers and lawyers to have a good understanding of the technology issues, including what the software does and the alternatives available. Many companies are moving toward Open Source because IT staff can paint a rosy picture on security issues to justify a move to programs they like or want to try. It is important not to take those arguments at face value and at least be able to ask the right questions.
8. Open Source Use Requires Open Source Training.
There are many myths and misconceptions about Open Source programs and Open Source licenses. Many programmers incorrectly believe that Open Source code and tools may be freely incorporated into their work. Knowing the right questions to ask is half the battle, but IT staff, contract negotiators and legal personnel, including outside lawyers, must be trained on the legal issues involved with Open Source as well as on the policies and procedures that you decide to take.
9. Reasonable Policies and Procedures Are Not Optional.
Many business people believe that if you give a lawyer a look at a business process and he or she will find the need for a written policy. In fairness, there are regulatory and other requirements that may dictate the need for a policy, but, in other cases, policies and procedures are good tools for legal risk management. Often existing policies and procedures can be revised to cover Open Source issues. With questions about security in Microsoft products, the business prospects of software companies and the evolution of subscription, on-demand and other models, there is no question that Open Source software will be an option in many software decisions. A ban on Open Source software will probably be as impractical and unwise as an "anything goes" or "Open Source only" policy. A reasonable, evolving set of policies and procedures crafted to fit the business needs and corporate risk comfort level of your company will invariably be the best approach to take.
10. Treat Open Source Policy as a Team Game.
It has become very clear in the last few years that IT policy should not be made in a vacuum. Consider the privacy example. Companies that left privacy policies to the IT department or the legal department quickly found that "standard language" had enormous implications for the marketing department, executives, sales staffs and others. Nothing turned out to be simple or standard until all constituents got involved and worked through the ramifications. Similarly, Open Source usage, especially if development projects are contemplated, creates a wide range of legal and business issues that should not be handled in isolation. Theory has to meet practice to get the best results. If the lawyer only looks at the legal issues and the CIO looks only at the IT issues, you increase the likelihood of finger-pointing when an unexpected, but quite predictable, bad result occurs. No one, especially me, likes the idea of yet another committee meeting, but Open Source is a good example where time and effort spent on the front-end will pay off substantially over the alternative of cleaning up potentially messy and expensive situations in which you may one day find yourself.
TrackBack URL:
3 comments on "Ten Tips For Managing Legal Risks for Businesses Using Open Source Sotware"
Sort by:
Most Recent
Top Rated
Commented by
Navin Chand, Project Manager, Interra Information Technologies
| 07 02 2008 01:01:33 +0000
Report Abuse
Not Rated
Commented by
Hari Prasad K, Head - e-Infrastructure and Security
| 04 29 2008 22:38:00 +0000
Report Abuse
Rating : +1
Commented by
Debasish Deb, Project Manager, HP
| 04 25 2008 22:27:02 +0000
Report Abuse
Rating : +1
Found the article
"Ten Tips For Managing Legal Risks for Businesses Using Open Source Sotware"
interesting ?
Share with your connections and communities
Leading Recruitment Firm
- Create a confidential Career Profile and Resume/C.V. online
- Get advice for planning their career and for marketing of experience and skills
- Maximize awareness of and access to the best career opportunities
Viewers also viewed
|
|
Yes vs No |
|
|
214 referals
9 arguments,
128 views
|
|
|
money vs work environment |
|
|
1245 referals
27 arguments,
400 views
|
|
|
|
150 referals
5 votes,
363 views
|
|
|
|
|
|
|
Recent Knowledge (108)
|
|
INSPIRATIONAL STORY...BY AN INDIAN CEO... of a US firm! From studying under the streetlights... |
|
|
78 referals
11 comments,
630 views
|
|
|
No 1: India Since 1991, when economic liberalization unshackled India from the slow rate of... |
|
|
202 referals
5 comments,
93 views
|
|
|
In today's news, I came across this article that scientists at Sandia National Labs who were... |
|
|
0 referals
5 comments,
163 views
|
|
|
|
|
Sponsored Jobs
More From Author
yes even i too agree Nitin that there is no such credentials for a PMP professional in construction, as such most of them are not aware of it as it is in the case of IT industry, construction still recognises experience more than these... |
The PMBOK Guide is considered one of the most essential tools in the project management profession and is the de facto global standard for the industry. The primary purpose of the PMBOK Guide is to identify that subset of the Project Management...... |
Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF ("sea-surf") or XSRF, is a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts.... |