[Gen]

For the time being, the project will be using the LGPL license to encourage community contributions to the project. The project will also be hosted on BitBucket using Mercurial, until a better solution can be had.

You can find the current repository here: https://bitbucket.or...engine/overview

We may relocate the repository and relicense at a later date to a different server if it better serves the community's interests.

This post has been edited by Gen: 11 March 2012 - 11:00 PM

[Gen]

So, let's talk about version control.

Since we're doing the whole open source thing, we're going to need a decent version control system that can decently handle branching, forking, and so on while still allowing us to easily merge changes in from a remote repository.

I'm going to go with recommended Mercurial here. It has pretty decent tools for Windows, Mac OS X, and Linux.

On top of that, I'm heavily leaning towards BitBucket for repo hosting, as it supports wikis, bug tracking, and most things you'd come to expect from GitHub, making project management a little bit easier.

Of course, Git would be nice if only because it's *faster* than Mercurial in a lot of operations, if there's decent enough GUIs for it on Windows yet.

If any one has any ideas for what version control system we should use, and even where it should be hosted, feel free to discuss it in this thread. The overall goal for the discussion is to decide on a defacto version control system, a place to host it, and client-side tools to recommend to people interested in the project.

[Aerosol]

My layman vote goes to Mercurial, simply because it can easily be thrown up on Retro's Mercurial with the rest of the stuff we make here.

[James K]

So what's wrong with the current Bitbucket you had setup?

This post has been edited by James K: 09 March 2012 - 01:23 PM

[Gen]

I'm mostly opening up discussion to see what other people would prefer. Nothing's been committed yet to that repository, so I figure now would be a good time to discuss it.

[Delta]

My first post involving this project. I know a little about licenses (I'm certainly no expert, and I'm definitely not a lawyer). Some brief pros and cons:

GPL
+ Encourages contribution, directly or indirectly.
+ Allows commercial/for-profit creations, as long as appropriate source code is published or given upon request.
+ Allows anyone to modify the engine as they see fit.
+ Prevents third parties from publishing engine modifications without releasing their source code.
- Anyone using the engine must also GPL their project (could be a deal-breaker for many), unless we explicitly state an exception for linking with engine binaries.
- Controversial among some. This doesn't necessarily have to do with the merit of the license, but it's something to consider if you want more users.
- Tends to be complicated to understand for a lot of people. This may not be a big deal, but if they want to know for sure what they can and can't do, it'll be more difficult.

LGPL
+ Similar to GPL, has the same pros.
+ Projects that dynamically link to unmodded engine binaries don't have to use the LGPL. Mods to the engine code still have to be published, though.
- Still a complex license.

ZLIB, BSD, MIT
+ Short, simple, straightforward. Easily understood.
+ These three licenses are nearly identical; essentially, you only have to include the license text and clearly represent/credit the code's origin.
+ Allows commercial/for-profit uses.
+ Allows static linking.
- No one is required to publish engine changes. It's possible for someone to take the engine code and make it proprietary. We'd still get credit according to the license, but zero guarantee of source code and/or contribution.

Overall
For the purposes of this project (fangame engine), I would say that the LGPL would be the best between the two extremes. Not everyone wants their project to be GPL'd, but at the same time I'd guess that no one wants the engine to be changed and charged for while giving nothing back. Just my opinion though.

[Sik]

Delta, on 09 March 2012 - 09:17 PM, said:

LGPL
+ Similar to GPL, has the same pros.
+ Projects that dynamically link to unmodded engine binaries don't have to use the LGPL. Mods to the engine code still have to be published, though.
- Still a complex license.

To make things clear: the LGPL is like the GPL except it isn't viral as long as you can change the LGPL'd code somehow. If your project is open source, this is pretty much already done regardless of how linking is done (since you can just rebuild the program). For binary-only programs, you'd need to use dynamic linking so the LGPL'd code can be changed without touching the binary.

Also are you sure that you aren't required to distribute the source code for LGPL libraries even if you don't modify them? I'm pretty sure you have to, just it doesn't affect the entire program.

(also big IANAL)

[Delta]

Sik, on 09 March 2012 - 09:57 PM, said:

Also are you sure that you aren't required to distribute the source code for LGPL libraries even if you don't modify them? I'm pretty sure you have to, just it doesn't affect the entire program.

LGPL libraries -do- have to distribute their source code, which is what I thought I said. But I don't think that projects using an LGPL library have to distribute that library's source code (unless modifications are done).

[Conan Kudo]

Atlassian's BitBucket or Google Code in Mercurial configuration would be my recommendations. Mercurial allows anyone with any OS (except DOS) to contribute to the repository. I'd probably suggest Google Code over BitBucket because BitBucket free accounts have a five-user restriction and Google Code repositories don't.

[Conan Kudo]

Delta, on 09 March 2012 - 10:06 PM, said:

Sik, on 09 March 2012 - 09:57 PM, said:

Also are you sure that you aren't required to distribute the source code for LGPL libraries even if you don't modify them? I'm pretty sure you have to, just it doesn't affect the entire program.

LGPL libraries -do- have to distribute their source code, which is what I thought I said. But I don't think that projects using an LGPL library have to distribute that library's source code (unless modifications are done).

You do have to redistribute LGPL libraries sources if the binaries are bundled. Having an LGPL'd engine just means you can use proprietary dynamic link libraries. Honestly, if I thought we could agree to use open-source libraries, I'd actually recommend going for GPL with an LGPL'd addon system so that developers can make proprietary addons with an SDK. I've mentioned in another thread that making the engine GPL/LGPL will protect us from threats by SEGA because of the unwillingness of the gaming industry to use GPL/LGPL code for core engine code, so that is another factor to consider.

This post has been edited by Conan Kudo: 10 March 2012 - 03:42 AM

[Covarr]

The LGPL would allow someone to use the engine in their game without necessarily providing the entire source to their game, simply the original engine, no? This seems ideal to me, such that the engine itself can be kept open while allowing people who use the engine to retain some control over their own products. That's always been my big issue with GPL, as the moment you add anything GPL to your work, even your own stuff isn't truly yours anymore.

[James K]

Ok, quick recap:

The issues with permissive licensing (BSD/MIT/ZLIB) is apparently:

1 ) Making it permissive may cause SEGA's to ask for cease and desist

Ok, I understand where you're coming from, but this is just the engine, there's nothing in the code or math that belongs to or is related to SEGA or SEGA's trademarks:

Physics engine? - No, they don't even use a decent sonic physics system in their engines anymore, barely in 2D, forget 3D.

Graphics system? No, making your own original rendering system isn't something that you can legally penalize anyone for. SEGA does not own OpenGL, Gen's code, or the algorithms he's using.


The engine has nothing to do with SEGA, just the engine alone would basically be this:

http://www.youtube.c...h?v=aQU3uHRhWxk


2) Permissive licenses means that people wouldn't share code

Well, are you speaking from what you've seen happen with other projects? Because I've seen that even with ZLIB/MIT/BSD licensed projects, many people will post what they're working on, get feedback, and many times release source code or parts of it.


I would say that there would be no difference in people sharing code if a permissive or "un-permissive" license is used, the benefit of a permissive license is just that - the code has no restrictions




Also, I know there's at least 2 game related projects that start the out with LGPL and later go to a permissive license.

SDL 1.2 LGPL -> SDL 2.0(and possibly 1.3) ZLIB: http://www.libsdl.org/license.php

Ogre 1.7 LGPL -> Ogre 1.8 MIT http://www.ogre3d.org/licensing


-----

If a new, general use game engine is going to developed, I still don't see any real drawbacks to use a permissive license, that's just my opinion.

This post has been edited by James K: 10 March 2012 - 08:58 PM

[Conan Kudo]

