Re: How to make a Pagure Pull Request and How it is licensed by default for contributors outside of 'packagers' group ?
by Miro Hrončok
On 23. 03. 22 9:35, Vít Ondruch wrote:
>>
>> 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.
If that's the case, can we please stop enforcing the signed-off-by thing in
Fedora projects (such as various Fedora projects on Pagure or Bodhi on GitHub)?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 month, 3 weeks
How to make a Pagure Pull Request and How it is licensed by default for contributors outside of 'packagers' group ?
by Michal Schorm
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].
But I've run into practical questions of how contributions can be made
to the Fedora Project in the first place. Let's start with
contributions to Fedora Linux.
--
The first Google result for "Fedora pull request" query points to [2].
On the first glance it looks fine, but it has two major issues.
1/ The instructions won't work and are holey
2/ It is a page under a "Fedora CI" project.
1/
Nowadays, we have a way for contributors outside of the 'packager'
group to make pull requests. It is a git push via HTTPS [3].
Neither [2] nor [3] describes that you need to have a FAS account
first, since without it you can't log in the pagure to fork a project
(otherwise there's nowhere you can push to).
I wanted to propose an update, but ...
2/
... this leads to a belief that such an important piece of
documentation should be probably placed outside of the "Fedora CI"
project, as it can be generalized to any project.
What could be this better location for a new documentation page to
which other pieces of documentation would point to?
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 ?
3/ Are there any other ways to contribute to either Fedora Linux or
the Fedora Project, which face the similar issue ?
[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
--
1 month, 3 weeks
good/bad v. approved/not-approved
by Jilayne Lovejoy
Hi all,
As has been mentioned here prior, Richard and I are having a look at the
Licensing part of the Wiki with an eye towards any updates and
improvements, as well as moving that to the Fedora Docs (along with
David C's work on the database for the license info).
Recently Richard posted here regarding an attempt to better define the
Fedora license categories in terms of what constitutes a "good" license.
He referenced the use of the terminology of "good" and "bad" to indicate
whether a license is approved for use in Fedora or not.
I wanted to raise that separately b/c as we go through the
documentation, how to best explain things in the clearest way comes up.
It'd be helpful to hear people's views on this.
Historically - "good" has meant the license is approved for use in
Fedora; "bad" has meant the license is not approved for use in Fedora;
and then there are also three nuanced categories related to fonts,
documentation, and content which mean that certain licenses are only
approved for use in that context, but not otherwise approved.
How do people feel about the use of "good", "good-for-fonts", "bad", etc
to describe these categories? Would simply using "approved",
"approved-for-fonts", "not-approved", etc. be easier to understand?
I'll throw in my opinion here, since I'm asking for that of others: I'm
kind of mixed on this. I always thought the good/bad indicator was kind
of nice in it's informality. However, now that I'm looking more closely
at documentation, sometimes the use of good and bad can end up reading
oddly. Practically speaking, I think use of "approved" and
"not-approved" might end up being easier to understand. Good/bad also
also has a greater connotation of judgement versus simply "approved" -
which implies more closely that it must be approved for something. So, I
guess I'd lean towards simply using "approved" and "not-approved".
Given that "good" and "bad" are historical for the Fedora licensing
documentation - what are your thoughts on this?
Jilayne
2 months, 1 week
GFDL invariant sections question
by Jilayne Lovejoy
Hi all,
Fedora lists the GNU Free Documentation License as "good" for
documentation. the GFDL has this concept of "invariant sections" which
can be declared or not in the license header. If this is used, then it
creates some restrictions for those sections and there are some other
specific obligations in the license. (I'm not going to try to explain
this here, but if you are interested, this is probably a better summary
than trying to actually parse the text of the license
https://www.gnu.org/licenses/fdl-howto-opt.en.html)
Does any one know if GFDL is approved for Fedora regardless of if the
invariant section is triggered?
Thanks,
Jilayne
2 months, 2 weeks
Re: Package Licensing - Open Data Commons Open Database License (ODbL) License
by Justin Zobel
Ahh OK. Well, it would make sense to have a combined list. Hopefully,
someone on the Fedora side can give me the all OK to include the package
based on RHEL's inclusion policy.
And I just realised I hit reply instead of reply-all on the email again.
On Wed, Feb 16, 2022 at 8:55 AM Richard Fontana <rfontana(a)redhat.com> wrote:
> In theory, the Fedora list is the RHEL list, but some time ago Red Hat
> started supplementing it internally with another "list" (or compiled
> information) resulting from review of results of certain scanning
> tools on RHEL package source code. That "list" is not currently public
> information. Our current plan is to essentially merge the two license
> approval efforts so that there is one single public list of approved
> and unapproved licenses. But it will take some time to undertake the
> various steps for getting there.
>
> Richard
>
> On Tue, Feb 15, 2022 at 5:14 PM Justin Zobel <justin.zobel(a)gmail.com>
> wrote:
> >
> > Thank you Richard. Is there an "Accepted Licenses" page for RHEL?
> >
> > On Wed, Feb 16, 2022 at 4:40 AM Richard Fontana <rfontana(a)redhat.com>
> wrote:
> >>
> >> On Mon, Feb 14, 2022 at 9:52 PM Justin Zobel <justin.zobel(a)gmail.com>
> wrote:
> >> >
> >> > Thank you for these insights. Are you able to provide a link to the
> RHEL review of ODbL for the Fedora license team to refer to in their review
> process?
> >>
> >> Unfortunately in this case there really isn't anything to link to
> >> apart from a snarky comment by me about how lengthy the license is :-)
> >>
> >> Richard
> >>
> >>
> >>
> >> >
> >> > On Tue, Feb 15, 2022 at 11:52 AM Richard Fontana <rfontana(a)redhat.com>
> wrote:
> >> >>
> >> >> On Mon, Feb 14, 2022 at 6:49 PM Justin Zobel <justin.zobel(a)gmail.com>
> wrote:
> >> >> >
> >> >> > Hi Team,
> >> >> >
> >> >> > I've just begun packaging for Fedora and of course, I happen to
> choose one with a license that needs querying.
> >> >> >
> >> >> > The Open Data Commons Open Database License (ODbL) is for database
> usage in the kpublictransport KDE library. It is used for access to
> OpenStreetMap via the KTrip application designed to aid users in navigating
> via public transport.
> >> >> >
> >> >> > From the OpenStreetMap Copyright page on their website:
> >> >> > OpenStreetMap® is open data, licensed under the Open Data Commons
> Open Database License (ODbL) by the OpenStreetMap Foundation (OSMF).
> >> >> >
> >> >> > Open Database License: https://opendatacommons.org/licenses/odbl/
> >> >> > Open Street Map: https://www.openstreetmap.org/copyright
> >> >> > KDE Source Repository:
> https://invent.kde.org/libraries/kpublictransport/
> >> >> > Fedora Source Repository:
> https://src.fedoraproject.org/rpms/kpublictransport/
> >> >> >
> >> >> > I would like to know if this license is acceptable to Fedora.
> >> >>
> >> >> This is somewhat interesting as it is the first case I can think of
> >> >> where a license that Red Hat has specifically reviewed internally for
> >> >> inclusion in Red Hat Enterprise Linux has at a later time come up for
> >> >> a decision in Fedora.
> >> >>
> >> >> We actually approved ODBL for RHEL last year, and I think if we had
> >> >> our contemplated merging of RHEL license review and Fedora license
> >> >> review in place, it would just end up on the "good" list, but given
> >> >> that the new process is not yet established it would probably be a
> >> >> good idea to do another review now that it has come up for Fedora.
> >> >>
> >> >> Richard
> >> >>
> >>
>
>
> --
>
>
2 months, 2 weeks
