[Adium-devl] GPL and Objective C
Ofri Wolfus
ofri.wolfus at gmail.com
Mon Mar 6 10:33:06 UTC 2006
You're missing the most basic thing - you NEVER call a GPL code in a
message. The system is the one that does or doesn't call it. It's
completely out of your hands to decide what method implementation
will be used by objc_msgSend(). I can even go one step further, and
say that even if today my code results in a GPL function being
called, in a future version of OS X it may not. You can not be held
responsible for the decisions your computer makes, and therefor can
not be blamed in calling GPL method imps.
Finding these little holes in papers is what lawyers get paid for :-P
- Ofri
On 06/03/2006, at 02:05, Colin Barrett wrote:
> Oh yeah? Well I wrote some awesome machine code out on a box of
> punch cards, and it executes your JMP statements, so now I own all
> *YOUR* stuff!
>
> You just can't beat little tiny holes in paper, man. You just can't.
>
> -Colin
>
> On Mar 5, 2006, at 5:16 PM, Adam Iser wrote:
>
>> I just wrote a block of assembly which JMPs into GPL code (A JMP
>> is not
>> a function call! HA! HA!). All your GPL code are belong to me.
>>
>> - Adam
>>
>> Ofri Wolfus wrote:
>>
>>> Hi everyone,
>>>
>>> A discussion with David in IRC has lead me to talk with a friend of
>>> mine (who is a lawyer) about the nature of objc code released under
>>> GPL. As you probably know, a message to an object is translated by
>>> the compiler to a call to one of the objc_msgSend() functions.
>>> Therefor, you never get to call any 'real' function from your code
>>> and you only indirectly call GPL functions.
>>> Well, GPL code forbids you from linking to it unless your code is
>>> GPL
>>> as well, but what happens if the GPL code lives in a plugin which is
>>> dynamically loaded? This is what GPL has to say about it (taken from
>>> http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins):
>>>
>>> "It depends on how the program invokes its plug-ins. If the program
>>> uses fork and exec to invoke plug-ins, then the plug-ins are
>>> separate
>>> programs, so the license of the plug-in makes no requirements about
>>> the main program.
>>> If the program dynamically links plug-ins, and they make function
>>> calls to each other and share data structures, we believe they
>>> form a
>>> single program, which must be treated as an extension of both the
>>> main program and the plug-ins. In order to use the GPL-covered plug-
>>> ins, the main program must be released under the GPL or a GPL-
>>> compatible free software license, and that the terms of the GPL must
>>> be followed when the main program is distributed for use with these
>>> plug-ins.
>>> If the program dynamically links plug-ins, but the communication
>>> between them is limited to invoking the `main' function of the plug-
>>> in with some options and waiting for it to return, that is a
>>> borderline case."
>>>
>>> But message sending is not a function call... Therefor, a message
>>> being sent to a GPL class, does not force the sender to be GPL as
>>> well. As long as your code does not set instance variables of a GPL
>>> class (directly - accessors are fine), use IMP caching or use the
>>> @defs() directive, your code DOES NOT have to be released under GPL
>>> license.
>>>
>>> But what about the classes themselves? GPL specifically says that
>>> one
>>> can not use GPL data structures in a non-GPL code. Well... it
>>> doesn't
>>> bother us at all since classes are translated by the compiler to the
>>> objc_class struct which has no effect on us. The same goes with
>>> instances of classes which are translated to pointers to an
>>> objc_object struct.
>>>
>>> Quite revolutionary ha? ;-) Using plugins, commercial apps can take
>>> advantage of ANY GPL code that can be wrapped in a cocoa class. Not
>>> so good... But for us it also means some good stuff. It means that
>>> Adium and ChatKit can use protocol libraries which are not GPL. :D
>>>
>>> - Ofri
>>>
>>>
>>> _______________________________________________
>>> Adium-devl mailing list
>>> Adium-devl at adiumx.com
>>> http://adiumx.com/mailman/listinfo/adium-devl_adiumx.com
>>>
>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Adium-devl mailing list
>> Adium-devl at adiumx.com
>> http://adiumx.com/mailman/listinfo/adium-devl_adiumx.com
>>
>
More information about the devel
mailing list