Re: GPL question

[Alexander Terekhov]

me@davecotter.com wrote:
> 
> can we all please stop talking in parables and references to topics we
> may not all share the detailed background knowledge of?  I'd like a
> straight answer with the entire answer within the text.
> 
> is the GPL basically not enforceable assuming you "work around" it
> technically by the aforementioned method?  Am i strange in thinking
> that this is strange?
> 
> What I glean is, yes i can, from the user's perspective, "include" a
> GPL'd software within my own proprietary software, and NOT be forced
> to release my source code?  (see previous for what i mean by "include")

http://www.usfca.edu/law/determann/softwarecombinations060403.pdf

<quote>

Under the U.S. Copyright Act, a combination of a computer program with 
other software results in the preparation of a derivative work only if 
the combination (a) is sufficiently permanent, (b) contains significant 
and creative portions of the other software, (c) is creative in its own 
right, and (d) involves significant and creative internal changes to 
the other software. Most software combinations fail to meet one or more 
of these requirements and constitute either compilations, collective 
works, or noncopyrightable aggregations, and neither affect copyright 
owners’ adaptation rights under Section 106 of the U.S. Copyright Act.

Software combinations involving dynamic links usually lack permanency, 
combination creativity and internal changes. Even software combinations 
through static links do not necessarily affect adaptation rights, 
because such linking often results in the creation of a compilation or 
non-creative aggregation of programs or sub-programs. Nevertheless, 
under the U.S. Copyright Act, software developers typically have to 
obtain a license before they may combine programs through static 
linking because this affects the duplication rights of the linked 
program’s copyright owner. Also, adaptation rights may be affected 
where software combinations (regardless of the code linking method) 
result in significant and creative changes to original screen output 
(e.g., in the context of computer games).

Under common commercial licensing conditions, end users typically 
receive an express or implied license to execute proprietary software 
in combination with other software, regardless of whether the
combination would qualify as a derivative work. Under the GPL, end 
users are free to combine GPLed code with any other code. Developers 
and distributors do not have to be concerned about contributory 
liability, so long as they distribute add-on software separately and 
the end-users are not legally restricted in combining the intended 
programs with the add-on software.

Anybody who wants to distribute programs in combination and alongside 
with GPLed code, however, will have to closely examine the reach and 
consequences of the various conditions and restrictions in the GPL. The 
term “derived work” in the GPL should be interpreted to mean 
“derivative works as defined by copyright law,” and as a consequence, 
most programs could be distributed in combination with dynamically 
linked GPLed code without the necessity of subjecting the linking 
programs to the GPL.

It seems possible, however, that courts may interpret the GPL in a 
broader way, which would increase concerns regarding the validity of 
the GPL under copyright misuse doctrines, competition laws and unfair 
contract term laws; such concerns can be greater or smaller depending 
on the circumstances of the licensing parties and jurisdictions 
involved. If such broad interpretations were to prevail––but the 
resulting validity concerns were not––the software industry might move 
more generally to GLP-like restrictive licensing practices that permit 
and prohibit certain software combinations. This would potentially have 
a serious impact on interoperability. Then, software combinations could 
become dangerous liaisons.

</quote>

regards,
alexander.