AppDevUploadProcess Automatic reviews

[Scott Kitterman]

On Friday, September 07, 2012 03:55:54 PM David Planella wrote:
> Al 07/09/12 13:55, En/na Scott Kitterman ha escrit:
> > On Thursday, September 06, 2012 05:43:41 PM Michael Hall wrote:
> >> On 09/06/2012 05:07 PM, Scott Kitterman wrote:
> >>> On Thursday, September 06, 2012 04:00:25 PM Michael Hall wrote:
> >>>> Most of the conversation on the previous thread has been about package
> >>>> isolation, but I wanted to make sure the other topics in the spec were
> >>>> also being discussed.
> >>>> 
> >>>> One of our primary goals was to eliminate every bottleneck we could. 
> >>>> To
> >>>> that end we detailed a series of restrictions, sandboxing and automated
> >>>> checks that would allow us to trust that these application could not do
> >>>> any accidental harm to the user or the user's system.  Human
> >>>> intervention has always become a bottleneck, as man-hours are one
> >>>> resource we can't scale up as the need arises, so removing that from
> >>>> the
> >>>> process has been a key driver for this spec.
> >>>> 
> >>>> Besides package isolation, the other important method for protecting
> >>>> our
> >>>> users is with the mandatory use of an AppArmor profile.  We, together
> >>>> with the security team, have identified what additional work needs to
> >>>> be
> >>>> done to provide a trustworthy sandbox for applications, and ways of
> >>>> informing the user about what access they those applications will need.
> >>>> 
> >>>>  Furthermore the AppArmor profile itself will be generated on our
> >>>> 
> >>>> servers (MyApps) based on the developer's input, and incorporated into
> >>>> their package automatically.  This assures us that the profile is both
> >>>> correctly made and correctly installed, without the developer having to
> >>>> learn how to do it.
> >>>> 
> >>>> The only part of the spec that still uses a human review is in
> >>>> verifying
> >>>> the identity of the user (though some process yet to be determined).
> >>>> This is important because, as I mentioned above, the other parts of the
> >>>> spec are only intended to prevent accidental harm, not intentionally
> >>>> malicious code. We believe that verifying the identity of the uploader,
> >>>> so that it is not an anonymous relationship between the uploader and
> >>>> Ubuntu, should prevent intentional abuse on their part.  If there is a
> >>>> case of intentional abuse, we would be able to remove that app and
> >>>> prevent the submitter from using the system again.
> >>> 
> >>> Those parts of the spec seemed reasonable to me.  You'll have a hard
> >>> time
> >>> automating review of copyright/licensing information though.  Is there a
> >>> plan for that?
> >>> 
> >>> Scott K
> >> 
> >> No, the uploader must claim either ownership of the copyright or
> >> approval from those who do to distribute it via Ubuntu.  After that it
> >> is their responsibility to convey licensing information to their users.
> > 
> > It is not rare for free software projects to copy code from other projects
> > and reuse it if it has a compatible license (and sometimes when it
> > doesn't).  Does this mean that projects that reuse code from other
> > projects aren't eligible for this process?
> > 
> > Checking for proper documentation of licenses and copyright (even if it's
> > all one project/person) is the most labor intensive part of the New
> > package review process that Ubuntu archive administrators do.  It's also
> > the part that's critical from a legal perspective because it's how we
> > know that it is legal for Ubuntu (really Canonical and the Ubuntu mirror
> > partners) to distribute.
> > 
> > If someone checks a box and claims ownership, that doesn't mean they
> > really
> > have it nor does it mean that all the code is legally distributable, so
> > I'm
> > not sure what you mean when you say it's their responsibility.  It's still
> > Canonical doing the distribution.
> 
> Upon creation of an account in MyApps, the app developer needs to agree
> to the terms of service [1] (something that already happens today):
> 
> " The developer will also be required to agree to terms and conditions
> that will clearly outline what content is acceptable and unacceptable,
> and that the software can be removed if questionable, illegal, or
> infringing content is found. Once approved the developer will be
> provided with upload access for that specific application to extras. "
> 
> https://wiki.ubuntu.com/AppDevUploadProcess#How_App_Devs_Upload_Their_Apps
> 
> I am not a legal or copyright expert, so I cannot give an authoritative
> answer, but we do have an "Ask the legal team to check if the terms of
> service need any changes as a result of the new process" work item
> covered in the spec.
> 
> Cheers,
> David.
> 
> [1] https://myapps.developer.ubuntu.com/dev/tos/

The current goal for the Ubuntu archive is to prevent distribution of content 
which Canonical and the mirror providers don't have legal authorization to 
distribute.  Changing from a proactive verification model (which is what we use 
now, although it relies generally on self assertions in the code so it's 
imperfect) to a reactive model where code is considered distributable based on 
a third party assertion until someone complains seems like a very substantial 
change.

Even in the case where we just look at copyright/license information inside a 
package it is quite common to find situations where licensing changes are 
needed to make code legally distributable.  This is not because upstreams are 
malicious.  Sometimes they don't particularly care and in others they don't 
understand the licensing implications of some of the technical choices they 
make.

IANAL either, but this seems risky to me.  At the very least, I'd suggest 
engaging them early to make sure they are comfortable with the concept of not 
checking (new work item) and you'll need to figure out how you'll deal with 
take down requests (another new work item).  If it turns out applications have 
been distributed illegally, do you intend a way to remotely remove them?

Scott K