Re: GPLv3 comedy unfolding -- DeLong: "TOP 10 REASONS WHY SOFTWARE ENGINEERS SHOULD BE WARY OF GPLv3"

[Alexander Terekhov]

<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