Hi Nick,
I just wanted to let you know that I finally received permission from
all contributors, and have matched RisingTide's relicensing of targetcli
and its dependencies to Apache 2.0, by relicensing the additional
contributions in the targetcli-fb branch under the same license.
I'm not quite sure the next steps are, except enjoying all our newly
non-viral source code, but much thanks for getting the ball rolling.
Regards -- Andy
p.s. targetcli is the userspace tool to easily configure the 'LIO'
kernel target, in case any readers were wondering.
On Tue, 2013-07-23 at 23:27 -0700, Andy Grover wrote:
> Hi Nick,
>
> I just wanted to let you know that I finally received permission from
> all contributors, and have matched RisingTide's relicensing of targetcli
> and its dependencies to Apache 2.0, by relicensing the additional
> contributions in the targetcli-fb branch under the same license.
>
> I'm not quite sure the next steps are, except enjoying all our newly
> non-viral source code, but much thanks for getting the ball rolling.
>
Making this type of announcement without coordinating with us on a plan
for moving forward is pretty lame. Especially considering that we've
kept asking you privately about how to work together to reconcile -fb
with upstream, and your response essentially boiled down to "What's in
it for me..?".
So if you really, really need an incentive to "do the right thing", how
about I start not accept kernel patches from you until you're ready to
drop -fb and start working with upstream for real..?
--nab
On Wed, 2013-07-24 at 13:09 -0700, Nicholas A. Bellinger wrote:
> On Tue, 2013-07-23 at 23:27 -0700, Andy Grover wrote:
> > Hi Nick,
> >
> > I just wanted to let you know that I finally received permission from
> > all contributors, and have matched RisingTide's relicensing of targetcli
> > and its dependencies to Apache 2.0, by relicensing the additional
> > contributions in the targetcli-fb branch under the same license.
> >
> > I'm not quite sure the next steps are, except enjoying all our newly
> > non-viral source code, but much thanks for getting the ball rolling.
> >
>
> Making this type of announcement without coordinating with us on a plan
> for moving forward is pretty lame. Especially considering that we've
> kept asking you privately about how to work together to reconcile -fb
> with upstream, and your response essentially boiled down to "What's in
> it for me..?".
Oh good grief, children, how about you both play nicely in the sand box
or I'll fetch your parents to make you see sense.
> So if you really, really need an incentive to "do the right thing", how
> about I start not accept kernel patches from you until you're ready to
> drop -fb and start working with upstream for real..?
Well, the thing is, being a maintainer in Linux is a position of trust.
The fastest way to lose that trust is to hold your tree to ransom or
indeed refuse to accept patches for anything other than technical or
licensing reasons.
James
On Wed, 2013-07-24 at 13:21 -0700, James Bottomley wrote:
> On Wed, 2013-07-24 at 13:09 -0700, Nicholas A. Bellinger wrote:
> > On Tue, 2013-07-23 at 23:27 -0700, Andy Grover wrote:
> > > Hi Nick,
> > >
> > > I just wanted to let you know that I finally received permission from
> > > all contributors, and have matched RisingTide's relicensing of targetcli
> > > and its dependencies to Apache 2.0, by relicensing the additional
> > > contributions in the targetcli-fb branch under the same license.
> > >
> > > I'm not quite sure the next steps are, except enjoying all our newly
> > > non-viral source code, but much thanks for getting the ball rolling.
> > >
> >
> > Making this type of announcement without coordinating with us on a plan
> > for moving forward is pretty lame. Especially considering that we've
> > kept asking you privately about how to work together to reconcile -fb
> > with upstream, and your response essentially boiled down to "What's in
> > it for me..?".
>
> Oh good grief, children, how about you both play nicely in the sand box
> or I'll fetch your parents to make you see sense.
>
> > So if you really, really need an incentive to "do the right thing", how
> > about I start not accept kernel patches from you until you're ready to
> > drop -fb and start working with upstream for real..?
>
> Well, the thing is, being a maintainer in Linux is a position of trust.
> The fastest way to lose that trust is to hold your tree to ransom or
> indeed refuse to accept patches for anything other than technical or
> licensing reasons.
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.
--nab
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.
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?
Regards -- Andy
(at oscon this week, replies may be delayed)
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
On 07/24/2013 06:19 PM, Nicholas A. Bellinger wrote:
> 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.
Hi Nick,
It's one thing to claim a prerogative of "upstream", but for this to
make sense, there needs to be an actual community around the upstream.
And if there's going to be submissions for review, then there needs to
be someone in charge of the community with a high degree of skill in the
code base. Nick you have a great deal of technical expertise around the
C code in drivers/target, but Jerome was the one who wrote rtslib,
targetcli, and configshell. I believe you can assess the technical
aspects of how the user library interacts with the kernel code, but the
maintainer should also be extremely conversant in the language the
library is written in. In this case, Python. So it's not clear to me if
submitting the code would actually result in meaningful code improvements.
Also, there has been no effort to sustain a community around this code.
There is no bug tracking, no separate mailing list, no regular releases.
Debian is running ancient, broken code because nothing's been tagged in
over two years.
I would love to have you maintain and improve this code, but if you
aren't then you can't just say "I'm the upstream bow to me!". We're
shipping this code in Fedora and it needs active maintenance. Now that
we're all on an even licensing footing, code can flow both ways, and
even into your commercial version.
So, if you get a Pythonista to maintain upstream, and actually work to
build a community around it, then I will play ball. But I must ask you,
do you *really* want to maintain this? Forever? In a private thread a
while back, RTS CEO Marc said your company's value-add was in different
areas now. It might actually be easier for you to hire a Python person
to reconcile targetcli-fb with your commercial needs, and then just
track it. The objection I have with what you're asking me is that it
feels like you're trying to get me to do that reconciliation work for
you for free as a condition of being "upstream", and I'm not willing to
do work that benefits only your company and not the community at large.
Regards -- Andy
On Friday 26 July 2013 09:01 AM, Andy Grover wrote:
>
> It's one thing to claim a prerogative of "upstream", but for this to
> make sense, there needs to be an actual community around the upstream.
> And if there's going to be submissions for review, then there needs to
> be someone in charge of the community with a high degree of skill in
> the code base. Nick you have a great deal of technical expertise
> around the C code in drivers/target, but Jerome was the one who wrote
> rtslib, targetcli, and configshell. I believe you can assess the
> technical aspects of how the user library interacts with the kernel
> code, but the maintainer should also be extremely conversant in the
> language the library is written in. In this case, Python. So it's not
> clear to me if submitting the code would actually result in meaningful
> code improvements.
>
> Also, there has been no effort to sustain a community around this
> code. There is no bug tracking, no separate mailing list, no regular
> releases. Debian is running ancient, broken code because nothing's
> been tagged in over two years.
>
> I would love to have you maintain and improve this code, but if you
> aren't then you can't just say "I'm the upstream bow to me!". We're
> shipping this code in Fedora and it needs active maintenance. Now that
> we're all on an even licensing footing, code can flow both ways, and
> even into your commercial version.
Yes. Apart from reaching out the developers directly, I am not aware of
other communication channels. There is a git and wiki though.
Nick, if you guys have the same license now, nothing should stop you to
pull the changes from the targetcli-fb repo. You can start afresh now
and comply with what the community guidelines are. Licensing is just one
part of it.
And regarding this whole licensing dispute in the open, the kernel
maintainers should have resolved this long ago, when it was decided to
have LIO as the in-kernel target for Linux.
You might say that the target component complied by the kernel's
licensing requirements. But for a subsystem inclusion, you don't look
just at the code, but also the maintainer. Their support tools. And
their long term plans. These rules have been applied, in the past, for
other features in the kernel.
--
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
Ritesh,
We have put immense labor and love in creating LIO and targetcli. Please
just take a look at the code, the wiki, the manual, target-devel - we have
poured years of our lives into this project, and we look forward to
implementing many more exciting ideas. Asking us to just abandon this is -
simply absurd. Of course, we'll continue to maintain one coherent software
stack with extensive documentation (we'd love contributions here, too!)
and provide support for all of it through a well-known forum
(target-devel).
If Andy prefers not helping us to pull his few changes upstream, we'll
gladly just do it ourselves.
Best regards,
Marc Fleischmann
DATERA | 650.384.6366 | @dateranews
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Ritesh Raj Sarraf
Sent: Friday, July 26, 2013 12:24 AM
To: target-devel; linux-scsi
Cc: Andy Grover; Nicholas A. Bellinger; James Bottomley;
[email protected]; linux-kernel
Subject: Re: targetcli -fb now also Apache 2.0 licensed
On Friday 26 July 2013 09:01 AM, Andy Grover wrote:
>
> It's one thing to claim a prerogative of "upstream", but for this to
> make sense, there needs to be an actual community around the upstream.
> And if there's going to be submissions for review, then there needs to
> be someone in charge of the community with a high degree of skill in
> the code base. Nick you have a great deal of technical expertise
> around the C code in drivers/target, but Jerome was the one who wrote
> rtslib, targetcli, and configshell. I believe you can assess the
> technical aspects of how the user library interacts with the kernel
> code, but the maintainer should also be extremely conversant in the
> language the library is written in. In this case, Python. So it's not
> clear to me if submitting the code would actually result in meaningful
> code improvements.
>
> Also, there has been no effort to sustain a community around this
> code. There is no bug tracking, no separate mailing list, no regular
> releases. Debian is running ancient, broken code because nothing's
> been tagged in over two years.
>
> I would love to have you maintain and improve this code, but if you
> aren't then you can't just say "I'm the upstream bow to me!". We're
> shipping this code in Fedora and it needs active maintenance. Now that
> we're all on an even licensing footing, code can flow both ways, and
> even into your commercial version.
Yes. Apart from reaching out the developers directly, I am not aware of
other communication channels. There is a git and wiki though.
Nick, if you guys have the same license now, nothing should stop you to
pull the changes from the targetcli-fb repo. You can start afresh now and
comply with what the community guidelines are. Licensing is just one part
of it.
And regarding this whole licensing dispute in the open, the kernel
maintainers should have resolved this long ago, when it was decided to
have LIO as the in-kernel target for Linux.
You might say that the target component complied by the kernel's licensing
requirements. But for a subsystem inclusion, you don't look just at the
code, but also the maintainer. Their support tools. And their long term
plans. These rules have been applied, in the past, for other features in
the kernel.
--
Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal
Operating System