Open xycaleth opened 9 years ago
It's also common to not tag source files, and just have the LICENCE in the root directory for each module.
We already have the license headers in the SP files so it only makes sense for MP as well.
Aren't the SP ones wrong?
No not really anymore. @smcv fixed them
It's also common to not tag source files, and just have the LICENCE in the root directory for each module.
That's commonly done, but is far from ideal. Putting a license in the same directory as some code is a lot less clear than specifically saying that (some of? all of?) the code is under the license; per-file license boilerplate makes it unambiguous.
It would also be good to have a verbatim quote of whatever license info was in the original Raven code-drop - I think http://sourceforge.net/u/richwhitehouse/jediacademy/ci/master/tree/README.txt might be it? - somewhere in the documentation, to have as much evidence as possible that we have valid permission from the copyright holders to distribute under GPL-2.
(I'm partly saying this because it's general best-practice, and partly because at some point I want to get OpenJK into Debian contrib, which means convincing the archive administrators that it isn't an unacceptable legal risk.)
I'm not sure who to list as the original copyright holder though as it's pretty unclear who holds the copyright over the source code :/
If in doubt, it's safest to assume that both Activision and Raven are copyright holders.
Here's my best guess at the complete copyright/licensing information (please let me know if you are aware of any other copyright holders or applicable licenses): http://anonscm.debian.org/cgit/pkg-games/openjk.git/tree/debian/copyright
I added raven's readme in c5940062f61c6948af335fbb426e61c36e2109d8 as rv-readme.txt.
Following @smcv's lead on this one, the copyright holders are...
id Software Raven Software Activision
Is it correct to list OpenJK as a copyright holder? OpenJK isn't a legal entity as far as I understand.
To clarify, the majority of the files will have the above companies as the copyright holders. We'll still need to go through all of the files to check which ones are relevant.
Strictly speaking, no, if there is no legal entity named OpenJK then it can't hold copyright. That rarely stops people from putting notices similar to "© 2013-2015 OpenJK" on open source projects, which on closer inspection are just not true. If you say something more like "© 2013-2015 OpenJK contributors" then at least it's a true statement, even if it isn't much use in determining who the "OpenJK contributors" are.
Ideally, everyone making a significant contribution to any given file would add themselves to the copyright holders and the year of modification as a copyright year, although in practice this is rarely fully comprehensive and up-to-date even for large or commercially-backed projects (and it's a lot simpler for commercially-backed projects where many contributions are owned by a small number of employers). "Significant" here means significant enough to be protected by copyright, which is actually quite a low bar; if in doubt, it's safest to assume that all contributions are copyrightable.
Similarly, if you copy in code from another project (usually ioquake3) you should preserve its copyright information, whatever that is.
When I'm compiling the debian/copyright
file for a Debian package, the Debian policy requirement is that I collect all the relevant copyright notices and license grants that I find, verbatim; so if you continue to claim that it is copyright OpenJK despite there probably being no legal entity of that name, and there's no actual evidence otherwise, I have to include OpenJK among the copyright holders in debian/copyright
anyway.
If OpenJK doesn't really exist as a legal entity but we list it anyway, then nobody is likely to complain (and it certainly can't sue us, because it isn't a legal entity); and if it does exist and we don't preserve that copyright notice, then maybe it could sue us. So it is safer to assume that all copyright claims are valid, in the absence of evidence that they aren't :-)
I believe the debian/copyright
that I linked above is comprehensive, except for:
I realise that bundled third-party libraries are something you need in order to do Windows deveopment, so I'm not going to complain about those, but I'm not going to spend a lot of time on dealing with them either.
except for
... oh yeah, also, the logo (see #630), although it seems that's in progress.
Great, thanks for the information @smcv :D I'll get started on heading up all of the source files, and hopefully the icon license will get sorted out soon too
How does this header look?
/*
===========================================================================
Copyright (C) 1999 - 2005, Id Software, Inc.
Copyright (C) 2003 - 2013, Raven Software, Inc.
Copyright (C) 2003 - 2013, Activision, Inc.
Copyright (C) 2013 - 2015, OpenJK contributors
This file is part of the OpenJK source code.
OpenJK is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
version 2 as published by the Free Software Foundation.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, see <http://www.gnu.org/licenses/>.
===========================================================================
*/
I'm not sure when the copyright starts for Raven and Activision, but they should be the same years since Activision is the parent company of Raven (I think?).
@xycaleth that looks good to me. It's safer to mention too many (potential) copyright years/copyright holders than too few - we don't really know whether copyright is held by Activision or Raven or both, so it's safest to assume the answer is both.
This is mostly done in 59dfa479f3 now. I'm sure I've missed a few people out but that can be sorted out at a later date, hopefully by someone else. (Adding/replacing headers in 950 files gets old pretty quickly).
While I was heading up all of the files, I came across a few extra files which could do with looking at or are not listed in your (@smcv) copyrights file
code/qcommon/tri_coll_test.cpp
and codemp/game/tr_coll_test.c
Both files contain code by Tomas Moller which originates from his paper on fast triangle intersection: http://www.cs.virginia.edu/~gfx/Courses/2003/ImageSynthesis/papers/Acceleration/Fast%20MinimumStorage%20RayTriangle%20Intersection.pdf It's not clear to me what license applies to code found in research papers like this...
codemp/mp3code/mp3struct.h
and code/mp3code/mp3struct.h
are files created by Raven. I didn't add license headers to these files because I wasn't sure who to add as copyright holders.
codemp/qcommon/md5.cpp
is in the public domain.
What about adding OpenJK contributors as license to the main cmakefiles in the project?
codemp/qcommon/md5.cpp is in the public domain.
Already listed as such in its in-file header, and in debian/copyright
in the packaging.
codemp/mp3code/mp3struct.h and code/mp3code/mp3struct.h are files created by Raven
I'd assume Raven + Activision, GPL-2, just like e.g. code/qcommon/z_memman_pc.cpp
, unless/until someone tells us otherwise.
What about adding OpenJK contributors as license to the main cmakefiles in the project?
Good idea.
code/qcommon/tri_coll_test.cpp
andcodemp/game/tr_coll_test.c
Both files contain code by Tomas Moller which originates from his paper on fast triangle intersectionIt's not clear to me what license applies to code found in research papers like this...
This is potentially awkward. There is no copyright license unless the copyright holder (presumably Tomas in this case?) has said there is, although the convention in academia seems to be "do whatever".
Rummaging on archive.org leads me to:
http://web.archive.org/web/20040614215002/http://www.acm.org/jgt/papers/Moller97/ http://web.archive.org/web/20120419132259/http://jgt.akpeters.com/papers/Moller97
both of which offer code very similar to what's in JA, but neither of which specify a copyright holder or license grant for it :-(
The author seems to have a web page here now: http://cs.lth.se/tomas_akenine-moller
I think the best way might be to contact Prof. Akenine-Möller and ask for permission to put a GPL-compatible license on that code, perhaps MIT/X11 like code/rd-vanilla/glext.h
. If you'd like me to do that on behalf of OpenJK, I can draft something and show it to you for approval before sending; or if you'd prefer for one of the core team to do it, please show me the proposed text first, because it'd be awkward to have to come back and say "actually, there's more..." after getting permission. It might be easiest to take that to email; I'm smcv@debian.org
.
@smcv, I'm happy for you to contact him to sort it out:) Thanks
The author of the OJK icon has given us permission to use the icon under the CC 4.0 BY-SA license, so I'll add a file for that somewhere on the repository. I'm thinking it might be a good idea to consolidate all of the different licenses used in OpenJK into one place so it's clearer and easier to find. Kind of like how D3 BFG (https://github.com/id-Software/DOOM-3-BFG) does it.
The author of the OJK icon has given us permission to use the icon under the CC 4.0 BY-SA license
Please include the .psd
in the git repository too: it's (presumably) the preferred form to use when modifying the icon (the closest that artwork gets to "source code"), even if a non-free tool (Photoshop) is necessary to do much with it.
Also please add a text file next to the icon source naming the copyright holder (by name or pseudonym) and stating that it, and the Mac and Windows icons derived from it, are under CC-BY-SA-4.0: putting a file with the license's "legal code" next to the icon is not really the same as actually saying the license applies.
Unfortunately, this license is not enough to link it into the executable (as we do on all platforms with shared/sdl/sdl_icon.h
and, on Windows only, also by listing the .ico
file in the .rc
file), because the executable is a derivative work of both the icon and the source code, and CC-BY-SA-4.0 is not GPL-compatible. This is the sort of thing I was worried about for the triangle intersection algorithm...
The GPL-2 basically says "you must release complete source code for derivative works (like the executable) with no more requirements than those of the GPL-2". Most of the stuff we build into the executable is GPL-compatible, i.e. under a license that does not have requirements beyond those of the GPL (BSD, MIT, zlib licenses are fine) but CC-BY-SA-4.0 does have non-GPL requirements.
One way to solve this would be to ask the author of the OJK icon to dual-license it, with a license grant something like this:
This work is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
version 2 as published by the Free Software Foundation, or,
at your option, the Creative Commons Attribution-ShareAlike
4.0 International license.
This work is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
That's the closest equivalent of the -SA license terms that would allow linking this thing into a GPL-2 executable.
Another way would be to ask them for a permissive non-copyleft license (again, I would normally suggest the MIT/X11 license as seen in glext.h), but if they have deliberately chosen the -SA license on principle, they might not want that. CC-BY-4.0 does not seem to be suitable: it isn't clear whether it's GPL-compatible or not.
Another other way would be to stop using .ico
embedding on Windows (this is a minor regression: the executable will have the default Windows .exe icon), and to load the icon used for SDL_SetWindowIcon()
from an external resource file - perhaps "openjk.png in the same directory as the executable" - rather than embedding it in a header file and linking it in.
That is irrelevant if we do not distribute the derivate work, so at the moment the buildbot is possibly violating the license but you'll have to take that up with the buildbot maintainer.
+1 for .psd part though.
OpenJK maintainers other than whoever runs the buildbot are not distributing the derivative work (the executable) right now, but the buildbot does, the Debian packages I'm preparing are going to (Debian is a binary distribution like Red Hat, not a source-only distribution like Gentoo), and presumably the OpenJK maintainers want to do an official binary release when it's ready.
I would like to minimize the number of modifications I need to make to OpenJK to make it redistributable by Debian and other Linux distributions, particularly those that remove features (in this case "the window has a nice icon"). Upstreams tend to dislike it when we delete their features, but if the reason is "otherwise it's illegal for us to do this", we don't really have an alternative.
Aaah, well that's a pain. I had asked Antonio (the icon author) to choose one of the CC licences but I didn't explain it very well. In the end I asked him it would be okay for us to use the icon specifically under the SA licence. I didn't realise it was incompatible with GPL2. I can ask if he'd be willing to let us use a different licence?
I can ask if he'd be willing to let us use a different licence?
Yes please. Depending what he wants, a "GPL-2 or CC-BY-SA-4.0" dual-license (see the code block in my comment), or just GPL-2, or MIT/X11 would all be fine. Would you mind cc'ing me on this?
If he refuses, the fallback plan can be to not embed icons in the executable - CC-BY-SA-4.0 is a perfectly OK license for a standalone icon file, it's just not suitable for this particular use.
@smcv, I'm happy for you to contact him to sort it out:)
Done; cc'd you and @ensiform. Let's see what he says... hopefully "yes".
We can't exactly remove or replace the tri col test files either way without pissing off the player base further. Saber collision is very specific.
We can't exactly remove or replace the tri col test files either way without pissing off the player base further
I'm aware. Unfortunately complying with the law is not always trivial.
I've contacted the author, if he says "yes that's fine" we're good, if he says "no" we can cross that bridge when (if) we come to it.
Well it was included in the SDK release so they most likely had validity to include it now.
I can ask if [the icon artist would] be willing to let us use a different licence?
Yes he would, it's now MIT/X11, which is GPL-compatible and suitable for linking into a GPL-2 executable. #647.
I've contacted the author [of tri_coll_test], if he says "yes that's fine" we're good
He did, so it is no longer relevant whether Raven had a valid copyright license for this code in the first place or not :-) #648.
I'm thinking it might be a good idea to consolidate all of the different licenses used in OpenJK into one place so it's clearer and easier to find
That might not be a bad idea...
What's left after #647 (or similar) is merged:
tools/
: I haven't audited this, in the Debian packaging I just delete it (apart from the one header file that the main code uses, tools/Ibize/ibize_platform.h
). I'm tempted to suggest doing the same in git master, moving tools/Ibize/ibize_platform.h
into shared
or something - people who want the tools can get them back from git history, and your build system doesn't build them anyway.tools/Ibize/ibize_platform.h
and ui/menudef.h
could do with having GPL-2 headers. They were part of the Raven code-drop and there's no indication that they aren't © Raven/Activision like the rest.lib/
, code*/*.dll
: for Debian I just delete these, apart from minizip which is a Q3-modified version and needs to remain available. License compliance might require pasting in some licenses for these, I haven't checked. I don't know where OpenAL32.lib
, ALut.lib
or the DLLs come from or what their licensing is like; the rest of lib/
is certainly open source.Anything else?
The openal libs are closed source proprietary versions with eax support for windows only.
The openal libs are closed source proprietary versions with eax support for windows only
Do you know where they come from / who holds the copyright / what their copyright license is? (Presumably something like "binaries may be redistributed unmodified".)
I'm going to hazard a guess that they belong to Creative when they were still around. The AL headers seem to suggest their own LGPL, but there's no specific mention of who the copyright holders are. It simply says "authors". The EAX extension headers/libs are definitely under a proprietary license.
We would want to use OpenAL Soft for the second release as this is licensed under the LGPL. I want to say just leave the OpenAL code as it is for the moment. It's wrong, but there's no stringent checks like there is when submitting to Debian.
The creative al code and eax should be totally disabled on the other platforms from Win32 since that is the only platform in which the lib exists.
The creative al code and eax should be totally disabled on the other platforms from Win32
They already are; the Linux build uses OpenAL-Soft (compatible API, different implementation).
In OpenJK it doesn't even support alsoft yet.
Sorry, my mistake, I was thinking of ioquake3 and iortcw (which do use alsoft). I'm obviously packaging too many Quake 3 engine variants :-)
We'd like it to, but there are a lot of code differences in Raven's sound code over Q3.
And we would need to investigate how to replace EAX with EFX properly as well.
Argh, so there's a few files remaining which haven't had their headers added. They haven't been added to the CMake list which is why they've been missed...
OpenJK is now in the "NEW queue" for Debian, waiting to be checked by the archive administrators. I'll let you know if they spot any further licensing issues.
Status update on licenses for the code? Would like to close if we can.
OpenJK has now made it into Debian contrib, which means the archive administrators are happy with the licensing of everything except for the files I excluded, which are:
Files-Excluded:
code*/client/OpenAL
code*/client/eax
code*/*.dll
lib/*.lib
lib/jpeg-8c
lib/libpng
lib/zlib
tools
I think this needs to be revisited at some point. I see in the DOOM3 project that their OpenAL headers (https://github.com/id-Software/DOOM-3/tree/master/neo/openal/include) are released under the GPL 2+ license. Not sure if that's something that's agreed on between id and Creative or if that's how the headers are released though.
We need to smarten up (read: add) the headers on all of the source files to show that they're licenced under GPLv2. I'm not sure who to list as the original copyright holder though as it's pretty unclear who holds the copyright over the source code :/