Re: DFSG violations in Lenny: new proposal
Debian project secretary
With a new option added to the list, the discussion period is
extended again, by a week, starting 10 Nov 2008 21:28:29.
The proposals, tentatively, as reproduced below.
|----------------------------------------------------+---+---+---+---+---|
| | 1 | 2 | 3 | 4 | 5 |
|----------------------------------------------------+---+---+---+---+---|
| Robert Millan <r...@aybabtu.com> | 1 | 1 | 1 | | |
| Bas Wijnen <wij...@debian.org> | 1 | | | | |
| Manoj Srivastava <sriv...@debian.org> | 1 | 1 | | | 1 |
| Holger Levsen <hol...@layer-acht.org> | 1 | 1 | 1 | 1 | |
| Peter Samuelson <pe...@p12n.org> | 1 | 1 | 1 | | |
| Hubert Chathi <uho...@debian.org | 1 | 1 | 1 | | |
| Andreas Barth <a...@not.so.argh.org> | | | | 1 | |
| Alexander Reichle-Schmehl <alex...@schmehl.info> | | | | 1 | |
| Reinhard Tartler <sire...@debian.org> | | | | | |
| Bernd Zeimetz <be...@bzed.de> | | | | 1 | |
| Neil McGovern <ne...@debian.org> | | | | 1 | 1 |
| Frans Pop <ele...@planet.nl> | | 1 | 1 | | |
| van...@debian.org (Rémi Vanicat) | 1 | 1 | 1 | 1 | |
| "John H. Robinson, IV" <jaq...@debian.org> | | | | | 1 |
| Lars Wirzenius <l...@liw.fi> | | | | | 1 |
| Damyan Ivanov <d...@debian.org> | | | | | 1 |
| Colin Tuckley <co...@tuckley.org> | | | | | 1 |
|----------------------------------------------------+---+---+---+---+---|
| | 7 | 7 | 6 | 6 | 6 |
|----------------------------------------------------+---+---+---+---+---|
#+TBLFM: $2=vsum(@2$2..@18$2)::$3=vsum(@2$3..@18$3)::$4=vsum(@2$4..@18$4)::$5=vsum(@2$5..@18$5)::$6=vsum(@2$6..@18$6)
,----[ Proposal 1: reaffirm the Social Contract ]
| 1. We affirm that our Priorities are our users and the free software
| community (Social Contract #4);
|
| 2. We acknowledge that we promised to deliver a 100% free operating system
| (Social Contract #1);
|
| 3. Given that we have known for two previous releases that we have
| non-free bits in various parts of Debian, and a lot of progress has
| been made, and we are almost to the point where we can provide a
| free version of the Debian operating system, we will delay the
| release of Lenny until such point that the work to free the operating
| system is complete (to the best of our knowledge as of 1 November 2008).
`----
,----[ Proposal 2: allow Lenny to release with proprietary firmware ]
| 1. We affirm that our Priorities are our users and the free software
| community (Social Contract #4);
|
| 2. We acknowledge that there is a lot of progress in the kernel firmware
| issue; most of the issues that were outstanding at the time of the
| last stable release have been sorted out. However, new issues in the
| kernel sources have cropped up fairly recently, and these new issues
| have not yet been addressed;
|
| 3. We assure the community that there will be no regressions in the
| progress made for freedom in the kernel distributed by Debian
| relative to the Etch release in Lenny (to the best of our knowledge
| as of 1 November 2008);
| 4. We give priority to the timely release of Lenny over sorting every
| bit out; for this reason, we will treat removal of sourceless
| firmware as a best-effort process, and deliver firmware as part of
| Debian Lenny as long as we are legally allowed to do so.
|
| (Since this option overrides the SC, I believe it would require 3:1
| majority)
`----
,----[ Proposal 3: (allow Lenny to release with DFSG violations ]
| 1. We affirm that our Priorities are our users and the free software
| community (Social Contract #4);
|
| 2. We acknowledge that there is a lot of progress on DFSG compliance
| issues; however, they are not yet finally sorted out;
|
| 3. We assure the community that there will be no regressions in the
| progress made for freedom in the packages distributed by Debian
| relative to the Etch release in Lenny (to the best of our knowledge
| as of 1 November 2008);
|
| 4. We give priority to the timely release of Lenny over sorting every
| bit out; for this reason, we will treat fixing of DFSG violations as
| a best-effort process.
|
| (Since this option overrides the SC, I believe it would require 3:1
| majority)
`----
,----[ Proposal 4: Allow release managers leeway to include non-dfsg bits as needed ]
| Debian's priorities are our users and free software. We don't trade
| them against each other. However during getting an release out of the
| door, decisions need to be done how to get a rock stable release of the
| high quality Debian is known for, release more or less on time, and to
| minimize the usage of problematic software. We acknowledge that there
| is more than just one minefield our core developers and the release
| team are working at.
|
| We as Developers at large continue to trust our release team to follow
| all these goals, and therefor encourage them to continue making
| case-by-case-decisions as they consider fit, and if necessary
| authorize these decisions.
|
| (Since this option overrides the SC, I believe it would require 3:1
| majority)
`----
,----[ Proposal 5: allow Lenny to release with firmware blobs ]
| 1. We affirm that our Priorities are our users and the free software
| community (Social Contract #4);
|
| 2. We acknowledge that there is a lot of progress in the kernel firmware
| issue; most of the issues that were outstanding at the time of the
| last stable release have been sorted out. However, new issues in the
| kernel sources have cropped up fairly recently, and these new issues
| have not yet been addressed;
|
| 3. We assure the community that there will be no regressions in the
| progress made for freedom in the kernel distributed by Debian
| relative to the Etch release in Lenny (to the best of our knowledge
| as of 1 November 2008);
| 4. We give priority to the timely release of Lenny over sorting every
| bit out; for this reason, we will treat removal of sourceless
| firmware as a best-effort process, and deliver firmware as part of
| Debian Lenny as long as we are legally allowed to do so, and the
| firmware is distributed upstream under a license that complies
| with the DFSG.
`----
manoj
--
Newlan's Truism: An "acceptable" level of unemployment means that the
government economist to whom it is acceptable still has a job.
Debian project secretary <secr...@debian.org>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Bernd Zeimetz
> | Reinhard Tartler <sire...@debian.org> | | | | | |
I think you've missed to count
<87d4hal...@faui44a.informatik.uni-erlangen.de>
here.
Cheers,
Bernd
--
Bernd Zeimetz Debian GNU/Linux Developer
GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
--
To UNSUBSCRIBE, email to debian-vo...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ben Hutchings
[...]
> ,----[ Proposal 2: allow Lenny to release with proprietary firmware ]
> | 4. We give priority to the timely release of Lenny over sorting every
> | bit out; for this reason, we will treat removal of sourceless
> | firmware as a best-effort process, and deliver firmware as part of
> | Debian Lenny as long as we are legally allowed to do so.
> |
> | (Since this option overrides the SC, I believe it would require 3:1
> | majority)
> `----
> ,----[ Proposal 5: allow Lenny to release with firmware blobs ]
> | 1. We affirm that our Priorities are our users and the free software
> | community (Social Contract #4);
> | 4. We give priority to the timely release of Lenny over sorting every
> | bit out; for this reason, we will treat removal of sourceless
> | firmware as a best-effort process, and deliver firmware as part of
> | Debian Lenny as long as we are legally allowed to do so, and the
> | firmware is distributed upstream under a license that complies
> | with the DFSG.
> `----
So far as I can see, the only significant difference between #5 and #2
(or #3) is the requirement that upstream distributes "under a license
that complies with the DFSG". But it is surely irrelevant whether the
licence text says we can modify the source when the copyright holder is
deliberately withholding the source. (Further, in some cases the
licence is GPLv2 which requires us to redistribute the source we don't
have - though thankfully there are only 1 or 2 such cases left.) So why
do you claim that #2 and #3 override the SC but #5 doesn't?
Ben.
Manoj Srivastava
> So far as I can see, the only significant difference between #5 and #2
> (or #3) is the requirement that upstream distributes "under a license
> that complies with the DFSG".
Yes. Without that clause, one can say we could ship something
like nvidia drivers in main -- since we are legally allowed to do so,
even though the license might be very non-free otherwise. That opens a
hole the size of a bus to let non-free code into Debian. That earned it
the "overrides the SC" label.
> But it is surely irrelevant whether the licence text says we can
> modify the source when the copyright holder is deliberately
> withholding the source. (Further, in some cases the licence is GPLv2
> which requires us to redistribute the source we don't have - though
> thankfully there are only 1 or 2 such cases left.)
How do you know the author is withholding the source? Yes, I
suspect they are, and I doubt that the blobs are the preferred form of
modification, but these are judgement calls, not proof. I mean, I have
written programs in hex in my time; the hex blob _was_ the source
code. One of these programs was even for a radio transmitter on a
breadboard.
All we are doing is is not throwing out code we suspect, but do
not know for a certainty, might violate the license it is distributed
under. Said license being DFSG free, though.
Yes, I feel slightly dirty doing so. Which is why I do not think
it fair for such decisions to fall to only some of us -- the whole
project should stand behind the decision to not confront potential GPL
violations in the kernel in order to release.
Post release, I would like to have kernel images based on your
work be the basis of the official kernel images, and would be willing
to put in the work required to make it so.
manoj
--
"No, no, I don't mind being called the smartest man in the world. I
just wish it wasn't this one." -- Adrian Veidt/Ozymandias, WATCHMEN
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Manoj Srivastava
This email is an excerpt from Sven Luther, sent via
private email. Ths is unedited, but incomplete, I have not included the
final paragraph of that email, since I could not defend posting that,
and this is what I am comfortable sending. The eliding the final
paragraph does not, in my opinion, detract from the content of the
message.
manoj
On Tue, Nov 11 2008, Sven Luther wrote:
> Hi Manoj,
>
> In order to avoid the mess that was the the etch vote, could you please
> clarify what exactly is meant by :
>
> and the firmware is distributed upstream under a license that
> complies with the DFSG.
>
> because this is subject to controversy, and i think we should avoid
> confusion at this point.
>
> Some may argue that it is enough for a binary-only firmware to be put
> under a source-less BSD-like license, and this is the kind of license
> that you mean here, but what is the fundamental difference between a
> blob which is issued of a BDS-like license where the license holder
> chose to do a binary-only release, and a firmware blob which has a
> distribution license not mentioning sources at all, like is the common
> case.
>
> Sure, you could say that the BSD is a free license, but there is
> absolutely no difference either practical or ideological, between these
> two cases, since in both cases the firmware blob is considered non-free
> by the DFSG.
>
> As such, it seems to me that the above sentences contradicts itself, and
> nullifies the rest of the proposal, which was already my critic
> concerning the etch vote.
>
> Could you thus clarify your thoughts, and give some example as to what
> you consider a firmware blob which could be distributed in main under
> your proposal, and another which could not.
> Please forward this mail to the mailing list, since i am being
> censored.
> Sven Luther
--
Capital Punishment: The income tax. --anonymous
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Ben Hutchings
> On Mon, Nov 10 2008, Ben Hutchings wrote:
>
> > So far as I can see, the only significant difference between #5 and #2
> > (or #3) is the requirement that upstream distributes "under a license
> > that complies with the DFSG".
>
> Yes. Without that clause, one can say we could ship something
> like nvidia drivers in main -- since we are legally allowed to do so,
> even though the license might be very non-free otherwise. That opens a
> hole the size of a bus to let non-free code into Debian. That earned it
> the "overrides the SC" label.
The nvidia drivers have never been in main, and AFAIK no-one claims they
are firmware.
> > But it is surely irrelevant whether the licence text says we can
> > modify the source when the copyright holder is deliberately
> > withholding the source. (Further, in some cases the licence is GPLv2
> > which requires us to redistribute the source we don't have - though
> > thankfully there are only 1 or 2 such cases left.)
>
> How do you know the author is withholding the source? Yes, I
> suspect they are, and I doubt that the blobs are the preferred form of
> modification, but these are judgement calls, not proof. I mean, I have
> written programs in hex in my time; the hex blob _was_ the source
> code. One of these programs was even for a radio transmitter on a
> breadboard.
But these are already DFSG-compliant and no resolution is required to
say so.
> All we are doing is is not throwing out code we suspect, but do
> not know for a certainty, might violate the license it is distributed
> under. Said license being DFSG free, though.
[...]
That's an even greater feat of double-think than is usual around
non-free.
Ben.
Manoj Srivastava
> On Tue, 2008-11-11 at 08:30 -0600, Manoj Srivastava wrote:
>> On Mon, Nov 10 2008, Ben Hutchings wrote:
>>
>> > So far as I can see, the only significant difference between #5 and #2
>> > (or #3) is the requirement that upstream distributes "under a license
>> > that complies with the DFSG".
>>
>> Yes. Without that clause, one can say we could ship something
>> like nvidia drivers in main -- since we are legally allowed to do so,
>> even though the license might be very non-free otherwise. That opens a
>> hole the size of a bus to let non-free code into Debian. That earned it
>> the "overrides the SC" label.
>
> The nvidia drivers have never been in main, and AFAIK no-one claims they
> are firmware.
I think you need a "dict like" about here.
>
>> > But it is surely irrelevant whether the licence text says we can
>> > modify the source when the copyright holder is deliberately
>> > withholding the source. (Further, in some cases the licence is GPLv2
>> > which requires us to redistribute the source we don't have - though
>> > thankfully there are only 1 or 2 such cases left.)
>>
>> How do you know the author is withholding the source? Yes, I
>> suspect they are, and I doubt that the blobs are the preferred form of
>> modification, but these are judgement calls, not proof. I mean, I have
>> written programs in hex in my time; the hex blob _was_ the source
>> code. One of these programs was even for a radio transmitter on a
>> breadboard.
>
> But these are already DFSG-compliant and no resolution is required to
> say so.
Umm. All the so called blobs would be fine in main if we were
convinced they were the preferred form of modification. Thing is, we
think they are not. We are not sure, but the chances are they are
not. So, the resolution is not to act on our gut, but to only act if we
have proof. We do not.
>
>> All we are doing is is not throwing out code we suspect, but do
>> not know for a certainty, might violate the license it is distributed
>> under. Said license being DFSG free, though.
> [...]
>
> That's an even greater feat of double-think than is usual around
> non-free.
If you have proof that the blobs are definitely not the
preferred form of modification, and thus are in violation ofthe
kernel's GPL, please present the proof, and not just to us, but to the
broader kernel community.
Until you have proof, do not engage in hyperbole like "feat of
double-think". It just showcases sloppy thinking.
manoj
--
Pushing 40 is exercise enough.
Manoj Srivastava
> On Tue, Nov 11, 2008 at 08:58:29PM -0600, Manoj Srivastava wrote:
>> > That's an even greater feat of double-think than is usual around
>> > non-free.
>>
>> If you have proof that the blobs are definitely not the
>> preferred form of modification, and thus are in violation ofthe
>> kernel's GPL, please present the proof, and not just to us, but to the
>> broader kernel community.
>
> The problem is that the kernel community mostly doesn't care, and when
> we approched them last time, they even replied quite agressively for us
> to point the finger to this.
I think that is ancient history. The upstream kernel community
is now taking steps to move firmware out into a separate git repo, so
we can not say that an uncaring upstream is an excuse.
> So, we are in the same situation, as other non-DFSG solution, as long as
> we don't prove that there is someone who cares, and someone with enough
> presence for this worry to be taken into account, and change things,
> people will just continue not-caring.
Again, this is not the case: Ben Hutching's work right now has
all the changes you are talking about. The question is the time taken
to assess the impact on other parts of Debian, but not that we do not
know how to make the changes.
> Please forward this, because i am being censored.
I have elided parts of the email that dealt with the Etch GR,
and the supposed flaws of that process that led us to the position we
are in no. I was not comfortable posting that here.
manoj
--
People love high ideals, but they got to be about 33-percent
plausible. Will Rogers
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org