Member Discussions

Hello fellow Admins and Builders!

Did you used to run a mud and now you have zones just sitting around and not doing anything?

I run a mud, '5 Kingdoms of Mercator', telnet://mercator.mudhaven.com:2411.

We are expanding at an ever increasing rate and we are
interested in aquiring more zones for the game.

We are willing to pay $2 a zone, so if you have a lot of zones sitting around you could make some nice money!

Because muds develop in different ways the transition
of your zone to our mud will be aided by them being in a stock fomat, with no color code, strange tags or other un-stock like things. We do however support 10 directions (n, e, s, w, u, d, ne, se, sw, nw).

Email your zones to: jake.turner@ic.ac.uk

Zones will be accepted after assessing their potential and suitablility within Mercator. Any that are rejected are gauranteed not to be used.

Payments will be made promptly and directly through the PayPal interface.

I look forward to hearing from you.

Culhaven
telnet://mercator.mudhaven.com:2411
http://mercator.mudhaven.com

doesnt this somehow directly violate the license?

Thats a good point,

I would be interested in counter claims but as far as I can see it doesn't.

The license states you cant make money using the source code in any way. By selling zones, you are not making the money from the code, you are making money solely from your own work and creation, the zone.

The liscence cannot hold any duristiction over material created entirely seperately to itself.

Thoughts?

Culhaven

http://www.circlemud.org/license.html

As far as I see it, creating a zone that is compatible with the source code requires use of the source code.

Not strictly speaking.

It requires you know the format, but zones can easily be written in notepad or the like. Or even with other OLC's like the one I use on my mud which I wrote, JakeOLC :P

People arn't making money 'out of CircleMUD' they are making it by selling their personally authored matieral?

Culhaven

If the zones were built offline (i.e. not by some sort of OLC that depends on the Circle code), then you are in the clear. If they were built using an OLC system, however (which would count as part of the CircleMUD code), then it gets a little hazier.

As far as I see it, creating a zone that is compatible with the source code requires use of the source code.

You must be joking. Are you trying to tell me that all programs compiled under gcc/g++ are bound to the GPL?

No, but a zone made for Circlemud isn't going to be used on some custom codebase. It's the same thing as hiring coders for Circlemud. I don't think the makers of Circlemud, or Diku for that matter, intended for people to earn money off of their codebase at all.

To me, that includes making areas for the mud. Legally, I don't know how it would work, but it seems quite obvious that if the areas are being made to be compatible with Circlemud code and not any other codebase, then the intent is to make money off of Circlemud.

No, but a zone made for Circlemud isn't going to be used on some custom codebase.

That's irrelevant. An Excel spreadsheet isn't going to be used by another spreadsheet program (typically), but that doesn't meant Microsoft owns your work. Your soul, maybe; but, not your work.

It's the same thing as hiring coders for Circlemud.

"Hiring (for pay) coders" has nothing to do with this discussion. The license says that you cannot profit off of modifications to the distribution. A custom zone is not a part of the original distribution, so it does not fall under the license. Moreover, independent modules and libraries do not fall under the Circlemud license either. If I wanted a feature, I could hire a coder for a library and then plug it in myself. That is legal.

I don't think the makers of Circlemud, or Diku for that matter, intended for people to earn money off of their codebase at all.

Of course not. But you don't understand what the license is covering.

To me, that includes making areas for the mud. Legally, I don't know how it would work, but it seems quite obvious that if the areas are being made to be compatible with Circlemud code and not any other codebase, then the intent is to make money off of Circlemud.

Wrong again. A tool cannot hold rights over the end-product. A paintbrush does not entitle the manufacturer rights to the artist's work. OLC is nothing more than a tool that creates areas. Therefore, the Circlemud license does not cover original areas.

As long as the builder is not trying to pawn off the original zones in the Circlemud distribution (as the originals or modified versions), then it is completely legal for a builder to sell his or her areas.

What are you talking about? I'm not talking about who owns the rights to the zone. You're twisting my words into something ridiculously out-of-proportion with the matter at hand.

I never said that because someone creates a zone under Circlemud that the zone is now owned by Circlemud. That's retarded.
However, I think that if you make something intended to be used for Circlemud, or any Diku-derivative for that matter, you shouldn't be profiting off of it. I don't care how original your work is.

Under your bogus logic, it would be okay to open a mud that requires you to pay for special skills because the code to use those skills was put into the mud by an totally-original coder. Why not stop there? We have to pay to enter certain areas that were magically made compatible with Diku-code even without thinking about it at the time it was made. Yes. That makes sense.

(Comment added by nephos on Sun Mar 13 20:39:15 2005)

Excuse the a-an mistake of course.

What are you talking about? I'm not talking about who owns the rights to the zone. You're twisting my words into something ridiculously out-of-proportion with the matter at hand.

Do you not understand copyrights? The Circlemud license cannot be imposed on the area unless the Circlemud creators have ownership of the area (or if the creator put it under the license, which is another story). If you do not claim that Circlemud has rights to the area, then your whole argument is flawed.

