Debian Developers - The new Social Contract and releasing Sarge

Author

The new Social Contract and releasing Sarge

Jeroen van Wolffelaar

2004-04-27, 10:34 pm

[ note: resent due to typo in debian-devel adress. The original went to
-vote and -release. Please reply to the original to not break
threading. ]

[ Please respect the Mail-Followup-To header, and reply to -vote. I will
inform debian-devel and debian-release regularly with updates and new
arguments in a concise and hopefully balanced way ]

Dear developers,

As was seen in another thread[1], the recent change to the Social Contract
also influences the release-policy of Sarge.

I see a lot of discussion about the Social Contract change, people are
calling for revote, there are accusations towards both sides. In any
case, things are quite subtle and not black/white, and some people think
there was insufficient information and inadequate discussion highlighting
all sides of the story.

But, as you might have noticed, the rage on debian-devel did _not_ start
when the result of the vote was announced. Rather, it was started
because of the implications Anthony Towns drew of the result of the
vote. I believe, and my talks with numerous DD's have stengthen me in my
belief, that many developers believed that the policy on ignoring
certain problems in Sarge (the sarge-ignore policy) was a practical
decision for the sake of releasing Sarge in the forseeable future. Those
who thought that the old SC basically said the same as it does now, did
for the most part excuse the RM's decision on this: it was not
practically viable to f.e. move GFDL-docs to non-free before Sarge was
released.

It now turns out that Anthony Towns based his sarge-ignore policy on his
reading of the Social Contract. I think quite some DD's would like to
release Sarge soon, even though it might still have some problems. This
wish is mostly pragmatic:

If Sarge, which is already long overdue, is to be released fully conform
the SC, a lot of extra work would still need to happen, amongst
others the d-i support for non-free. Stalling the release also has a
very negative impact on d-i itself[2][3], and people are going to try to
get in a lot of new upstream stuff, etc etc, while currently, Sarge is
well on its way to be released relatively soon.

Also note the situation of woody, which doesn't conform to the new
(reading of the old, according to some) SC either. Stopping to
distribute it would not be in the interest of our users - it would also
mean stopping security support.

I therefore propose a GR which explicitely excuses Sarge from some
issues, something that previously was already done by the Release
Manager on his own. There are basicaly two approaches to this, one is to
amend the Social Contract to explicitely say so, the other is to merely
pass a GR excusing Sarge from the SC. Please see
http://www.wolffelaar.nl/~jeroen/gr...se_sarge_gr.txt (included
below) for a current draft of this GR. I want to include concisely and
to the point the arguments for each side of the case on the GR itself,
so that voters can make a well-informed decision even if they do not
wish to follow this whole discussion. I would like to get the mentioned
text integral on the ballot for the advantage of all voters, also those
who wish to not fully follow the discussion. I therefore promise to
include any argument in the document if it gets at least 3 DD's
seconding it (unless my promise is abused, to my own descretion), or
when I myself am convinced it is a valid argument.

Note that I also added two options, A and B, which partly or fully revert the
decision made in the last GR. While I didn't intially want to put those
options on the draft ballot, I've still done so because of popular demand, and
they would have been added anyway otherwise.

The ballot is now quite full, once it is time for seconds (not yet, let's
first discuss), maybe some options will fail to get five seconds, so they are
dropped. If all get enough seconds, well, this is what the voting system is
designed to handle: a very broad spectrum of opinions, and still a good method
to determine the best option for everyone.

Procedural note: Since I'm not a Debian Developer, I guess some Debian
Developer would in addition need to officially propose any of the options.

