ToDo: Auth and Game Files

[a'moaca']

That is an impressive list. It does cover some of the things I had for it.

We also need a proper license from Cyan for the server auth and game files. This could be a multipart question:
- Obviously there must be a license to redistribute the files, or there's no point.
- Can they be bundled in a prebuilt MOSS install or do they need to be downloaded separately from here?
- People are going to want to change the Python. The license should be explicit about whether or not that is allowed under the license for these files.

I saw backups on your list, and that's one of the ones I was going to mention. I would actually mark it a blocker... because you'll be entrusted to others' work once it's public. Losing others' work is really lousy. But I can see why it's not a blocker, too. Could there maybe be a middle-of-the-road blocker that handles periodic backups of the repo, or even just periodic checkouts to somewhere safe?

- a'moaca'

[JWPlatt]

I am going to insert the GPLv3 license into the game and auth zip files, per Mark. Or are there some files within them that should get the Cyan insert?

Backups on my list are for everything except Foundry. Foundry backups are in rarified's domain. And he has explained this is already part of things. I think.

[a'moaca']

I am going to insert the GPLv3 license into the game and auth zip files, per Mark. Or are there some files within them that should get the Cyan insert?

Uh, isn't that up to Cyan?

Can you GPL compiled code? Can you GPL encrypted compiled code? What does that mean for the decompiled version? Well... I think it means that we have to provide the Python source. I mean, if the compiled version is GPL. That's the point.

I'd double-check. We would not want to accidentally GPL what is kinda-sorta content. And if they do want to GPL it, it would awfully nice to get the original Python to distribute per GPL instead of a decompiled version.

- a'moaca'

[JWPlatt]

I am going to insert the GPLv3 license into the game and auth zip files, per Mark. Or are there some files within them that should get the Cyan insert?

Uh, isn't that up to Cyan?

You'd think so. But that's what Mark asked me to do. Who'd know? I mean, before I just typed that sentence? I like your advice to double-check, and I'll mention the content question. Yes, I was wondering too whether encrypted compiled needed a GPL. Which is why I asked at all. Binaries don't need it. But the age files are not encrypted while they are encrypted in the downloaded dat folder.

[Mac_Fife]

If you apply GPL then you must make the sources available: The principle of "free software" under GPL is that you should be "free" to use it as you wish, "free" to modify it, etc. Else you throw a copyright/EULA on it if it's going to remain closed.

For things that are more artistic/cultural in nature (e.g. things that don't really fit being described as "code") then a Creative Commons type of license is probably more appropriate, if it's going to be open.

[a'moaca']

For things that are more artistic/cultural in nature (e.g. things that don't really fit being described as "code") then a Creative Commons type of license is probably more appropriate, if it's going to be open.

I think all these files count as code rather than art.

I had to come back because I was thinking about the ramifications GPL'ing the Python would have. I think someone needs to think carefully about this. If Cyan wants to GPL it, fine, but...

That would mean that technically all server-runners must provide Python source. Actually I think that's superb, but it's something to think about. (MOULa would be excluded as Cyan is the original copyright holder and they have a non-GPL copy to work from.) But GPL on the Python would also maybe kinda make new user ages in a tough spot. Most new Python is basically a copy of the old Python. Does that mean that finally we have a license to distribute age Python, but GPL? Or is it not really the case new age code doing the same thing is a copy, and it's "original" code? What about all the "glue" that lives, identically, in every single Uru python source file? Unless Cyan gives license to use that part unencumbered (i.e. public domain), it would probably be nigh impossible for an age creator to have non-GPL Python. That could be good too, but I'm not sure how age creators might feel about it. Or maybe, because the now-GPL'd MAX plugin probably spits out that code, it's output of a GPL'd program and thus not required to be GPL itself.

My point is, they might want to think about the ramifications of GPL before slapping it on. They may still want to do it, and I am not objecting in advance here... but GPL always warrants some extra consideration of what it means down the road, IMO.

Also I'm still not sure Cyan can really GPL the compiled version without giving us the original source.

The .sdl and .age files are not much to worry about. The SDL files are just encrypted, not compiled. So it does not seem quite so weird to me to propose GPL'ing them.

- a'moaca'

[Mac_Fife]

Also I'm still not sure Cyan can really GPL the compiled version without giving us the original source.

I'd agree - For GPL, I think the original source is a requirement.

[JWPlatt]

Update: We may get these files in source, with the same license in the headers. I'm asking for a review of a'moaca's concerns.

[Chogon]

The "glue" code is not really part of every python module source which is a misconception by everyone that only has the *.pak file to look at. What happens during the build process is that the python module source is read into memory, the "glue" python code is appended in memory, the whole mess is compiled in memory and written out to the *.pak file. But that is really just splitting hairs… but it "could" be viewed that the "glue" code is something separate.

But I'm not sure I see the difference between someone making a special client that a server-runner adds to their file server so they would have to make the source available and doing the same for Python code that is distributed by the file server. And I would think that people attaching to a "fan" server would want to have some idea of what is being downloaded onto their PC and run (Python code can do as much harm to someone's PC as a C++ written client).

Anyhow, I think that is will be important for fan created content to have access to the original python code - hopefully having comments will increase understanding - but also it will make it easier for us to try to include fan created content on the MOULa servers.

I'll try to get the sdl and python sources up there sometime this afternoon so everyone can have a look see - if it still seems like a bad idea to use GPL for the python code then we can discuss further.

Thanks!
Mark

[a'moaca']

Well, I learned something about the "glue" today.

I wasn't trying to say I thought GPL was a bad idea. I just wasn't 100% certain that, since the Python code is mostly centered around implementing gameplay, and was therefore closer to content than client/plugin/server source, Cyan would want to give out the source. Especially as the xKI.py source had no license. Then when I started thinking through the downstream effects, and as they spread out and became less clear, it seemed like we should make sure they were intended too.

But I'm not sure I see the difference between someone making a special client that a server-runner adds to their file server so they would have to make the source available and doing the same for Python code that is distributed by the file server. And I would think that people attaching to a "fan" server would want to have some idea of what is being downloaded onto their PC and run (Python code can do as much harm to someone's PC as a C++ written client).

In fact I agree. This is why I called having to make Python source available "superb". I have several pages of a forgotten writeup that center around Python security...

The question about what counts as copying and what counts as similar but new code is not unique to this code base, of course. The glue being separate does, I think, mean that it would be conceivable one could release brand-new Python not under GPL. I agree that I'd rather they didn't. And if the intent of GPL includes trying to keep Python code public, I'm fine with that, too.

Thanks for addressing my questions.

- a'moaca'