I never said that because someone creates a zone under Circlemud that the zone is now owned by Circlemud. That's retarded.

Of course it is. But that is the problem with your position. For the Circlemud's license terms to apply, the area must be owned in some form by the Circlemud team.

However, I think that if you make something intended to be used for Circlemud, or any Diku-derivative for that matter, you shouldn't be profiting off of it. I don't care how original your work is.

And, of course, that is your opinion. However, the law does not agree with you.

Under your bogus logic, it would be okay to open a mud that requires you to pay for special skills because the code to use those skills was put into the mud by an totally-original coder. Why not stop there? We have to pay to enter certain areas that were magically made compatible with Diku-code even without thinking about it at the time it was made. Yes. That makes sense.

Ironicily, you call my logic bogus only to throw a slippery-slope fallacy at me...

However, your example doesn't apply. The items you listed are all in-game, which is all a part of the service, which is made from the codebase, which is bound by the Circlemud license. Independant areas and libraries (meaning that it does not contain any the of material that was a part of the Circlemud package) is not bound by the license, so you have no comparison between the two.

Well, should it be legal, I find it morally reprehensible.

Anyone who accepts payment for zones/areas compatible to a Diku-derivative is quite a douche. Good luck to the poster and any of the roaches that take his offer.

We are willing to pay $2 a zone, so if you have a lot of zones sitting around you could make some nice money!

$2 a zone? I could make better money with leasing the space occupied by such zones as web space. $2 is way under the work value.

(Comment added by Razzer_9 on Sun Mar 13 22:20:56 2005)

Of a good area, of course.

Of course it's perfectly legal, and neither is it immoral, unless you're a red commie rat fink. *smirk* After all a zone or area is your own damn creative work not Mr Jeremy Circle's, Mr. Hans Diku's or Uncle Joe Stalin's. If it's not your work then yeah that's not legal nor moral. And it doesn't even matter that you created with OLC, VIM or WORD. If you'd created it with Word it wouldn't belong to Billy Gates either (and that has precedent).

Of course selling it for a paltry $2 is pretty stupid as I think the market will bear more. Someone was offering around $30 or more a year ago.

> Are you trying to tell me that all programs compiled under
> gcc/g++ are bound to the GPL?

Actually the object files and the executables would be, yes. Equally, if you write a custom module of code and compile it into an executable with Diku code, the end result would fall under the Diku licence (as well as any licences on the compiler itself - so if you compile a Diku derivative with gcc, technically speaking you cannot legally distribute the object files or executable).

Of course, the source code for your mud would not be affected by the compilation - nor would the source code for your own custom modules (assuming they really were written completely from scratch). You could recompile your Diku derivative under a different compiler, or take your custom modules to a different mud, and the new executable would not be affected by any licensing conditions from the old (the old would have been deleted, after all). The same logic extends to areas.

If your area is based on a Diku-authored zone, then it'd be a Diku derivative and couldn't be sold. If it is based on a non-Diku-authored zone which came with the Diku bundle, then (unless you can track down the original author and get explicit permission to use the zone) you'd be relying on the Diku licence for permission to create your derivative, and therefore I'm pretty sure you wouldn't be able to sell it. If your areas are scratch-written, but based on an existing theme (Lord of the Rings, Star Wars, Harry Potter, etc) they'd likely be considered works of 'fan fiction', and trying to sell them might run you into problems with the author of the work your area was based upon.

