On Fri, Feb 03, 2006 at 05:16:24PM +0200, Anton Zinoviev wrote: > > Our discussion became too complicated and I am not sure on what we > agree and on what we disagree. I will try to explain my current > opinion in a separate message and if we have some disagreement we can > continue from there.
I tried to find some criterion upon which we can easy determine whether some license makes the compilation works impossible or not. Unfortunately I could only find a list of different cases with different proofs. For example all proofs I gave in the former discussion are valid for some licenses and invalid for others. Here I will give another proof for a case which I am intentionally making as close to the text of DFSG4 as possible. For reference the text of DFSG4 is: The license may restrict source-code from being distributed in modified form _only_ if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. Suppose we have a license X that makes use of this rule of DFSG. In particular the X license gives us only the following permissions with respect to the source code: 1. Permits to distribute and build unmodified copies of the source of the program. 2. Permits to distribute "patch files". It is not necessary to require the distribution of the "patch files" together with the original source code even though DFSG seams to allow such a requirement. 3. Permits to use the "patch files" for the purpose of modifying the sources of the program at build time. Suppose that the works A and B are covered by X and C is a combined work based on A and B. Under these conditions the sources of C can not be distributed because theyr distribution form should have simultaneously the form sources_of_A+patches_for_A and sources_of_B+patches_for_B and this is impossible. (The formal proof of this impossibility is too abstract, but I hope the following analisys will make it clear.) During the previous discussion Matthew Garrett and Kalle Kivimaa proposed some ways to distribute the sources of C. Here I am going to analise the proposed ways: 1. Distribute a build system that applies a patch against work A which turns it into a patch against work B. Applying this results in work C. You are allowed to distribute the original sources of A and a patch which turns them into a patch against work B and the license of B may permit to use such automatically generated patches. Obviously any patch that is automatically generated in this way is a work based on A. The license of A permits to use "patch files" for the purpose of modifying the sources of A at build time. However the license of A doesn't explicitly permit us to use "patch files" or any other work based on A for the purpose of modifying the sources of another program, in our case B. 2. We distribute the sources of C in the form sources_of_A + sources_of_B + patch_set_to_A_and_B. >From the license of A it follows that patches_for_A == sources_of_B + patch_set_to_A_and_B. Consequently patches_for_A is a work based on the sources of B. Because of that the license of B does not allow us to apply these patches to anything different than the original sources of B. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]