Oolite Bulletins

Moderator: this is a response to this post.

Ahruman wrote:

A general clarification here: nobody in the comoonity is going to start waving lawyers about (you there! Put down Littlebear at once!). ...

... For instance, if you use a license that doesn’t permit derivative works, and someone tries to determine how far they can go while not quite being derivative, then it’s clear that person is acting in bad faith; whether they would “get away with it” in court is little more than a thought experiment. ...

... Using a plethora of different licenses also introduces a risk of conflicting licenses, where it would be possible to use aspects of OXP A or OXP B, but not both, because of some silly unintentional detail.

Which clearly illustrates the can of worms you do open not only for my "Oolite Extended" and any meta-oxp idea, but also for yourself and all oxp authors here if you - in the future - accept people issuing oxps not under the Creative Commons "copy-left" license, but other licenses that permit restrictions to share-alike as well.

The fact that restricting one's contributions to an open source hobbyist project completely dependent on copy-left agreements concerning the share-alike option won't stand a snowball's chance in hell in front of any court in the western world is not the relevant aspect here, quite correct.

The next step would - logically - be to enforce on the board and wiki that no one "acts in bad faith" (in regard to your definition of that above) and uses stuff from someone else who doesn't want that to happen. That will - coincidentally - in a nice and pseudo-legalese way sink my "aaall-of-it" project immediately.

But the pandora's box scenario you open up is this. In the future, if A doesn't like B, A will simply make their A.oxp license-restricted concerning the share-alike aspect so that B can't use stuff from the A.oxp in the B.oxp. Sure, B can ask A, but as A doesn't like B, A always says no.

But then there's C, and C and A are getting along well. So C does the C.oxp and with A's permission uses stuff from A.oxp in there. C does use the share-alike option, meaning that now some parts of the fictional C.oxp are sharealike and some not!

The end result will be this: Not only concerning oxps, with every shader, every texture, every AI someone wants to reuse in another oxp, be it on a big scale like in OE or on a smaller scale, the question has to be: Which license applies to that single shader here? In which oxps is it, and are they share-alike or not?

Already see where this is going? But it gets even better.

It was claimed above that the original oxp author can also change the license on a whim. Meaning, that even if the particular shader/texture/AI/whatever is free to share now, it might, as a result of a future quarrel between Z and Q, suddenly become "illegal" or at least "bad faith" that it is in B.oxp, C.oxp and Q.oxp as well.

And so on. This could de facto and quite probably unintentionally become the most elaborate scheme yet to remove future Oolite Extended from Oolite or at least the boards and wiki. Besides the human factor, I wouldn't go down that road. You are going to pay a very high price for not demanding the share-alike option licenses for all oxps. See above what will probably happen.

L

PS: I am going to duplicate this reply for the Oolite Extended thread. I ahve something additional to say there which doesn't fit and belong here.

Lestradae-
I had a much longer response typed just now, and have thought better of it. I have no desire to feed any fires, your's or other's.

I, however, would strongly suggest you take a good LONG read on exactly what the Creative Commons licenses are and what they allow and disallow. There are a variety of them, and they vary a great deal. Everthing from CC0 to CC BY-NC-ND 3.0 Unported.
http://creativecommons.org/about/licenses/

I mean no disrespect in posting this. I am merely trying to help you gain a better understanding of the tools you are debating about.

Lestradae wrote:

Which clearly illustrates the can of worms you do open not only for my "Oolite Extended" and any meta-oxp idea, but also for yourself and all oxp authors here if you - in the future - accept people issuing oxps not under the Creative Commons "copy-left" license, but other licenses that permit restrictions to share-alike as well.

As I have pointed out several times already, most OXPs do not currently fall under Oolite’s licenses, and I have no authority to dictate their license. For an original work, only the author can do that. If no specific terms are specified for an OXP, you cannot validly assume that they fall under any particular license.

I could dictate licensing terms if I managed a repository of OXPs, but I don’t, and I wouldn’t want to if I did.

Lestradae wrote:

The fact that restricting one's contributions to an open source hobbyist project completely dependent on copy-left agreements concerning the share-alike option won't stand a snowball's chance in hell in front of any court in the western world is not the relevant aspect here, quite correct.

