Re: [HC Evolution] Re: libole2 -> gnomevfs backend?

[Ettore Perazzoli <ettore helixcode com>]

    Dan> This seems rather GPL-centric. GPLed modules cause a problem,
    Dan> so we force _other_ modules to say whether or not the GPL has
    Dan> a problem with them.

  That's because we want to protect the GPL, as that's the most common
license.  Of course we can provide other enums for other license
types, such as the Mozilla one.

    Dan> At any rate, this doesn't seem like it should especially be
    Dan> gnome_vfs's problem. Anything that does dynamic loading might
    Dan> have to deal with it, right? So if you are going to code a
    Dan> "solution", it seems like it belongs in gmodule.

  The difference is that GNOME VFS hides modules completely.  The user
might not be aware of what module is loaded to do which operation,
that's why we need to protect the application's and the module's
licenses no matter what.

  Of course `g_module()' might want to deal with that as well, but (a)
glib has its own release schedule and (b) we need a license
declaration API in gnome-vfs anyway, so I'd definitely go ahead adding
it to gnome-vfs.

    Dan> Oh, and here's a gross hack idea: quarantine the GPLed
    Dan> libraries into a separate app and use CORBA to talk to
    Dan> them. Ha ha!

  At some point there should indeed be a CORBA (Bonobo?) hook to build
GNOME VFS modules.  Although I wouldn't personally encourage that as a
way to exploit GPL VFS modules into proprietary programs.

    Dan> (Personally, I think we should just encourage people to not
    Dan> GPL libraries.)

  It depends on the libraries.  But I don't want to go over this
discussion again...  It's rather off-topic here, too.  :-)

  Anyway, this GNOME VFS discussion is becoming rather off-topic too,
so I'd rather stop it or continue it on gnome-vfs helixcode com 

-- 
Ettore