From legal-discuss-return-16327-archive-asf-public=cust-asf.ponee.io@apache.org Sun Jun 23 23:18:15 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 93C3A180679 for ; Mon, 24 Jun 2019 01:18:15 +0200 (CEST) Received: (qmail 94349 invoked by uid 500); 23 Jun 2019 23:18:14 -0000 Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: Reply-To: legal-discuss@apache.org List-Id: Delivered-To: mailing list legal-discuss@apache.org Received: (qmail 94333 invoked by uid 99); 23 Jun 2019 23:18:14 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 23 Jun 2019 23:18:14 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 425D51809DD for ; Sun, 23 Jun 2019 23:18:10 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.03 X-Spam-Level: * X-Spam-Status: No, score=1.03 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, KAM_ASCII_DIVIDERS=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=shaposhnik-org.20150623.gappssmtp.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id qXnpRnTTpJut for ; Sun, 23 Jun 2019 23:18:08 +0000 (UTC) Received: from mail-qt1-f194.google.com (mail-qt1-f194.google.com [209.85.160.194]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 230985F18F for ; Sun, 23 Jun 2019 23:18:08 +0000 (UTC) Received: by mail-qt1-f194.google.com with SMTP id m29so12696747qtu.1 for ; Sun, 23 Jun 2019 16:18:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shaposhnik-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=IQReb3Hoe3KAxILM5u0fGsqy7pC/bTbyPmNIvgATarE=; b=VKM35G4F9zxWuyRN5zBvqSwM5KNJCETFC+CEW9/jNpnRysmWk5gzhJBkyTDDViXluD SVDQUhM95hNfRocqFnWShKvmrzy/2EMtnlhKnoeOq0PrxnUkvdoD2m/XYkP870Cz01Uv kGhPpTSaStChdEn+04qyBN8j1mELhy5rKLcfsx28oydtxr2X3ymquFJ79T8O2hxdtBUr E90BeLXlMLqV5KrpDDrPLP93U3xY5akjAHk5jNxrlDX4Ww63KwXNBNPjb/Kn8NhCCTq8 q+kB8jizejxDtGXzhnkPK8rkRrP4k0xlFQgMp8/8gK5Ja1cACshgxVrMRpTSrOmw9+CV P2Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=IQReb3Hoe3KAxILM5u0fGsqy7pC/bTbyPmNIvgATarE=; b=oqRN82llf8GpypwfrvIUIn9PlahBdwQfYLZ0sNmURQLJKBprFpqnbJ9p6O7WBw2YJW v/Rg06JJsj3z/vYmTiOWfZQuxrTg0IchWRW6vsJNldmSGdbNYocnQnACvgWtpZWPDsCJ J6Q6lC3F901jzYiSf1uiAPnkTeQe7JRUOzuSRuubfPn0Ecf7sTiGx7R1kdGHYseXBrio X1NfmIjB/E3bCWy+l/PnxGhQ7hSbCKX/XWUrzYgkIiqvEziKWpPPT305SUFKtRlSKSs8 mSid5nE5Giox8wyzbLify5N2aquoW3fPsrHZFj52uk+rBaTQkmPV6w2CBbH8TBi/YNH+ mE2g== X-Gm-Message-State: APjAAAUxi2AbeOl6O3i5P02J2iK0+wVhDIpF6Xd6Y+ke1UD27WOZC1DB s+NQP1PZizgs3dk3JaR57uurIq6I5DtkONzdRPDz5LrR X-Google-Smtp-Source: APXvYqwHzOjrsqRVNtL+UgUo3uWg/kT9JyhV/ixdr57TR++f7GtUkKImld9cWFsWDLrQwWEvvlN12sfX7EFjZAJ64AA= X-Received: by 2002:ac8:d9:: with SMTP id d25mr96573458qtg.29.1561331887202; Sun, 23 Jun 2019 16:18:07 -0700 (PDT) MIME-Version: 1.0 References: <88CF9C64-24A3-457C-89E2-22A020C70F75@classsoftware.com> <21105FB4-D49F-41B8-8D94-B54240CEA0FC@classsoftware.com> <4C13C829-9481-4124-B802-8598C39B420E@gmail.com> In-Reply-To: <4C13C829-9481-4124-B802-8598C39B420E@gmail.com> From: Roman Shaposhnik Date: Sun, 23 Jun 2019 16:17:55 -0700 Message-ID: Subject: Re: Podling releases and ASF policy To: legal-discuss@apache.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Before I comments on this thread, I must point everybody to the thread that's going on over on general@incubator: https://lists.apache.org/thread.html/1a4c137100e76bedd3ed202874c8b8e30= 6c8990a439938d70b64ad54@%3Cgeneral.incubator.apache.org%3E With my VP Legal hat on (and with my Incubator IPMC hat off) the only way I can interpret that thread is this: IPMC is trying to come up with *business* decision on whether Incubator *itself* is a bonafide TLP producing multiple unrelated artifacts (not unheard of at ASF since something like Apache Commands does exactly that) or it is a special construct within the foundation. As a VP Legal I have no opinion one way or the other, but I must say that if the business decision is to treat it as a TPL when it comes to releases -- the rest of this discussion is moot: we can NOT allow any relaxation of the ASF release policy for a TLP. So I'll proceed commenting on the assumption that the business decision will lean towards treating Incubator as a special construct within the Foundation. On Fri, Jun 21, 2019 at 4:59 PM Craig Russell wrote: > > Hi Justin, > > I took an action item from this week's board meeting to work with Roman a= nd the IPMC to get clarity on the expectations of the board and legal for i= ncubator releases. > > I'm not sure that email is the best way to deal with this, but I'll refor= mat and re-post your earlier message in hopes that we can work on one list. > > Blocker: Must be fixed and then revote: > > - Missing DISCLAIMER > > - Missing LICENSE > > - Missing NOTICE > > - 3rd party Category X or Category B bundled code licenses not listed i= n LICENSE I would also add to it a new requirement of listing that bundled code in DISCLAIMER. In addition to that, if there are binaries bundled in the release the origin of those binaries also need to be DISCLAIMEd. > > - Missing both checksums and signatures[0] > > - Invalid/missing both checksums and signatures [0] > > Blocker: Must be fixed and then release: > > - Missing KEYS file [1] > > - Distribution not in the correct dist directory [1] > > - Invalid/missing signatures as long as checksum is ok [1] > > - Invalid/missing checksum as long as signature is ok [1] > > - SHA1 or MD5 checksum instead of SHA256 or SHA512 [1] > > Issue: Release then file a JIRA to fix before next release > > - Missing ASF headers > > - ASF headers missing or incorrect headers on files > > - 3rd party Category A bundled code licenses not listed in LICENSE > > - Included compiled code (which is Category A) > > - Included compiled code (which is Category B/X) [3] > > - Includes uncategorised source code [2] > > Minor Issue: Release then file a JIRA to fix before graduation > > - Includes Category X source code (or other files) [3] > > - Includes Category B source code (which makes it Category X) [3] > > - Includes content that they don=E2=80=99t have permission to distribut= e (copyright issue) This will have to be explained and under some conditions it may end up being a blocker. > > - Has Category X dependencies > > - Has uncategorised dependencies [2] > > - Extra information in NOTICE or LICENSE > > - Malformed NOTICE > > > [0] Without a proper checksum, no guarantee what was voted on. > > [1] Can be fixed right away without having to re-vote so not an issue > > [2] Depends on the license of included code/dependencies > > [3] Must be properly documented in LICENSE > > > Earlier comments from Hen: > > One premise that I think is assumed, but could do with stating, is that= no item should be included in a release if it was previously highlighted a= s a non-blocking issue in a previous release. I'm sure there are exceptiona= l items, but I expect them to be rare. > clr: some features of existing code might need several releases to compl= etely get rid of issues > > >> - Included compile code (which is Category B) > > > These would depend on the license and situation; I would worry about wh= ether the license allows it to be included in the release, whether it would= cause a typical user an unpleasant surprise, and whether it would affect t= he licensing of the core product > clr: as long as the code has its license in the LICENSE these can be reso= lved later > > >> - Includes Category B source code (which makes it Category X) > > > Cat B source code is a scenario that, while it's not Cat A or B (thus I= see your point about Cat X), I think it would usually be safe. Again I won= der if it is causing a typical user an unpleasant surprise and whether it a= ffects the licensing of the core product (typically unlikely). If we are ab= le to highlight the issue outside of the release (release notes for example= ), then I think the inclusion can be mitigated for users. > clr: as long as the code has its license in the LICENSE these can be reso= lved later > > >> There's a thread on the IPMC general list to improve the DISCLAIMER (t= ext to be decided) to make it clear that podling releases content may not b= e fully compliant with ASF policies. It also expected that podling document= s any issues found so people are aware of them and that they can be tracked= and fixed before graduation. > >> Note this would only apply to podling releases, not TLP ones. By the t= ime a podling graduated, their releases will follow all ASF policy. > > I don't see why we wouldn't treat TLP and Podlings the same. > clr: podlings releases need to be given additional time to resolve all th= e issues; TLPs have had plenty of time > > > Except for some people, who think that most things should be allowed, t= here seems to be general agreement in the IPMC on this list, except for all= owing compiled code or having a category X dependency in a podling release. > clr: this statement is a bit ambiguous > > > Votes on releases on the IPMC general list also confirm this. Some peop= le have expressed the view that as long as it is legal it is allowed, but i= t unclear if that means full compliance with 3rd party licenses or not. In = a few cases, things from this list have been allowed with permission from V= .P legal / V.P incubator. > clr: I think we all agree that getting special permission should be a las= t resort because by definition it delays a release > > > > The incubator wants to be more lenient on podling releases but is wary = of not following ASF policy that it doesn=E2=80=99t set. Does the legal com= mittee have any guidance on what could be allowed, from the above list in p= odling releases? Basically what parts of ASF policy can we safely ignore? > clr: my proposal is contained in the Issues and Minor Issues above. > > Please discuss, > > Craig > > > > Thanks, > > Justin > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org > > For additional commands, e-mail: legal-discuss-help@apache.org > > > > Craig L Russell > clr@apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org > For additional commands, e-mail: legal-discuss-help@apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org For additional commands, e-mail: legal-discuss-help@apache.org