I’m not sure what you’re saying here, but: OXPs are not contributions to Oolite, they are separate entities designed to be combined with Oolite.

Lestradae wrote:

The next step would - logically - be to enforce on the board and wiki that no one "acts in bad faith" (in regard to your definition of that above) and uses stuff from someone else who doesn't want that to happen. That will - coincidentally - in a nice and pseudo-legalese way sink my "aaall-of-it" project immediately.

There is very little enforcement of any kind on the board. People acting in bad faith tend to be censured by the community, though.

Specifying the terms of use of up front is not intended to “punish” or restrict anyone. Instead, it makes it easy to avoid acrimony and accusations of bad faith by making it clear whether something is permitted even before you do it. You are not automatically entitled to combine a bunch of people’s work into an omnibus edition against their will.

(In the interests of full disclosure, I should note for the record that I’m a copyright reform activist. There are more copyright reform proposals than you can shake a stick at, but without going into detail, I’d prefer a system where combining OXPs without permission, as a non-profit venture, would be legal to the mess we have now. That wouldn’t necessarily make it ethical, though, which is part of the reason I write things “statement of intent” and “entitled” rather than “binding agreement” and “permitted”. Acting in good faith is more important for the harmony of the community than having the legal upper hand.)

Lestradae wrote:

But the pandora's box scenario you open up is this. In the future, if A doesn't like B, A will simply make their A.oxp license-restricted concerning the share-alike aspect so that B can't use stuff from the A.oxp in the B.oxp. Sure, B can ask A, but as A doesn't like B, A always says no.

But then there's C, and C and A are getting along well. So C does the C.oxp and with A's permission uses stuff from A.oxp in there. C does use the share-alike option, meaning that now some parts of the fictional C.oxp are sharealike and some not!

Firstly, you’re confusing sharealike (derivative works must be under a similar license) with (the absence of) no-derivatives. The scenario you’re trying to describe would be one where A uses a no-derivatives license.

In any case, it doesn’t work like that. A and C would have to agree on a single license for all of C.oxp, even if specifying that parts can be distributed under other terms. (For instance, the overall license for Oolite is the GPL v2, but assets can also be distributed under CC-by-sa-nc 3.0).

The easiest approach in this scenario would be to use no-derivatives for C.oxp – that is, the most restrictive license wins. Otherwise, A would have to agree to release the parts of A.oxp that are used in C.oxp under a less restrictive license. (Note that A can relicense his work under as many different licenses as he wishes, as long as none of them is exclusive.)

This is not a new problem specific to Oolite. It’s a problem in all collaborative works, and especially in open source software with its plethora of licenses. The Creative Commons licenses are designed to minimize the problem by using a simple lexicon to create a flexible set of restrictions, but it can’t simply be magiced away. Again, no-one but the author has the right to stipulate licensing terms. Certainly not me.

Lestradae wrote:

The end result will be this: Not only concerning oxps, with every shader, every texture, every AI someone wants to reuse in another oxp, be it on a big scale like in OE or on a smaller scale, the question has to be: Which license applies to that single shader here? In which oxps is it, and are they share-alike or not?

This is already the case. The difference is merely that as it stands, you have to guess (and get it wrong). This is why I deliberately started a custom of writing copyright terms in the code of JS scripts.

Lestradae wrote:

It was claimed above that the original oxp author can also change the license on a whim. Meaning, that even if the particular shader/texture/AI/whatever is free to share now, it might, as a result of a future quarrel between Z and Q, suddenly become "illegal" or at least "bad faith" that it is in B.oxp, C.oxp and Q.oxp as well.

This is not the case. Most open source/open content licenses (including CC ones) specify that they’re “perpetual grants”, meaning that if B.oxp 1.0012 is released under, say, CC-by-sa it may be distributed under CC-by-sa forever. However, the author of B.oxp may release a new version under a different license, assuming he has the rights to relicense all the content.

Again, there is nothing I can do about this, except encourage people to make it explicit. I am not suddenly granting OXPers special rights, nor can I take said rights away.

Lestradae wrote:

And so on. This could de facto and quite probably unintentionally become the most elaborate scheme yet to remove future Oolite Extended from Oolite or at least the boards and wiki.

