On Fri, 2022-08-26 at 11:58 +0100, Simon McVittie wrote: > I don't think it's always useful to talk about "the" source or "the" > preferred form for modification, as though there is only one.
I see both the licensing and source aspects of the Free Software movement as aspiring to providing a high level of equality of access to a work between both the original author and far downstream recipients. Obviously full and universal equality is impossible because part of the work is only in the author's mind and not everyone can obtain, use and program computers, but approaching that as closely as possible is important and it is important to think about how to achieve a high level of equality for each work in each context. What is the "source" in any given context is a *choice* the author makes about what level of access to a work that they want allow for themselves and others in the future. > I think it would be more appropriate to consider whether the form > in which some software is provided is suitable for exercising your Free > Software rights (as described in the FSF's "four essential freedoms", > for example) within the scope of whatever package we're talking about at > the time, or whether it's unsuitable for that use. If it's suitable, then > it's source, or close enough; if it's unsuitable, then that needs fixing. I have to strongly disagree with this, because of the equality of access issue that that I mentioned above. For example: I use autotools to create a ./configure shell script but ship only the shell script itself. You can run/read/modify that script just fine, but it is incredibly verbose and there is a lot of repetition due to how these scripts are generated. Clearly I have better access than you. I use mrustc to generate a C version of some Rust code, ship the C code to you as source. You can do everything you want with the C code, but you cannot build the Rust code with rustc and get a safer binary nor fix bugs in the code generation etc. I still can do those and more, as well as all the things that you can do with the C code. I write some JavaScript with extensive comments and formatting, then I run a minifier and ship that as the source. You can still run, read, modify the code just fine, but Debian so far doesn't consider it as source. If instead of minifying, I just strip all the comments then the code will be more accessible to you and Debian probably wouldn't be able to tell I stripped it, but I will be able to understand the code much easier than you since I have comments. I create a model in Blender, keep that model private, render it to a PNG file and ship that as source. You have all the essential freedoms for the PNG form of the scene, but you can't easily modify the texture or shape of the model and rerender, but I can still do all of those things. Later I lose the Blender model and now we are equal, both unable to do useful things. At some point an app store flags the game the image is in as inappropriate in some culture and to fix that I need to recreate the model from scratch. This time I learn my lesson and check the Blender model into the git repo. > If we insist on a particularly puritanical view of what is source and > what is the preferred form for modification, then I think there is a > significant risk of producing a distribution which is unquestionably Free > Software, but either is missing useful Free software because it would be > too hard to get that software into a form that meets our self-imposed > policies, or can only contain that software as a result of individual > developers putting a heroic amount of effort into meeting those policies - > particularly if we always go back to the "true source" and generate from > there every time We have the contrib/non-free areas of the archive for situations where we aren't yet meeting our requirements, including around source and build dependencies. I see no reason why we should not use it more often for things that are licensed as Free Software but hard to package according to our principles. > (which I will note that the ftp team specifically do not insist on > unless there is a technical reason to do so, they merely require > source to be *available*). This is slightly incomplete, as I understand it the source has to be available in Debian main *and* the build process must be *possible* using only components from Debian main, but it isn't mandatory to run the build process. Of course the best way to prove those requirements are met is to actually run the build process. Personally, I think our current policies on building from source are not adequate to ensure that Debian and our users can practically exercise our Free Software rights for all source files in future. At minimum, I would like to see a requirement to build-depend on the appropriate build tools, even if those tools aren't yet run during the build process because the build is impractical etc. > If we require contributors to do a considerable amount of work that > does not advance the project's goals, at best that's a waste of our most > limited resource (developers' time and motivation), and at worst it's a > recipe for burned-out contributors, which we absolutely should not want, > both because we're a community that cares about the well-being of our > contributors (or at least I hope we are!) and because even from a purely > amoral/utilitarian point of view, contributors giving up on the project > harm our ability to achieve our goals. There are a lot of examples of busywork in Debian, such as documenting licenses, packaging dependencies, removing non-free files that are only in source packages, runtime selection of correct CPU instructions, fixing build failures, porting reverse dependencies to newer versions of APIs etc. All of these are things that contributors complain about and get burned out by us requiring or even suggesting. All of them however are necessary in some way. I think the requirements around source and building are just another example of this. -- bye, pabs https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
