ARB legality checks

[Allison Randal]

This is one of the topics we discussed at UDS, with the conclusion that 
while we may not be quite as strict as Debian, we will follow most of 
their guidelines, as a well-tested procedure for ensuring that the 
software is legally distributable.

We're setting up a "Security Checklist" wiki page now, and may need a 
similar "Legal Checklist", so it's completely transparent what we're 
accepting and rejecting. (We might be able to refer to the 
PackagingGuide's Copyright content instead, will re-review with an eye 
to how straightforward it is to apply it to our process.)

Allison

On 11/16/2010 06:53 AM, Colin Watson wrote:
> Dear ARB members,
>
> I have an action from a few TB meetings ago to check that the legality
> checks applied by the ARB are in sync with those applied by
> ubuntu-archive.  The only information I can find on what the ARB does is
> here:
>
>    https://wiki.ubuntu.com/PostReleaseApps/Process
>
> which says:
>
>    Applications must be Open Source and available under an OSI approved
>    license.
>
> Admittedly, the ubuntu-archive documentation on this
> (https://wiki.ubuntu.com/ArchiveAdministration#NEW%20Processing) is none
> too clear either, but we do have a few links.  Here are the important
> checks we do over and above simply checking that the application is open
> source, summarised from
> https://wiki.ubuntu.com/PackagingGuide/Basic#Copyright and
> http://ftp-master.debian.org/REJECT-FAQ.html.
>
> These matter because there are situations of licence conflicts that can
> put us in violation of even open source licences if we get things wrong
> (violating the GPL *automatically* terminates your rights under it ...),
> so I do think the ARB should be aware of them.
>
> (I am not a lawyer and this is not legal advice.)
>
>    * It must be clear which licence applies to each source file.  (Some
>      ubuntu-archive people check whether there's a licence statement on
>      all files; my understanding is that a licence document that clearly
>      applies to the whole package is sufficient.)  This is probably a
>      subset of your existing checks, but we often find that a package has
>      the GPL at the top of it and then there are some other licences
>      hiding elsewhere, so do check.
>
>    * Files shipped under the GPL must be in their preferred form for
>      modification (e.g. no .swf files under the GPL without some other
>      source file).  Use suspicious-source from ubuntu-dev-tools to help.
>
>    * If the package uses the GPL or LGPL, it needs to say which
>      version(s).
>
>    * Copylefted files must only be linked with files which don't impose
>      any additional restrictions.  In practice the main situation where
>      this comes up is that you don't get to link GPLed files together
>      with OpenSSL, unless you have a special exception for all the GPLed
>      files.  Distributing the two alongside each other ("mere
>      aggregation") is OK.  If you're not sure how to tell the difference
>      (which can be tricky), ask - maybe ask a lawyer if in doubt.
>
>    * Be careful with different versions of the GPL and LGPL when packages
>      use libraries: not all combinations are OK.  For instance, you can't
>      use an LGPLv3 library from a GPLv2-only program, although if it uses
>      the "or later" clause it's OK.
>
>    * Many licences say that you aren't allowed to distribute the program
>      without the licence text (reasonably enough).  We make an exception
>      for things in /usr/share/common-licenses/ since we put those on
>      everyone's system, but otherwise the package needs to come with a
>      copy of the licence as well as simply saying which licence applies.
>
>    * I think we should probably ensure that the licence isn't specific to
>      us ("Canonical may ..." or "Ubuntu may ...").  My understanding is
>      that we want mirrors to be able to legally mirror all of
>      extras.ubuntu.com.
>
> I don't think, of course, that you need to be as strict as
> http://ftp-master.debian.org/REJECT-FAQ.html in general, nor do I think
> it's necessary to shove all of this in applicants' faces; most simple
> applications written by the applicant aren't likely to have a problem,
> and interpreted applications have a simpler time of it anyway since the
> "binaries" are transparent.  We just need to make sure we're on the same
> page regarding what source and (especially) binaries we're entitled to
> distribute.
>
> Comments?  Where would be a good place to record this kind of thing?
>
> Thanks,
>