Copyleft/guide Changeset - d1962968b668

Changeset - d1962968b668

Parent rev.

Child rev.

[Not reviewed]

2020-pull-requests/05

0 1 0

Hugo Roy - 9 years ago 2015-04-03 01:57:03
hugo@fsfe.org

deleted redundant paragraph and added suggestion/comment

1 file changed with 9 insertions and 6 deletions:

gpl-lgpl.tex

0 comments (0 inline, 0 general)

gpl-lgpl.tex

➞

Show inline comments

@@ ... @@
 would get with a typical work not covered by a copyleft license.  Thus, to
 say that this condition is any way unreasonable is simply ludicrous.
 The GPL  recognizes what is outside its scope.  When a programmer's work is
 ``separate and independent'' from any GPL'd program code with which it could be
 combined, then the obligations of copyleft do not extend to the work
 separately distributed.  Thus, Far from attempting to extend copyleft beyond the
 scope of copyright, the licenses explicitly recognize.
 Thus, GPL recognizes what is outside its scope.  When a programmer's work is
 ``separate and independent'' from any GPL'd program code with which it could
 be combined, then copyleft obligations do not extend to the independent work
@@ ... @@
 the scope of copyright, GPL explicitly limits the scope of copyleft to the
 scope of copyright.
 % Comment: The above is only true to the extent that the independent work is
 % not also combined as part of a whole based on the GPL'd program, because in
 % such case, the licensor needs to "extend" the GPL terms to the whole,
 % including the independent work "regardless of who wrote it".
+%
 % I think the paragraph could thus benefit in clarity by not mentioning the
 % "limits the scope of copyleft to the scope of copyright" here (but that may
 % have to be with the fact I disagree with this statement in general 😉
 GPL does not, however (as is sometimes suggested) distinguish ``dynamic''
 from ``static'' linking of program code.  It is occasionally suggested that a
 subroutine ``dynamically'' linked to GPL'd code is, by virtue of the linking

0 comments (0 inline, 0 general)