Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id B67EA200C05 for ; Mon, 23 Jan 2017 22:58:25 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id B5395160B49; Mon, 23 Jan 2017 21:58:25 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 0918C160B3C for ; Mon, 23 Jan 2017 22:58:24 +0100 (CET) Received: (qmail 96073 invoked by uid 500); 23 Jan 2017 21:58:19 -0000 Mailing-List: contact dev-help@felix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@felix.apache.org Delivered-To: mailing list dev@felix.apache.org Received: (qmail 96048 invoked by uid 99); 23 Jan 2017 21:58:19 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 23 Jan 2017 21:58:19 +0000 Received: from mail-ot0-f177.google.com (mail-ot0-f177.google.com [74.125.82.177]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id EAAC51A06AA for ; Mon, 23 Jan 2017 21:58:18 +0000 (UTC) Received: by mail-ot0-f177.google.com with SMTP id 104so113378602otd.3 for ; Mon, 23 Jan 2017 13:58:18 -0800 (PST) X-Gm-Message-State: AIkVDXIwkcCi04SeyKVH8vMGZk2vKnKAuZVNhiV+476L58mWo4nYuEZBYK+23f+eaRU9i1U9HAapBjgCTd3FvQ== X-Received: by 10.157.57.201 with SMTP id y67mr14053487otb.1.1485208698203; Mon, 23 Jan 2017 13:58:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.129.50 with HTTP; Mon, 23 Jan 2017 13:57:57 -0800 (PST) In-Reply-To: <15f097f8-57b4-f467-041f-ca81ca7dbbd4@apache.org> References: <15f097f8-57b4-f467-041f-ca81ca7dbbd4@apache.org> From: Guillaume Nodet Date: Mon, 23 Jan 2017 22:57:57 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs To: dev@aries.apache.org, dev@felix.apache.org Content-Type: multipart/alternative; boundary=001a114072c8dfb68f0546ca1883 archived-at: Mon, 23 Jan 2017 21:58:25 -0000 --001a114072c8dfb68f0546ca1883 Content-Type: text/plain; charset=UTF-8 Right, we discussed that. My understanding is that we have 2 options: * either the API is committed first at Apache, in which case, it can't really be copyrighted to the OSGi Alliance * or it's copyrighted to the OSGi Alliance and it has to pre-exist the commit in our svn source tree If we choose #1, that's easy, we just have to remove the copyright on the APIs headers. If we go for #2, for specs that have been released, that's not a problem, they usually come from the released spec jar (and they usually are not even included in the source tree). For spec / rfcs under development, the only thing needed is to commit the api first in an osgi repository. For example: https://github.com/osgi/design/tree/master/rfcs/rfc-xxxx/api and then commit the same code referencing the commit in the above directory. If the above is not practical, it can be any github repo actually, even you own repo. From the moment is has been committed by you somewhere outside the ASF, the copyright can be granted to the OSGi in a clear way, so that if the github code / commit is referenced from out svn commit, we can track the IP correctly. I think an OSGi repository such as the one above would be better. The only thing is to avoid committing an API directly to the ASF and pretending it's copyrighted by the OSGi Alliance, because source committed to the ASF is by default supposed to be given a non-exclusive copyright license grant coming from the ICLA/CCLA. So I'm not sure what's wrong with the above, nor how that's practically impossible, not that it would prohibit any kind of development. 2017-01-23 22:28 GMT+01:00 Carsten Ziegeler : > Well, we discussed this in length last week, and as a matter of fact the > OSGi API which is under development is not available publically. So how > can we define a policy that is practically impossible? > This goes back to what I said several times last week, we can only > change our side (Apache) but we can't change the OSGi Alliance side. > > I think having a separate commit for the API and mentioning some > reference like the commit id or similar is a good idea. However, only > developers working for a member company of the OSGi Alliance can verify > this. But in practice, we have a lot of committers here being able to do > so, including Guillaume. > > Carsten > > Guillaume Nodet wrote > > As discussed on legal@ (see [1]), and in order to be able to track code > IP > > correctly, I propose that all commits that includes API code from the > OSGi > > Alliance are done in separate commit and include a reference to the > public > > source where the code comes from. > > > > Thoughts ? > > Guillaume > > > > [1] > > http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201701.mbox/% > 3cCAA66Tppc9Lp71ak4uoXsNZ8qzg+BNutYNTZspbt+z48dynumpg@mail.gmail.com%3e > > > > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziegeler@apache.org > -- ------------------------ Guillaume Nodet --001a114072c8dfb68f0546ca1883--