On Tue, Sep 05, 2006 at 10:35:49AM +0200, Sven Luther wrote:
> > It therefore seems to me as though we're going to be failing to meet the
> > social contract again, and as a consequence I think we should seriously
> > reconsider whether the change we made in 2004 was the right one. So I'd
> > like to propose the following course of action for consideration:
> ... you do a gigantic leap to this conclusion, which is not at all waranted by
> the above poll.
There's two steps:
(1) we're not going to meet the social contract for etch
(2) having repeatedly failed to meet the new social contract over
an extended period, we should reconsider whether it was a
good idea to adopt it in the first place
Only (1) is justified by the poll. (2)'s my opinion; I think it makes
sense, but YMMV. Without (1), (2) is irrelevant, of course.
> The idea was that it is too short until the etch release (actually it is way
> too late, since kernel freeze was in early august) to solve the non-free
> firmware issue, and your little poll clearly stated that this was a poll aimed
> at releasing etch on time, not to revert the decision already taken on this
> subject.
That's correct. I don't think there's anything unreasonable about any of
the options on the table, on their own merits or in light of those polls.
> > ----
> > The Debian Project resolves that:
> > (a) The Social Contract shall be reverted to its original form,
> > as at http://www.debian.org/social_contract.1.0
> > (b) The term "software" as used in the Social Contract shall be
> > presumed only to cover programs, scripts, libraries and similar
> > executable works to be executed directly as part of the Debian
> > System.
> > (c) In addition to the commitments made in the Social Contract,
> > the Debian System shall only include documentation, images,
> > sounds, video, fonts and similar works that meet the Debian
> > Free Software Guidelines, and are available in some reasonably
> > modifiable form.
> > (d) Notwithstanding the above, the Debian Free Software Guidelines
> > shall not be applied to logos, firmware or the text of copyright
> > licenses that may be included in the Debian System.
> So, we can include GFDL documentation, and other non-free stuff in main again ?
> Nice, especially as firmware falls more often than not in this category.
> Oh, so you revert the social contract to the older wording, which fails to
> consider most firmware cases, and then make a special exception for all those
> non-firmware stuff we already removed ?
> And then grant a special excemption, not for the duration of the etch release,
> but in general for firmware. I wonder what was the rationale for (a) then ?
The rationale for (a) and (b) is having a social contract we can meet.
The rationale for (c) is that we can go beyond just meeting that social
contract, and we shouldn't be ashamed of saying that. The rationale for
(d) is that there are areas we haven't achieved what we'd like yet,
and we shouldn't be ashamed of saying that, either.
> Could you not have written the same without reverting the social contract to
> its older form ? This only adds to the confusion instead of clarifying it.
Without reverting the social contract, we're still breaking it for
etch. I'm uncomfortable with that. We could do a timed reversion like
we did for sarge, but personally, I think the current social contract
is flawed by design and we're better off with the old one until we come
up with something better than both of them.
> > (e) Following the release of etch, the Debian Project Leader shall:
> > i. ensure that the Debian community has a good understanding
> > of the technical and legal issues that prevent the Debian
> > Free Software Guidelines from being applied to logos and
> > firmware in a manner that meets the needs of our users;
> > ii. ensure that project resources are made available to
> > people working on addressing those issues;
> > iii. provide a report to the Debian community on progress achieved
> > in these areas at DebConf 7 in Edinburgh.
> >
> > (f) Following the release of etch, the Debian Project as a whole shall
> > reopen the question of which commitments should be codified in the
> > project's Social Contract. This shall including both an online
> > consultation with Debian users, Debian derivatives and the free
> > software community, and a public in-person discussion and debate
> > at DebConf 7 in Edinburgh in honour of the 10th anniversary of
> > the original publication of the Social Contract on the 4th
> > of July 1997.
> Mmm.
> I dislike this way of doing it, you want to, instead of making an exception
> for etch, generalize the situation, and then come back in a year or so, to
> finally solve the issue.
Last time we did it, we pretended the issue was solved as soon as sarge
would be released, then left the GFDL discussion up in the air for another
six months after sarge's release, and realised over a year later that
the firmware stuff still wasn't resolved. I do prefer a specific plan
with specific milestones on getting this thing fixed generally, yes.
I originally had (e) being marked to happen in the first six months
following etch's release, but then realised that DC7 will hopefully be
seven or eight months after etch, so scrubbed the specific times. I'd
expect to start on (e) a month or two after etch releases unless others
get to it first, and that (f) would probably begin around March or April.
> > Personally, I think it's a mistake to have a social contract that we
> > can't meet -- I would much rather say "we're not only meeting our social
> > contract, but we're going above and beyond it" than keep worrying about
> > how we've overpromised and keep having to underdeliver.
> Bah. The above wording sounds much like compromising our ideals in order to
> release etch, however you word it.
While we ship the text of the GPL, we'll be shipping content that's not
100% free. If that counts as one of your ideals, we'll be compromising
them for the forseeable future.
If you consider our ideals to be the original social contract, applied
to programs not images and firmware, we've been meeting and improving
upon our ideals every year and every release.
If you consider our ideals to be the current social contract, we've been
violating them and compromising them and apologising for not meeting
them every year and every release since we adopted it.
> > I think (e) is an important part of meeting our users' expectations,
> > as well as our own, that committing to releasing etch on time won't be
> > a permanent cost to our efforts towards free, sourceful firmware. I'm
> How can a commitment to release *ETCH* on time be a permanent cost, i mean,
> once etch is out the door, it won't matter anymore to the solution of this
> problem.
AFAICS, Steve's proposal is a permanent exception to DFSG#2 for images and
firmware that's not tied to etch's release; Joss's is temporary, tied to
the the development of "technical measures" that will allow firmware to be
separated; Don's isn't an exception at all, and won't allow us to release
etch on time without a further proposal; and Frederik's is an exception
just for etch, in the same way the last reversion was an exception just
for sarge: one that may well be repeated next time if nothing getsdone.
> So, why do you want to reopen the debate about it ?
Because I don't think we ever had a debate on it, and I don't think it's
working out for us. The ballot that chose the current social contract
didn't have any alternatives included, and was conducted immediately
following the constitutional amendment to allow voting on non-free
removal, the non-free removal debate itself and then the DPL elections,
with only minimal discussion on -vote, most of which occurred prior to
the non-free vote.
> I mean, the problem is not
> really if firmware or fonts or whatever is software, but what we want to have
> in main or not. These are fully orthogonal issues, and all those arguing that
> we should accept firmware in main because it is not 'software' are misguided
> at best, and misleading at worst.
There are two social contract texts we have a reasonable understanding
of -- the original one we had, and the new one we've got. Both have
significant flaws, in my opinion, but I'd much rather have one that we
can meet and exceed than one that we've repeatedly demonstrated we can't.
> Let's be open and direct, all the stuff which goes on the debian cds and/or is
> in debian archive is software, and then discuss the relative priority of
> having it in main or not.
I think:
(b) The term "software" as used in the Social Contract shall be
presumed only to cover programs, scripts, libraries and similar
executable works to be executed directly as part of the Debian
System.
is pretty direct, even if it's not your preferred definition of the word.
But yes, discussing the relative priority of having various things in
main is exactly what we should be doing, so that we can decide to devote
energy to fixing logo licenses, or making d-i handle non-free udebs,
or whatever else.
> instead of renaming
> firmware as data or classifying stuff as non-software, it would be much better
> to commit to a long-term clarification of the usage of non-free, [...]
Yes, I completely agree. The fact that "contrib" and "non-free" are
specifically named in the social contract makes that somewhat hard,
though. Is it against the social contract to create an area that includes
non-free stuff called "restricted", eg? After all, the SC says that we
created the "non-free area" for those works...
> > TTBOMK the Debian, Firefox and Thunderbird [3] logos all currently have
> > non-free copyright licenses acting as trademark protection, hence the
> > specific exception for logos, given images are mentioned previously. To
> Mmm, i am not sure, but does the DFSG really include not-trademarked (or
> not-patented) claims ?
Each of those logos are covered by a restrictive copyright license,
instead-of/as-well-as a restrictive trademark license.
If you take one of those logos, and change it completely so it doesn't
look similar to the original at all, you're not infringing the trademark,
but you are infringing copyright -- which makes it non-free...
> > Seconds and comments appreciated.
> I hope those comments will be useful, they may be seen a bit strong or
> whatever, but i hope you will be able to see past the wording to the content.
My original mail was a bit strong, so I'm not really surprised. It's
hard not to get worked up about this after so long, at least for me.
Cheers,
aj
Attachment:
signature.asc
Description: Digital signature