Thorsten Glaser wrote on Sunday, October 6, 2019 3:24 PM > Florian Weimer dixit: > > >for shipping corresponding source code that was actually compiled, and > >not just upstream tarballs plus downstream patches. > > upstream tarballs plus downstream patches is preferred form of modification, > though > > >It's not unreasonable to do this for link-time optimization purposes. > > but precisely that would not match the requirements, I’d rather embed a > tarball > > > Cem Karan dixit: > > >That said, I for one would find it *highly* amusing if gcc/clang added > >a switch to embed the complete project > > but gcc/clang can’t know the complete corresponding source, which adds build > systems… and IMHO also e.g. the debian/ subdirectory of > packaging as separate(!) entity
You're right, which is why this was more of a thought experiment than anything else. If it were to be done seriously, then a great deal more thought would need to go into it. In one of the messages I sent out (see https://www.mail-archive.com/license-discuss@lists.opensource.org/msg01132.html) I found a method that allows you to create a filesystem within a file, which with some tweaking would allow you to create a filesystem within an ELF binary that could then be mounted. One could imagine an external tool that could copy the contents of a directory into a filesystem within the ELF binary, and a second tool that knew how to mount it. The trick is that we're assuming that there are no malicious actors out there, ready, willing, and able to load innocuous sources into a malicious binary. Thus, if we went down this path, there would have to be some engineering effort put into digital signatures, methods of upgrading the hashes used, etc. to make sure that the sources match the binaries. I'm sure that there are a lot of other problems as well, but as was pointed out in https://www.mail-archive.com/license-discuss@lists.opensource.org/msg01133.html, while this is a fun discussion, it has nothing to do with the original subject line (Discussion: AGPL and Open Source Definition conflict), nor is it really something that the license-discuss mailing list is really set up to handle. That said, I get the sense that there are enough people on the list that are at least mildly interested in this that it would make sense to start a project/mailing list somewhere. Where is the best place to move this to? I originally thought GitHub, but now I'm starting to think it might be better somewhere on OpenSource.org. Thoughts, suggestions? Thanks, Cem Karan --- Other than quoted laws, regulations or officially published policies, the views expressed herein are not intended to be used as an authoritative state of the law nor do they reflect official positions of the U.S. Army, Department of Defense or U.S. Government. _______________________________________________ License-discuss mailing list License-discuss@lists.opensource.org http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
