linux-kernel - Re: targetcli -fb now also Apache 2.0 licensed

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 24 Jul 2013 18:19:00 -0700
From:	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>
To:	Andy Grover <agrover@...hat.com>
Cc:	James Bottomley <James.Bottomley@...senPartnership.com>,
	target-devel <target-devel@...r.kernel.org>,
	linux-scsi <linux-scsi@...r.kernel.org>,
	Ritesh Raj Sarraf <rrs@...ian.org>,
	targetcli-fb-devel@...ts.fedorahosted.org,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: targetcli -fb now also Apache 2.0 licensed

On Wed, 2013-07-24 at 17:06 -0700, Andy Grover wrote:
> On 07/24/2013 01:54 PM, Nicholas A. Bellinger wrote:
> > Yes, which is why I've been accepting his kernel patches the entire time
> > that user-space has been forked into -fb.  Now that the user-space code
> > has been relicensed as promised, there is no longer any reason for a
> > separate -fb fork to exist.
> >
> > That said, it's time to start moving forward toward a single set of
> > source trees for upstream userspace, so that all distributions can
> > mutually benefit from the effort.  As mentioned above, this has so far
> > not been enough to get -fb reconciled with upstream.
> >
> > So I don't consider the above 'holding for ransom' or any nonsense like
> > that, considering the end goal is for everyone (not just Fedora) to
> > benefit from -fb.
> 
> There's nothing stopping any other distro (or commercial entity) from 
> adopting targetcli-fb. I don't know why they haven't, except that 
> there's a default attitude that the originator of the project is the 
> "upstream" forever.

Please stop trying to drive the split wider, and attempting to make
yourself upstream for something that you did not create.

You are responsible for this fork (and associated headaches) to begin
with.  Now that we have, as promised, relicensed this code, the time has
come to do the right thing for the wider community and push your changes
upstream.

Please read the following:

https://fedoraproject.org/wiki/Staying_close_to_upstream_projects

"The Fedora Project focuses, as much as possible, on not deviating from
upstream in the software it includes in the repository."

Don't you think this applies to you, too?

> 
> I think I've done a pretty good job maintaining -fb over the past two 
> years -- -fb has bug tracking, a list, tarballs, and is actively 
> maintained and improved, all things that are not true of upstream.
> 
> My question to you (Nick) is, why don't we all just unify on -fb?
> 

Because -fb has had close to zero peer review, and you've not solicited
much input (none from us) before making significant changes to
rtslib/targetcli over the past 1 1/2 years.

For your own private tree this wouldn't matter.  However, for a single
upstream tree moving forward, it seems irresponsible to just ask us to
sign off on every decision that you've made in -fb with little external
review or input.

So, to help us get back to a community development model, please cut a
-fb branch against upstream rtslib/configshell/targetcli, and start
sending the series out for public review.

--nab

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/