GPL contamination with ffidl?
pal...@yahoo.com
an issue with its license. It appears as though ffidl is under a BSD
license but fficall is GPL'ed which makes it unusable for me, even in
open source apps. But reading the docs it seems that one can use
libffi (BSD) in place of fficall? Or is libffi used in addition to
fficall?
Anyone out there know for sure whether there is some configuration of
ffidl what would be completely free of GPL code?
Thanks
/Ashok
Robert Hicks
I *thought* that if you linked a library you did not have to GPL the
whole thing? Is that incorrect?
I am not a GPL fan at pretty much any level.
Robert
Georgios Petasis
No, if you link with GPL software then the whole app becomes GPL. You
can only execute a GPL program from a non GPL app...
George
Robert Hicks
wrote:
Ah, no wonder people hate it.
Robert
Daniel A. Steffen
> I was thinking of using FFIDL to create runtime bindings but ran into
> an issue with its license. It appears as though ffidl is under a BSD
> license but fficall is GPL'ed which makes it unusable for me, even in
> open source apps. But reading the docs it seems that one can use
> libffi (BSD) in place of fficall? Or is libffi used in addition to
> fficall?
no, ffidl uses either libffi or ffcall, but never both. If you use my
0.6 update to ffidl, the choice of libffi vs ffcall is a compile time
option (with libffi being the default for GPL avoidance reasons).
A ffidl binary built with the default configure options (or with --
enable-libffi) will contain only BSD licensed code, whereas a ffidl
built with --enable-ffcall will indeed become GPLd as a whole by
virtue of static linking with ffcall.
I did allude to this issue on
http://wiki.tcl.tk/ffidl
but probably did not go into enough detail, feel free to add
clarifications...
Cheers,
Daniel
Dave (from the UK)
>>No, if you link with GPL software then the whole app becomes GPL. You
>>can only execute a GPL program from a non GPL app...
>>
>>George
>
>
> Ah, no wonder people hate it.
>
> Robert
>
The LPGL
http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License
was created to allow people to make code as a library and others link to
it without releasing their source code.
I think the choice is nice. Someone wanted me to re license 'atlc'
under the GLPL (from GPL) so they could link it with their commerical
closed-source PCB analaysis software. I declined to do that. That was my
choice and their choice not to use it.
------
Dave (from the UK)
Please note my email address changes periodically to avoid spam.
It is always of the form: month...@althorne.org
Hitting reply will work for a few months only - later set it manually.
http://chessdb.sourceforge.net/ - a Free open-source Chess Database
Kevin Walzer
Is there any way to build ffidl as a universal binary on OS X? (10.4.8)
I believe the binaries you built are PPC only? I've had various
difficulties getting it to build at all--probably my own
incompetence--but I also noted that it's based on TEA 3.2, and isn't TEA
3.5 better for fat binaries?
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
pal...@yahoo.com
/Ashok
On Feb 26, 3:55 am, "Daniel A. Steffen" <daniel.stef...@gmail.com>
wrote:
Donal K. Fellows
> No, if you link with GPL software then the whole app becomes GPL. You
> can only execute a GPL program from a non GPL app...
Arguably, if a non-GPL program has a foreign function call interface
and is instructed by the user to load and invoke a function within a
GPL library, then there is no license problem as the non-GPL program
is entirely usable without any GPL component and hence cannot be a
derivative work. But a script to do the same thing (e.g. by invoking
the same Tcl commands) would itself (probably) be GPL-infected (only
an issue if the script is distributed though) as it is itself a
derivative work. But the real key is "at what point do you have a
derivative work" and that's a question that's quite hard (and would
need a court to determine if it came to it). That the FSF argues one
way does not mean that that is correct; I'm not aware of any
precedents in this area.
BTW, this sort of thing is probably the biggest single hole in the GPL
as it stands (there are ways to leverage the hole wider). I also
suspect that it is difficult to close without going against the spirit
of the GPL itself, as it depends on a key goal of the license: freedom
for users to use the code.
Donal (my code is BSD or Public Domain precisely because I don't want
to deal with this sort of stuff).
Daniel A. Steffen
> Is there any way to build ffidl as a universal binary on OS X? (10.4.8)
> I believe the binaries you built are PPC only? I've had various
> difficulties getting it to build at all--probably my own
> incompetence--but I also noted that it's based on TEA 3.2, and isn't TEA
> 3.5 better for fat binaries?
I have a mac-intel port of ffidl, some changes were necessary in ffidl
AFAIR as well as a later version of libffi than what is included in
the 0.6 ffidl tarball, I have also updated to latest TEA.
I have unfortunately not had the time to package this up yet, but it
is high up on the todo list...
It won't be possible to build a universal binary directly with this
however (universal is tricky in this case because the ffcall and
libffi configure scripts test various processor specifics that would
need to be overridden at compile time), but I plan to provide a
universal binary that is manually lipo'd from a binary built on ppc
and one built on i386.
Cheers,
Daniel
pal...@yahoo.com
> Donal (my code is BSD or Public Domain precisely because I don't want
> to deal with this sort of stuff).
My sentiments exactly.
/Ashok
Georgios Petasis
Actually, the only way to not be GPL infected, is everything to happen
at the user level. An application that can use a GPL package if found,
does not need to be GPL. As a result, you can distribute an app that
is under BSD, that uses a GPL package, but the distribution does not
include the GPL package. The GPL package can be a separate download.
Then the user must install both to make it work, and there are no
licensing issues, as long as the user does not redistribute
the combined thing.
George (which also writes BSD, except an LGPL app and tileqt, whose
binary is GPL due to Qt :-( - but the code is BSD!)
Donal K. Fellows
> Actually, the only way to not be GPL infected, is everything to happen
> at the user level.
Not quite. There are some dirty tricks you can play. The key is to be
able to demonstrate that the major non-GPL code is not a derivative
work of the GPL code. If you can show that, then you're home free.
It's quite a lot of work to do this with real code though; easier to
avoid GPL stuff like a bad dose of the plague...
Donal.
Andreas Leitgeb
>> can only execute a GPL program from a non GPL app...
Rather than using the term "contamination" I tend to prefer
the analogy of a burning candle giving light of freedom to
another candle...
PS: I know that with Tcl being BSD licensed, this is not
the most opportunate opinion for this group.
Gerald W. Lester
We could also use the analogy of a flesh eating bacterium invading a healthy
organism through a minor break in the skin.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
Donal K. Fellows
> We could also use the analogy of a flesh eating bacterium invading a healthy
> organism through a minor break in the skin.
As in <URL:http://en.wikipedia.org/wiki/Necrotizing_fasciitis>? Yuck.
Donal.
sleb...@gmail.com
wrote:
> Georgios Petasis wrote:
> > Actually, the only way to not be GPL infected, is everything to happen
> > at the user level.
>
> Not quite. There are some dirty tricks you can play.
Actually, the "trick" Georgios proposed is even dirtier and should be
a valid work-around : don't distribute the combined code!
Distribute your own code which uses GPL code but without linking or
even including the GPL code in your distribution. Ask the user to find
the GPL portion himself. And tell him how to combine the two.
Obviously this is extremely user-unfriendly.
This is interesting, I've never considered this angle before. The
standard rule of the thumb says that you can't develop a GPL plugin
code to a non-GPL program. It appears that it's not quite the case
since GPL makes no restriction whatsoever on the USE of the code. It
just defines restrictions on the DISTRIBUTION of the code. So you
can't distribute the GPL plugin together with the non-GPL program but
you certainly can distribute them separately as long as the user
doesn't redistribute them together ;-)
Uwe Klein
> We could also use the analogy of a flesh eating bacterium invading a
> healthy organism through a minor break in the skin.
Brhh,
But the lady _did_ tell you beforehand she was so cheap because
she had the clap!
>
uwe
Robert Hicks
wrote:
I thought she said "when we are done I will clap." : )
Uwe Klein
.. the night was dark the drink was deep!
uwe
Andreas Leitgeb
> Andreas Leitgeb wrote:
>> Rather than using the term "contamination" I tend to prefer
>> the analogy of a burning candle giving light of freedom to
>> another candle...
> We could also use the analogy of a flesh eating bacterium invading a healthy
> organism through a minor break in the skin.
I take it from your somewhat hostile wording that while you'd
fancy to play with the GPL-kids in their sandbox, playing
with their toys, you don't want to offer your own toys for
them to play with.
Either play GPL yourself, or ignore it altogether,
but don't whine.
Sorry, if I took your response more seriously than it was meant.
Donal K. Fellows
> I take it from your somewhat hostile wording that while you'd
> fancy to play with the GPL-kids in their sandbox, playing
> with their toys, you don't want to offer your own toys for
> them to play with.
The problem with the GPL-kids is that they say that if you want to
play with their toys, you've got to not let your toys be used by the
other kids over in the corner.
(Not a perfect analogy, but I'm tired.)
Donal.
Larry W. Virden
wrote:
> Andreas Leitgeb wrote:
> > I take it from your somewhat hostile wording that while you'd
> > fancy to play with the GPL-kids in their sandbox, playing
> > with their toys, you don't want to offer your own toys for
> > them to play with.
>
> The problem with the GPL-kids is that they say that if you want to
> other kids over in the corner.
And I think that, while analogies are not always safe, if we stick
with this specific analogy for a while, we get to at least one major
conflict.
>From one perspective, putting aside politics, etc., gpl basically says
"hey, if you want to freely make use of my toys (tools, etc.) whenever
you want, then in return you are going to legally be required to let
anyone else freely make use of the things you make/build that require
my things". It doesn't say anything about your toys/tools/etc. that
are have no "contaminating contact" with GPL licensed software. Just
that, if you make use of my work to get your job done, then in return,
you will be expected to make your work available in the same way.
If you don't want to make your work available in that way, don't use
my tools.
Certainly subsequent variations (LGPL, etc.) have tried to add degrees
of freedom to the fundamental view of equivalent exchange - to get
something, you should expect to have to give back something of equal
value.
I'm not saying that I prescribe to the viewpoint - just saying that I
can see, philosophically and politically, where those using the
license come from.
I myself prefer the BSD for tcl, etc.
However, I would hope that, rather than the hostility I often see
arise during these discussions, people might see the concept of
requiring someone to give back at least as much as they take.
Peter Dalgaard
Yes. It's more like you can't let the other kids play with the GPL
kids' toys unless the GPL kids get to play with the other kids' toys
as well as yours. Like letting others play with your basket and a GPL
ball while keeping the GPL kids out of the basketball game.
If "your toys" are truly yours, the GPL has nothing to say.
(This whole matter is not really suited to discussion by analogy. It's
probably more useful to point to the fact that things like the
ActiveState license is disallowed under GPL, but not BSD or Artistic
licenses, i.e. restrictions get added because the original license
does not disallow them from being added. Whether that is good or bad
is exactly the crux.)
--
O__ ---- Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~~~~~~~~~ - (p.dal...@biostat.ku.dk) FAX: (+45) 35327907
Kevin Walzer
I find the flame wars between the GPL and other open-source licenses to
be tiresome.
The GPL is an important, and useful, license. A huge amount of valuable
software has been created under the GPL. In the past I have made use of
GPL code in some of my own projects (and given back the code by
releasing these applications under the GPL, as per the license
requirements--see http://aquatkbibtex.sourceforge.net,
http://latex2applehelp.sourceforge.net, and
http://aquaethereal.sourceforge.net).
However, the GPL is not an appropriate license for every use. Despite
what its advocates say, I believe that building a viable business using
GPL'ed software--for instance, by offering support contracts--is more
difficult in many instances than by using other business models and
other licenses. In my case, I currently am a solo programmer developing
and marketing desktop utilities for end users on my chosen platform (Mac
OS X). My revenue from this model is derived by selling licenses to use
the programs. End users in my market niche are not interested in support
contracts. They are accustomed to paying a registration fee, then
receiving a license key to gain full use of my programs. The foundation
of this business model is a restrictive proprietary license for end
users. Without such restrictions, I would earn no money at all. (I once
experimented by trying to sell GPL-licensed programs, keeping the code
open but charging a fee for an easily-installed build: I earned very
little from this approach.)
Given my business model, I have chosen to incorporate code
libraries--whether open-source or not--that are compatible with a
proprietary license. In some instances I purchase proprietary
components, such as icons. In most cases it means I use BSD-licensed
code, which does not require me to open up my entire application to be
freely redistributable. And, in fact, whenever I make improvements to
BSD-licensed code, I do try to honor the spirit of reciprocity that the
GPL also encourages by submitting my changes back to the original
developer. In recent months I have submitted code to Mats Bengtsson, the
developer of MacCarbonPrint. I also maintain more than one open-source
Tcl package of my own creation--and maintain them even if I no longer
use the libraries in my own code. (See
http://tk-components.sourceforge.net.) I recognize that the efforts of
the open-source Tcl community has benefitted my own code greatly, and I
do want to give something back.
I am sure there are cases where it is possible to build a viable
business model on top of GPL'ed code, but my guess is this is easier for
large corporations like IBM or Sun who can earn their revenue from
sources other than the applications they develop and/or distribute. In
my case, experience has shown this model is not viable. So I'm glad that
there are other licenses and approaches available that make it possible
for me to earn revenue from software development.
Darren New
> I am sure there are cases where it is possible to build a viable
> business model on top of GPL'ed code,
Sure. Just don't sell it when you're done. The GPL can't keep you from
doing anything you want with the code as long as you don't redistribute
the results. With the rise of web services, this isn't that strange an idea.
--
Darren New / San Diego, CA, USA (PST)
"Let the wine breathe" does not mean to blow bubbles.
Trust me: your wine does not need CPR.