commercial use

[John Bailey]

On 08/26/2010 11:23 AM, Enrico Weigelt wrote:
> * Ethan Blanton <elb at pidgin.im> wrote:
> 
>> Then why is linking into the same address space derivative?  Your
>> claim makes no sense.  Address space is not covered in copyright law,
>> either.  What about a microkernel system?
> 
> You're right. Linking into the address space is not the point.
> But using the code into other code. Note: code (text), not concepts.
> So, speaking a language (which an network protocol is) does not
> qualify this, and it's not required to use a specific code, eg.
> from pidgin, to speak that language. It would, if you use pidgin
> code to generate the protocol handling.
> 
> 
> cu

As Ethan said, this is not the appropriate place to argue the semantics of the
GPL's effects on users of our code.  In that vein, I am declaring that this is
the last message to hit the development list on this thread.  If further
discussion is needed, it will go to discussion at imfreedom.org, or it will be ignored.

All that said, the effects of the GPL on libpurple users are clear, particularly
when the Free Software Foundation's extensive documentation on the subject is
taken into consideration.  ANY work that would use libpurple via a network
protocol is a derivative work of libpurple IF libpurple cannot be
*transparently* interchanged for another backend library.  If the client
interacting with libpurple via a network protocol *requires* modification to use
a different backend library, then the client is a derivative work, whether a
network protocol is involved or not.  Copyright has a quite distinct and (for
those who have no clue) unexpected effect on software, as it covers *both*
source *and* object code.  Your arguments on this subject are pointless and
meaningless.

John

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20100826/3344ff8a/attachment.sig>