On Thu, May 28, 1998 at 02:47:53PM +0100, Ian Jackson - Debian Project Leader wrote: > I'd like the opinions of the developers regarding a conflict of > interest I think I have. I'm not a developer (yet), but I play one on a mailing list! => I'll offer my opinions anyway, they may be useful to someone besides myself. > We need to ratify the DFSG according to the soon-to-be-inplace > constitutional mechanism. > > However, I personally have at least one outstanding issue with the > DFSG that I'd like to see changed - the `patches only' exception in > para.4. There are also a number of other issues that need to be > resolved. In particular, the status of standards and documentation in > general needs to be sorted out. How would you like to see these things changed? I have read many people say they'd like to see small changes, but I have yet to see anything from people as to how exactly they would like them changed. If I've just missed this somehow, I'd like to know that too. => > Furthermore, I think the DFSG isn't very well-worded in general - it > seems to have a couple of rather specific points where general rules > would be better. For example, it says there must be `no > discrimination against fields of endeavour'; surely it should say that > no restrictions are allowed except ones that it should list. It could be argued the GPL discriminates against people writing programs for Qt. In fact, RMS argues that it does. Clearly he is discriminating against both KDE in his current interpretation which is a turnaround from the things he was saying before that about netscape. The particular example was that GPL additions for non-GPL code (Mozilla) could be written in seperate files and later compiled/linked in. However, saying that KDE cannot legally use the GPL because it links Qt is clearly discrimination--whether it's on the part of the license or RMS is something I cannot say for sure. When I first read it that paragraph seemed like a good thing. Of course I was just coming outta proprietary software and most things seemed like good ideas. But now as it stands, that paragraph seems kinda dangerous IMO considering the changes RMS has been entertaining lately--whether they're good or not (which I am skeptical about, but that's for another argument..) > So, I have a wide spectrum of choices. Naturally I could push my own > agenda (and, being a zealot I think this would be the Right Thing, of > course). The leadership role has a lot of ability to control the text > of documents, especially if the document is proposed by the leader. I suggest then that you don't propose a complete document, only changes that might be made. Let -devel hash it out and have developers vote on it after we've all had a chance to make comments about some of the changes. > An alternative is that where contentious changes are made I could fail > to accept my own amendments, thus allowing them to be voted on. We > could even have an `old version vs. new version' vote. This is > probably my preferred course of action. It would allow me to write > the text in a way that I feel is clear and correct, but allow the > developers to decide on the meaning. Let the developers figure out if they wanna accept them or not. I'm sure we're all capible of nit-picking your ideas just as well as we can anyone else's. > At the other end of the scale, I could delegate the whole job of > ratifying the DFSG to someone who strongly agrees with the current > meaning and wording and place myself in the position of a developer. > However, I'm not necessarily convinced that this would make it easy > enough to get even essential and uncontroversial wording changes > through. This could be an answer. As long as the person in question was open-minded about changes.
Attachment:
pgpVq8vO4ZenO.pgp
Description: PGP signature