Hello Dimitry and others,
AD 1. It is not really a valid argument, but rather an impulse for thought.
That we already do something does not logically imply that it is all right.
If you knew that you are distributing something under a license incompatible
with GNU GPL V2, maybe there should have been a discussion about that. On
the other hand, AFAIK GPL V3 is planned to be compatible with Apache
license, so maybe there is a way out of a trouble.
AD 2. I am afraid that linking together does not present a mere aggregation.
follows, with highlights by me, probably difficult to read in a plain text
mailing list, but hopefully readable at your mailbox.
* What is the difference between "mere aggregation" and "combining two
modules into one
aggregation of two programs means putting them side by side on the same
CD-ROM or hard disk. We use this term in the case where they are separate
programs, not parts of a single program. In this case, if one of the
programs is covered by the GPL, it has no effect on the other program.
Combining two modules means connecting them together so that they form a
single larger program. If either part is covered by the GPL, the whole
combination must also be released under the GPL--if you can't, or won't, do
that, you may not combine them.
What constitutes combining two parts into one program? This is a legal
question, which ultimately judges will decide. We believe that a proper
criterion depends both on the mechanism of communication (exec, pipes, rpc,
function calls within a shared address space, etc.) and the semantics of the
communication (what kinds of information are interchanged).
If the modules are included in the same executable file, they are definitely
combined in one program. If modules are designed to run linked together in a
shared address space, that almost surely means combining them into one
By contrast, pipes, sockets and command-line arguments are communication
mechanisms normally used between two separate programs. So when they are
used for communication, the modules normally are separate programs. But if
the semantics of the communication are intimate enough, exchanging complex
internal data structures, that too could be a basis to consider the two
parts as combined into a larger program.
On 6/6/07, Dimitry Polivaev <dpolivaev@...> wrote:
> Hello everybody,
> I see that we discuss generally the question, whether the FreeMind
> license (GPL) allowes us to to make use of independently developed
> pieces of software which do not have the GPL license. I think that we
> can do it because of the following arguments:
> 1. we already do it distributing java archive files released under
> Apache Foundation license together with the FreeMind.
> 2. the text of the GPL contains following passage clearly related to the
> discussed topic:
> "... mere aggregation of another work not based on the Program with the
> Program (or with a work based on the Program) on a volume of a storage
> or distribution medium does not bring the other work under the scope of
> this License." (http://www.gnu.org/licenses/gpl.html)
> In this sense I do not see any reasons prohibiting inclusion of
> HotEqn.jar in the standard FreeMind distribution package.
> To be properly understood I have to add that I prefer using the open
> source software whenever it is possible because of the maintaining
> reasons, ad I see that some organisations may have further restrictions
> on the use of the freeware which is not open source based. I make
> efforts to contact the author of the used component. But even if my
> efforts are not successful, the component itself and freemind may be
> distributed together.
> Regards, Dimitry
> Dan Polansky schrieb:
> > Hello Chris and Dimitry,
> > should not the Patches tracker contain only open-source code?
> > Best regards,
> > Dan
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> Freemind-developer mailing list