Tim wrote:
But you do not merely "use" libraries, you include them in the program.
In most cases, the end user supplies his own copy of the library, which
he obtained as a standard component of his OS distribtution, so I think
the whole concept is on pretty shaky legal ground.
This is the bit, about the computing industry, that I just find
incredibly weird: A strange use of the term derived.
Yes, if you took someone else's coding and put it *into* your coding, or
put in the essence of how it did its job even if a bit modified, your
work is "derived" from it.
The FSF claim has been that if the program won't work with any library
except the GPL'd one, it is a derived work even if it is distributed
separately. If the compile/run time linkage can work with alternate
libraries, then it isn't unless it includes covered material.
No, if your work communicates with someone else's program, it's not
"derived" from it. My chair is not "derived" from a screwdriver, even
if one was used to put it together. Nor is it derived from a table,
even chairs and tables are sold together.
You don't usually 'communicate' with a sql server, you include it's
client library code, sometimes with dynamic loading.
If you copied someone else's file, and put it into a package with your
own program, that's not "derived," either. That's a copying issue.
The GPL is the weird thing here: normally you are permitted to let an
end user obtain his own copies of all other needed libraries under
whatever terms are required, and you can distribute your own code that
links to them on your own terms. The FSF claims you can't, and that
things using library interfaces are derivative works unless an
alternate, non-GPL'd library exists. This is rather bizarre, since
with this interpretation, an unchanged piece of code might be considered
a derived work one day but not the next.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
