Re: Ogre3d : Upstream paths have changed and the licensing has changed
On Wed, 29 Dec 2010 at 12:42:37 +0100, Manuel A. Fernandez Montecelo wrote:
> Now, for your information and for the rest of the people in the mailing list
> which might not know: I created the package 1.7.1 and uploaded it 2 months
> and a half ago, as NMU/overtake of the package.
If you're a member of the games team, there's no need to hijack the
package, you can just add yourself to Uploaders and be a co-maintainer.
If you're not a member, perhaps you could join and maintain it in this team
rather than hijacking our packages? Even if you're going to be the only regular
uploader, it seems appropriate to maintain a library for games in the Games
Team, and membership of this team is generally rather open. Joining a
relevant team can also be a good way to find sponsors (maintainers of packages
that use Ogre might be willing to sponsor it, for instance).
Hijacking Debian packages from another maintainer, even an inactive one, is
generally not done, so that's one reason why an ftpmaster reviewing the NEW
queue might decide to review a less troublesome package instead.
> Of course, mid october was relatively late in the freeze process so it won't
> get into the next stable. But it also didn't get approved for unstable
> because FTP-masters don't want to consider it for some reason (probably
> because they don't care for package that won't go into stable).
The upload was to unstable, during a freeze, but Ogre appears to break
compatibility (SONAME) with every upstream version. That's certainly not
appropriate during a freeze.
It'd be much more appropriate to upload each new Ogre version to experimental,
make sure all packages that depend on it work when rebuilt against the new
version, then (when squeeze has been released and the freeze is over!)
ask the release team when you can re-upload to unstable, make any uploads or
binNMUs that are needed for packages that depend on it, and get it into
testing (a transition, in release team jargon). This applies at all times,
but even more so in a freeze.
The ftpmasters do accept NEW uploads during a freeze, but only to experimental
(which will never go into testing without further uploads), or to unstable
for packages that won't break/delay the release (such as ioquake3, which was
safe to put in unstable because nothing in squeeze depends on it).
Here are some other things that jump out at me when I look at
http://ftp-master.debian.org/new/ogre_1.7.1-1.html with a ftpmaster-like frame
of mind. (I am neither a lawyer nor an ftpmaster.)
The copyright file explains that the relicensing to MIT was done without
updating copyright headers; do you have any evidence whether it was done
legally (i.e. with the permission of all copyright holders?) This doesn't
necessarily make it non-free, because the other potential license is the
LGPL which is also Free, but a ftpmaster looking to get some NEW packages
approved/rejected seems likely to look at this and think "what a mess, I'll
deal with 10 quicker packages instead"...
When dealing with relicensing or license clarifications, it's usually a
good idea to quote the verbatim text of the relicensing or clarification
in the copyright file.
I'm not sure that the nvparse license is Free, since it lacks an explicit
permission to redistribute, modify, or redistribute modified versions:
License: other
All files in this distribution can be used however you want.
You write:
License: LGPL-2.1+
See /usr/share/common-licenses/LGPL-2.1
but that's not "a verbatim copy of its copyright information and
distribution license" (Policy §12.5); when referring to common licenses, you
should still quote the "This program is free software ... " blurb,
as seen in, for instance,
<http://packages.debian.org/changelogs/pool/main/t/telepathy-glib/current/copyright>.
You write:
License: MIT
See /usr/share/common-licenses/MIT
but:
smcv@reptile% dpkg -s base-files| grep Version
Version: 6.0
smcv@reptile% less /usr/share/common-licenses/MIT
/usr/share/common-licenses/MIT: No such file or directory
and if the license you're trying to refer to is the same "MIT/X11" license
used by libexpat, you're violating this condition of that license:
"The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software."
(which is probably why the MIT license isn't in base-files, in fact).
The copyright file lists several contributors to the packaging; why are
none of them Uploaders any more?
You're (now) the sole maintainer with no co-maintainers - what happens
if you lose interest or can't find a sponsor?
Hopefully that gives you some things to think about. Perhaps you could
address some of those in a -2 upload to experimental?
Regards,
Simon
Reply to: