<quote> 1. The language of GPLv3 is difficult to understand. A license should clearly inform people what they can and cannot do. GPLv3 does neither. Lawyers assume that they could understand it if only they were software engineers, and engineers assume that the lawyers grasp it. Both are wrong.
Since Richard Stallman of the Free Software Foundation (FSF), who controls the process, is an engineer, and since an important function of the document should be to provide engineers with instructions on how to write code that can interact with code covered by the GPL, the difficulties it presents to engineers are particularly unsettling. 2. The uncertainties and ambiguities must be deliberate. Eben Moglen of the Software Freedom Law Center (SFLC) has been working with Stallman on the revision for over two years. When a lawyer with Moglen's credentials spends two years producing something so impenetrable, it is by intent, not ineptitude. Furthermore, the rationale document explaining the new license is devoid of examples. Lawyers who are trying to be clear instruct through illustration, and the failure to use this technique should be a red flag. The drafters want the document to be misunderstood, they want to force programmers to return to them for interpretations, which these can be favorable or not, depending on the closeness of petitioner's connection to the FSF and the SFLC. 3. The problem of linked programs is not resolved. Under GPLv2, there is a question concerning how closely an ancillary program must be linked to a GPL'ed program to trigger the GPL requirement that the code of the ancillary program also be made open. GPLv3 does not resolve this issue. Indeed, it makes the matter even more inscrutable than before. 4. Interoperability is inhibited. Customers are demanding that the offerings from different vendors interoperate. They care not whether software is proprietary or open source, and they do not want to be bothered by civil wars within the software community. The GPLv3 is designed to prevent such interoperability, through its provisions on patents, DRM, linking, and web services. Engineers cannot in good conscience advocate that their employers marginalize themselves with respect to the needs of the customers. These GPLv3 provisions will also discourage corporate participation in standard-setting activities by forcing companies that license IP necessary for standards to extend the terms to those who do not reciprocate or are unwilling to pay even reasonable royalties. 5. Dual licensing will become very difficult. As the OpenSolaris Governing Board (OGB) concluded in February 2007: "There are significant downsides to dual licensing, including, but not limited to, license complexity, confusion and the possibility of long term bad press from any exception language that such a license would inevitably require." (CAB/OGB Position Paper # 20070207 version 0.6; Topic: Should OpenSolaris be dual licensed via CDDL and GPLv3?) The latest version may be improved, but the problems remain. 6. The use of Digital Rights Management (DRM) in conjunction with code covered by GPLv3 may well be prohibited as a practical matter; this will condemn GPLed code to fringe status. The language of the license is not clear, but many public statements by its proponents are clear: they detest any form of DRM and would like to keep it from operating in conjunction with GPLv3 code. Whatever one's opinion of DRM, and many in the tech community oppose it, content creators and disseminators regard it as vital, and will not use any software that is incompatible with DRM. 7. The DRM provisions are morally objectionable By what right do programmers, in the name of programming "freedom," dictate to other creators that these cannot impose controls designed to prevent people from free-riding on their creativity? That is not freedom; that is authoritarianism. Programmers who oppose DRM need to suggest business models that can satisfy other creators, not impose their own parochial views. 8. The application of the GPLv3 to web-based services is muddled. At the outset of the revision process, one of the issues concerned companies that take GPL'ed code, modify it, and then use the result to provide web-based services to consumers. Since these companies are not distributing their modifications, they are not subject to the requirement that they make these modifications available. Some members of the open source community regard web-based services as a loophole that should be closed. However, GPLv3 explicitly says, in one section, that this is not being done, that the rules remain unchanged. But another section allows contributors to GPL'ed programs to add to the provisions of the GPLv3 language from a different software license (the Affero license) that would require web-based service companies using that particular code to reveal the source code of any modifications. This requirement might (ambiguity, again) cover the code for all modifications made by the web-service company, not just those related to particular code covered by the Affero license. But it is impossible to be certain because the relevant portion of the Affero license has not even been drafted. Any engineer working for a company that in any way produces web-based services must take account of the reality that patches or other code additions might be subject to Affero license terms as well as GPLv3 ones, and that the result could be complex multi-forking. 9. GPLv3 will not be part of "the great patent workaround." Everyone knows that the patent system is in some disarray, especially with respect to software, with problems of bad patents, vague patents, poor search tools, and other issues. People are working through Congress, the courts, and the USPTO to clean up the problems. In the interim, tech companies have developed "the great patent work-around," which consists of cross-licenses, guarantees of RAND and commercially-reasonable terms, standards bodies, non-suit clauses, and other devices designed to let the tech world function efficiently. The GPLv3 is specifically designed to keep users of its code from being part of this system and to prevent them from interacting with proprietary code. It rejects arrangements similar to the recent Microsoft-Novell deals. It may attempt to outlaw the MSFT-NOVL deal retroactively -- that is still under debate. 10. GPLv3 has serious implications for makers of devices that use embedded code. Under GPLv2, a question arose about the situation in which a maker of a hardware device modifies GPL'ed code for use as an operating system. Does the sale of the device count as a "distribution" of the modified code that requires that the buyer be furnished with the source? FSF says "yes," but not everyone has been aware of this interpretation, which is codified in GPLv3. Any manufacturer that thinks its operating system provides a competitive advantage should not use GPLed code in the future. </quote> He he. regards, alexander. -- http://www.linuxtaliban.com/bilder.htm _______________________________________________ gnu-misc-discuss mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-misc-discuss
