[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