Oolite Bulletins

Guys, I was taken a bit by surprise seeing the OXP List page changed in a way that one or two people here thought would be necessary.

As spara mentions, and as has been discussed at length when the page was created, the page is for players, not for authors. As such, the Licensing Problems sections has no place there. Also, the OXPs listed there have been taken out from the main list, so from a player's perspective, there are now two lists with functioning OXPs. Not a good idea in my opinion. A better idea is to either indicate on the respective OXP's page that there are licensing problems. If it doesn't exist yet it is a good reason to create it.

While the OXP difficulty section is player centric and as such not a bad idea, it is similar to the OXP difficulties section on the [wiki]OXP[/wiki] page and therefore can be removed here as well. The link to the new page (which is incomplete and manually maintained and therefore will, if ever completed, soon be outdated because I don't see authors updating more than one list voluntarily, see earlier discussions about lists on the wiki) can go there, too.

I propose these changes be reversed.

Edited to finish a sentence

Seconded. While some of these changes may in time be adapted for use in the table the current arrangement is messy and confusing. I agree we should revert to the 'tried and trusted' format for now while discussions continue.
On a related note, many of the entries now seem to be overlength and are consequently taking two lines which again is making the layout look untidy. This is another aspect of the table that took a great deal of time and effort to get right when the table was being developed, and so I think a bit of judicious editing is needed here as well.

I think that if an author didn't include a licence in the package, one can assume he doesn't bother about modifications/improvements, provided they are made in a new OXP, that he is given credit and that it is provided for free. In other words, public domain should be assumed.

On the dead man/MIA clause one could make a rule that an OXP that isn't updated for some period of time (maybe relative to the latest release of Oolite) could automatically be "liberated".

For having seen similar issues in other mod communities (including even the inclusion of free mods in commercial packages without the permission of their authors), licences in FOSS are mostly "wish lists" and "gentlemen agreements" if you don't have the resources to defend them on a legal ground. Sad, but true.

Astrobe wrote:

...if an author didn't include a licence in the package...public domain should be assumed.

Not so, I'm afraid. The legal situation is quite clear as has been discussed at length elsewhere. No licence means the strictest of restrictions - you can't do anything at all with it, and even possession is a bit of a grey area!

Smivs wrote:

Astrobe wrote:

...if an author didn't include a licence in the package...public domain should be assumed.

Not so, I'm afraid. The legal situation is quite clear as has been discussed at length elsewhere. No licence means the strictest of restrictions - you can't do anything at all with it, and even possession is a bit of a grey area!

Indeed - though a license to possess it for personal use is generally granted by the author when they post here and say "hey, I made this OXP - download it here and try it out!" or words to that effect.

I would personally say:
- not having a license which allows modification, reuse and/or redistribution is not a bug at all [1]. Yes, it's inconvenient for reuse, but we're hardly short on OXP code which can be reused and the majority of old OXPs are not great examples of modern coding practices anyway. If this ends up affecting an OXP which the community really likes but which doesn't work properly in current Oolite, remember that the implementation is copyrighted but the concept is not: you can always make "FreeOldOXP" as an independent reinterpretation of the concept.
- if the license statement in the package is absent or doesn't match licensing statements elsewhere this is a minor packaging bug (but I would consider it less serious than "doesn't prefix package contents properly" and no-one's suggesting a separate list for OXPs which do that)

[1] The obvious exception being when the OXP includes or modifies non-trivial amounts of stuff from the Oolite Resources folder, and so has to be released under the same license as Oolite (choice of two, for most of that folder)

Out of curiosity, do you know what is the "legal" status of patches? What about publishing files that modify an OXP?

Also, could it be possible that, because OXPs are modifications of Oolite (or for you with Oolite only), Oolite authors could "enforce" a licensing policy? For instance could they include a statement in their license saying that their license also apply to OXPs?

Astrobe wrote:

Out of curiosity, do you know what is the "legal" status of patches? What about publishing files that modify an OXP?

The difficulty with publishing files which modify an OXP is:
- assuming the OXP's license doesn't allow derivative works, you can't base the files, at all, on the OXP being modified. It has to be a clean reimplementation+modification. For some file types that's entirely practical; for others it's very difficult.
- Oolite doesn't guarantee any loading order for OXPs, so overriding individual files only has a 50/50 chance of working. JS files you can be a bit cleverer with but that's obviously limited. Similarly shipdata-overrides in very limited circumstances can be used.

Astrobe wrote:

Also, could it be possible that, because OXPs are modifications of Oolite (or for you with Oolite only), Oolite authors could "enforce" a licensing policy? For instance could they include a statement in their license saying that their license also apply to OXPs?

OXPs are more like applications which Oolite runs [1]. If we could do that, then your OS manufacturer could say that its license applied to any application written for that OS. Unless you actually use bits of Oolite's code in your OXP, you can use whatever license you like for them.

[1] And while it would be an implausible amount of effort for anyone to go to at this time, it would be entirely possible for a different group of people to write an entirely independent space game - possibly not even in an Elite-like setting - under a different license, which also ran OXPs. Clearly that wouldn't retrospectively dual-license every OXP ever written to the license of that other game.


EDIT: I should add that, legalities aside, I think an author is well within their rights to say that they would rather their OXP potentially became unusable due to feature drift in their absence, than it was modified by someone else in a way that they potentially didn't approve of, and it would be polite to respect that. While the community as a whole obviously benefits from OXPs being released under open licenses, that shouldn't place pressure on authors to do so if they don't want to.

This is why licensing is so important - it determines what can and can't be done with an OXP.
The most commonly used Creative Commons license allows others to use/patch/modify the OXP in whole or in part. However the original author must be credited for their work, it can not be used in any commercial way and the 'product' must have the same license as the original.

Could there be different levels of such a clause? If someone wants to put a mia clause in their oxp, but doesn't want someone to take the oxp in directions they don't want; could they put a license that would only allow modification for compatibility with the latest version of Oolite? In other words, if I wanted to update the code and formating, fine. But if I wanted to change the end of mission oxp or something, then there would be problems. Is there any license that could do that, that is legally binding?

There aren't any existing licenses that would do that, to my knowledge. You could probably modify a CC "no derivs" license by adding a clause to say that it was allowed to distribute modified versions if the modifications were solely to maintain compatibility with changes in Oolite ... the problem then comes if you want to actually define what "maintain compatibility" means - take the changes to the NPC lasers and AI between 1.76 and 1.77: they change the balance of some OXP-generated fights, often quite substantially. Is it a "compatibility" change to switch some of them from military to beam lasers (adjusting for a core change), or a more substantial one (the core change does not prevent the OXP working and you really wanted military lasers there)?

Writing the additional clause so that it was clear and unambiguous to someone in your extended absence what changes you were happy with and what core changes short of completely breaking the OXP were acceptable to respond to would be quite difficult, I think.

Norby wrote:

new OXPers tends to copy licenses from famous authors and the problem will spread.

And occurred: the new Fuel Regen OXP copied a license with this problem.
Sorry for the constant mentioning but I am really afraid that we will not be able to fix nor update many OXPs after a few years when we cannot reach the authors.

Thank you for the answer. I hope you and others will be here for a long time but I am afraid about new OXPers who has higher odds to disappear.

Please help me to resolve some inconsistency what I think between your words ("adaption are allowed") and this post, when my try to fix an OXP with the same license was rejected by a consensus which said that I can not update it without extra permission.

Which is true regarding your restricted licence (I really can not decide):
- is allow fixes what I can not read between the lines (sorry, I am not a lawyer),
- is not contain permission for updates but you allow it from now (for your OXPs only),
- is not allow any fixes, only a takeover is possible which need extra modifications.

Thank you, the current situation is pretty clear now.

I think we can find out a better solution of your original interference problem.
How about if the license deny the reuse of the mentioned identifiers but allow two cases:
1. (as now) if all ids are changed to make an independent derivation,
2. (newly) allow fixes if all ids remain unchanged, so the result is surely a new version of the original OXP?