08 Jun, 2011, KaVir wrote in the 41st comment:
Votes: 0
The patch wouldn't just contain your own work though, it would include modifications and deletions as well as additions. Unless all you ever did was add new code, the diff would include bits of Diku.
08 Jun, 2011, Runter wrote in the 42nd comment:
Votes: 0
KaVir said:
The patch wouldn't just contain your own work though, it would include modifications and deletions as well as additions. Unless all you ever did was add new code, the diff would include bits of Diku.


Do you think it including the diku code is the only problem? What if it only included a description of where the code should be put? Or a line number based on the unmodified diku codebase? Is it legit to write code to modify the codebase itself and operate under a different license just because it's got an intermediate step?
08 Jun, 2011, KaVir wrote in the 43rd comment:
Votes: 0
Well there are the nonliteral elements as well, particularly for features that are heavily reliant on the Diku architecture (such as OLC). But the situation obviously isn't black and white, just different shades of grey.

If the codebase contains independent/standalone custom modules, perhaps the easiest option would be to sell those. Then you could offer the rest of the codebase (or just a patch if you prefer) for free, so that anyone can download it - but without your custom modules.

It probably wouldn't be long before someone leaked your modules, but if you were only planning to sell to one person anyway then it's no big deal.
08 Jun, 2011, plamzi wrote in the 44th comment:
Votes: 0
Runter said:
KaVir said:
The patch wouldn't just contain your own work though, it would include modifications and deletions as well as additions. Unless all you ever did was add new code, the diff would include bits of Diku.


Do you think it including the diku code is the only problem? What if it only included a description of where the code should be put? Or a line number based on the unmodified diku codebase? Is it legit to write code to modify the codebase itself and operate under a different license just because it's got an intermediate step?


I believe there are numerous precedents for selling patches to a free codebase. One that comes to mind: the Joomla CMS is free but there are literally thousands of commercial plugins for it: http://extensions.joomla.org/.

As long as you're not re-selling the literal code (in a functional state), I think it's fine to sell a patch that says "insert this line of mine after this original line." In that scenario, you are NOT making money from the codebase itself – you're providing implementation instructions, having made clear to the user that your product is meant to enhance an existing product and will not work without it.

So, for instance, assuming that KaVir wrote that GUI snippet from scratch, he would have been fine selling it to developers instead of giving it away, despite the fact that it's meant to plug into a number of free databases.

Anyone have a counter-argument?
08 Jun, 2011, KaVir wrote in the 45th comment:
Votes: 0
plamzi said:
I believe there are numerous precedents for selling patches to a free codebase. One that comes to mind: the Joomla CMS is free but there are literally thousands of commercial plugins for it: http://extensions.joomla.org/.

Joomla is open source and released under the GPL, so there's nothing in the licence preventing commercialisation.

A more relevant question would be whether the Joomla plugins automatically fall under the GPL as well. But even then I'm not sure how comparable that would be with direct modifications to the Diku source code.

plamzi said:
As long as you're not re-selling the literal code (in a functional state), I think it's fine to sell a patch that says "insert this line of mine after this original line." In that scenario, you are NOT making money from the codebase itself – you're providing implementation instructions, having made clear to the user that your product is meant to enhance an existing product and will not work without it.

I don't think any of this has a clear-cut answer, but I would point out that a large amount of the changes in most Diku derivatives cannot be realistically broken down to a set of hand-written instructions - it would be a massive undertaking to create such instructions, and an equally painful experience for someone to try and use them.

plamzi said:
So, for instance, assuming that KaVir wrote that GUI snippet from scratch, he would have been fine selling it to developers instead of giving it away, despite the fact that it's meant to plug into a number of free databases.

The GUI snippet was originally based on my GW2 implementation, which I wrote from scratch, and would be a good example of what I meant earlier about independent/standalone custom modules.

One could perhaps argue that the installation instructions are Diku/Merc/SMAUG/TBA/etc derivatives, as they include lines from those codebases. But it would have been easy enough for me to publically post the installation instructions on my website for everyone to read, and then just sell the snippet itself.
08 Jun, 2011, Tyche wrote in the 46th comment:
Votes: 0
plamzi said:
Anyone have a counter-argument?


DikuMud isn't open source. Joomla is open source without commercial restrictions. I could sell you a copy of Joomla itself, so that's not really a good comparison.

I'd suggest a good guide as to whether one's code is indeed standalone and not derivative of DikuMud, is if I could also plug it into my Mush, LPMud or MOO.
08 Jun, 2011, plamzi wrote in the 47th comment:
Votes: 0
Tyche said:
plamzi said:
Anyone have a counter-argument?


DikuMud isn't open source. Joomla is open source without commercial restrictions. I could sell you a copy of Joomla itself, so that's not really a good comparison.

I'd suggest a good guide as to whether one's code is indeed standalone and not derivative of DikuMud, is if I could also plug it into my Mush, LPMud or MOO.


Good point. I read the license section @ http://en.wikipedia.org/wiki/DikuMUD , which confirms that DikuMUD is not open source regardless of the fact that the code itself is freely distributed and modifiable.

But so then, KaVir's example of selling a snippet and posting DikuMUD implementation on a site would seem to satisfy the terms of the license even if that snippet's sole purpose is to plug into DikuMUD, right?

Here's a more hypothetical example: Party A is giving away vacuum cleaners under the condition that no part of them can be re-sold and that they can't be used in a commercial setting. Party B is selling an extension for Party B's vacuum cleaner, which enables users to clean corners better. Can terms of use set by the manufacturer carry over to that extension just because the extension is built exclusively to be used with that particular product? I would think not, but I'm no expert.
08 Jun, 2011, duwnel wrote in the 48th comment:
Votes: 0
plamzi said:
Here's a more hypothetical example: Party A is giving away vacuum cleaners under the condition that no part of them can be re-sold and that they can't be used in a commercial setting. Party B is selling an extension for Party B's vacuum cleaner, which enables users to clean corners better. Can terms of use set by the manufacturer carry over to that extension just because the extension is built exclusively to be used with that particular product? I would think not, but I'm no expert.


Consider the more relevant iPod debacle Numerous components are sold after-market to work with the iPod, only very few of which are officially "licensed" (Consider akin to the modifications made to the DikuMUD base). Even though to be properly licensed by Apple, one needs to submit a proposal and pay a hefty fee, very few producers do. Now, these items are specifically intended for use solely with Apple iPod/iPhone/iPad products… This does not, however, prevent them from being sold as derivative works (their existence impossible if not for the existence of the product from which they are derived).

The OP could, in fact, give money to his friend. Afterward, his friend could give him a copy of his code base. Assuming in the US alone, a citizen may gift any other citizen some US$22,000.00 without taxation. The amounts beyond this become taxable. Anyone alleging that this was a sale would have to prove it speculation does not equal fact. I could propose that KaVir's GW2 is in fact built by unpaid Chinese labor, or that Scandum's MUD is built in violation of Microsoft copyrights. It's not true, and if it were both could be conceivably detrimental, but they are, in fact, simple speculation, and these two transactions need not be considered relevant.

For instance, my friend has bought a DVD that I covet. Technically, the licensing restrictions prevent even transfer of ownership of DVD media. If I gave him a gift on his birthday of a check for US$30.00, and he, for my birthday some 5 days later gives me the DVD, is there necessarily a parallel?

The law is not about the truth, no matter what your law professors may tell you. It's about what can be proven in court.
08 Jun, 2011, Runter wrote in the 49th comment:
Votes: 0
Quote
Anyone alleging that this was a sale would have to prove it speculation does not equal fact.

That doesn't change the fact that he's already admitted it would be sold, not gifted. Your argument kinda is bad since it's basically like saying as long as they can't prove it, it's legal. But that's not really true. As long as they can't prove it, you can't be held responsible in court, perhaps. Legality of actions isn't really determined by how well you cover the tracks of your crimes. In fact, many criminals end up in prison assuming that their crime couldn't be proven and turns out that it could. Or the dots were connected easily enough.
08 Jun, 2011, Tyche wrote in the 50th comment:
Votes: 0
plamzi said:
But so then, KaVir's example of selling a snippet and posting DikuMUD implementation on a site would seem to satisfy the terms of the license even if that snippet's sole purpose is to plug into DikuMUD, right?


I haven't seen the example, but if I couldn't plug it into LPMud, AberMud, Mush, or something not a DikuMud, then I would presume the example is a modification to DikuMud and is a derivative work.

plamzi said:
Here's a more hypothetical example: Party A is giving away vacuum cleaners under the condition that no part of them can be re-sold and that they can't be used in a commercial setting. Party B is selling an extension for Party B's vacuum cleaner, which enables users to clean corners better. Can terms of use set by the manufacturer carry over to that extension just because the extension is built exclusively to be used with that particular product? I would think not, but I'm no expert.


Vacuum cleaners cannot be copyrighted, only patented. An improvement to an existing device is usually in itself patentable, presuming it's non-obvious. Whether or not the original vacuum is patented or not, the manufacturer cannot prohibit the creation and sale of extensions, even if the extension cannot be used with any other vacuum cleaner. This is almost the direct opposite of how copyright law operates.
08 Jun, 2011, Vigud wrote in the 51st comment:
Votes: 0
Tyche said:
plamzi said:
But so then, KaVir's example of selling a snippet and posting DikuMUD implementation on a site would seem to satisfy the terms of the license even if that snippet's sole purpose is to plug into DikuMUD, right?


I haven't seen the example, but if I couldn't plug it into LPMud, AberMud, Mush, or something not a DikuMud, then I would presume the example is a modification to DikuMud and is a derivative work.
I've built an area editor on top of a Diku derivative. It can't be plugged into anything else, but I can't see how it is a derivative work. To complicate the matter, it can't be plugged into the original Diku MUD either.
08 Jun, 2011, Tonitrus wrote in the 52nd comment:
Votes: 0
Vigud said:
I've built an area editor on top of a Diku derivative. It can't be plugged into anything else, but I can't see how it is a derivative work.

Emphasis mine.
08 Jun, 2011, Vigud wrote in the 53rd comment:
Votes: 0
Yes. Now tell me how my custom GTK+ widget or the glade file is derivate work of Diku MUD…
09 Jun, 2011, Scandum wrote in the 54th comment:
Votes: 0
Vigud said:
I've built an area editor on top of a Diku derivative. It can't be plugged into anything else, but I can't see how it is a derivative work. To complicate the matter, it can't be plugged into the original Diku MUD either.

It's a contentious area. I think once a derived work is over 90% original there's some argument to be made that someone is entitled to the fruits of their labor, especially if they take the effort to rewrite the remaining 10% from scratch as best they can.
09 Jun, 2011, Cratylus wrote in the 55th comment:
Votes: 0
Scandum said:
It's a contentious area.


Indeed. I wonder if this thread will be moved to the controversial topics area.
09 Jun, 2011, plamzi wrote in the 56th comment:
Votes: 0
Scandum said:
Vigud said:
I've built an area editor on top of a Diku derivative. It can't be plugged into anything else, but I can't see how it is a derivative work. To complicate the matter, it can't be plugged into the original Diku MUD either.

It's a contentious area. I think once a derived work is over 90% original there's some argument to be made that someone is entitled to the fruits of their labor, especially if they take the effort to rewrite the remaining 10% from scratch as best they can.


Vigud's area editor, if standalone, would more properly be termed "dependent" rather than "derivative." I believe extensions or accessories like the iPad cases are also "dependent" because they (unlike a software plug-in) can exist and function without the core product, just not very well – you can use an iPod case as a coaster long after an iPod model ceases to exist.

This discussion is getting into an area in which I'm keenly interested, because as many of you know, I am selling an iPhone GUI app that is "dependent" on a modified DikuMUD server. It does not contain a single line of the original DikuMUD code but its purpose is to connect exclusively to one single Diku-base game server. I wonder just how grey my area is, given that the license makes no mention of clients.

The iPod accessories comparison seems to me to be very apt for "dependent works." I believe what Apple is charging manufacturers for is not their ability to sell their product at all, but rather their ability to market it as an iPod (trademarked) accessory that has been blessed by Apple. I don't think Apple would have any legal grounds to pursue financial compensations from a manufacturer of MP3 player cases which happen to fit only one iPod model if the word iPod is not mentioned in the marketing of the item. I could be wrong.
09 Jun, 2011, Tonitrus wrote in the 57th comment:
Votes: 0
Vigud said:
Yes. Now tell me how my custom GTK+ widget or the glade file is derivate work of Diku MUD…

Depends how it works. You could implement an area editor as a separate program that edits files independently, or embed the code directly into Diku. Whether you use GTK or not is pretty irrelevent. As a standalone program, it's probably not a derivative work because the file format isn't protected under copyright law, provided you didn't learn the file format from looking at the code.
09 Jun, 2011, Scandum wrote in the 58th comment:
Votes: 0
plamzi said:
This discussion is getting into an area in which I'm keenly interested, because as many of you know, I am selling an iPhone GUI app that is "dependent" on a modified DikuMUD server. It does not contain a single line of the original DikuMUD code but its purpose is to connect exclusively to one single Diku-base game server. I wonder just how grey my area is, given that the license makes no mention of clients.

Looks like a license violation to me as you're making money off of DikuMUD. Depending on the features the client offers one could consider it a form of pay for perks. You can't compare yourself to zMud as the author of zMud doesn't run a DikuMUD and as such isn't bound by the licensing terms, which are very broad as the license states its scope is *ANY* part of Dikumud in any possible way.

There's really no gray area with the DikuMUD license, though on the other hand few people really care as nobody makes money off of DikuMUD without putting in a lot of hard work first.
09 Jun, 2011, Runter wrote in the 59th comment:
Votes: 0
Scandum said:
plamzi said:
This discussion is getting into an area in which I'm keenly interested, because as many of you know, I am selling an iPhone GUI app that is "dependent" on a modified DikuMUD server. It does not contain a single line of the original DikuMUD code but its purpose is to connect exclusively to one single Diku-base game server. I wonder just how grey my area is, given that the license makes no mention of clients.

Looks like a license violation to me as you're making money off of DikuMUD. Depending on the features the client offers one could consider it a form of pay for perks. You can't compare yourself to zMud as the author of zMud doesn't run a DikuMUD and as such isn't bound by the licensing terms, which are very broad as the license states its scope is *ANY* part of Dikumud in any possible way.

There's really no gray area with the DikuMUD license, though on the other hand few people really care as nobody makes money off of DikuMUD without putting in a lot of hard work first.


It's not part of dikumud. It's separate software with a separate license. Your end users are well aware of what they're buying, and it's not service on the game.
09 Jun, 2011, Scandum wrote in the 60th comment:
Votes: 0
So if I run a DikuMUD that's only accessible through a commercial client costing $10 a month that's not in violation of the license?
40.0/96