Licensing with Dead Man clause

[maik]

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

[Smivs]

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.

[Astrobe]

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.

[Smivs]

...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!

[cim]

...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)

[Astrobe]

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?

[cim]

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.

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.

[Smivs]

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.

[Commander Wilmot]

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?

[cim]

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]

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.

[Thargoid]

To take that particular case (as it's my license he used, as his work is based on mine) I would point out that there is actually nothing in there which would prevent someone taking over my (or any of my) OXPs in case of my untimely demise (and I ain't dead yet ).

The license used is basically CC BY-NC-SA 3.0, with the only modifications there specifically as in the past there have been examples of people copying some of the code incorrectly and producing an OXP which interfered with and broke my original (by re-using equipment identifiers and script names mostly). It was never a case where a quiet word didn't get it fixed, but the license point is there to ensure I have the right to insist just in case.

But as both sharing and adaption are allowed by my license, someone could take them over if required. In the worst case a completely new OXP/OXZ could be made in parallel with some minor adjustments to names etc to make a separate derived work which did exactly the same job as the original in the same way using the same code skeleton and add-on bits.

I have given this topic some thought, and my personal decision is that short of involuntary retirement from life I will always be contactable enough to make an announcement like Dr Nil did recently about his YAH work. And as the other case is somewhat more difficult to legislate for (aside from putting it in my will, or coming back to haunt you lot from beyond) then at that point the above comments can come into play anyway as a baseline.

[Norby]

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.

[Thargoid]

That would be an example of where strictly a "new derivation" (or adaption, to keep consistent wording) would strictly have been needed. There all conflicting unique items such as equipment and script names, shipdata.plist unique identifiers and such would need to be changed to make it a new OXP which didn't interact with the original.

To do so is some degree of work, but is reasonably easy to do (it's just copy-paste work). Essentially it becomes a new work based on the same concept and idea, and can legitimately re-use most of the same code etc as per the license. All that is prevented is that if the two OXPs happen to both be installed, that they don't over-write or override one another (although of course if both are performing the same function then they will tend to get in each others way anyway, but that's a slightly different case).

For your question - my license does not allow people other than the author to make updates etc, but what it does allow is for other people to "adopt" the OXP into their own distinct version, which they can then update and do whatever they want with. But that new version is then (by the act of changing all of the items noted above and in the license) their own work, and it equally then becomes their responsibility to further maintain, update, debug and generally support (as I have no desire to support other peoples modifications, nor be responsible for anything they may cause).

And that in effect is the "dead mans clause", as at that point it would cease to be my OXP in terms of support and ownership.

Hope that clears it up a little

[Norby]

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?