Open-source, for lawyers
From computerworld, concerning things to tell lawyers about open-source.
1. "Get educated on the business case for open-source." Unfortunately, lawyers counseling technology companies don't always understand the business reasons underlying the legal opinions and advice they are asked to provide. Take time to explain the business reasons and benefits behind your decision to embrace open-source. [Hmmm, a legal opinion is supposed to be an opinion on the law. While it may impact business, "business reasons" are not supposed to be the basis for the opinion.]
2. "Understand the basics of how open-source is built through the distributed software development model." Knowing how code is developed and shared, how contributions to projects are tracked and how decisions are made to include code (or not) will help them understand the extensive peer review and code vetting that takes place -- which in turn places open-source on more solid legal ground than the proprietary software companies would have them believe. Find opportunities for your lawyers to talk with engineers involved in open-source so they can hear firsthand how the development process works and how it produces results that are better from both a technology perspective and a legal perspective than they might expect. [Hmmm, what does peer review and code vetting have to do with solid legal ground?]
3. "Force your way into our business discussions about how to deploy or produce open-source. Educate us on the legal issues as those discussions progress and our decisions take shape." Getting your lawyers involved early means you can solve problems or mitigate the risks before they arise. Make it a practice to include them early in your thinking about adopting open-source.
4. "Don't propagate FUD. Question the claims made by proprietary software vendors and arrive at your own legal conclusions, in consultation with other lawyers experienced in open-source legal issues if needed." Let your attorneys know you expect them to question and then research the legal risks associated with open-source, but that those same issues should be examined for proprietary software as well. The development and use of all software carries risk. Those risks are largely the same for open-source and its proprietary alternatives.
5. "Resist the temptation to create a new open-source license for software we develop; use an existing Open Source Initiative-approved license if possible." Like it or not, some attorneys' bread and butter is drafting software licenses. However, each new open-source license makes more work and creates more legal risk for end users. Worse, a multitude of open-source licenses often results in less code being reused because the licenses under which they are distributed are incompatible. If an existing license doesn't address your business needs, encourage your lawyers to work with the steward of an existing license to seek changes that could result in that license working for you.
6. "Odds are we have (or will soon have) open-source software in our corporate environment. Establish and implement processes and procedures for managing this inevitability." Surprising at it may sound, CIOs and their lawyers often believe that if they tell their engineers and employees not to bring unapproved software (whether proprietary or open-source) into the corporate environment, they won't. The reality is it happens. Instruct your attorneys to partner with your IT department to develop policies and procedures for software as it comes into your company, as well as develop a mandatory product-review process that occurs before any software product is shipped.
7. "Join in the long-term effort to insist on reform of the patent system, particularly where software patents are concerned." The proliferation of software patents is the single biggest threat to proprietary and open-source software. Task your lawyer with voicing concerns in one of the several legal forums or associations where reforms are debated and lobbying efforts are mounted, such as the U.S. Patent Bar, the American Bar Association or the American Intellectual Property Law Association. [Hmmm, there are no "software" patents. There are business method patents. There is no much discussion of them in the current patent reform bill, HR 2795.]
1. "Get educated on the business case for open-source." Unfortunately, lawyers counseling technology companies don't always understand the business reasons underlying the legal opinions and advice they are asked to provide. Take time to explain the business reasons and benefits behind your decision to embrace open-source. [Hmmm, a legal opinion is supposed to be an opinion on the law. While it may impact business, "business reasons" are not supposed to be the basis for the opinion.]
2. "Understand the basics of how open-source is built through the distributed software development model." Knowing how code is developed and shared, how contributions to projects are tracked and how decisions are made to include code (or not) will help them understand the extensive peer review and code vetting that takes place -- which in turn places open-source on more solid legal ground than the proprietary software companies would have them believe. Find opportunities for your lawyers to talk with engineers involved in open-source so they can hear firsthand how the development process works and how it produces results that are better from both a technology perspective and a legal perspective than they might expect. [Hmmm, what does peer review and code vetting have to do with solid legal ground?]
3. "Force your way into our business discussions about how to deploy or produce open-source. Educate us on the legal issues as those discussions progress and our decisions take shape." Getting your lawyers involved early means you can solve problems or mitigate the risks before they arise. Make it a practice to include them early in your thinking about adopting open-source.
4. "Don't propagate FUD. Question the claims made by proprietary software vendors and arrive at your own legal conclusions, in consultation with other lawyers experienced in open-source legal issues if needed." Let your attorneys know you expect them to question and then research the legal risks associated with open-source, but that those same issues should be examined for proprietary software as well. The development and use of all software carries risk. Those risks are largely the same for open-source and its proprietary alternatives.
5. "Resist the temptation to create a new open-source license for software we develop; use an existing Open Source Initiative-approved license if possible." Like it or not, some attorneys' bread and butter is drafting software licenses. However, each new open-source license makes more work and creates more legal risk for end users. Worse, a multitude of open-source licenses often results in less code being reused because the licenses under which they are distributed are incompatible. If an existing license doesn't address your business needs, encourage your lawyers to work with the steward of an existing license to seek changes that could result in that license working for you.
6. "Odds are we have (or will soon have) open-source software in our corporate environment. Establish and implement processes and procedures for managing this inevitability." Surprising at it may sound, CIOs and their lawyers often believe that if they tell their engineers and employees not to bring unapproved software (whether proprietary or open-source) into the corporate environment, they won't. The reality is it happens. Instruct your attorneys to partner with your IT department to develop policies and procedures for software as it comes into your company, as well as develop a mandatory product-review process that occurs before any software product is shipped.
7. "Join in the long-term effort to insist on reform of the patent system, particularly where software patents are concerned." The proliferation of software patents is the single biggest threat to proprietary and open-source software. Task your lawyer with voicing concerns in one of the several legal forums or associations where reforms are debated and lobbying efforts are mounted, such as the U.S. Patent Bar, the American Bar Association or the American Intellectual Property Law Association. [Hmmm, there are no "software" patents. There are business method patents. There is no much discussion of them in the current patent reform bill, HR 2795.]
posted by Lawrence B. Ebert at 5:42 AM
0 Comments:
Post a Comment
<< Home