"Chris B" <nom### [at] nomailcom> wrote:
> The aggressiveness of those advocating GPL is to try and protect you. Not to
> try and swindle you out of your own code (that role was already taken).
> Remember, you are not bound by the terms of use in the license that you
> issue. You have obligations as the license issuer, not as the recipient of
> the license.

Whe I develop software that makes use of other software, I *am* also the
recipient of a license.

Maybe I'd be much more benevolent towards the GPL if it wasn't for the ghastly
aggressive undertone of the FSF, and that they don't seem to put much effort
into showing how to circumvent certain "collateral damage" the paragraphs of
the GPL do.

As for example how to use a GPL'ed library in a basically commercial software
project.

It dawns to me now that it can be done by writing a GPL'ed wrapper around the
library that provides some socket- or pipe-based access to the library,
distributing it as a project of its own, and writing that commercial piece of
software, which will require the user to install that wrapped library - which
I'd provide a link to - and drive it via that socket or pipe (or
what-have-you).

I can't see, however, what the legal advantage for the author of the library,
the free software community as a whole or even the FSF would be to allow such a
thing, but disallow straightforward dynamic linkage of a separately available
library.

With the described concept, could I not actually even write a wrapper for the
socket interface, to give me again an interface much alike the original
libray's?

All it does, as it seems to me, is unnecessarily consume computing power and
development time.

> Imagine you spend years on an ingenious open source project that develops
> some clever and complex algorithms and you don't give it the protection that
> the GPL affords. You're about to add a cool front-end when someone else
> embeds your code, adds their own commercial front-end and patents the notion
> of using your code through a GUI front-end. Your years of altruistic
> development have now been effectively blocked by someone who knocked up a
> quick and dirty 'wrapper' to your code and you can't even develop your own
> front-end without paying them royalties for their genious idea of using your
> software through a front-end. Their patent lasts for the rest of your life.

What prevents someone to do the same with the described socket- or pipe-based
wrapper interface?

They might not be able to patent this particular way of using exactly your code,
but with a somewhat more general patent claim it would do the same harm.

The real fight in this scenario is against software patents, which has not much
to do with the GPL as it seems to me.


> Imagine you write an application to manipulate a mesh that you found with an
> open license which is not GPL or some other comparable license that has some
> tested legal foundation. You sell it at $5 a shot for a couple of years
> before a lawyer buys the company that released the mesh. He challenges and
> overturns the license and then sues you for loss of earnings claiming the
> mesh alone to be worth $500 a copy. You now have the choice of  A)
> negotiating to see if he'd be kind enough to take the $20K you'd earned and
> the rights to the software you wrote to get off your back or  B) hoping that
> someone who likes you dies leaving you $2M plus legal expenses in the next
> few days.

You mean a non-GPL license covering the mesh? Or my application? (I don't
release that, do I?)

Here, we're not talking about a benefit of the GPL as such, but of proven,
tested licenses. They do not need to be as virulent as the GPL to be as
effective, I guess.


> > Or, alternatively, it should suffice
> > to disallow distribution of the library along with the product - but even
> > dynamic linkage with a library that needs to be obtained separately is an
> > option ruled out by the GPL.
>
> I've watched the different clauses in the GPL build up over the years and
> the FSF has been careful to explain why each clause has had to be introduced
> to counter a new attack. I believe the clause you refer to was in response
> to organisations that burned two CD's and said that the library and code
> were therefore distributed 'separately', but you'd have to check back on the
> FSF site to be sure.

See my elaboration above: The problems you describe here do not only apply to
dynamically linked libraries, but also to socket- or otherwise-based "plug-ins"
or however you'd call them. So the scenario you describe needs to be tackled in
a different manner than by forbidding dynamic linkage while still allowing
socket-/pipe-based dynamic "quasi-linkage".


> I suspect it's also
> true that the less obsessive personalities on both sides of the argument
> tend to drop out as the bitterness deepens.

Which makes my point, that the FSF is (maybe has become) too radical.

> I don't believe that the FSF is just another evil empire waiting in the
> wings.

I don't believe in evil empires anyway. But I believe in the potential in man to
overdo things because they think the direction to go that was right in the past
will always be the right direction to go.

If you are in the wild woods west of the path you should be on, go east - but
only until you're back on the path. Then check your position again and decide
whether you need to follow the path north or south.

Post a reply to this message