dtufs writes: > Michael Poole writes: > > > One sign is the frequent use of alternatives -- > > "features/functionalities", "product/modifications", > > and so forth -- rather than defining a minimal set > > of terms up front and using them later. > > In reality, use of alternatives, either in brackets or > slash-separated can only clarify the meaning and make > it more precise (not vice versa). Likewise, giving > examples in brackets in a license text can only > clarify the meaning or extent (not vice versa).
Oh? Is "A/B" the union or the intersection of the two sets? Even beyond that, the license is much less readability for saying "your product/modifications (as defined in Section III.1.)" rather than saying "your Derived Work". > This does not affect the 'free software status' of the > license. Vagueness certainly can affect freeness. If I were considering distributing or modifying TrueCrypt, the license would make me think twice. [snip] > > This is a lawyerbomb. It is not clear that > > including a copy of the full source code with every > > copy you distribute is sufficient, and it is not > > clear whether "every copy of your > > product/modifications" is meant to apply to copies > > made by third parties. > > This might be true. However, it does not affect the > 'free software status' of the license (it is clearly > required that "source code of your product or of the > modified version must be freely and publicly > available"). The importance of "including a copy of the full source code with every copy you distribute" satisfying the license is that it is non-free to require a distributor to serve copies of the work to third parties, as in GPL 3(b) taken alone. The importance of the third-party limitation is that it is non-free for me to be responsible for whether Joe follows the license just because I gave Joe a copy of the software. > The term "Your product" is clearly defined in Section > III.1 (it includes the meaning of "derivative work"). > >>From III.3.b.: > > "Your product/modifications (as defined in Section > III.1.) are > > distributed and used only internally within the > organization and only by > > members/employees of the organization for which > you created the > > product/modifications and of which you were a > member/employee when you > > created the product/modifications. (Here the word > "organization" means > > a non-commercial or commercial organization, or a > government agency.)" > > > >Another lawyerbomb. Under traditional laws of agency > >and employment, this is redundant of III.3.a, except > >that it mixes in the vague term "member" with the > >term of art "employee". > > First, what does "traditional laws of agency and > employment" mean? Depending on the jurisdiction (on > the country whose laws apply to the licensee), > distribution to other individuals within a corporate > entity might be qualified as public distribution. I was thinking of English and American common law. Under which laws would distribution within a corporate entity be treated as public distribution? (The FSF interprets the GPL as treating a corporate entity as one licensee, with employees acting as such being part of the entity, especially as regards distribution of modified versions.) > Second, "member" is not a vague term. Foundations, for > instance, may have employees and members. Again, this > also largely depends on the country whose laws apply > to the licensee (laws in most countries actually > recognize the difference between "member" and > "employee"). This is again why it is important to define license terms. In the US, non-profit organizations may have members who are not "part" of the entity under the US's laws of agency. This is generally the case for an organization's members, so it seems odd to address members at the same time as employees. [snip] > > Overall, this seems like a fairly pointless and > > dangerous but not clearly unfree license; > > The statement that the "license is not clearly unfree" > is vague and potentially misleading. It actually has > had negative consequences: The false statement of the > editor of the Debian news mailing list who wrote at: > http://www.debian.org/News/weekly/2006/26/ the > following: "Michael Poole answered that the license > isn't free at all". You might want to correct him. > > Your analysis did not present any points that would > indicate that the license is "unfree". My own overall > analysis of the license concludes that it is actually > as "free" as GPL (actually even more free than the > GPL). You also might want to correct the DWN editor; I have no desire to do so. Taken in context, my comment is neither vague nor misleading. I pointed out places where the license could be interpreted to be non-free, but the balance of the evidence suggests that the intention was to make a free license. That is why I made particular suggestions as to clearer ways to achieve a very similar result to the original license -- in particular GPL "with SSL exception". Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