W.r.t. Steve Langasek's proposal, it is quite close, but not the same as
the option C figurating in this mail. It is about either revert the SC
temporarily, also with fixed deadline (Steve's variant), or note in the
SC itself that it will only apply from a later date.

The actual text of the current draft:

========================================
===========================

This draft lists 6 options, ranging from completely going back to the previous
version, to keeping the current one and applying it to Sarge, with some
gradational-option in between:

A: The recent Social Contract change is reverted
B: The Social Contract is changed to apply to software+documentation only
C: A clause is added to the Social Contract stating it will be effective
starting just after Sarge is released
D: Social Contract is left alone, but a GR is passed stating Sarge can be
released with GFDL docs and binary firmware
E: Social Contract is left alone, but a GR is passed stating Sarge can be
released with binary firmware
F: Social Contract is left alone, and Sarge will fully abide by it
G: Further Discussion

| Sarge | Sarge++ |
----------------------+-------+---------+
DFSG to software only | ABCD* | A |
DFSG to sw + docs | E* | B |
DFSG to all data | F | CDEF |

* D and E for Sarge will be a GR excemption, not backed by the Social Contract

Option A:

| It is decided that the Social Contract is to be replaced with version 1.0of
| the Social Contract, which was ratified July 5, 1997
|
| Or, this option could read that the Social Contract is changed to reflect
| the view that the DFSG only applies to software, and not to documentationand
| other data.
|
| Firmware is considered data.

Rationale:
- The Social Contract is changed towards the strict view that DFSG only applies
to software, and to nothing else, because that's what the DFSG is intended
to cover. It makes not much sense to have DFSG cover documentation and other
data too

Option B:

| It is decided that the Social Contract is to be replaced with a version
| emphasizing that the DFSG applies to software and documentation, but not
| to other data like fonts, images, and the like. It is also added that the
| requirements for documentation only are effective after the release of Sarge.
|
| Firmware is considered data.

Rationale:
- For practical reasons, the new meaning of the Social Contract (new w.r.t.
the July 5, 1997 edition) only starts to apply after Sarge is released.
- ...

Option C:

| It is decided that the Social Contract is to be amended as follows:
|
| Clause one of the Social Contract, currently reading:
|
| > Debian will remain 100% free
| >
| > We provide the guidelines that we use to determine if a work is "free" in the
| > document entitled "The Debian Free Software Guidelines". We promise that the
| > Debian system and all its components will be free according to these
| > guidelines. We will support people who create or use both free and non-free
| > works on Debian. We will never make the system require the use of a non-free
| > component.
|
| shall have this text appended:
|
| > We apologize that the current state of some of our documentation and
| > kernel drivers does not live up to this part of our Social Contract. While
| > Sarge will not meet this standard in those areas, we promise to rectify
| > this in the following release.
|
| resulting in the new Clause one of the Social contract being as follows:
|
| > Debian will remain 100% free
| >
| > We provide the guidelines that we use to determine if a work is "free" in the
| > document entitled "The Debian Free Software Guidelines". We promise that the
| > Debian system and all its components will be free according to these
| > guidelines. We will support people who create or use both free and non-free
| > works on Debian. We will never make the system require the use of a non-free
| > component.
| >
| > We apologize that the current state of some of our documentation and
| > kernel drivers does not live up to this part of our Social Contract. While
| > Debian 3.1 will not meet this standard in those areas, we promise to rectify
| > this in the following release.
|
| It is still tried to implement the new Social Contract as good as possible,
| but where that is not easily possible, for example where significant changes
| to the Debian Installer are needed to accomodate users who require some
| sorts of firmware during installation even though that is in non-free, are
| not done before Sarge is released.

Rationale:
- Woody is also DFSG-buggy as above, delaying Sarge will also mean that our
current stable system violates the DFSG like we want eventually to prevent.
- Delaying Sarge will cause more users to think about a switch to other
distributions that will not delay a release for a very long time
merely because some problem that exists for many many years was just
recently decided to be release-critical, even though the current stand of
affairs is that there is a long time to go to fix it.
- Having a release which might require non-free for even booting the
installation media, will require additional work to ensure this is working
smoothly, something that cannot be done in a reasonable timeframe.
- It is very unproductive w.r.t. the recent talks with the FSF to get to an
agreement about the GFDL if Debian would mid-conversation drop GFDL from
main. It probably nullifies any chance to have a fruitfull discussion with
the FSF.
- Releasing Sarge without adequate documentation in the default install is not
wise and user-friendly.

Option D:

| It is decided to release Sarge when it's ready, even though it might still
| contain DFSG-related bugs of the classes (and only of the classes):
|
| - It contains GFDL documents
| - It contains binary firmware
|
| But DFSG-related bugs like:
|
| - Package is under a non-free license (excempting GFDL)
| - Package has no license
| - Package cannot be distributed
|
| are still considered release-critical
|
| This resolution has no effect on releases after Sarge

Rationale: as Option C, and in addition:
- The Social Contract will not changed by this option, which would be quite
inconsequent, but rather it is clarified that implementing the new version
of the Social Contract for the upcoming release is not an currently
achievable goal, and that a delay in implementing is only a natural.
- Only the wording of the SC has changed, the meaning has not. It was always
meant to say what it says now, and release management has decided to ignore
particular classes of violations for the sake of releasing Sarge. It was
agreed by consensus that this was ignored before, so it should be ignored
for Sarge also at this moment.

Con:
- Anthony Towns has stated that he wishes to not violate the Social Contract
releasing Sarge, even if a GR like this one is passed allowing him to do so.

Option E:

| It is decided to release Sarge when it's ready, even though it might still
| contain DFSG-related bugs of the class (and only of the class):
|
| - It contains binary firmware
|
| But DFSG-related bugs like:
| - It contains GFDL documents
| - Package is under a non-free license (excempting GFDL)
| - Package has no license
| - Package cannot be distributed are still considered Release Critical.
| are still considered release-critical
|
| This resolution has no effect on releases after Sarge

Rationale:

As option C, but:
- The Social Contract is not changed, which would be quite inconsequent, but
rather it is clarified that implementing the new version of the Social
Contract for the upcoming release is not an currently achievable goal, and
that a delay in implementing is only a natural.
- Considering the recent vote there is no reason to release Sarge with GFDL
documents in main.
- Documentation can easily be moved: no software depends on documentation, a
move of documentation from main to non-free should not be very hard to do,
and thus not delay the release of Sarge too much (unlike the binary firmware
issues). If one puts non-free in one's sources.list, there will be no
difference for the user.

Con:
- Anthony Towns has stated that he wishes to not violate the Social Contract
releasing Sarge, even if a GR like this one is passed allowing him to do so.

Option F:

| It is decided to release Sarge when it's ready, which includes that Sarge
| must not violate the DFSG in any way.
|
| This means that DFSG bugs like:
|
| - It contains binary firmware
| - It contains GFDL documents
|
| are also considered release-critical

This option serves as an explicit option for those who believe Sarge shouldbe
released only after it has fully be cleaned of GFDL documents and sourceless
binary firmware.

Rationale:
- Considering the recent vote there is no reason to release Sarge with GFDL
documents or sourceless binary firmware in main

Option G:

| Further discussion

========================================
===========================

I'd like to thank the following people who provided valuable feedback to
me in the past 1.5 day while I was preparing this document:
- Colin Watson
- Anthony Towns
- Pascal Hakim
- Scott James Remnant
- Frank Kuester
- Marc Brockschmidt
- Andreas Barth

And the following people who are supporting me in this effort:
- Colin Watson
- Pascal Hakim
- Norbert Tretkowski
- Frank Lichtenheld
- Christian Perrier
- Frank Kuester
- Andreas Barth
- Marc Brockschmidt

Thanks for considering this,

--Jeroen

[1] http://lists.debian.org/debian-deve...4/msg03857.html
[2] http://lists.debian.org/debian-deve...4/msg04006.html
[3] http://lists.debian.org/debian-deve...4/msg04112.html

--
Jeroen van Wolffelaar
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl

Jamin W. Collins

2004-04-28, 2:33 am

On Wed, Apr 28, 2004 at 04:20:53AM +0200, Jeroen van Wolffelaar wrote:
>
> But, as you might have noticed, the rage on debian-devel did _not_ start
> when the result of the vote was announced. Rather, it was started
> because of the implications Anthony Towns drew of the result of the
> vote. I believe, and my talks with numerous DD's have stengthen me in my
> belief, that many developers believed that the policy on ignoring
> certain problems in Sarge (the sarge-ignore policy) was a practical
> decision for the sake of releasing Sarge in the forseeable future. Those
> who thought that the old SC basically said the same as it does now, did
> for the most part excuse the RM's decision on this: it was not
> practically viable to f.e. move GFDL-docs to non-free before Sarge was
> released.

In many cases there was more than enough time to do something about
them. A search of the BTS for the sarge-ignore tag shows that most (all
but 2) listed bug reports are over 200 days old, more than enough time
to do something about them. Granted this is but a cursory glance at
these tickets.

> If Sarge, which is already long overdue, is to be released fully conform
> the SC, a lot of extra work would still need to happen,

A good deal of which should have already been done regardless of the
sarge-ignore tag.

--
Jamin W. Collins

Remember, root always has a loaded gun. Don't run around with it unless
you absolutely need it. -- Vineet Kumar

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Frank Küster

2004-04-28, 12:34 pm

Jamin W. Collins

2004-04-28, 7:34 pm

On Wed, Apr 28, 2004 at 04:43:09PM +0200, Frank K?ster wrote:
> "Jamin W. Collins" <jcollins@asgardsrealm.net> schrieb:
>
> Of course there would have been time.

Would have been time? There _was_ time, over 200 days in most cases. If
the necessary change couldn't be made in 6+ months, how much longer should
it be given?

> But instead of removing them, the
> better thing would be to relicense them, or to change the GFDL. Many
> people hoped, and still hope, that the negotiations with the FSF will
> lead to some action in that direction.

In the meantime, they _are_ violations of the DFSG and should be _fully_
treated as such. If that means removing their current versions from
main, so be it. If instead the parts in violation are removed, so be
it. They can be added/moved back when the violation is resolved.

--
Jamin W. Collins

It has always been Debian's philosophy in the past to stick to what
makes sense, regardless of what crack the rest of the universe is
smoking. -- Andrew Suffield

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Colin Watson

2004-04-28, 10:33 pm

On Wed, Apr 28, 2004 at 01:55:30PM -0600, Jamin W. Collins wrote:
> On Wed, Apr 28, 2004 at 04:43:09PM +0200, Frank Küster wrote:
>
> Would have been time? There _was_ time, over 200 days in most cases.
> If the necessary change couldn't be made in 6+ months, how much longer
> should it be given?

Sometimes the change has some other detrimental effect, and therefore
maintainers may have chosen not to make them unless they have to. For
instance, fixing #211640 requires me to change openssh_*.orig.tar.gz so
that it no longer matches the GPG signature distributed alongside the
OpenSSH source distribution by its developers, which for a piece of
security-critical infrastructure I feel would be a great shame. (I
suppose I should at least remove that document from the binary package,
though; in fact, I've just done that in CVS.)

--
Colin Watson [cjwatson@flatline.org.uk]

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Jamin W. Collins

2004-04-29, 1:33 am

On Thu, Apr 29, 2004 at 01:11:18AM +0100, Colin Watson wrote:
> On Wed, Apr 28, 2004 at 01:55:30PM -0600, Jamin W. Collins wrote:
>
> Sometimes the change has some other detrimental effect, and therefore
> maintainers may have chosen not to make them unless they have to.

Maybe we see things differently, but from my point of view, the
maintainers have known for quite a while that they did have to change
things. Sure, it may have been possible to interpret the previous SC's
wording so this was a grey area. Not specifically prohibited, but the
mere fact that these items were marked as sarge-ignore shows that they
were recognized as a problem, and one that did need to be resolved.
Letting these items sit without corrective action being taken/started
for 200+ days hoping that something would be done externally directly
lead to part of the situation we now find ourselves in (I am in no way
saying this was the intent of the recent GR). Had work been done on
these packages from the beginning, regardless of the sarge-ignore tags,
we wouldn't be in such a bind.

Just because a specific class of problem is given a temporary stay of
action doesn't mean the developer's responsible for the packages
shouldn't have taken the initiative to make corrective changes anyway.

> For instance, fixing #211640 requires me to change
> openssh_*.orig.tar.gz so that it no longer matches the GPG signature
> distributed alongside the OpenSSH source distribution by its
> developers, which for a piece of security-critical infrastructure I
> feel would be a great shame. (I suppose I should at least remove that
> document from the binary package, though; in fact, I've just done that
> in CVS.)

Was this not a problem that would have needed to be addressed after the
sarge release anyway? If so, why postpone it? In the hopes sarge was
released soon? That shouldn't have stopped the developer's from working
to correct their packages in the meantime.

I'm not sure that the above change in anyway corrects the actual problem
since the orig.tar.gz contains non-free items, and thus should not be in
main.

--
Jamin W. Collins

To be nobody but yourself when the whole world is trying it's best night
and day to make you everybody else is to fight the hardest battle any
human being will fight. -- E.E. Cummings

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Mark Brown

2004-04-29, 7:33 am

On Wed, Apr 28, 2004 at 11:28:34PM -0600, Jamin W. Collins wrote:

> Letting these items sit without corrective action being taken/started
> for 200+ days hoping that something would be done externally directly
> lead to part of the situation we now find ourselves in (I am in no way
> saying this was the intent of the recent GR). Had work been done on
> these packages from the beginning, regardless of the sarge-ignore tags,
> we wouldn't be in such a bind.

For those packages where the problem is the GFDL (which from what I
gather seems to be a reasonable chink of them) I'd say that the work
Mako and others are doing with the FSF is constructive work on resolving
the issue. You may question the results but I don't think it's fair to
say the problem is being completely ignored.

> Was this not a problem that would have needed to be addressed after the
> sarge release anyway? If so, why postpone it? In the hopes sarge was
> released soon? That shouldn't have stopped the developer's from working
> to correct their packages in the meantime.

There's also the usefulness issue to consider - clearly, the best way
out of this problem is to get all the things we want to release licensed
under a free license but that's obviously not the case at present.
Given that situation deciding to keep the documentation for the time
being in the hope that a more constructive solution can be found seems
like a perfectly sensible situation.

--
"You grabbed my hand and we fell into it, like a daydream - or a fever."

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Frank Küster

2004-04-29, 8:34 am

"Jamin W. Collins" <jcollins@asgardsrealm.net> schrieb:

> On Thu, Apr 29, 2004 at 01:11:18AM +0100, Colin Watson wrote:
>
> Maybe we see things differently, but from my point of view, the
> maintainers have known for quite a while that they did have to change
> things.=20=20

One option of changing things would be to convince the FSF that the
current GFDL is not free, and to create a better version and aks
upstreams to "upgrade" to that one.

> Was this not a problem that would have needed to be addressed after the
> sarge release anyway? If so, why postpone it? In the hopes sarge was
> released soon? That shouldn't have stopped the developer's from working
> to correct their packages in the meantime.

In the FSF case, many people thought that waiting, moving flamewars to
other issues, and letting our representatives talk to the FSF would be
the best way of "working".

Regards, Frank
--=20
Frank K=FCster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie

Jamin W. Collins

2004-04-29, 11:34 am

On Thu, Apr 29, 2004 at 11:46:06AM +0100, Mark Brown wrote:
> On Wed, Apr 28, 2004 at 11:28:34PM -0600, Jamin W. Collins wrote:
>
>
> For those packages where the problem is the GFDL (which from what I
> gather seems to be a reasonable chink of them) I'd say that the work
> Mako and others are doing with the FSF is constructive work on
> resolving the issue. You may question the results but I don't think
> it's fair to say the problem is being completely ignored.

Unless the authors of these packages were directly involved in the
attempts to correct these issues, yes they were being ignored. Granted
the talks with the FSF _may_ result in a change to the GFDL that makes
it DFSG free. However, in the meantime the problem continues to exist
in our archives. The developers could have made the necessary changes
to their package (construction or location) to resolve the problem and
then reverted those changes later. Would this have required time, sure.
Did they have this time, sure.

>
> There's also the usefulness issue to consider

Only so far as we do not violate any of our guiding documents. There
are many useful items that we can not distribute for one reason or
another.

> clearly, the best way out of this problem is to get all the things we
> want to release licensed under a free license but that's obviously not
> the case at present.

I agree.

> Given that situation deciding to keep the documentation for the time
> being in the hope that a more constructive solution can be found seems
> like a perfectly sensible situation.

Don't agree with this. Work should have been done to correct the
packages in the interrum.

--
Jamin W. Collins

"Never underestimate the power of very stupid people in large groups."
-- John Kenneth Galbraith

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Jamin W. Collins

2004-04-29, 11:34 am

On Thu, Apr 29, 2004 at 01:29:08PM +0200, Frank K?ster wrote:
> "Jamin W. Collins" <jcollins@asgardsrealm.net> schrieb:
>
> One option of changing things would be to convince the FSF that the
> current GFDL is not free, and to create a better version and aks
> upstreams to "upgrade" to that one.

And in the interrum the packages could have been modified to resolve the
violations in the current state of things and reverted when/if the
discussions with the FSF succeeded.

> In the FSF case, many people thought that waiting, moving flamewars to
> other issues, and letting our representatives talk to the FSF would be
> the best way of "working".

And we have a specific delegation to continue these talks. In the
meantime, the packages could have been updated/corrected.

--
Jamin W. Collins

Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Andreas Metzler

2004-04-29, 12:34 pm

Jamin W. Collins <jcollins@asgardsrealm.net> wrote:
> On Thu, Apr 29, 2004 at 11:46:06AM +0100, Mark Brown wrote:
[...]
[vbcol=seagreen]
> Unless the authors of these packages were directly involved in the
> attempts to correct these issues, yes they were being ignored. Granted
> the talks with the FSF _may_ result in a change to the GFDL that makes
> it DFSG free. However, in the meantime the problem continues to exist
> in our archives. The developers could have made the necessary changes
> to their package (construction or location) to resolve the problem and
> then reverted those changes later. Would this have required time, sure.
> Did they have this time, sure.

Would it necessarily have been sensible? No.

The course of action most of agreed on was to try to make the
conditions of the private talks with the FSF as good as possible by
stopping the fruitless flamefests on debian-legal, not making Manoj's
platform official and refrain from other stuff that would generate
heat.
cu andreas

--
NMUs aren't an insult, they're not an attack, and they're
not something to avoid or be ashamed of.
Anthony Towns in 2004-02 on debian-devel

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Colin Watson

2004-04-29, 8:34 pm

On Wed, Apr 28, 2004 at 11:28:34PM -0600, Jamin W. Collins wrote:
> On Thu, Apr 29, 2004 at 01:11:18AM +0100, Colin Watson wrote:
[...][vbcol=seagreen]
> I'm not sure that the above change in anyway corrects the actual problem
> since the orig.tar.gz contains non-free items, and thus should not be in
> main.

If I thought it fixed the problem, I would have uploaded it and closed
the bug, wouldn't I? No. However, removing it from the binary package
will let me hear if there are user complaints earlier, in which case
I'll need to come up with user documentation.

Package maintenance is a little more than just removing stuff ...

Cheers,

--
Colin Watson [cjwatson@flatline.org.uk]

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Frank Küster

2004-04-30, 5:34 am

"Jamin W. Collins" <jcollins@asgardsrealm.net> schrieb:

> On Thu, Apr 29, 2004 at 01:29:08PM +0200, Frank K?ster wrote:
>
> And in the interrum the packages could have been modified to resolve the
> violations in the current state of things and reverted when/if the
> discussions with the FSF succeeded.

The point is that many people expected that such action would

- lower our chances for an agreement with the FSF

- worsen the relationship between individual package maintainers and
upstream. And this would in turn lower the chances that these upstream
authors are willing to relicense their work, should the discussions
with the FSF _not_ succeed.

>
> And we have a specific delegation to continue these talks. In the
> meantime, the packages could have been updated/corrected.

Which I had considered unwise. Only for the GFDL stuff, firmware is a
different issue.

Regards, Frank
--=20
Frank K=FCster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie

Nathanael Nerode

2004-04-30, 6:35 am

Frank K=C3=BCster wrote:

> One option of changing things would be to convince the FSF that the
> current GFDL is not free, and to create a better version and aks
> upstreams to "upgrade" to that one.

Good luck. As far as I could tell last time I tried, the FSF does not =
want
to listen to its developers, let alone Debian, even about minor draftin=
g
issues.

> In the FSF case, many people thought that waiting, moving flamewars t=
o
> other issues, and letting our representatives talk to the FSF would b=
e
> the best way of "working".

And some of them are beginning to doubt that after 6 months. :-(

--=20
There are none so blind as those who will not see.

Nathanael Nerode

2004-04-30, 6:35 am

Frank K=C3=BCster wrote:

> The point is that many people expected that such action would
>=20
> - lower our chances for an agreement with the FSF
Current assessment seems to be that it's the opposite; lack of such act=
ion
has led the FSF to ignore Debian.

> - worsen the relationship between individual package maintainers and
> upstream.
Even when upstream is FSF-owned, this probably won't happen. Requestin=
g
licensing changes from upstream before removing packages is always good=

practice, of course.

> And this would in turn lower the chances that these upstream
> authors are willing to relicense their work, should the discussions=

> with the FSF _not_ succeed.

--=20
There are none so blind as those who will not see.