Yes, I’m sure that’s what Queen Anne was planning all along.

L, I personally see this thread as nothing more than a clarification of the situation as it is now. As Ahruman said, the only people who have got a say on a licence for any oxp, or indeed any published piece of software and / or creative work are the people who actually create the work.

Personally, any oxp I've made from scratch (3 of them, yay!) I've no intention of changing the licence for, mainly because I've always intended them, rightly or wrongly, as demos, for others to perhaps take inspiration from.

For the one oxp (Hotrods) that I've created using other people's work as well as my own contributions, the licencing terms were already CC Attribution Non-Commercial Share Alike, and I've got no legal or moral right to change those licencing terms.

However, I might well adopt an Attribution Non-Commercial No Derivatives for portions of it: a future, more complex TigerTurf.js and the yet-to be implemented HotrodTurf.js (wholly independently created scripts that allow for some interesting stuff to happen to the player).

What would that all mean in practice?

1) According to previous statements from you, you want to include unchanged oxps inside OE. Perfect. If the future TigerTurf.js is put unchanged inside OE you can do so without any problem whatsoever. Problem solved. Done.

2) If there are bugs, or incompabilities with another script included inside OE, do bugfix / modify the script, then send the modifications to me for approval & inclusion in a new version of TigerTurf.js / HotrodsTurf.js - Of course I, as the original author, might in turn modify the OE modifications in order to fit better with the rest of my OXP, or with planned future developments. The thing is, and I feel strongly enough about it to mention this, there is no obligation on my part to modify my oxp in order to fit better with OE.
This again follows nicely from a few posts of yours where you were talking about people bullying you. You rightly said that no-one had the right to tell you what to do inside your own oxp, and that you won't let yourself be bullied into making changes to your creation based on what someone else says. Very true. By the same token you don't have the right to automatically bully everyone else to make changes to their own work just to help OE along, regardless of what they want to do. However friendly dialogue, done in the spirit of cooperation & friendship should provide the necessary changes to the original OXP and better mutual understanding. (this is starting to sound like the old COMECON manifesto, but bear with me history buffs)
If the original author disagrees with your assessment, and isn't inclined to make the changes you request, please don't automatically assume there's personal animosity against you. The best thing to do in those cases is to try and see things from their point of view, and see if there's any way to reach a compromise that won't actually go against the original intents of the original OXP maker. Again this should dovetail nicely with the various posts you made about wanting to have more constructive dialogues with people.

3) If you agree to disagree with the original OXP maker, (i.e. me in this hypothetical case), I could grant you a waiver from the No Derivatives clause of the licence. To elaborate: let's say you want the tigers not to attack the player if something else inside OE is happening at a specific time. And let's say I find it unnecessary to do so for my own OXP, and I'm against adding what effectively would be dead code to cater for something else I've no control over. However, let's say that after looking at your changes, I've absolutely no problem with you using them inside OE. In that case I'll grant an explicit waiver for a specific version of OE (wip or not). When a newer version of OE - or of the original OXP - comes along, a new waiver can be issued, provided a new agreement between us can be achieved.
Again, not a problem, since this coincides nicely with what you said you were going to do in any case: notify the original author of any changes made, and wait for their input before going ahead. To clarify further: no real change in planned behaviour required here. The only difference is that the considerate actions you were already planning to do would be actual legal requirements for you to be able to include CC No Derivatives works in OE.

4) In case there's a total breakdown in communications, i.e. the original author feels that the OE modifications would inevitably mangle his/her vision, and you feel you cannot insert their OXP without modifying the No Derivative part of their work, then - and only then - the only thing to do is either remove that oxp from OSE, or come up with your own intellectual property that provides a reasonable facsimile of what you wanted to include in the first place. If there are previous, Share Alike versions of the OXP you want to include, you could modify those for OE purposes. One thing you won't be able to do is to use a waiver from a previous version of OE to make further changes to the included OXP.

Depending on how exactly the waiver was worded, you might still be able to include the last waived-&-modified OXP in newer versions of OE.