Covarr, on 10 March 2012 - 08:15 PM, said:

The LGPL would allow someone to use the engine in their game without necessarily providing the entire source to their game, simply the original engine, no? This seems ideal to me, such that the engine itself can be kept open while allowing people who use the engine to retain some control over their own products. That's always been my big issue with GPL, as the moment you add anything GPL to your work, even your own stuff isn't truly yours anymore.

This is indeed true. The LGPL/GPL only covers code, not game assets. If any scripting language is going to be used to drive actual game logic (separate from the engine, but part of game assets), then the game logic would also not be covered. If necessary, it could be clarified with an explicit exception granting that game logic in the scripting language would not be covered. As it is, the LGPL would not conflict anyway, since it falls under the runtime exception already included.

James K, on 10 March 2012 - 08:57 PM, said:

Ok, quick recap:

The issues with permissive licensing (BSD/MIT/ZLIB) is apparently:

1 ) Making it permissive may cause SEGA's to ask for cease and desist

Ok, I understand where you're coming from, but this is just the engine, there's nothing in the code or math that belongs to or is related to SEGA or SEGA's trademarks:

Physics engine? - No, they don't even use a decent sonic physics system in their engines anymore, barely in 2D, forget 3D.

Graphics system? No, making your own original rendering system isn't something that you can legally penalize anyone for. SEGA does not own OpenGL, Gen's code, or the algorithms he's using.


The engine has nothing to do with SEGA, just the engine alone would basically be this:

http://www.youtube.c...h?v=aQU3uHRhWxk

Intent is more than enough to send a cease-and-desist. Especially since the Mobius engine is geared toward Sonic-style games, with the emphasis on the Sonic part.

This post has been edited by Conan Kudo: 10 March 2012 - 09:13 PM

[Gen]

Conan Kudo, on 10 March 2012 - 09:10 PM, said:

Intent is more than enough to send a cease-and-desist. Especially since the Mobius engine is geared toward Sonic-style games, with the emphasis on the Sonic part.

Well, I guess if legality is a problem, we could potentially generalize a little bit more than "A Sonic fangame engine" and go more into "An easy to use game engine with roots in the Sonic community". At that point, it'd be a bit harder for SEGA to have a legal basis to send a cease and desist, since our engine could generally be used to create virtually any kind of game, even if initially it may have its initial roots in the Sonic community.

Alternatively, there's always the option of just writing our own using one of the more simplistic licenses as a base. Personally, I'd be a fan of a BSD based license, since it's generally easier to understand, and would be pretty easy to base a license off of.

This post has been edited by Gen: 10 March 2012 - 09:37 PM

[Conan Kudo]

Gen, on 10 March 2012 - 09:35 PM, said:

Conan Kudo, on 10 March 2012 - 09:10 PM, said:

Intent is more than enough to send a cease-and-desist. Especially since the Mobius engine is geared toward Sonic-style games, with the emphasis on the Sonic part.

Well, I guess if legality is a problem, we could potentially generalize a little bit more than "A Sonic fangame engine" and go more into "An easy to use game engine with roots in the Sonic community". At that point, it'd be a bit harder for SEGA to have a legal basis to send a cease and desist, since our engine could generally be used to create virtually any kind of game, even if initially it may have its initial roots in the Sonic community.

Alternatively, there's always the option of just writing our own using one of the more simplistic licenses as a base. Personally, I'd be a fan of a BSD based license, since it's generally easier to understand, and would be pretty easy to base a license off of.

Well, SEGA doesn't have a problem with fangames as long as there's no chance for commercialization (and thus potentially driving away sales from SEGA). Since most people/companies have the mindset that the GNU licenses can't be used for commercial works, it's an effective shield. I'm personally in favor of the LGPL. Writing our own license is just asking for trouble, and the GNU family of licenses have long since been proven to stand up in courts around the world. The language of the LGPL isn't all that difficult to understand, and there's a very nice FAQ about the GNU licenses too.