(Mike Mitchell)
11/25/2011 7:52:00 AM
On Thu, 24 Nov 2011 21:39:50 -0600, ralph <nt_consulting64@yahoo.net>
wrote:
>On Thu, 24 Nov 2011 23:48:59 +0100, Schmidt <sss@online.de> wrote:
>
>>Am 24.11.2011 20:02, schrieb ralph:
>>> On Thu, 24 Nov 2011 17:54:44 +0000, MM<kylix_is@yahoo.co.uk> wrote:
>>>
>>>> If I'm reading the incredibly convoluted GNU GPL v3 legal blurb it
>>>> seems that I have to release *my* freeware application under the GPL
>>>> simply for using a GPL'd ActiveX control in it.
>>>>
>>>> If this is correct, then obviously I won't use the ActiveX, but will
>>>> seek an alternative way of getting the required functionality.
>>>>
>>>> I can understand needing to make the source code of the ActiveX
>>>> control available or pointing to a URL whence it can be downloaded,
>>>> but to require me to open my freeware app source code is risible.
>>>>
>>>
>>> The GPL considers a product or work as a whole. In this case you can
>>> argue that your application and the ActiveX component are separate
>>> "works". Thus you would need to provide the source code for the
>>> component, but not for your application.
>>>
>>> Others take a different view arguing something along the lines of -
>>> your application wouldn't be the complete 'work' it is without the
>>> component. So using any Open Source invokes the GPL.
>>
>>One has to consider the concrete License of the component.
>>And not each and every OpenSource-Library or -Component
>>(since you wrote "any Open Source invokes the GPL")
>>comes under the GPL-V2 or GPL-V3, which are the most
>>"restrictive" ones (with regards to embedding such
>>open-source-based parts into closed-source-solutions).
>>
>>There's a lot of OpenSource-Libs, which come under
>>LGPL, MIT- or even BSD-License, which allow "mixed-up"
>>solutions (combination and redistribution with
>>closed-source-parts, without the necessity, to open
>>ones own "surrounding sourcecodes").
>>
>>As for Libs under GPL - those are (if there's no
>>special exception-clause from the author himself)
>>normally not considered to be "integratable" or
>>"shipable" without opening all the other parts
>>of a solution under GPL too.
>>
>>Better to stick to LGPL or MIT- or BSD-licensed libs,
>>if one wants to be on the safe side (when there's
>>alternatives to the "plain GPL-Lib" in question,
>>which after some digging-around is often the case).
>>
>>If there's no alternative to the Lib under GPL,
>>then there's some "grey zone", under which it
>>is allowed to use these Libs - and this is, when
>>your App is not really dependent on the GPLed-
>>functionality (when it's not an integral part
>>of your Application) - meaning, when the
>>functionality is more or less optional - and
>>could be provided also by a different Library
>>or COMponent.
>>For example, if the functionality is for
>>viewing PDFs - and your Application comes per
>>Default with settings for the Acrobat-PDF-
>>Control - but you offer your users the choice,
>>to optionally make use of an alternative way
>>to view PDFs within your App (in the cleanest
>>way, when there's a Dialog, which tells them
>>about the GPLed Component and its license -
>>and enables this *alternative* over a user-switch,
>>then GPLed-libs, which are "dynamically bound"
>>this way, are not considered an "integral part"
>>of your App - and hence the GPL is not violated.
>>
>>In other words, if your App "can live without it",
>>then it's OK to keep your sources closed -
>>as on the other hand, if your App is "badly in
>>need" of the GPLed component (to achieve its main-
>>functionality at all), then one is good advised,
>>to open also his "surrounding sources" under GPL.
>>
>
>Good summary.
>
>Developers who primarily work with Windows will easy accept that an
>ActiveX component is a separate work. Programmers from other realms
>will argue to the death that a "library" is a "lib" whether dynamic or
>static, binary or text, function-called or object, in-process or
>out-of-process, ...
>
>The main loop-hole is proving your App "can live without it". You do
>that by providing an alternative which leads to an inevitable
>consequence - if you can use something else then why not use it and
>avoid any issues with GPL in the first place. <g>
>
>I never touch GPL.
Got an idea how to mimic the functionality of that UUDeview ActiveX in
the way it doesn't care what order the multiparts are handed to it?
The only way I can see is for a Sub or Class to create as many
temporary files as needed to shuffle the parts into the right order,
then read the whole thing as one continuous stream. This would be
easier with yEnc since every part has that ybegin=part=nn at the
start, whereas UUcode doesn't. It only has begin on the first file.
Not hard, but a PITA when the work has already been done and the GPL
he say no.
MM