All this seems perfectly reasonabe to me, and since what you said is you are trying to create a collection of OXPs unchanged from the originals, it souldn't affect either you or OE in the slightest. However I understand that reality might be slightly different from your stated intentions.

The stuff above applies to released OE versions. What about unreleased svn versions of OE? Well, considering that anybody could access the svn repository, you'd have to ask each and every oxp author with a No Derivatives licence for a waiver before putting their work on svn. Again not a problem. IIRC, you were planning to also contact authors of Share Alike works at that stage anyway. As long as they say 'sure, you can use it on svn' you've got your waiver for svn usage. Before releasing OE, you will need to ask for a different waiver, this time to include that modified OXP inside the specific version of OE you plan to release. Of course, coordinating a release is going to take a relatively long time: all the No Derivatives work will need to be waived, and if any part of OE changes between the waive and release, the original author might feel the need to check if this could affect their modified oxp. The best way to handle it is to have a tagged release candidate, and make no changes whatsoever to the code until everybody gives the go ahead. This will involve a lot more collaboration between OE and the original author that is presently the case, and according to what you said before, it sounds like it's something you would welcome!

A final point, if I may. Extending stuff, by making various not-quite-the-same copies of the original, is a change, and it does seem to fly in the face of OE stated intentions, as stated by you. Of course, you might want to change OE's stated intentions at any point.
Legal stuff - and legalese in particular - while distasteful to most, has the advantage of helping to clarify things.
When using everyday language it's very easy to come up with stuff that can be interpreted one way or another. Legal language is meant to make implicit (aka common sense) agreements into explicit ones, and to remove any possible ambiguity from the aforementioned explicit agreements.
Much as I dislike the word 'aforementioned', I think we can all do with a dose or two of clarity here!

Ok, rant over! Wow, is that the time? I do get carried away sometimes.

PS: to the best of my understanding the above makes 100% sense if parts of an OXP are No Derivatives. If the whole of the OXP is No Derivatives, you'd need to get a waiver for point 1). I might still be wrong, and you might still need a waiver for point 1 in any case. Still, that shouldn't be a major problem either, just a matter of contacting the original authors & getting a waiver for each new release.

I think its worth remembering that most OXP authors probably feel quite open-sourcy or they wouldnt be working on oolite extensions, so it shouldnt be too difficult to get them to give retrospective licenses pretty leniently. I suspect most intended their work to be freely available (gpl or similar).

Kaks, I’m afraid you’re mistaken.

If one of your scripts is no-derivatives, it can’t be used in OE (without a waiver) because OE as a whole would be a derivative work of the script. In the same way, you can’t claim one script is ND while the OXP it’s in is SA, because you can’t release a modified version of the OXP without being derivative of that script (unless you remove it). Again, the most restrictive license wins: ND > SA > neither.

Ok, that's why I did write the PS to my post on the other page. I clearly needed to do some more thinking on the matter.

If I go for the ND option, I can always release the ND Hotrods.oxp with the scripts in and an SA HotrodsLite.oxp with no scripts in it. It's an approach that seems to work with a few projects already - I'm thinking of VirtualBox, but I seem to remember seeing similar arrangements for other software too.

Thanks Ahruman, Kaks & Cmdr James for your responses.

Especially the two long texts were quite informative (Ahruman) and also very much in agreement with my own thoughts (Kaks).

I do actually agree with everything you, Kaks, said. It might be a way forward if I continue the OE project, of which I am unsure atm for obvious reasons.

My problem was never communicating/cooperating with original oxp's authors. I would have liked to do that in much earlier stages. But we all know that continual, inacceptable and hostile behaviour of some towards me made such attempts impossible in the past. I won't repeat myself all the time saying this, but it has to be said. I did not just ride roughshod over everyone's wishes in bad intentions - with some, I simply never got any chance to cooperate! Had I not gone ahead and simply done things I would have been stopped at every junction of the way!

What is most irksome is to find out about licensing problems after investing two years of work into this!

If I continue the OE project, I will take care of this licenses issue. I would welcome a more cooperative, community approach to OE if it became possible via this debate. If something really changes after that.

I am quite afraid that people hostile to this project will now simply shoot it down with "no derivatives" licenses, and it would have been nice to find out about that possibility beforehand. I also would find it more constructive if open source would simply be open source.

