Bug#883950: Next steps on "[GPL-3+]" proposal
Markus Koschany <apo@debian.org> writes:
> I have a hard time to imagine what kind of breakage might occur with
> those non-Lintian parsers.
It's pretty straightforward: currently, a License field must either
contain an extended paragraph or references one elsewhere in the document.
Therefore, whenever a parser sees a License field without an extended
paragraph, it currently knows (and expects) there to be a stand-alone
license paragraph later in the document. But with this change that
paragraph wouldn't exist.
> I personally dislike the trend in Debian to create more and more
> complexity in our source packages.
Well, I think avoiding changing the version of the standard and adding
this special case (and special-casing a specific set of licenses) adds
*more* complexity to the format than my proposal, as did the brackets. It
requires encoding options and branches and multiple interpretations of the
same field. Simplicity is exactly why I want to just change the version
number, introduce a new field with a clear meaning and syntax, and have
clean and simple semantics in the new version.
> I find the Standards-Version field unnecessary, VCS fields should not be
> part of a debian/control file, all DFSG licenses approved by our
> ftp-team should be listed in /usr/share/common-licenses and maintainers
> allowed to reference them, simple clarifications for copyright format
> 1.0 elements should not require a separate document 1.1 and so on.
That's an interesting assortment of things that seem very, very unlike
each other to me. Including a few I agree with (such as VCS fields not
being in the debian/control file; I'd love to find a good migration
strategy to move such metadata about the package maintenance process, as
opposed to a single instance of a source package, out of debian/control
for a cleaner separation of concerns).
Personally, I'd be happy to have all approved licenses listed in
common-licenses (there are a few complexities to actually doing that, but
it would be nice if we worked those out) since it would make my life a lot
easier, but you'll have to take that one up with the embedded systems
folks (and minimal container folks, for that matter), who have indicated
they'd be quite *unhappy* about that. (I suspect the base-files
maintainer wouldn't be thrilled either.)
One of the jobs of being a Policy Editor is to try to keep in mind the
widely varying uses to which Debian is put and to try to chart a course
between those concerns. The common-licenses compromise is awkward and not
particularly graceful, and it would be nice to have a better approach, but
I don't think shipping several megabytes of text in base-files is the one
that's going to make everyone happy.
> I have noticed that you are always in the opposite camp and a proponent
> for more complexity. I believe this kind of perfectionism makes it more
> and more difficult to change even smaller details in Debian.
This amuses me a lot, since part of what I've tried to do in Policy in the
past year or two has been to argue against perfectionism and to push
things forward despite some objections and desire to get all the details
more correct, to the considerable annoyance of some folks.
It is certainly true that Policy is probably too bureaucratic, and I'd
like it to be more streamlined and faster as well. But formulating
standards through consensus is hard, and every standards process ends up
having this problem to some extent if it's successful. If you think this
is bad, you should try the IETF or, heaven forbid, POSIX. :)
Debian is really large, and there are a lot of edge cases, and
standardization becomes the place where we find all those edge cases and
talk about them and try to write them down. If anyone has figured out how
to do that without being bureaucratic, I haven't heard about it.
I think what you're seeing is a large and mature project with a stronger
committment to quality and consistency than you find in most communities.
(And, to be fair, quite a lot of momentum and adherence to "the way things
have always been done," probably more than we should have.) That
inherently comes with a certain lack of agility. I wish we could have
both at the same time, but I think it might be a constraint of human
nature.
> For me #883950 and this proposal is a no-brainer and should have been
> handled much more gracefully.
Yup, that's a common theme -- just about everyone who comes to Policy for
a specific proposal thinks their proposal is a no-brainer (but usually has
some objections to some other proposal someone else had, like putting VCS
fields into debian/control).
> I'm not surprised that I can't convince you but for the sake of other
> Policy bug reporters, I suggest that you make your decision making
> process more transparent in the future. For instance I was asked by one
> Policy editor to contact the ftp-team, which are the authoritative body
> in Debian when it comes to licenses, I got the OK for my proposal but
> now it is blocked by another Policy editor who subtly implies that the
> resolution of this bug depends solely on him. It would have saved us
> time and effort if we got that straight right from the start.
I think you're confusing two very different things. You were asked to
reach out to see if they felt the need to have an explicit pointer to the
file in common-licenses in debian/copyright, which you did, and they
don't, and that's great. That unblocks a big chunk of this. Thank you
very much for doing that!
We also need to check with them on whether the license grant needs to be
copied into debian/copyright, since that would get rid of another chunk of
work. (That's now a separate bug.)
I only raised my concern about backward compatibility *after* you had
checked with ftp-master, because that was the first time I'd had a chance
to really think about that implication of the proposal in detail and
realized it had that issue. So I obviously wouldn't have asked you to ask
them about that, since it hadn't occurred to me. It's also not something
we would ask ftp-master about in particular, since it's a format issue,
which is outside the scope of stuff they care about.
So I think you've gotten the timeline a bit confused here, and are
(understandably) frustrated about a speed bump that didn't come up until
late in a long discussion. I'd say that's my "fault" in the sense that I
could have raised it earlier if I'd noticed it, but I'm not going to take
any blame on it because Debian is a volunteer project and sometimes people
just don't have time to think about things until they're farther along.
It happens.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: