Buggeration - just seen the change of title again.
OK, this is probably too late but can I ask the following questions/make the following suggestions...
Given Aegidian's clarification of the licensing, which, as Ahruman, points out, has actually been available and stickied for some time basically means that OXPs with no specific license included in the OXP or stated in its release conditions must be assumed to have very strict non-reuse licensing terms - this is sad - but is a fact and therefore we must live with it - it is easy for those who are still active on the board and oxping to rectify - simply state/re-release oxp with you intended licensing terms.
This will put some oxpers in a strange position but it must be done so we can all move on from this point that oxpers can't have it both ways - you can't say - "do with it what you will" AND "please don't put it in O(S)E" - unless you specifically state so in a license. Before O(S)E brought it to the fore - we have all been rather huggy and "nice" - although the Sung Texture issue should have been a portent of the potential of what was to come - but clearly we have moved on since then - oxps seem to be much bigger and more complicated than I remember being in the past and the potential for disaster and incompatibility is now legion without careful management - a potential reasoning for licensing if nothing else (allowing management/distribution of oxps at the author's intended rate and reasoning).
While it seems possible for current and active oxpers to license (openly or restrictively) their work - what do we do about orphaned oxps - legally, it would seem that you cannot simply say, we didn't hear from the original author for a bit so we have picked up their work and debugged and re-released, this would seem to fly in the face of what Aegidian claimed - which is without a license - the strictest terms must apply - so potentially - unless these orphaned oxps are redone from a conceptual point of view upwards they are actually effectively lost to us (from a future modification pov) unless I am misunderstanding the fall-out from non-licensing states of some older oxps.
OK, that's the waffle over - I think my idea overall is a relatively straightforward one, although, as a non-coder I can make such claims, because I may not understand the deeper, more complex issues, but let me say what I think and you can shoot me down afterwards.
My basic assumptions:
Some OXPs have a license that means they could be included in OE because they state so
Some OXPs have a license that means they could not be included in OE because the license is more restrictive (ND)
Some OXPs have no license and therefore should not be included (ever?) in OE (until some time in the future such a license is forthcoming)
OE did some stuff on its own that does not require other OXPs - such as the ship price calculator (controversial though this is/was), buying stations, Oobay Trading (and possibly much more that I am unaware of)
OXPs live in the AddOns directory, OXPs are loaded in alphabetical order with the last OXP loaded by this method overriding any content of other loaded OXPs where data uses the same "name".
If some/all/most of the above is true then does thiis/could this work:
A graphical front end for OE - it has included by default all of the core OE stuff that does not require other OXPs - (let's presume it's done by tick box selection) - if nothing else is ticked then this OE front-end moves the OE core pack into the AddOns dir and then runs Oolite.
The OE GUI front-end has access to another dir which contains all of the OXPs that L has permission to include in OE - when OE GUI is run the OE GUI visits this dir and populates a list - the user then ticks oxps they wish to include in their OE flavour Oolite. OE GUI then does the following:
Checks the Oolite AddOns dir to see if another variant of the ticked OXP exists, if it does, then OE GUI points this out (colour codes, textual display, etc) and where possible tries to check which is the newer version of the OXP (the one already in the AddOn dir or the one in the OE oxp dir) - and where it cannot be determined offers a "proceed at your own risk" statement.
In addition to this - OE GUI will, when some OXPs are ticked, others in the list will be highlighted as being incompatible and/or down-right-does-not-play-nicely-with the OXP of choice - so it is up to the user to decide which OXP they want - and OE GUI will also have to check the AddOns dir for the presence of any variant of the incompatible oxp(s) and flag this up too - this is where L could do some excellent value-added work.
Finally, ticking some OXPs will then automatically tick other oxps as mandated requirements for that OXP to work as intended.
Then - with the tick list done - OE GUI copies the required files to the AddOns dir and fires up Oolite.
Of course, you may wish to play the same game over and over again so there should be a quick launch option in the GUI which does nothing but fire Oolite with the AddOns dir contents as is.
OE could be updated several ways this way - change in GUI, change in core OE structure - addition/upgrading of OXPs in the OE_AddOns dir, making for smaller downloads once the main OE pack was downloaded.
Well, that's it - thoughts - have I just been a naive dumbass?
EDIT: It would seem in the time it's took me to write this over long message (I'm trying to look after a sickly 2yr old as well as get some marking done) - CA has made a similar suggestion...
EDIT2: or on re-reading possibly not...