What is public/private fork? - Criteria packaging in fedora
mschwendt at gmail.com
Fri Dec 11 11:33:13 UTC 2009
On Fri, 11 Dec 2009 16:43:16 +0530, Rahul wrote:
> On 12/11/2009 04:38 PM, Michael Schwendt wrote:
> > On Fri, 11 Dec 2009 16:14:40 +0530, Rahul wrote:
> >> On 12/11/2009 03:56 PM, Florian Festi wrote:
> >>> Without knowing the history:
> >>> Best solution would be to ask former upstream for permission to continue
> >>> the project under its original name
> >> That was already denied
> >> https://lists.feep.net:8080/pipermail/libtar/2009-May/000259.html
> > Don't call it denial, though, because libtar is licensed under terms
> > similar to MIT/BSD (with no advertising clause) . This alone gives many
> > permissions. See the license text for the details.
> Sure but my comment has nothing to do with the license but the name of
> the project.
The author doesn't deny it, he only expressed a personal wish.
The license decides whether one may modify the project and distribute the
modified project ... and so on. Whether to do that in a src.rpm with
patches, in a private fork or in a public fork, is a different matter.
Interestingly, the author refers to the license as "BSD-style",
which is what matches my impression quoted above. Fedora's package
says "MIT", which isn't true. Another item for the review request.
> > The real reason not to use the "libtar" namespace for a fork are
> > others.
> If a upstream developer requests anyone not to use the same name for
> continuing maintenance of a project, then regardless of the license, it
> would only be polite not to do so setting aside everything else.
Here I agree.
Just changing the project name does not suffice, however, if files and API
and ABI conflict with the old project. Refer to my older bugzilla comment
for the details.
More information about the fedora-devel-list