02 Aug, 2010, Rojan QDel wrote in the 1st comment:
Votes: 0
I am currently the Head Admin/Coder for Legends of the Jedi, an SWR derivative (though heavily modified). We are considering releasing it through Github, Sourceforge, or Google Code so that others can adapt or contribute to the code. I wanted to ask for feedback on licensing the code, since it already has the SMAUG, SWR, Diku, etc. licenses attributed to it. Our hope was that it would be openly usable under the condition that any derivatives be released publicly as well. I am considering the GNU GPL v3 (http://www.opensource.org/licenses/gpl-3...) or By-NC-SA 3 (http://creativecommons.org/licenses/by-n...) - would anyone be able to help me determine if either one of these licenses accomplishes what I want and is still compatible with all of the licenses already governing the codebase? Thanks!
02 Aug, 2010, David Haley wrote in the 2nd comment:
Votes: 0
You cannot release it under the GPL (or other similar license) because it is already licensed under the SMAUG etc. licenses, which are incompatible with the GPL.
02 Aug, 2010, Deimos wrote in the 3rd comment:
Votes: 0
Not only that, but even if you weren't bound by SMAUG, etc., I'm not sure the GPL or similar licenses would do what you think it would. Someone could still legally take your source, modify it, and start running a game without ever having to disclose the derivative source to you or anyone else. Generally speaking, source disclosure only applies to redistribution:

Quote
One is allowed to make private modified versions, without any obligation to divulge the modifications as long as the modified software is not distributed to anyone else.
02 Aug, 2010, Rojan QDel wrote in the 4th comment:
Votes: 0
I see, hehe.. I'm not very competent in legalese, hence why I decided to ask here. Could someone point me in the direction of a license (perhaps MUD specific) or language that would make the source open and force all derivatives to be open as well (does the CC NC SA not do this?)
02 Aug, 2010, kiasyn wrote in the 5th comment:
Votes: 0
Heres the license I used for Sandbox ages ago:

http://www.mudbytes.net/index.php?a=topi...
03 Aug, 2010, David Haley wrote in the 6th comment:
Votes: 0
You still can't necessarily use that license… you have to make sure that provisions don't conflict. For example the GPL conflicts because it requires that people be able to do several things with the code, including commercial use, whereas Dikurivative licenses explicitly forbid that.
03 Aug, 2010, KaVir wrote in the 7th comment:
Votes: 0
I'm not sure how many people would be willing to use a licence that forced them to release their own changes - there are a lot of muds out there, and those of us who run them tend to go to great lengths to make our games stand out from the competition.

If you had an LPmud-style separation of driver and mudlib then applying the licence to the driver would be fairly reasonable IMO. But as you're running a Diku derivative, I presume that's not the case?
03 Aug, 2010, Rojan QDel wrote in the 8th comment:
Votes: 0
Nope, we don't have a separate driver and mudlib. I also understand that a share-alike license is unappealing for many coders, but it is the provision under which we want to license it… So keeping in mind that GPL wont work, could anyone recommend another license or would having our own license language be the best option?
03 Aug, 2010, David Haley wrote in the 9th comment:
Votes: 0
Since your situation is rather unusual, it might make sense to roll your own. It sounds like you only want to add forced redistribution of changes, which you can express in just a sentence or two added to the Diku etc. licenses.
03 Aug, 2010, Tyche wrote in the 10th comment:
Votes: 0
Rojan QDel said:
I also understand that a share-alike license is unappealing for many coders, but it is the provision under which we want to license it… So keeping in mind that GPL wont work, could anyone recommend another license or would having our own license language be the best option?


Well you'd simply add a new restriction to the license. Something like… in order to use FooMud you must follow the Diku, Merc, whatever licenses and in addition under the FooMud license all your changes must be publicly released back to me at FooMud. You simply aren't going to find a pre-written canned license compatible with the existing code.

Of course a secondary problem is that you won't be able to host it on Sourceforge, Freshmeat or Github unless you lie about the license and pick one of their canned licenses. Not that it's stopped anyone from hosting Diku derived servers on Sourceforge through plain ignorance of the compatibilty issue or knowing deception.

I'd consider self hosting it or asking someone here in the mud community who is willing to host repositories. (maybe whoever hosts RAM will?) That way you don't have to lie to get it hosted and incur any wrath from anyone in the DikuMud community. I mean they might not like your license restrictions and not use it, but at least everything would be legit.
03 Aug, 2010, KaVir wrote in the 11th comment:
Votes: 0
Rojan QDel said:
I also understand that a share-alike license is unappealing for many coders,

A ShareAlike licence doesn't force you to distribute your changes, it only states that if you choose to distribute them, you must do so under an identical licence.

I'm trying to think of any licences for comparison…even the GPLv3 only applies to copies you've "conveyed", and clarifys that "Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying". I guess that would work with room descriptions and such, but I don't see how it would force people to distribute their source code.

Or did I misunderstand what you're trying to do? If someone downloads your codebase and modifies it, are you saying that:

1) They must immediately distribute their changes, or:

