SCO NDA Offers Little Information, Much Risk
On May 14, SCO VP Chris Sontag offered to show evidence of SCO's infringement claims against Linux, under a non-disclosure agreement, to an independent panel of experts. SCO has released the text of the agreement, and we include it below.
Dan Ravicher, an attorney who specializes in free software and open-source issues at the firm of Patterson, Belknap, Webb & Tyler, said in an interview there are three key problems with the NDA. First, Ravicher said, "SCO can pick and choose among all its evidence" to show only the parts that back up the company's claims. "They're agreeing to let you see the half of the picture that they want you to see", he added.
Second, the NDA does not exclude information that the recipient obtained in ways other than from SCO. If SCO showed a patent or other public document to someone bound by the NDA, that person would not be allowed to discuss it even if he or she had been previously aware of it, Ravicher said. "The definition of confidential information is much larger than I've seen in any other agreement", Ravicher said. "It covers a lot of stuff that wouldn't be, by a textbook definition, confidential."
Finally, the NDA requires any dispute to be settled in the state of Utah, which could be "pretty onerous" for people outside the state. "They could sue me and make me go to Utah to prove I didn't disclose confidential information", Ravicher said.
Ravicher's interview does not constitute legal advice, and anyone considering signing an NDA should consult with his or her own legal counsel.
"If someone wants to enter this despite all those bad parts, it's a free country", Ravicher said. "I'm not saying someone should or should not do this, but these are things that you should be aware of."
Chris DiBona, the former Slashdot editor and Damage Studios co-founder who Linus Torvalds suggested for the panel, said he does not think anyone actively involved in kernel development or planning to contribute to free software projects should sign the NDA. But he said he wants to find out if other software experts would be interested in participating. The following are the qualifications this person should have:
Can sign an NDA with SCO without endangering existing open-source projects, including BSD, Linux, other kernels or other projects.
Experience with a large scale software project in C, with some low level systems work.
No business connection to SCO or any company involved in a legal case with SCO.
No direct connection to SCO as a licensee.
Not bound by an existing NDA that would prohibit him or her from expressing his or her opinion on this matter.
Have the time to do the work involved.
If you meet these qualifications and are interested in participating, you can contact [Linux Journal], and we will put you in touch with the right person at SCO.
[Linux Journal] publisher Phil Hughes has instructed Linux Journal staff not to accept the NDA because of concerns that it may interfere with the publication's normal work, which can involve reading and publishing Linux kernel code.
The following text is the version of the NDA we received from SCO on Wednesday, June 4, 2003:
Confidentiality and Nondisclosure Agreement This Confidentiality and Nondisclosure Agreement is dated June ____, 2003 and is by and between the following Parties: SCO: The SCO Group, Inc. 355 South 520 West Lindon, Utah 84042 RECIPIENT: ______________________________ ______________________________ ______________________________ WHEREAS, The SCO Group, Inc. ("SCO") possesses certain Confidential Information, including source code and other proprietary information, and WHEREAS, RECIPIENT desires to review the Confidential Information, and thereafter to generally summarize portions of the Confidential Information without revealing the confidential source code itself, or its design methods and concepts, or specific comparisons of code; NOW THEREFORE, IN CONSIDERATION of the mutual promises and agreements made herein, and other good and valuable consideration, THE PARTIES agree as follows: 1. Disclosure of Confidential Information. RECIPIENT desires that SCO disclose to RECIPIENT certain Confidential Information relating to SCO's Unixware and SCOsource businesses and certain statements SCO has made publicly regarding SCO's property relative to the Linux operating system. RECIPIENT acknowledges that it will receive access only to a portion of information relevant to these issues. 2. Purpose. RECIPIENT warrants that the Confidential Information disclosed by SCO to RECIPIENT shall only be used for the purposes of (a) evaluating SCO's public statements regarding its UNIX source code and attendant rights and the ways in which those UNIX rights affect one or more distributions of Linux, and (b) evaluating whether RECIPIENT's or other's use of Linux violates any of SCO's UNIX-related source code or other rights. Following RECIPIENT's review of the Confidential Information, it may publicly offer its general opinion on and a general, brief summary of the Confidential Information it has seen. However, RECIPIENT shall not divulge details or specifics as to any Confidential Information with respect to specific source code, files, derivative works, modifications or design methods and concepts it has seen, nor shall it divulge any third party information it has seen, either in source code, products, contracts or in other third party Confidential Information. 3. Definition of Confidential Information. " Confidential Information" means any and all data, technology, research, inventions, intellectual property, trade secrets, know how, computer programs, source code, file names, file trees or extensions, works of authorship, products, processes, methods, customer names, plans, forecasts, prices, business information, financial information, and other information shown or relayed by SCO to RECIPIENT on _______________________ [date]. 4. Protections. RECIPIENT shall not disclose or transfer any Confidential Information to any other person or entity. RECIPIENT shall not use Confidential Information except for the purpose and by the methods described in Paragraph 2. RECIPIENT shall use its best efforts to ensure against any disclosure, transfer or use of Confidential Information not specifically authorized by SCO in writing. 5. Employees. Access to Confidential Information by RECIPIENT's employees shall be limited by RECIPIENT to employees having a specific need to know. RECIPIENT shall be responsible for its employees and their compliance with this Agreement. 6. No License. SCO is not obligated to grant to RECIPIENT any license or right under any patent, trade secret, copyright, trademark or other intellectual property right of SCO. 7. No Obligation to Disclose. SCO has no obligation under this Agreement to disclose to RECIPIENT any Confidential Information which SCO elects to withhold. 8. Injunctive Relief. It is understood and agreed that damages are an inadequate remedy in the event of a breach or intended or threatened breach by RECIPIENT of this Agreement and that any such breach by RECIPIENT will cause SCO irreparable injury and damage; accordingly, RECIPIENT agrees that SCO shall be entitled, without waiving any additional rights or remedies (including monetary damages) otherwise available to SCO at law, or in equity, or by statute, to preliminary and permanent injunctive relief in the event of a breach or intended or threatened breach by RECIPIENT. 9. Severability. In case any one or more of the provisions contained herein shall, for any reason, be held to be invalid, illegal, or unenforceable in any respect, such invalidity, illegality or unenforceability shall not affect any other provisions of this Agreement, and this Agreement shall be construed and enforced as if such invalid, illegal or unenforceable provision(s) had never been contained herein, provided that such invalid, illegal or unenforceable provision(s) shall first be curtailed, limited or eliminated to the extent necessary to remove such invalidity, illegality or unenforceability with respect to the applicable law as it shall then be applied. 10. Final Agreement. This Agreement constitutes the final, complete and exclusive agreement between SCO and RECIPIENT concerning the subject matter of this Agreement and supersedes all prior agreements, understandings, negotiations and discussions, written or oral, between SCO and RECIPIENT with respect thereto. Any modification, recission or amendment of this Agreement shall not be effective unless made in a writing executed by SCO and RECIPIENT. 11. Waiver. Any waiver of, or promise not to enforce, any right under this Agreement shall not be enforceable unless evidenced by a writing signed by the Party making said waiver or promise. 12. Construction. The headings in this Agreement are for the purpose of convenience only and shall not limit, enlarge, or affect any of the covenants, terms, conditions or provisions of this Agreement. This Agreement represents the wording selected by the Parties to define their agreement and no rule of strict construction shall apply against either Party. 13. Governing Law, Jurisdiction and Attorney's Fees. This Agreement shall be governed and enforced in accordance with the laws of the state of Utah, without regard to its conflict of laws principles, and RECIPIENT hereby consents to the exclusive jurisdiction and venue in courts (whether federal or state) in the state of Utah. RECIPIENT waives all defenses of lack of personal jurisdiction and forum non conveniens. In any action to enforce any right or remedy under this Agreement or to interpret any provision of this Agreement, the prevailing party will be entitled to recover its reasonable attorney's fees, costs and other expenses. 14. Authorization. The persons signing below represent that they are authorized to execute this Agreement for and on behalf of the Party for whom they are signing and to bind said Party to the terms of this Agreement. AGREED TO AND ACCEPTED BY: ("RECIPIENT") Authorized Signature: Name (print): Title: The SCO Group, Inc. ("SCO") Authorized Signature: Name (print): Title:
Don Marti is Editor in Chief of Linux Journal.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide