No, I mean if you statically link a binary, all the code in every object file you use is (by definition) present in the binary itself. IANAL, but I can't imagine why you'd need to provide the *seperate* object files. Requiring the source code to generate those object files makes sense, but binary code is binary code. It makes no difference if I provide a binary with the code in it, the .o files, a .a file, a .so file, or any other permutation of binary code, at least from a technical viewpoint.



Cratylus beat me to it…. but I'll go ahead and post it anyways, since I word things differently.

There are a couple of reasons why distributing binaries is a little less acceptable in the unix world. Let me try to come at this from the sysadmin point of view.

Yes, I do have java installed on my linux server. However, Java is a binary produced by a very large company (Oracle), and distributed through the official Debian (in my case) mirror system. This means there are at least two layers of corporate entities I can point the finger at if something BAD(TM) happens. Any malicious code has to make it through Oracle's own QA team, and then it has to remain hidden through the Debian QA process. If something does get through, I know there's somebody I can contact, and if need be, at least attempt to bring legal action against, even if the odds of my getting anything from it are likely small.

Contrast that with your project. I don't know you. I know nothing about you beyond that you're some guy in a forum I read, who has some nice idea and wants me to run his random executable on my system, but won't provide me any source code. You're probably a great guy, and I seriously doubt your binary would cause any harm (intentional or not)… but, if it does, what do I do?

There's another angle on this too.

You say your binary uses mysql. I already have mysql installed and working on my system. Can you gaurentee that your version is compatible with mine? I won't be updating (or downgrading) my version for your project. If I had source, I could compile it against my own version and make changes if need be.

The windows universe is a little different. There is an official source for windows, and when you provide a windows binary, you're working in a known environment. Each user may have third-party stuff installed, but if you stick to the base development kits Microsoft provides, it's more or less guarenteed to work. Linux distros have no such control. Debian != Redhat != Puppy Linux. They can have radically different layouts, and there is NO way to make things work cross-platform other than linking everything you want into a single static binary that's aimed at the lowest-common-denominator (namely 32-bit intel linux).

Personally, I applaud you for making the effort! But if you want to distribute something binary-only, you're going to have to provide some very good reasons other than "I don't want to", or "I think end-users are stupid and can't type ./configure && make && make install". Those both may be true, but they don't mean anything to me. :)

In short, *WHY* should I install your binary-only thing? How is your project so revolutionary that you feel the need to protect your source code when so many other projects don't need to do so?

BTW, Java is open source and you can compile it yourself, if you like.

Even self compiled stuff isn't safe. How many people actually inspect very line of code before building it? How many people only trust code they can read? We all trust other people at some point and credibility is king. I.e. it's probably unlikely you're going to get something malicious from a well known repository. It's very likely you'll get something malicious on limewire.

Some people will read the code, and it only needs one person to spot a problem.

But it's just not about safety, it's also about control over the future my work. If I'm investing time and effort into developing my own mud, but it requires a binary core, what happens when my operating system becomes obsolete? What happens if the developer gets bored and moves on, or gets greedy for large licencing fees, or gets hit by a bus? What happens if someone discovers a critical exploit and there's nobody maintaining it?

This is why I'd never use something like MudMaker, and was also one of my original concerns with ScapeFX. It also reminds me a bit of Ilyrias - although that was actually a licence issue, the end result was much the same; their efforts were flushed down the toilet because they could no longer use the codebase they'd built their game on.

Oh, I'm not an advocate for closed source binary distributions. I'm just saying, if you find a small-time project on the internet, download it, and compile it (without reading the code, even though you assume "some people" must have and spotted the malicious code), then it's still not safe because you have the code. If the code compiles to malicious instructions then it's still just as bad. Honestly, though, that's the same mentality people use with binary downloads. That if it were bad someone would have already taken action to prevent it from being distributed, but we know things aren't really that simple.

I don't know anything about that project and the page you linked doesn't the circumstances. What codebase were they using that they couldn't any longer?

Hey people-

So i had a long response to everyone typed out with things like "good point" and counter arguments and such. But through some series of wild keystrokes i closed the window and lost it.

So well skip all that and get to the point.

Here is the problem. I want people to be able to create free muds for people to play with it. I dont want my credits stripped out and claimed as their own or used in someone elses commercial game/product. I do want to sell a more generic version of the core that is not slanted towards muds.

You see the dilemma. The mud core is still generic enough, and designed in such a way it would be very easy for someone to strip out the code and make it useable for any sort of thing they wanted, and claim it as their own.


I love the mud community, i love muds. I think the core i want to release really is a "next-gen" server base. I just dont want it used outside the terms i set forth, and releasing the code seems like thats just gonna happen, it seems like its just unavoidable.

I am working on a version of Rom that i have adapted some of my systems to, but really its just a pain in the neck. In comparison the modified Rom looks like a sad haphazardly thrown together broken down toy in comparison to my base. I would really rather just delete it then release another sad attempt at reviving a horse that should of been put to pasture years ago.


Anyone see another route for me to follow here?

Should i just stick to my binary path, knowing that there will be those who simply wont use it because its in binary format?
Should i co-mingle my nicely separated code in such a horrid fashion as to make it easier to just write a base from scratch then try to follow it and remove the undeed stuff?
Other options?

I know this is perhaps not the open source view alot of you may have, but i am trying to say hey here is something great that i think people would like to use, and i dont want to charge people not trying to make a buck on it.

_-Menser-_

An additional comment about binaries on Linux:

Linux users may also hate binaries for very practical reasons. I completely loathe them, and not for any lofty philosophical or ideological reason. I loathe them because for several years I used a tablet that had an nvidia card in it that nvidia did not properly support. The fastest performance I could get out of it was putting the kernel in a framebuffer mode and using X with fbdev. Nvidia's official drivers made it lock up, and their 2d open source drivers are crap. Naturally, as soon as I built myself a desktop, they dropped support on the old nvidia card I had in it. The legacy drivers still work in that case. Now if an open source driver or program screws up, someone will fix it, if a binary breaks, only the original distributor can fix it. And if I can't trust a big company like nvidia to keep their binaries working properly, I certainly can't trust a lone individual on the internet.

Linux is a moving target for binaries. Don't even bother putting out binary-only releases. They won't work properly, and you'll either be constantly trying to fix it, or, more likely, you'll just give up, and people won't be able to use it anyway.




Sounds like the diku license to me. The diku team even made a commercial version of their own mud (which they distribute as binary-only, which is where I lost interest). The problem in diku's case is mainly that the diku team doesn't enforce their own license. There are plenty of people who will do anything they can get away with.



That's still a licensing issue, unless you're concerned that you'll never find out about it. I can't help you in that case.



No. In the long run, no one will be able to use it, meaning that the people who are able to in the short term will waste valuable time building a creation that they ultimately will lose the ability to run.



Deliberately making the code difficult to use and modify hasn't helped the gcc project any. Each release just gets slower. I can't wait until clang and llvm take over.



Find a license you like or make one up (with the help of a lawyer, please, I don't want to hear people debating your license until the end of time). Enforce it. You can release your code under any terms you like, it doesn't even have to be open source. You could release your code while forbidding anyone to modify it, or release it for viewing only, forbidding anyone to compile it, or any number of other insane things. You could allow use only during certain phases of the moon, or only for people who have spent less than 30 minutes a year debating license issues, or any other thing. You don't have to choose between GPL/MIT and fully closed proprietary licenses.



The objection to binaries in this case is both philosophical and pragmatic. Don't let the ideology confuse the facts. As a practical approach, binary-only releases are not going to work.

Bravo. A bit more categorical than I'd put it, and people will quibble probably, but good points, well made. Would read again.





Either get used to being ok with releasing source with a license you enforce, or use Windows.

There is actually a third option, which is to build a solid reputation for integrity and reliability, and put out a
great product that people really want and does things better than the other available products. Then people
might put up with the inconvenience of a Linux binary from you. This option does work…people use
Adobe's products on Linux all the time. It does take a fair amount of effort tho, so you might want to give
serious thought to the first two options I mentioned.

-Crat
http://lpmuds.net

If you really love the mud community, then show a little trust and respect. You might get some in return. Yes, there are plenty of jerks out there who will strip headers and try to claim they did all the work. That happens everywhere. Even a binary won't save you from that.

If you really hate the idea of it happening, keep your eyes open, and get a lawyer if you spot a violation. It's up to you to enforce your copyright. As said above, the DikuMUD people didn't bother, and so for every legal game running, there's probably two more in violation to some degree.

If you think about your stance, you are telling your neighbors that they are welcome to use your garden hose to water their vegetables, but you are fitting a padlock on the hose, and a shutoff valve on the water supply. *shrug*

You should also prepare yourself for the fact that no matter how you license or distribute your code the chances are nobody will use it anyway.

There are plenty of bitter people around to prove that point. The best model for a successful codebase is 1) A big player base 2) Recruit a big staff (code leaking isn't an issue as you're going to release anyways)

Most people get stuck at #1


Kind of difficult to get the story straight based on that information. I think it says more about the need to avoid a 3rd party license than IRE.

I strongly suspect that the majority of Linux users install binaries and never look at the source code. There doesn't appear to me to be any difference in accountability, character or responsibility between those distributing source, binaries for either windows or *nix systems. You can't even depend on a build system to be present on newer Linux distributions. Your best bet is to release using the package management system for each Linux distro you are targeting. Ensuring your binaries run on many major linux distros isn't that hard. Well… let's just say the difficulty is directly proportional to the number of library dependencies your server has.

Seeing as how you dowant to charge people who want to use the code commercially, I think you'll just have to own up to the fact that you'll have to put in time on the business side, not just the programming side, of the equation. At the moment you seem hung up on the latter.

reminds me: http://www.mudbytes.net/index.php?a=topi...

This will sound a bit confrontational, but it's not meant to be insulting. Please don't take it as such.

You keep saying you want to give back to the community, but then you say the community is filled with scumbags and you can't trust any of them. This may well be true, but trying to force a binary distribution model on people who DO NOT WANT IT, is just dooming your project to an early grave.

Think about this. How many MUD codebases do you recognize by name? DikuMUD? LpMUD? MudOS? Nightmare? Dead Souls? Circle? ROM? I'm sure there are plenty more you could name without having to look them up. Why is that? If everyone out there has nothing better to do than strip credits from source code and claim they wrote it all from scratch, why would there be ANY recognizable names for freely distributed codebases?

Because, at one time, each of those was a popular, living, supported entity. Because they all developed communities build around people who were using them, and asking one another for help. Maybe even because there really are more people who just want to get their MUD up and running, so they can start working on their game.. rather than trying to "steal" somebody's work.

If your images of the MUD community being nothing more than a den of thieves is accurate, there shouldn't be any codebases you can name. Dead Souls would just be Cratylus's MUD, and there's be 100 copies out there with other names that don't admit they used Dead Souls as a base. The very fact that brand recognition exists kindof implies that the majority of people who use it really do admit what it is, and where it came from.

So, ponder that as you research your thousand-and-one binary package systems. How is your code so revolutionary that it deserves to be treated differently than the hundreds of other games which DO provide source code?

As a follow-up to what quixadhal said, how many binary-only MUD codebases do you know by name? I only know of one, and I'm not even sure I remember the name. In fact, I don't really know any other proprietary codebases, source distributed or otherwise.


"Early grave" is my assessment as well.

Why do you believe he needs to create any installation packages? What's wrong with shipping only the binary file (in two versions; 32-bit and 64-bit) for core program, sources and documentation in one tar file? The only good thing about packages is that package managers do automatic check for requirements, but, honestly, doing it manually is a piece of cake, provided that required software is listed in a text file distributed with the program. I've had to install stuff (boost and friends, to be precise) required by some MUD code in order to be able to compile the sources, but… so what? Doing the same for a binary file is not going to be any harder. Trying to run a MUD is not like installing another web browser from your system's repository, you're doing kind of administration work after all…

I think you've hit on a good point there. If he doesn't really care about wide adoption, he'll be fine doing a halfassed job of releasing.

-Crat
http://lpmuds.net

You're wrong. Not distributing packages for distros is not a sign of not caring about adoption. See Warsow download site for an example.

I'm speaking specifically about RoF. I am not attempting to articulate a general law of software.

-Crat
http://lpmuds.net