[xsd-users] License and Portability

[Benjamin Schindler]

Sorry for chiming in here...

Peter, are you a lawyer? If not, well you better consult one, because
then in the end all you are doing is hand-waving because you are in no
position to make an informed statement. Legalese is difficult.
I'm sure Boris has consulted the FSF over this matter so he is probably
in a good position.
Boris has decided to put the generated code under the GPL. So the only
way to challenge this is consulting a lawyer/the FSF.

Cheers

Benjamin

On 07/06/2011 12:30 PM, Peter Backes wrote:
> Hi Boris,
> 
> On Mon, Jul 04, 2011 at 06:57:16PM +0200, Boris Kolpackov wrote:
>> For any schema that you compile with XSD I can trace for you every
>> bit of generated code back to the XSD compiler source code, with
>> the exception of class/function names, which is what comes from the
>> schema. In fact, that's essentially what the XSD compiler does: it
>> takes bits of source code (embedded into it) and parameterizes them
>> with names that come from the schema.
> 
> Every compiler does that. Only if the translation introduces some 
> non-trivial code, then some copyirght claim on the output may exist.
> 
>> This is a very strong statement. XSD outputs large chunks of non-trivial
>> code (e.g., parsing code) that I am pretty sure is copyrightable. Also,
>> if you believe that XSD consists of just a bunch of basic idioms thrown
>> together, then I am sure you will be able to implement a replacement in
>> an evening or two ;-).
> 
> I am not saying that it is trivial to implement. But copyright is not 
> based on a "sweat of the brow" doctrine, at least in most countries.  
> Even if something may take some effort and skill to implement: If there 
> is no originality in it, then it cannot be copyrighted.
> 
> I cannot make a general statement because I have used XSD only in one 
> small project. But from what I have seen, the generated code mostly 
> does trivial comparisons against strings from the schema, and calls 
> methods from the header library as well as the user's implementation. 
> There is hardly any other way to do this using the header-library 
> parsing framework.
> 
> You certainly agree that it is possible to implement a replacement, 
> which, given the constaints imposed by the header-library framework, 
> would basically result in the same code, even if the one who 
> implemented it never saw any generated code or the XSD source code. 
> Perhaps not in an evening or two, but in some time it would be done.  
> That is in fact an argument against the copyright claim...
> 
>> There is a difference. When you pass a program in C++, it already
>> contains the "logic" or "execution plan". Assembly is just another
>> representation of that logic. If there is a loop in C++, there is
>> a loop in assembly, etc.
> 
> Yes, but there is also some code introduced for handling the 
> object-oriented stuff, and this code is not contained in the C++ 
> program you compile.
> 
>> I don't think you will disagree that XSD-
>> generated C++ code is not just another representation of the XML
>> Schema. While, for example, an auto-generated from XML Schema
>> Relax NG would in fact be just another representation.
> 
> The XSD generated C++ is a translation of the schema.  I don't think it 
> makes a practical difference for copyright whether you consider it to 
> be a different representation or not.
> 
>> It is wrong. There are substantial chunks of the generated code that
>> do not depend on the input (e.g., code generated for built-in types).
> 
> That may be the case; I have not read the generated code in detail, 
> especially not with respect to built-in types.
> 
>> determined only by the XML Schema. It is also determined by what
>> "patterns" (C++ code) are inside the XSD compiler.
> 
> Sure, but only for trivial parts of the code, at least in the generated 
> code that I have seen.
> 
>> Let's change this problem slightly and see if you still think I am 
>> wrong. Let's say I wrote an implementation of an algorithm in C++
>> that uses preprocessor macros to specify some parameters. So in
>> order to obtain the actual algorithm implementation, you have to
>> pre-process my code with some macro definitions. Do you think that
>> because the output is "directed" by your macro definitions that the
>> result pre-processed code is not copyrightable?
> 
> It depends on the originality and complexity of the macro definitions. 
> Many macros I have seen, and perhaps even in the average, were less 
> trivial than the XSD code generatioxn.
> 
> Sure, these things may be gray areas.  I think it is not a good thing, 
> from a philosophical point of view, to try to claim copyright on such 
> generated code, even if, in the end, such a claim could be upheld.  It 
> is much better to disclaim copyright for generated code of any 
> compiler-like program.  I think that the header library gives you a 
> fair and sufficient way to protect the program from being made 
> proprietary.
> 
> I also read the FLOSSE and I have some reservations against it.  Some 
> of it seems redundant (why give permission to license your program 
> under a GPL-compatible free software license if the GPL already gives 
> you this permission), and most of it seems to try to be too clever... 
> It would be better to have some easy to understand, clear and standard 
> permission.
> 
> I would like to publish some academic tool under the GPLv3 that makes 
> use of XSD generated code. Given the fact that XSD has the non-standard 
> GPLv2-only license (something else that IMO tries to be too clever), I 
> need to rely on this FLOSSE exception. But it is hard for me to find 
> out what it really means.  Why not simply license the program GPLv2 or 
> any later version and thus make it easy and clear for people who want 
> to publish something under GPL-compatible licenses?
> 
> Greetings from ECRTS11
> Peter
>