targetcli -fb now also Apache 2.0 licensed
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.
Quoted 10 lines · Andy Grover
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
James Bottomley
maintainerQuoted 12 lines · Nicholas A. Bellinger
Quoted 10 lines · Andy Grover
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.
Quoted 5 lines
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.
Quoted 3 lines
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
Quoted 22 lines · James Bottomley
Quoted 12 lines · Nicholas A. Bellinger
Quoted 10 lines · Andy Grover
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.
Quoted 5 lines
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.
Quoted 8 lines
Quoted 3 lines
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
Quoted 5 lines · Nicholas A. Bellinger
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.
Quoted 8 lines
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)
Quoted 11 lines · Andy Grover
Quoted 10 lines · Nicholas A. Bellinger
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.
Quoted 8 lines
Quoted 3 lines
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?
Quoted 7 lines
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
Quoted 4 lines · Nicholas A. Bellinger
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.
Quoted 8 lines
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
Quoted 19 lines · Andy Grover
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.
Quoted 5 lines
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.
Signature · 2 lines
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
Quoted 19 lines · Andy Grover
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.
Quoted 5 lines
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