2) If they later choose to distribute a copy of their mud to anyone else, they must release it to the entire public (not just a private release), and cannot impose any further licence restrictions (no additional credits or clauses).
03 Aug, 2010, Rojan QDel wrote in the 12th comment:
Votes: 0
Yeah, we could host it ourselves and that might be the best option despite the convenience of those other services.

What I'd ideally like to have happen is that anyone who decides to use our codebase as a base for modification, releases it as a branch on whatever service we are using to host/release our code. This way, anyone else using our code benefits from these modifications and we can choose to incorporate them into the trunk release as well.
03 Aug, 2010, quixadhal wrote in the 13th comment:
Votes: 0
Rojan QDel said:
What I'd ideally like to have happen is that anyone who decides to use our codebase as a base for modification, releases it as a branch on whatever service we are using to host/release our code. This way, anyone else using our code benefits from these modifications and we can choose to incorporate them into the trunk release as well.


That imposes an extra burden on your potential adopters, in that it requires them to also use whatever source control system you choose to use, even if they would prefer to use another. I would suggest that the vast majority of folks who download MUD server software, download it as a pre-packaged archive. Getting them to install svn/git/whatever and type in a single line to checkout a read-only copy is hard enough, but convincing them they have to set up their own branch and then make it accessible to the public is quite another.

Suppose I run a MUD on a hosted site that uses Windows as its OS. If you choose git, doing a checkout and making it a branch isn't too hard, but how the heck do I make that branch accessible to the rest of the world? Do I have to muck with IIS? Do I have to bug my provider to do it? How much of my bandwidth allotment is going to be consumed by people grabbing updates of my branched source, instead of people playing my MUD?

If you choose a centralized repository, such as subversion, are you going to give everyone write permission to your own repository so they can commit their branch changes to you? What if they screw up and overwrite someone else's branch? What if you screw up and give them write permission to the wrong branch?

I understand your goal, I think. You put time and effort into something that you'd like to give to the community, but in return you want to force others to act in kind. I may disagree with that, but I understand it. However, once you move from just saying that changes must be shared to specifying HOW they are to be shared, you've jumped into a nightmare of logistics that *I* wouldn't want to touch with a 50' light saber pole. :)

Good luck!
03 Aug, 2010, Rojan QDel wrote in the 14th comment:
Votes: 0
Thanks for that, its a great point. So I suppose we would just want derivations to be released publicly (or sent to us for release on our versioning system) and under the same license conditions, with no requirements on where/how they are released. I'm going to try to write some language, incorporating all of the parent licenses, and then post it here for feedback.
03 Aug, 2010, David Haley wrote in the 15th comment:
Votes: 0
Note that your license can simply refer to the other licenses; you don't need to craft the language yourself again.

Quote
ROJAN'S LICENSE

- Some stuff about releasing
- Some other stuff about where things are released
- All provisions in the Diku, Merc, SMAUG, SWR, etc., licenses apply
04 Aug, 2010, Kaz wrote in the 16th comment:
Votes: 0
Deimos said:
Not only that, but even if you weren't bound by SMAUG, etc., I'm not sure the GPL or similar licenses would do what you think it would. Someone could still legally take your source, modify it, and start running a game without ever having to disclose the derivative source to you or anyone else. Generally speaking, source disclosure only applies to redistribution:

Quote
One is allowed to make private modified versions, without any obligation to divulge the modifications as long as the modified software is not distributed to anyone else.


He said GPL v3, so that ain't necessarily so, as I pointed out in a post on TMC some six years ago, althought it's not entirely clear cut.
04 Aug, 2010, David Haley wrote in the 17th comment:
Votes: 0
The FAQ makes it pretty clear-cut, actually. Emphasis mine. Basically, if you distribute it publicly, you must distribute modifications as well, but just because you modify something, you don't have to distribute those modifications.

The GPL FAQ said:
Does the GPL require that source code of modified versions be posted to the public?

The GPL does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization.

But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL.

Thus, the GPL gives permission to release the modified program in certain ways, and not in other ways; but the decision of whether to release it is up to you.




EDIT: Well, the point is moot anyhow, because the GPL is incompatible with the Dikurivative licenses.
05 Aug, 2010, Kaz wrote in the 18th comment:
Votes: 0
Did you read the post I linked? I don't think so.
05 Aug, 2010, David Haley wrote in the 19th comment:
Votes: 0
Yes, as a matter of fact, I did, but the FAQ makes the point clear and your speculation irrelevant. Your post is based on a planned version of the license; please base speculation on the actual, effective current version, at least. Besides, if you go to the Wikipedia article you cited yourself, the bit about usage over networks is completely gone.

So, yeah. :rolleyes:
05 Aug, 2010, Kaz wrote in the 20th comment:
Votes: 0
Actually, the FAQ didn't answer that, because the contention was as to whether simply running the mud from a place accessible to anyone else was counted as distributing it (which the FAQ snippet you posted doesn't discount).

Good on them for removing that clause, though. That would have been a disaster.

I suppose in any case it shows the sort of clause one could introduce into a sub-licence in order to have that sort of effect (if the OP really wanted that sort of thing and hadn't been talked out of it by now for being a really, really bad idea).
0.0/21