Well. As Ahruman said, there's legal stuff about licenses that simply is the way it is. And everyone loves the big corporations for levering that, don't they?

I'll consider my options from here, thanks for spending some brainpower on this.

L

Thargoid wrote:

If the files etc are not altered but only how they are distributed (en-mass in this case), would a group packaging like OE actually class as a derivative work? It would be helpful to know at what point something becomes a derivative as opposed to a re-distribution.

I think the way OE is structured now would still class it as a derivative work.

To count as simple re-distribution would mean to keep the whole of the original OXP package intact.
In other words, at the end of the OE installation you'd have to get - say - 'Captured Thargons 1.00.oxp' inside the AddOns directory, with exactly the same files as you'd get by downloading & installing the captured Targons oxp by itself.

Kaks wrote:

Thargoid wrote:

If the files etc are not altered but only how they are distributed (en-mass in this case), would a group packaging like OE actually class as a derivative work? It would be helpful to know at what point something becomes a derivative as opposed to a re-distribution.

I think the way OE is structured now would still class it as a derivative work.

How so? If I leave everything exactly the same as in the original oxp, how would it be a derivative work to distribute it in a bundle?

That would mean that, say, publishing here my AddOns folder zipped would make the oxps in them derivative works, too.

Please keep in mind that I said that I wouldn't change anything in, i.e., mission oxps for so much as an apostrophe! So that criterium would be fulfilled, anyways.

Kaks wrote:

To count as simple re-distribution would mean to keep the whole of the original OXP package intact. ... In other words, at the end of the OE installation you'd have to get - say - 'Captured Thargons 1.00.oxp' inside the AddOns directory, with exactly the same files as you'd get by downloading & installing the captured Targons oxp by itself.

Let's take to an example here. Assume the targons.oxp and the behemoth.oxp, both consisting of say four folders and some plists in is distributed as non-derivative. Why should posting the two as they are but in a bundle with merged plists and folders count as a derivative work?

It would not be derivative. It's the same two oxps. Exactly the same. Please explain, to me this doesn't sound logical.

Something else obviously if something in the oxp gets changed. I don't need that one explained. Then it becomes derivative, I understand that one.

To resolve this question clearly once and for all is one of my decision points if I even consider to continue OE or not. And I don't want to find out an enormous amount of wasted time later that there is a fundamental problem with that - again.

L

Well, I am not a lawyer, so I'm more than happy if someone with more experience in these matters could confirm or correct what I'm going to say:

Lestradae wrote:

I wouldn't change anything in, i.e., mission oxps for so much as an apostrophe! So that criterium would be fulfilled, anyways.

<snip>

Assume the targons.oxp and the behemoth.oxp, both consisting of say four folders and some plists in is distributed as non-derivative. Why should posting the two as they are but in a bundle with merged plists and folders count as a derivative work?

It would not be derivative. It's the same two oxps. Exactly the same. Please explain, to me this doesn't sound logical.

<snip>

I do think the logical problem here is:

having 2 separate files is not exactly the same as having 1 file. You do need to make changes, however minimal - the apstrophe comment is very much appropriate here. I'll illustrate this with a very basic example. Let's assume there are two descriptions.plists that are going to be merged into one:

file 1:
file 2:
You'll get this combined file
Which is different from either file one or file two, hence a derivative work.

Even if you wanted to make an exact copy of those 2 files into 1 file, you'd have to have the exact contents of both files into one:
Which, apart from not actually working, is still different from either file 1 or file 2, hence a work derived from both of them!

This might sound quite disheartening, but do bear in mind that no-one has licenced their OXP as No Derivative yet, and - more importantly - nothing inside OE has got an ND licence, so you can continue developing all the stuff already inside OE .8 in complete freedom anyway.

As I already wrote in the OE thread, before thinking if I want to continue three issues have to be resolved first: The legal, practical, and human factor issues.

I will try to solve them in that sequence. So the legal issue is the first and most relevant, as anything else depends on that as a basis. I will first try to get the legal issues out of the way before taking care about the practical and human issues. (Which I will. Afterwards.)

