Ticket #564 (closed defect: fixed)

Opened 14 years ago

Last modified 6 years ago

clean up licensing

Reported by: geofft Owned by: jdreed
Priority: normal Milestone: Precise Alpha
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:

Description

  • There are (at least) two versions of the MIT license in use in our packages: one along the lines of <mit-copyright.h>/<mit-sipb-copyright.h>, and one the X11/Expat license, which is what the world at large considers the MIT license. We should standardize on one, probably the latter, because in my reading the former ("Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted...") implies that you can't make derivatives or sell them.
  • The names of people who own copyrights are often wrong. For instance, Tim Abbott and Anders Kaseorg are listed as owning the copyrights for debathena-printing-config's packaging, but they haven't ever committed to that package.
  • Binary packages that use DEB_TRANSFORM_FILES and therefore include modified versions of upstream files, and potentially all configuration packages, need to be licensed the same as the upstream package they configure, as derivative works.

For the record, the fact that sometimes code is copyright individuals and sometimes copyright MIT is intentional -- things by paid (IS&T) staff are owned by MIT, but things by (SIPB) volunteers are owned by themselves. It's possible we should consider assigning the copyright for everything to MIT, but there hasn't yet been a compelling reason.

Change History

comment:1 Changed 13 years ago by jdreed

Having had a lot of fun with find, md5sum, and uniq, I come up with the following differences between the copyright files:

  • As noted, there's the full MIT (Expat) License, and there's that ancient blurb we have. We could standardize on the MIT License. OTOH, the TLO recommends BSD, GPL, or LGPL. So... yeah.
  • Copyright years are arbitrary, especially for "Athena" code. I see 1996, 2008, and everything in between. I'm not sure what the "right" value is. Perhaps Greg Hudson or Andrew Boardman can comment?
  • Some files contain this header, some don't. Do we need it?
    This package was debianized as part of the Debathena Project
    <http://debathena.mit.edu/> of the MIT Student Information Processing
    Board.
    

Questions that remain:

  • Does each file need to say where the Athena source code was obtained from? That was relevant when Debathena was not "Athena", but I don't think it's relevant any longer. If we're going to keep it, we should ensure the URL is one that will be permanent.
  • Going forward, I think we should officially designate a license for the Debian packaging, rather than say "has the same license as the original software". That way, if copyright files do get copied around, or the software substantially changes, we don't magically end up with Debian packaging licensed under the Apache License or something, when that's not what the creator intended.
  • What do we do for packaging that was, e.g., created by Tim & Anders, but has now been changed by an IS&T employee. Add "Massachusetts Institute of Technology" to the copyright holder list? Something else?


I'm not so sure I agree that binary packages that use DEB_TRANSFORM_FILES are now derivative works. Is the configuration file itself copyrighted? And in the case of many packages, was the configuration file written by the software author, the Debian maintainer, the Ubuntu maintainer, or what? I suspect a can of worms has been opened here.

I will attempt to compile a list of individual people named in each file so we can verify they're correct.

comment:2 follow-up: ↓ 4 Changed 13 years ago by jdreed

  • Owner set to jdreed
  • Status changed from new to accepted
  • Milestone changed from The Distant Future to Fall 2011

