This seems fair enough, and was more or less what I meant.
> > 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.
> > 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). After we transitioned to this we also started using
an is_active setting on each plugin rather than a_active_plugins.
> > Also some of the Beryl multihead
> > changes would likely be very nice.
>
> I don't know what this is.
>
> >
> > The biggest points we believe to be essential are the first one, and
> > the second point (or an even less stringent model).
>
> OK.
I will write again once I have a chance to talk to other members of
the community again.
Thanks,
Robert