[xsd-users] License and Portability

Peter Backes rtc at cdl.uni-saarland.de
Thu Jul 7 06:03:27 EDT 2011


On Wed, Jul 06, 2011 at 01:30:15PM +0200, Boris Kolpackov wrote:
> I think we will just have to agree that we disagree ;-). IMO, the
> major flaw in your reasoning comes from the fact that any however
> complex program can be viewed as just a collection of trivial and
> unoriginal idioms and code snippets. Following your logic we can
> then conclude that such a program (or poem, or book, etc) is not 
> copyrightable.

Not at all, because the general arrangement and way of combining such 
ideas is usually original and thus copyrightable.

Here, however, the general arrangement that might introduce 
copyrightability is completely dictated by the schema.

Again: You do not need copyrightability of the generated code to 
achieve what you want.  The fact that you own copyright of the header 
library is completely sufficient.

> I think what plays an important role is the way
> these fragments are arranged and are interacting to perform
> something useful.

Exacly.

> In case of the XSD-generated code the "trivial"
> pieces of code are arranged and interact in such a way that they
> will parse an XML and present you with its object model (note
> that the schema does not provide a recipe that states how this
> code should be arranged or interact to achieve this; it merely
> describes the kind of XML documents that we must be able to 
> handle).

The only thing that can be said to be non-trivial in this respect is 
the way the schema is written. I do not see any non-trivial piece of 
code or arrangement structure introduced by XSD, although I admit that 
I may not have seen all characteristic cases.

> The same holds true for bison/lex; you merely state
> what kind of language you want to parse/lex, not how to achieve
> this.

But that is not the reason why code generated by bison/flex ise 
copyrighted. The reason is that bison/flex copies library source code 
into its output, much like the header library used by XSD.

> This is in contrast to, say, a C++ program being translated
> to assembly, where the arrangements and interactions are specified
> in C++ and assembly is merely a different representation of these
> rules.

I can only repeat again that this is not true. The way you translate 
object oriented structures to assembler is not imposed by C++. (The 
same holds already for almost all imperative constructs of C). The fact 
that the assembler output has no copyright restrictions other than 
those of the input has to do with the translation not introducing 
anything copyrightable, in the same way as XSD. Again please note that 
copyright has no notion of "merely a different representation".

> FLOSSE gives you permission to license your program under various
> open-source licenses, many of which are GPLv2-incompatible.

That seems to be its intention, but I am pretty sure the way it does it 
doesn't do much good.

> We put the Rationale section before the legal terms especially to
> clarify this. It provides concrete examples that show the situations
> where FLOSSE can and cannot be used. Not sure what else we can do to
> help with this.

It uses a lot of vague terminology that can basically mean anything. 
The rationale secion is very very hard to read and doesn't help very 
much with understanding. I get some of the intention, but what it means 
in practice remains completely unclear.

Users run a high risk if they rely on the FLOSSE, IMO.

> 1. We may not necessarily agree with the ideas behind GPLvX. Giving
>    a third-party a perpetual right to dictate the license under which
>    our software is distributed is something that we are not comfortable
>    with.

Even with "or any later version", nobody can dictate the license under 
which the software is distributed. It remains to user's option which 
version of the license to use (at least for code that you have written 
and licensed).

The "or any later version" clause cause the freedom of the program to 
be increased over time.  Only when you see this in terms of you loosing 
your power to dictate how the program should be used, there can be any 
problem. This point of view, however, is contrary to the Free Software 
philosophy, and you should be careful to use a licenses like the GPL 
that has been specifically designed to attack this point of view.

> 2. GPLv3 is still incompatible with some open-source licenses. We
>    use FLOSSE to give you the right to release your code under these
>    licenses (including GPLv3) provided certain conditions are met
>    (i.e., you are not simply relicensing the generated code to use
>    it a proprietary application).

As discussed above, the user has that right anyway, as you probably 
cannot claim copyright on the generated code. It is not necessary 
either, because the header library does all you want.

The overwhelming majority of all cases is covered if you license under 
GPLv2 or any later version.  You can then make exceptions on a 
case-by-case basis, without the confusion of the FLOSSE.

Regards
Peter

-- 
Peter Backes, rtc at cdl.uni-saarland.de            Office 403
Compiler Design Lab, Saarland University         Campus E1 3
Phone: +49-681-302-2454, Fax: -3065              66123 Saarbruecken
http://rw4.cs.uni-saarland.de/people/rtc.shtml   GERMANY



More information about the xsd-users mailing list