Since nobody but me has looked at this ticket, I propose the following:

  • Change all occurrences of variations of the MIT license to the BSD license, as recommended by TLO. (I think we can "just do that", right? Or are there legacy things we need to consider?
  • Not care about the copyright years.
  • Remove the blurb about where the Athena source code was obtained from, since we _are_ the Athena source code.
  • For all packages that says "This Debian packaging has the same license as the original software", we license the packaging under BSD or GPLv2 (I don't care which, but we should pick one.)
  • E-mail all named individuals and ask them if they're ok with copyright being re-assigned to either "Debathena Project", "Student Information Processing Board", or "MIT" (at their discretion). If they don't respond, take no action (but keep poking them).
  • Update http://debathena.mit.edu/trac/wiki/Copyright to include the BSD license, the Debian packaging clause, etc.

Feedback on the bullet points above would be awesome.

comment:3 Changed 13 years ago by ghudson

I can't give an authoritative answer as to what to do with the years that appear in copyright notices. My own opinion is that copyright notices in source files doesn't accomplish much. The ASF doesn't use them, for instance, although they do have a per-package copyright notice in the NOTICE file, containing the year of the current release.

Here are links to the FSF and ASF policies if you want some totally conflicting advice by organizations with lawyers:

 http://www.gnu.org/licenses/gpl-howto.html
 http://www.apache.org/legal/src-headers.html

comment:4 in reply to: ↑ 2 Changed 13 years ago by kaduk

Replying to jdreed:

Since nobody but me has looked at this ticket, I propose the following:

  • Change all occurrences of variations of the MIT license to the BSD license, as recommended by TLO. (I think we can "just do that", right? Or are there legacy things we need to consider?

I don't know.

  • Not care about the copyright years.

Probably not worth worrying about, agreed. A range 200X-2011 would be concise.

  • Remove the blurb about where the Athena source code was obtained from, since we _are_ the Athena source code.

Sure.

  • For all packages that says "This Debian packaging has the same license as the original software", we license the packaging under BSD or GPLv2 (I don't care which, but we should pick one.)

BSD sounds fine :)

  • E-mail all named individuals and ask them if they're ok with copyright being re-assigned to either "Debathena Project", "Student Information Processing Board", or "MIT" (at their discretion). If they don't respond, take no action (but keep poking them).

I won't oppose this, but I'm not super-convinced it's necessary. We have lots of individuals' copyrights in FreeBSD sources, for example.

Sounds good

comment:5 Changed 13 years ago by ghudson

To be horribly pedantic, I would shy away from using a range of years in copyright notices. The FSF guidelines on copyright notices have some significant provisos on the use of ranges. Interestingly,  http://www.copyright.gov/circs/circ03.pdf says that "if the work is a derivative work or a compilation incorporating previously published
material, the year date of first publication of the derivative work or compilation is sufficient." So using the year of the last significant change (the last creation of a derivative work) sounds reasonable to me.

comment:6 Changed 13 years ago by jdreed

I'm going flip out and do this soon unless somebody tells me not to. To clarify, I will take the following action:

  • For anything currently licensed under the "MIT License" (which includes sipb-copyright.h and friends), change it to the BSD license.
    • Anything not under some variation of the MIT License will be left alone.
  • For anything that says "this Debian packaging has the same license as the original software", explicitly license the packaging under BSD.
  • Leave dates alone.
Last edited 12 years ago by jdreed (previous) (diff)

comment:7 Changed 13 years ago by jdreed

Right, ok, I have a better idea:

  • Not give a crap about existing copyright files.
  • Create a new boilerplate copyright file which uses the BSD license and explicitly licenses the packaging also under the BSD license, and use this going forward.

comment:8 Changed 13 years ago by andersk

Can we clarify for the record what you and/or the TLO mean by “BSD license”? There’s the 4-clause/original/obnoxious BSD license, the 3-clause/new/revised BSD license, and the 2-clause/FreeBSD/simplified BSD license. The 2-clause is most similar to the MIT/X11/Expat license, but I think “BSD license” with no qualifications means 3-clause to most of the world.

(I might have asked this on zephyr before.)

comment:9 Changed 13 years ago by jdreed

I have updated [Copyright]. I don't really care whether it's 2 or 3 clause. The TLO doesn't say, but I bet they also want 3-clause, because you can't use "MIT" to advertise anything.

comment:10 Changed 13 years ago by jdreed

comment:11 Changed 12 years ago by jdreed

Since this was originally written, Tim and Anders have in fact committed to printing-config's packaging: Tim in r23349 and Anders in r25144.

comment:12 Changed 12 years ago by jdreed

OK, I have looked at this. For explicit licenses in the text, we have:

  • The no-advertising version of the MIT License (/mit/jdreed/Public/license-1)
    • dns-config, network-manager-config, license-config, emacs-config, alpine-config, c-l-c, nmh-config, auto-update, cupsys-config, ntp-config, syslog-config, recovery-mode-config, email-icon-config, cluster-cups-config, reactivate, chrony-config, language-support, maybe-krb4-config, build-depends, maybe-ubufox, xsession, metrics, counterlog, nautilus-afs, larvnet, dotfiles, console, pidgin-wrapper, evolution-wrapper, tmp-cleaner, tex-extras, xlock, firefox-wrapper, olc, command-not-found, gconfd2-wrapper, locker-menu, clusterinfo, kiosk, misc-glue, moira-gui, transcript-glue
  • The "MIT License" as defined by the OSI (/mit/jdreed/Public/license-2) -base, tex-config, gconf2-config, thunderbird-config, fingerd-config, msmtp-config, tellme, apparmor-config, ldap-config, quota-config, moira-passwd-config, pam-config, zephyr-config, kerberos-config, upgrade-config, help-config, afs-config, shell-config, nsswitch-config, ssh-server-config, mutt-config, finger-config, printing-config, gdm-config, from-config, lprng-config, ssh-client-config, ssl-certificates, hesiod-config, the metapackages and thirdparty, athena-libraries, maybe-apparmor, extra-software, syslog, libpam-*, archive-keying, python-hesiod, python-moira, c-p-d example packages (but not cpd itself), pharos-support, libnss-afspag, aclocal, all of manual-config
  • 3-clause BSD: lightdm-config
  • LGPL 2.1: libnss-nonlocal,
  • GPL (no version specified, but it's 2): debathena-live
  • GPL 2: c-p-d, pyhesiodfs,

So, given this, I think we should stick with the plan of "Don't change existing copyrights, moving forward use the Copyright in Trac. Unless there's a compelling reason to update the ones using the ancient MIT license?

Can someone confirm the "real names" of the two licenses for which I provided samples?

comment:13 Changed 12 years ago by jdreed

  • Status changed from accepted to closed
  • Resolution set to fixed

OK, the samples I provided are various versions of the X/MIT license, and as previously mentioned, I'm not going to touch them. I think we're in a good state to move forward. The things which don't use BSD or some variation of MIT have compelling reasons to do so (nss-nonlocal, c-p-d, pyhesiodfs), and we don't actually use debathena-live anymore, but if we do, GPLv2 is fine. For MIT-only packages (that is, those only contributed to by employees), we can update to 3-clause BSD as needed, but I don't see a compelling reason to do so now.

comment:14 Changed 6 years ago by adehnert

FWIW,  SIPB's (nominal) license recommendation is MIT, MIT TLO doesn't actually differentiate between MIT and BSD, MIT is  about 10x more common than BSD 3-clause on Github, and  Github recommends MIT. I don't know if it makes sense to switch back to MIT (X11/Expat) for future development.

Note: See TracTickets for help on using tickets.