Good.
>
> > > License, MIT might be ok, but would have to be discussed more.
> > > LGPL was brought up, this would still allow linking to by non GPL
> > > compatible plugins but be less liberal in it's terms than MIT.
> >
> > I'm interested in reasons people have to why MIT shouldn't be used that
> > are so important that the reasons for using MIT that I've pointed out
> > would have to be sacrificed.
> >
>
> Again, I'm not really concerned about MIT so I can't argue this point
> for other people, I will try and get some more specific information
> though. After taking to people though there seems to be very little
> resistance.
Good.
>
> > > Core of the new project would have to have settings all in core
> > > (no settings plugin like Compiz has...), something like
> > > libberylsettings would be preferred, though this is definitely
> > > something that can be discussed.
> >
> > I'm very skeptical to this. I'd need a very good motivation for why we
> > would want to have a specific configuration backend part of the core.
> >
>
> I think we could probably work something out here, will have to talk
> to others about this though. One thing that I think does make a lot of
> sense is the settings plugin being in core (individual backends can
> still be plugins).
What is the settings plugin? Is it not that you just want to share some
code between different configuration backends? That's a different thing
and it could be OK to include such code in the core or if it's likely
that some want compiz running without plugins that use that
functionality loaded it might make more sense to keep it in a library
instead.
> After we transitioned to this we also started using
> an is_active setting on each plugin rather than a_active_plugins.
hm, is your settings plugin extending the current options with more
information?