However, as you point out, if your area is written from scratch, without being based on any other copyrighted works, then you can do what you wish with - as long as you do so outside of the DikuMUD (i.e., you can't sell people equipment in-game from your custom area, because when being used by a running mud it falls under the Diku licence - but as a separate file outside of the mud you are perfectly entitled to sell it).

> Are you trying to tell me that all programs compiled under
> gcc/g++ are bound to the GPL?

Actually the object files and the executables would be, yes.


No the output of the GCC/G++ compilers is NOT covered under the GPL. Only if the resulting executable is linked with a GPLed library might it be. Since most people use gcc with libc and libm and they are under LGPL then again no.

(Comment added by Tyche on Mon Mar 14 9:19:31 2005)

Equally, if you write a custom module of code and compile it into an executable with Diku code, the end result would fall under the Diku licence (as well as any licences on the compiler itself - so if you compile a Diku derivative with gcc, technically speaking you cannot legally distribute the object files or executable).

Yes and no. The resulting executable would fall under both licenses. Since gcc output is not GPLed then it's not relevant whether you used gcc or lcc or or VC++ or BorlandC as neither of those compilers have licensing restrictions on their output either (although they do with some libraries). If however you happened to incorporate use of the GPL'ed REGEX library with Diku for example, then you couldn't not distribute as binary only as the licenses conflict.

> No the output of the GCC/G++ compilers is NOT covered under
> the GPL. Only if the resulting executable is linked with a
> GPLed library might it be. Since most people use gcc with
> libc and libm and they are under LGPL then again no.

Well, then the executable would fall under the LGPL. The point I was trying to make was that the executable is a derivative work based upon both the source code and the compiler - because it is linked with the library. This is also how Borland is able to let people use their compiler, while restricting people from doing so for commercial purposes - the executable is a derivative of their work.

Also of interest:

http://www.fsf.org/licensing/licenses/gpl-faq.html#CanIUseGPLToolsForNF

"Can I use GPL-covered editors such as GNU Emacs to develop non-free programs? Can I use GPL-covered tools such as GCC to compile them?

Yes, because the copyright on the editors and tools does not cover the code you write. Using them does not place any restrictions, legally, on the license you use for your code.

Some programs copy parts of themselves into the output for technical reasons--for example, Bison copies a standard parser program into its output file. In such cases, the copied text in the output is covered by the same license that covers it in the source code. Meanwhile, the part of the output which is derived from the program's input inherits the copyright status of the input.

As it happens, Bison can also be used to develop non-free programs. This is because we decided to explicitly permit the use of the Bison standard parser program in Bison output files without restriction. We made the decision because there were other tools comparable to Bison which already permitted use for non-free programs."

> Yes and no. The resulting executable would fall under both
> licenses.

Isn't that exactly what I just said? *ponder*

Strictly speaking, no it dosen`t violate the license. The zones are technically the total property of the builder who made them. If the builder wishes to sell them, he/she has rights to. Due to the fact that zones are the creative and intellecutla property of the builder who made them, the creators of the codebase cannot in any way claim any ownership to them, and it`s not making money off the original codebase.

Were kind of loosing the point here people...
Anyone got any old zones they want to give me? :P

Culhaven

Well, then the executable would fall under the LGPL. The point I was trying to make was that the executable is a derivative work based upon both the source code and the compiler - because it is linked with the library.

No it's not derivative. Gcc's output is not LGPLed either, it couldn't be as Gcc is under GPL license. You own the full copyrights to compiled object code output from the gcc compiler, just like you own the full copyrights to your source code.

Now if you should mean the libc or libm parts of the execuatble that may or may not be linked, then distributing those parts with your program would be and that's assuming they are even linked at all, you are even using libc or libm. Some people use newlib or public domain libraries with gcc.

However that does not make the resulting executable a 'derivative' of libc or libc (nor gcc either) by any stretch of the imagination. The LGPL license specifically disclaims that (excepting certain conditions which you might recall were the subject of a nasty IMC2 flamewar). Anyway the typical usage of libc and libm don't fit those obviously.

...Can I use GPL-covered tools such as GCC to compile them?

Some programs copy parts of themselves into the output for technical reasons--for example, Bison...

Gcc does not copy part of itself into the output. They (FSF) don't use it as an example even after being asked that question directly because they do not claim the output of gcc is GPLed, and they have never claimed it.

(Comment added by Tyche on Mon Mar 14 13:46:36 2005)

IRT Borland, if you read the license carefully (v5.5) they do not assert any claims over the compiler's output either. They do however assert license restrictions over running their software, that is usage, and distribution restrictions on the libraries as well.

Were kind of loosing the point here people...
Anyone got any old zones they want to give me?

Not for $2 I don't. And besides I wouldn't send anyone a damn thing until I received the payment and it had cleared.

Ok, how about $3?
I'm cutting my own throat here.

- Culhaven the cut throat.

Why don't you spend less time begging and more time developing your own builders? Unique zones will be much more worth the effort, as it can be one of the things that will set your mud apart from the other 234984923 out there.

> > Well, then the executable would fall under the LGPL.
> > The point I was trying to make was that the executable
> > is a derivative work based upon both the source code
> > and the compiler - because it is linked with the
> > library.
>
> No it's not derivative.

http://www.gnu.org/copyleft/lgpl.html

"The reason we have a separate public license for some libraries is that they blur the distinction we usually make between modifying or adding to a program and simply using it. Linking a program with a library, without changing the library, is in some sense simply using the library, and is analogous to running a utility program or application program. However, in a textual and legal sense, the linked executable is a combined work, a derivative of the original library, and the ordinary General Public License treats it as such."

Actually the object files and the executables would be, yes.

Not for the reason that you are assuming.

Quote (http://www.gnu.org/licenses/gpl-faq.html#WhatCaseIsOutputGPL):
In what cases is the output of a GPL program covered by the GPL too?
Only when the program copies part of itself into the output.

I have never seen anything in gcc/g++ that copies part of itself into the executable. You could argue that because it writes the specific object/machine code that it does, but I doubt that would hold up very well.

The only reason why the executable would be bound to the GPL license (or any other license) would be because of the addition of the library into the end-product. An analogy would be if each of two authors had each of his or her work combined into one product. The the creator of the word processor that was used to merge the documents would not hold ownership over the product, only the two authors that combined their work.