On Wed, Mar 23, 2022 at 9:36 AM Vít Ondruch <vondruch@xxxxxxxxxx> wrote: > Dne 22. 03. 22 v 19:18 Michal Schorm napsal(a): > > On Tue, Mar 22, 2022 at 7:06 PM Richard Fontana <rfontana@xxxxxxxxxx> wrote: > >> I would assert that the "unlicensed > >> contribution" scenario contemplated by the FPCA is actually going to > >> be fairly rare apart from the special case of spec files, which the > >> FPCA was particularly aimed at. In the typical case, a Fedora-related > >> project makes clear what the applicable license of a repository (or of > >> files within a repository) is/are, and under the "inbound=outbound" > >> convention, that will be understood to be the license of the > >> contribution. > > I've never heard about "inbound=outbound convention". > > I think you can get more information about this concept in Richard's > article: > > https://opensource.com/article/19/2/cla-problems What a great article ! That answers it to me. We don't need the contributors to sign the FPCA or any CLA. Thanks. Michal -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Wed, Mar 23, 2022 at 9:36 AM Vít Ondruch <vondruch@xxxxxxxxxx> wrote: > > > Dne 22. 03. 22 v 19:18 Michal Schorm napsal(a): > > On Tue, Mar 22, 2022 at 7:06 PM Richard Fontana <rfontana@xxxxxxxxxx> wrote: > >> I would assert that the "unlicensed > >> contribution" scenario contemplated by the FPCA is actually going to > >> be fairly rare apart from the special case of spec files, which the > >> FPCA was particularly aimed at. In the typical case, a Fedora-related > >> project makes clear what the applicable license of a repository (or of > >> files within a repository) is/are, and under the "inbound=outbound" > >> convention, that will be understood to be the license of the > >> contribution. > > I've never heard about "inbound=outbound convention". > > > I think you can get more information about this concept in Richard's > article: > > https://opensource.com/article/19/2/cla-problems > > > > > > I understand your answer as that: > > it is irrelevant whether the contributor specified the license (e.g. > > text "I submit this under GPL-2.0 license" in the pull request > > comment) > > > If somebody states license of the contribution, then it has to be > respected. Otherwise it is assumed that the contribution has similar > licensing conditions as the target project. > > > Vít > > > > > or whether none was specified, or whether the FPCA was > > accepted by the contributor; since every contributor to a code (let's > > say a single package repository) is always legally assumed to be under > > the license othe code of that package has, unless specified > > differently by the contributor. > > > > Is my understanding correct ? > > > > Michal > > > > -- > > > > Michal Schorm > > Software Engineer > > Core Services - Databases Team > > Red Hat > > > > -- > > > > On Tue, Mar 22, 2022 at 7:06 PM Richard Fontana <rfontana@xxxxxxxxxx> wrote: > >> On Tue, Mar 22, 2022 at 12:25 PM Michal Schorm <mschorm@xxxxxxxxxx> wrote: > >>> Hello, > >>> > >>> I'm trying to answer this question: > >>> "Under which license are the contributions done to Fedora Project, > >>> unless license is specified - and how make this clear to the > >>> contributors (or whether we make this clear enough)". > >>> The answer is _probably_ FPCA [1]. > >> The FPCA basically says that there's a particular default license that > >> applies in cases where the contribution is not "covered by explicit > >> licensing terms that are conspicuous and readily discernible to > >> recipients." This does not spell out what "explicit", "conspicuous" > >> and "readily discernible" actually mean, much as you haven't explained > >> what you mean by "specified". I would assert that the "unlicensed > >> contribution" scenario contemplated by the FPCA is actually going to > >> be fairly rare apart from the special case of spec files, which the > >> FPCA was particularly aimed at. In the typical case, a Fedora-related > >> project makes clear what the applicable license of a repository (or of > >> files within a repository) is/are, and under the "inbound=outbound" > >> convention, that will be understood to be the license of the > >> contribution. > >> > >> I'm not aware of any reason to make anything clearer that it currently > >> is. I think at this point the FPCA is sort of a historical curiosity > >> that lives on because of inertia (other than as an indirect statement > >> of licensing policy around certain special things like spec files but > >> those could be addressed in a different way). > >> > >>> And this HTTPS workflow leads back to my original question - since FAS > >>> users outside of 'packager' group AFAIK don't need to sign FPCA [1], > >>> but can contribute a code - under which license or agreement it is > >>> contributed ? If it is FPCA - are such contributors aware ? > >> If contributors haven't signed the FPCA, the FPCA doesn't apply to > >> their contributions. But this is most likely unproblematic, for much > >> the same reason that Fedora could abandon use of the FPCA altogether > >> without causing any significant problem. > >> > >> Richard > >> > >> > >>> [1] https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement > >>> [2] https://docs.fedoraproject.org/en-US/ci/pull-requests/ > >>> [3] https://fedoraproject.org/wiki/Infrastructure/HTTPS-commits > >>> > >>> -- > >>> > >>> Michal Schorm > >>> Software Engineer > >>> Core Services - Databases Team > >>> Red Hat > >>> > >>> -- > >>> _______________________________________________ > >>> legal mailing list -- legal@xxxxxxxxxxxxxxxxxxxxxxx > >>> To unsubscribe send an email to legal-leave@xxxxxxxxxxxxxxxxxxxxxxx > >>> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > >>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > >>> List Archives: https://lists.fedoraproject.org/archives/list/legal@xxxxxxxxxxxxxxxxxxxxxxx > >>> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > > _______________________________________________ > > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