I am no lawyer too, but have read through the Creative Commons Attribution-Noncommercial-Sharealike 3.0 Unported license which is Oolite's. If I understand correctly what it says there - and use common logic from there - I come to the conclusion that strictly legally it is not possible to restrict the use of oxps to non-derivative and non-bundle at all.

http://creativecommons.org/licenses/by-nc-sa/3.0/

It says there:

1) You are free to Share — to copy, distribute and transmit the work.

2) You are free to Remix — to adapt the work.

Note that point 2 exactly covers the topic of derivative works debated here.

It also says below (amongst other things):

"Share Alike — If you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one."

And there we have it. Build upon this work. This is exactly and logically undisputably what Oolite's oxps do. They build upon Oolite itself.

The reason? Oxps can't be seen as "independent" of Oolite in any way, or something that "runs alongside". Without Oolite itself, they are completely useless lines of code that do nothing in and of themselves. They can exclusively be used together with Oolite! Therefore, oxps most definitely are derivative works of Oolite that build upon it!

Which brings us to the last point, if we combine the above three statements into one statement using logic, it says:

"If you create an oxp for Oolite, you may distribute the resulting work only under the same or a similar license to Oolite's - which means, other people are free to Share, to copy, distribute and transmit, and to adapt your work (oxp)."

If someone can explain to me a sound reason why the above should not be the case without going to legal hair-splitting extremes, I take back what I say here - but I can't see how.

I rest my case, so to speak.

Btw, before anyone else panics now: I have no intention to damage the integrity of this community and game in any way. So after clearing the legal issues, I will in any case, whatever the legal "solution" to this actually turns out to be do my part to clear the practical and human factor issues that came up, too - I would find it a good thing if hatchets could be buried, a new chapter opened and a possible future OE be more of a community-including effort than it has been in the past.

But, what I am going to demand from my side is - after having to endure pointless hostilities for two years coming from attitudes that don't care at all if my work goes out the window however much I invested into it - no further artificial showstoppers via hairsplitting happen. So I won't stop doing something because someone else doesn't like it.

The legal issues are point one. Then I will take care about the arguments concerning the (im-)practicalities of something like OE (updating, bug-fixing, etc. that bundle). Last I will see to the human factor of all willing to bury hatchets.

I'll post this in the Oolite Extended thread and the OXP Licensing thread both, not ideal, but it affects both topics.

L

L-
Unfortunately, your conclusion is a flawed one. Derivative works means that you take an original piece of art (be it code, graphical, sound, or otherwise) and modify that piece into something new. Like taking a sample from a David Bowie song, adding one note to it to make a new rift. Your work is derived from that of the original author's work. It can stand on it's own, but is derived from it. In this incidence, it would mean taking the source code of Oolite (or one of it's plists, or some other part of it) and modifying it into something new.

Now, if I take a completely blank page in Notepad, and I write a script, or an AI, or a plist from complete scratch - That is NOT a derivative work. Whether it has meaning onto itself or not is immaterial. I used no part of the original to make mine. Therefore, whatever I license that work under is purely my choosing. Be it CC0, a GPL, Ms-PL, or a custom-written license that only lets it be distributed by hamsters wearing toupees.

What you are doing is not building upon the work of Oolite, but it building upon (in some cases), transforming (in a few more cases) the work of other OXP authors. Whether their code is useful outside of Oolite is immaterial. It can be fully argued that they are - I can load the models in Wings, Blender, or some other application. The textures can be opened in Photoshop, Paint, GIMP, or printed and displayed on a wall. Hell, I can use an image as a cryptographic key in a database. I could write a completely new program (well, *I* couldn't, but you get the idea) from scratch that implements a java script engine. Those scripts could be used in my theoretical program to do whatever.

Now, does this mean I'm trying to throw you another "roadblock". No. It means I'm trying to help you understand modern software development, and what copyright, licensing, open-source, and a host of other concepts really mean. Once you get a good fundamental understanding of these things, you'll have a better idea of if and how you can move forward.

Now, I'm sure I probably had more to say, and probably could have put a lot of this better... But it's nearly 1am here, and I'm brain-dead... So, don't take it harsh. Not trying to sink your ship here. Talk to you all tomorrow.