Subject: Re: Re: proprietary plugins
From: Rui Miguel Seabra (rms@multicert.com)
Date: Tue Jan 08 2002 - 12:20:32 CST
> The plugin architecture should not trust any plugin.
I don't know how you can make a sandbox for binary code, specially
running in the same address space (correct me if I'm wrong here).
> Although it is not currently practicle (although not impossible) to
> write a proprietary plugin, it may eventually be possible and even
> desirable to have third party plugins, although preferably not closed
> source.
It's as possible to write a proprietary plugin as is a free plugin. Just
don't free the code. You can't work around that technically. That's what
GPL is there for, for instance.
It's desirable to have third party plugins, but not proprietary code.
> The trick or "problem" is identifying or figuring out if and when
> plugins are being used and this can only really be done by good
> quality bug reporting.
> It may be a difficult task and be hard to identify, but not our
> "problem". (i use the word problem very loosely, i hope you get my
> meaning).
Don't worry, it as loose as I used it.
What the linux kernel uses is a trick to identify proprietary code.
However, nothing prevents proprietary code to do that, but it would
filter out the sloppier ones.
It would also make bug reporting easier (think: <<... and there was a
message warning: AbiWord is Tainted!>>)
> its not that we dont allow proprietary plugins, its just wildly
> impractical to make them.
> You would have to do some grossly pointless reverse engineering just
> to allow you to make a plugin and comply with the GPL. Even so i dont
> think the GPL precludes closed source plugins within a company, its
> only when you want to distribute binaries publically that it becomes
> an issue (ill discuss this offlist if you like).
That's why we can't forbid the usage (hence the License declaration in
the plugin -- or module in the linux case). However, I was worried with
distributed binary plugins, not private ones.
> i think we all know you feel strongly about Software Freedom. Legal
> action should be a last resort, the first stage is always to explain
> carefully and ask politely that the code be released in compliance
> with the terms of the Gnu Public License.
Enter prosecute in www.dict.org and you'll see that only in the last of
three dictionaries (though the first two are arguably the same) is
prosecute first associated with Law :) I meant to go after the culprits
(first contact must be polite, of course).
> Tainted is a stong word to use.
But perfect. The free code is infected... corrupted... touched by
something corrupting ;)
That's why it was chosen on the linux kernel.
It's strong, but there is no other word that fits the job so fine.
It's not a showstopper in any form, but I think that it would help
debugging someone's problem. It's a care we should take because of using
plugins.
Hugs, rms
-- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Ghandi + So let's do it...?
This archive was generated by hypermail 2b25 : Tue Jan 08 2002 - 07:19:47 CST