From rtc at cdl.uni-saarland.de Fri Jul 1 10:41:35 2011 From: rtc at cdl.uni-saarland.de (Peter Backes) Date: Fri Jul 1 10:41:41 2011 Subject: [xsd-users] License and Portability In-Reply-To: References: Message-ID: <20110701144135.GC30135@cookie.cs.uni-saarland.de> On Sun, Jun 19, 2011 at 06:21:28PM +0200, Boris Kolpackov wrote: > Klaim - Jo?l Lamotte writes: > > > 1. The xsd license is GPL even for generated code, right? > > As my project's license is MIT and I wish companies to build over my code, > > using xsd to generate code forces me and other companies using or selling my > > tool to provide the source code or to have a commercial license with your > > company? Am I correct? > > In addition to the GPL we also have the Free/Libre and Open Source > Software (FLOSS) exception which, provided you actually build > something useful on top of the generated code, allows you to > effectively re-license the generated code under other open-source > licenses, including MIT. For more information see the FLOSSE text > which has a nice "Intent" section including more detail on situations > where it can and cannot be used: The FSF has generally taken the position that you cannot claim copyright of the output users generate with the help of your program, except if that program copies some significant amount of its source code into the output. That is why gcc compiled programs need not be put under the GPL. Thus, IMO, the only thing that prevents XSD users from choosing any license they want is the fact that the header-only XSD runtime library is needed to make an executable. http://www.codesynthesis.com/projects/xsd/FLOSSE seems wrong to me when it justifies its claims by also referring to "XSD generated code" See http://www.gnu.org/licenses/gpl-faq.html Is there some way that I can GPL the output people get from use of my program? For example, if my program is used to develop hardware designs, can I require that these designs must be free? In general this is legally impossible; copyright law does not give you any say in the use of the output people make from their data using your program. If the user uses your program to enter or convert his own data, the copyright on the output belongs to him, not you. More generally, when a program translates its input into some other form, the copyright status of the output inherits that of the input it was generated from. So the only way you have a say in the use of the output is if substantial parts of the output are copied (more or less) from text in your program. For instance, part of the output of Bison (see above) would be covered by the GNU GPL, if we had not made an exception in this specific case. You could artificially make a program copy certain text into its output even if there is no technical reason to do so. But if that copied text serves no practical purpose, the user could simply delete that text from the output and use only the rest. Then he would not have to obey the conditions on redistribution of the copied text. In what cases is the output of a GPL program covered by the GPL too? Only when the program copies part of itself into the output. Regards Peter -- Peter Backes, rtc@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 From boris at codesynthesis.com Fri Jul 1 15:00:46 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Jul 1 15:03:27 2011 Subject: [xsd-users] License and Portability In-Reply-To: <20110701144135.GC30135@cookie.cs.uni-saarland.de> References: <20110701144135.GC30135@cookie.cs.uni-saarland.de> Message-ID: Hi Peter, Peter Backes writes: > The FSF has generally taken the position that you cannot claim > copyright of the output users generate with the help of your program, > except if that program copies some significant amount of its source > code into the output. All of the output produced by the XSD compiler is copied from the XSD compiler source code. There is no C++ code (or any other kind of programming language-like code) in the input (which is XML Schema). So I believe we are in agreement with the FSF when we claim copyright on the generated code. Boris From rtc at cdl.uni-saarland.de Fri Jul 1 16:10:26 2011 From: rtc at cdl.uni-saarland.de (Peter Backes) Date: Mon Jul 4 12:32:54 2011 Subject: [xsd-users] License and Portability In-Reply-To: References: <20110701144135.GC30135@cookie.cs.uni-saarland.de> Message-ID: <20110701201026.GA28060@cookie.cs.uni-saarland.de> Hi Boris, On Fri, Jul 01, 2011 at 09:00:46PM +0200, Boris Kolpackov wrote: > Peter Backes writes: > > The FSF has generally taken the position that you cannot claim > > copyright of the output users generate with the help of your program, > > except if that program copies some significant amount of its source > > code into the output. > > All of the output produced by the XSD compiler is copied from the XSD > compiler source code. I disagree. The XSD compiler generates the source code by systematic transformations from the schema. In fact, that is just what a compiler is supposed to do. No code is copied from the XSD compiler source code. Of course, XSD generates the code according to certain programming idioms and makes use of some basic code snippets that are present in the XSD compiler. But these are not copyrighted. They lack originality and/or copyrightability: You cannot claim a copyright a programming idiom or pattern or on basic code snippets. > There is no C++ code (or any other kind of > programming language-like code) in the input (which is XML Schema). Nor is there any assembler code in the input you pass to the GCC C compiler. In fact, compilers are translators. What you pass as the input is in a different language from what it gives you as output. This is exactly the idea. So it does not matter that there is no C++ code in the input, and the GPL FAQ makes no restriction in this respect. All that matters is that all the output is determined by the input completely. There is no piece of copyrightable code that is inserted regardless of the input. (Contrary to bison, which does copy substantial pieces of code from its own source code into the output; irrespective of what the input is.) Please correct me if I got this wrong, but it was my impression from looking at the generated code. > So I believe we are in agreement with the FSF when we claim copyright > on the generated code. I disagree. In fact, you are in perfect disagreement. ;) You claim to be able to do legally what the FSF terms as "legally impossible". Why do you need to make this questionable claim on the output of your compiler? Isn't it sufficient to make a claim on your own libxsd header code? Regards Peter -- Peter Backes, rtc@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 From boris at codesynthesis.com Mon Jul 4 12:57:16 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Jul 4 12:59:56 2011 Subject: [xsd-users] License and Portability In-Reply-To: <20110701201026.GA28060@cookie.cs.uni-saarland.de> References: <20110701144135.GC30135@cookie.cs.uni-saarland.de> <20110701201026.GA28060@cookie.cs.uni-saarland.de> Message-ID: Hi Peter, Peter Backes writes: > The XSD compiler generates the source code by systematic transformations > from the schema. In fact, that is just what a compiler is supposed to > do. No code is copied from the XSD compiler source code. 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. > Of course, XSD generates the code according to certain programming > idioms and makes use of some basic code snippets that are present in > the XSD compiler. But these are not copyrighted. They lack > originality and/or copyrightability: You cannot claim a copyright a > programming idiom or pattern or on basic code snippets. 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 ;-). > Nor is there any assembler code in the input you pass to the GCC C > compiler. In fact, compilers are translators. What you pass as the > input is in a different language from what it gives you as output. > This is exactly the idea. 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. 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. > All that matters is that all the output is determined by the input > completely. There is no piece of copyrightable code that is inserted > regardless of the input. (Contrary to bison, which does copy > substantial pieces of code from its own source code into the output; > irrespective of what the input is.) Please correct me if I got this > wrong, but it was my impression from looking at the generated code. 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). But I also do not agree with your statement re "if the output is determined by the input...". I haven't seen this definition in the GPL FAQ either. But even if we use this test, XSD output is not determined only by the XML Schema. It is also determined by what "patterns" (C++ code) are inside the XSD compiler. 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? Boris From mjklaim at gmail.com Mon Jul 4 16:16:50 2011 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Tue Jul 5 04:46:02 2011 Subject: [xsd-users] Shared library and exported symbols problem In-Reply-To: References: Message-ID: Hi, I'm still stuck with this problem. I'm considering switching to a static library temporarly to continue other works as I still need aoslcpp and aosdesigner to work together in a way or another. But before going to extreme solutions, I'm trying to understand where the problem comes from exactly. It is strange that my test executable isn't affected by the same problem. I tried comparing .lib import from the two projects but they seem similar (both import aoslcpp.lib and xerces lib). I modified the test to reproduce the same problem, with "success". I tweaked it to corner the specific case, and it seems that what is really needed is to include the generated code in the headers of my projects instead of just including them in the cpp. For example, assuming I have an aosl::Sequence class generated with this configuration : http://code.google.com/p/art-of-sequence/source/browse/tools/aoslcpp/script/generate_cpp.cfg In main.cpp : #include #include "test.h" int main() { std::cout << "Hello, world!"; Test test("a_test"); return 0; } Then I tried to define Test in two different ways. First the one that gives the same link error : #pragma once #include #include namespace aosl { class Sequence; } class Test {public: Test( const std::string& name ); ~Test(); const std::string& name() const { return m_name; } private: std::string m_name; std::unique_ptr m_sequence; }; test.cpp : #include "test.h" #include "aoslcpp/aosl/sequence.hpp" Test::Test( const std::string& name ) : m_name( name ) , m_sequence( new aosl::Sequence ) { } Test::~Test() { } Now, the modified version that does compile and link without any problem : #pragma once #include #include #include "aoslcpp/aosl/sequence.hpp" // added this class Test {public: Test( const std::string& name ); ~Test(); const std::string& name() const { return m_name; } private: std::string m_name; std::unique_ptr m_sequence; }; Once I found that it might be a solution, I tried to apply the same change in this file of aosdesigner that is similar to the Test class : http://code.google.com/p/art-of-sequence/source/browse/tools/aosdesigner/core/Sequence.hpp But that generates link errors with boost filesystem : 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path_traits.obj) : error LNK2005: "public: __thiscall std::basic_string,class std::allocator >::basic_string,class std::allocator >(class std::basic_string,class std::allocator > const &)" (??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@ABV01@@Z) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path_traits.obj) : error LNK2005: "public: __thiscall std::basic_string,class std::allocator >::basic_string,class std::allocator >(void)" (??0?$basic_string@DU?$char_traits@D@std@ @V?$allocator@D@2@@std@@QAE@XZ) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path_traits.obj) : error LNK2005: "public: __thiscall std::basic_string,class std::allocator >::~basic_string,class std::allocator >(void)" (??1?$basic_string@DU?$char_traits@D@std@ @V?$allocator@D@2@@std@@QAE@XZ) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path_traits.obj) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::operator=(char const *)" (??4?$basic_string@DU ?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEAAV01@PBD@Z) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path_traits.obj) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::operator+=(class std::basic_string,class std::allocator > const &)" (??Y?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@ @QAEAAV01@ABV01@@Z) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path_traits.obj) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::operator+=(char const *)" (??Y?$basic_string@DU ?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEAAV01@PBD@Z) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path_traits.obj) : error LNK2005: "public: char const * __thiscall std::basic_string,class std::allocator >::c_str(void)const " (?c_str@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QBEPBDXZ) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path_traits.obj) : error LNK2005: "public: bool __thiscall std::basic_string,class std::allocator >::empty(void)const " (?empty@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QBE_NXZ) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path_traits.obj) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::append(class std::basic_string,class std::allocator > const &)" (?append@ ?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEAAV12@ABV12@@Z) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path_traits.obj) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::append(char const *)" (?append@?$basic_string@DU ?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEAAV12@PBD@Z) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path_traits.obj) : error LNK2005: "public: unsigned int __thiscall std::basic_string,class std::allocator >::size(void)const " (?size@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QBEIXZ) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path_traits.obj) : error LNK2005: "public: void __thiscall std::basic_string,class std::allocator >::_Tidy(bool,unsigned int)" (?_Tidy@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@ @QAEX_NI@Z) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path_traits.obj) : error LNK2005: "public: __thiscall std::_String_val >::_String_val >(class std::allocator)" (??0?$_String_val@DV?$allocator@D@std@@@std@@QAE@V ?$allocator@D@1@@Z) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path_traits.obj) : error LNK2005: "public: __thiscall std::_String_val >::~_String_val >(void)" (??1?$_String_val@DV?$allocator@D@std@@@std@@QAE@XZ) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path_traits.obj) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::erase(unsigned int,unsigned int)" (?erase@ ?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEAAV12@II@Z) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path_traits.obj) : error LNK2005: "public: char * __thiscall std::basic_string,class std::allocator >::_Myptr(void)" (?_Myptr@ ?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEPADXZ) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path_traits.obj) : error LNK2005: "public: unsigned int __thiscall std::basic_string,class std::allocator >::max_size(void)const " (?max_size@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QBEIXZ) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path_traits.obj) : error LNK2005: "public: class std::_String_iterator,class std::allocator > __thiscall std::basic_string,class std::allocator >::end(void)" (?end@?$basic_string@DU?$char_traits@D @std@@V?$allocator@D@2@@std@@QAE?AV?$_String_iterator@DU?$char_traits@D@std@ @V?$allocator@D@2@@2@XZ) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path_traits.obj) : error LNK2005: "public: class std::_String_iterator,class std::allocator > __thiscall std::basic_string,class std::allocator >::begin(void)" (?begin@?$basic_string@DU ?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE?AV?$_String_iterator@DU ?$char_traits@D@std@@V?$allocator@D@2@@2@XZ) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path_traits.obj) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::append(unsigned int,char)" (?append@ ?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEAAV12@ID@Z) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path_traits.obj) : error LNK2005: "public: void __thiscall std::basic_string,class std::allocator >::reserve(unsigned int)" (?reserve@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@ @QAEXI@Z) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path.obj) : error LNK2005: "public: __thiscall std::basic_string,class std::allocator >::basic_string,class std::allocator >(void)" (??0?$basic_string@DU?$char_traits@D@std@ @V?$allocator@D@2@@std@@QAE@XZ) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path.obj) : error LNK2005: "public: __thiscall std::basic_string,class std::allocator >::basic_string,class std::allocator >(class std::basic_string,class std::allocator > &&)" (??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@ $$QAV01@@Z) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path.obj) : error LNK2005: "public: __thiscall std::basic_string,class std::allocator >::~basic_string,class std::allocator >(void)" (??1?$basic_string@DU?$char_traits@D@std@ @V?$allocator@D@2@@std@@QAE@XZ) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path.obj) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::operator=(class std::basic_string,class std::allocator > const &)" (??4?$basic_string@DU?$char_traits@D@std@ @V?$allocator@D@2@@std@@QAEAAV01@ABV01@@Z) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path.obj) : error LNK2005: "public: void __thiscall std::basic_string,class std::allocator >::_Tidy(bool,unsigned int)" (?_Tidy@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@ @QAEX_NI@Z) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path.obj) : error LNK2005: "public: __thiscall std::_String_val >::_String_val >(class std::allocator)" (??0?$_String_val@DV?$allocator@D@std@@@std@@QAE@V ?$allocator@D@1@@Z) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path.obj) : error LNK2005: "public: __thiscall std::_String_val >::~_String_val >(void)" (??1?$_String_val@DV?$allocator@D@std@@@std@@QAE@XZ) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path.obj) : error LNK2005: "public: unsigned int __thiscall std::basic_string,class std::allocator >::size(void)const " (?size@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QBEIXZ) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path.obj) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::erase(unsigned int,unsigned int)" (?erase@?$basic_string@DU?$char_traits@D@std@ @V?$allocator@D@2@@std@@QAEAAV12@II@Z) already defined inaoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path.obj) : error LNK2005: "public: char * __thiscall std::basic_string,class std::allocator >::_Myptr(void)" (?_Myptr@ ?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEPADXZ) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(path.obj) : error LNK2005: "public: unsigned int __thiscall std::basic_string,class std::allocator >::max_size(void)const " (?max_size@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QBEIXZ) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(codecvt_error_category.obj) : error LNK2005: "public: __thiscall std::basic_string,class std::allocator >::basic_string,class std::allocator >(void)" (??0?$basic_string@DU?$char_traits@D@std@ @V?$allocator@D@2@@std@@QAE@XZ) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(codecvt_error_category.obj) : error LNK2005: "public: __thiscall std::basic_string,class std::allocator >::basic_string,class std::allocator >(class std::basic_string,class std::allocator > &&)" (??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@ $$QAV01@@Z) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(codecvt_error_category.obj) : error LNK2005: "public: __thiscall std::basic_string,class std::allocator >::~basic_string,class std::allocator >(void)" (??1?$basic_string@DU?$char_traits@D@std@ @V?$allocator@D@2@@std@@QAE@XZ) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(codecvt_error_category.obj) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::operator=(char const *)" (??4?$basic_string@DU ?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEAAV01@PBD@Z) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(codecvt_error_category.obj) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::operator=(class std::basic_string,class std::allocator > const &)" (??4?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@ @QAEAAV01@ABV01@@Z) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(codecvt_error_category.obj) : error LNK2005: "public: void __thiscall std::basic_string,class std::allocator >::_Tidy(bool,unsigned int)" (?_Tidy@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@ @QAEX_NI@Z) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(codecvt_error_category.obj) : error LNK2005: "public: __thiscall std::_String_val >::_String_val >(class std::allocator)" (??0?$_String_val@DV?$allocator@D@std@@@std@@QAE@V ?$allocator@D@1@@Z) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(codecvt_error_category.obj) : error LNK2005: "public: __thiscall std::_String_val >::~_String_val >(void)" (??1?$_String_val@DV?$allocator@D@std@@@std@@QAE@XZ) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(codecvt_error_category.obj) : error LNK2005: "public: unsigned int __thiscall std::basic_string,class std::allocator >::size(void)const " (?size@?$basic_string@DU ?$char_traits@D@std@@V?$allocator@D@2@@std@@QBEIXZ) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(codecvt_error_category.obj) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::erase(unsigned int,unsigned int)" (?erase@ ?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEAAV12@II@Z) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(codecvt_error_category.obj) : error LNK2005: "public: char * __thiscall std::basic_string,class std::allocator >::_Myptr(void)" (?_Myptr@ ?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEPADXZ) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_filesystem-vc100-mt-gd-1_46_1.lib(codecvt_error_category.obj) : error LNK2005: "public: unsigned int __thiscall std::basic_string,class std::allocator >::max_size(void)const " (?max_size@?$basic_string@DU ?$char_traits@D@std@@V?$allocator@D@2@@std@@QBEIXZ) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_system-vc100-mt-gd-1_46_1.lib(error_code.obj) : error LNK2005: "public: __thiscall std::basic_string,class std::allocator >::basic_string,class std::allocator >(class std::basic_string,class std::allocator > const &)" (??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@ABV01@@Z) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_system-vc100-mt-gd-1_46_1.lib(error_code.obj) : error LNK2005: "public: __thiscall std::basic_string,class std::allocator >::basic_string,class std::allocator >(char const *)" (??0?$basic_string@DU?$char_traits@D @std@@V?$allocator@D@2@@std@@QAE@PBD@Z) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_system-vc100-mt-gd-1_46_1.lib(error_code.obj) : error LNK2005: "public: __thiscall std::basic_string,class std::allocator >::basic_string,class std::allocator >(class std::basic_string,class std::allocator > &&)" (??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@ $$QAV01@@Z) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_system-vc100-mt-gd-1_46_1.lib(error_code.obj) : error LNK2005: "public: __thiscall std::basic_string,class std::allocator >::~basic_string,class std::allocator >(void)" (??1?$basic_string@DU?$char_traits@D@std@ @V?$allocator@D@2@@std@@QAE@XZ) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_system-vc100-mt-gd-1_46_1.lib(error_code.obj) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::erase(unsigned int,unsigned int)" (?erase@?$basic_string@DU?$char_traits@D@std@ @V?$allocator@D@2@@std@@QAEAAV12@II@Z) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_system-vc100-mt-gd-1_46_1.lib(error_code.obj) : error LNK2005: "public: unsigned int __thiscall std::basic_string,class std::allocator >::size(void)const " (?size@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QBEIXZ) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_system-vc100-mt-gd-1_46_1.lib(error_code.obj) : error LNK2005: "public: void __thiscall std::basic_string,class std::allocator >::_Tidy(bool,unsigned int)" (?_Tidy@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@ @QAEX_NI@Z) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_system-vc100-mt-gd-1_46_1.lib(error_code.obj) : error LNK2005: "public: char * __thiscall std::basic_string,class std::allocator >::_Myptr(void)" (?_Myptr@ ?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEPADXZ) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_system-vc100-mt-gd-1_46_1.lib(error_code.obj) : error LNK2005: "public: __thiscall std::_String_val >::_String_val >(class std::allocator)" (??0?$_String_val@DV?$allocator@D@std@@@std@@QAE@V ?$allocator@D@1@@Z) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_system-vc100-mt-gd-1_46_1.lib(error_code.obj) : error LNK2005: "public: __thiscall std::_String_val >::~_String_val >(void)" (??1?$_String_val@DV?$allocator@D@std@@@std@@QAE@XZ) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_system-vc100-mt-gd-1_46_1.lib(error_code.obj) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::operator=(class std::basic_string,class std::allocator > const &)" (??4?$basic_string@DU?$char_traits@D@std@ @V?$allocator@D@2@@std@@QAEAAV01@ABV01@@Z) already defined in aoslcpp.lib(aoslcpp.dll) 1>libboost_system-vc100-mt-gd-1_46_1.lib(error_code.obj) : error LNK2005: "public: unsigned int __thiscall std::basic_string,class std::allocator >::max_size(void)const " (?max_size@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QBEIXZ) already defined in aoslcpp.lib(aoslcpp.dll) Now I don't understand how to fix the problem in the generated code. As said in my previous email, I tried the solutions suggested in the discussion without any success. I also tried to just not generated inline files but it makes compilation errors with types not found (because it's type-per-file I guess?). Do you have some suggestions I might try? If the problem is really about inheriting std::string, how can I change this? Jo?l Lamotte From rtc at cdl.uni-saarland.de Wed Jul 6 06:30:57 2011 From: rtc at cdl.uni-saarland.de (Peter Backes) Date: Wed Jul 6 06:31:03 2011 Subject: [xsd-users] License and Portability In-Reply-To: References: <20110701144135.GC30135@cookie.cs.uni-saarland.de> <20110701201026.GA28060@cookie.cs.uni-saarland.de> Message-ID: <20110706103057.GA26127@cookie.cs.uni-saarland.de> 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 -- Peter Backes, rtc@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 From bschindler at inf.ethz.ch Wed Jul 6 06:36:13 2011 From: bschindler at inf.ethz.ch (Benjamin Schindler) Date: Wed Jul 6 06:39:39 2011 Subject: [xsd-users] License and Portability In-Reply-To: <20110706103057.GA26127@cookie.cs.uni-saarland.de> References: <20110701144135.GC30135@cookie.cs.uni-saarland.de> <20110701201026.GA28060@cookie.cs.uni-saarland.de> <20110706103057.GA26127@cookie.cs.uni-saarland.de> Message-ID: <4E143A9D.60000@inf.ethz.ch> 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 > From boris at codesynthesis.com Wed Jul 6 07:30:15 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Jul 6 07:33:07 2011 Subject: [xsd-users] License and Portability In-Reply-To: <20110706103057.GA26127@cookie.cs.uni-saarland.de> References: <20110701144135.GC30135@cookie.cs.uni-saarland.de> <20110701201026.GA28060@cookie.cs.uni-saarland.de> <20110706103057.GA26127@cookie.cs.uni-saarland.de> Message-ID: Hi Peter, Peter Backes writes: > 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 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. I think what plays an important role is the way these fragments are arranged and are interacting to perform something useful. 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 same holds true for bison/lex; you merely state what kind of language you want to parse/lex, not how to achieve this. 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 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. FLOSSE gives you permission to license your program under various open-source licenses, many of which are GPLv2-incompatible. > 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. 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. > 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? To issues: 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. 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). Boris From boris at codesynthesis.com Wed Jul 6 07:32:13 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Jul 6 07:34:53 2011 Subject: [xsd-users] License and Portability In-Reply-To: <4E143A9D.60000@inf.ethz.ch> References: <20110701144135.GC30135@cookie.cs.uni-saarland.de> <20110701201026.GA28060@cookie.cs.uni-saarland.de> <20110706103057.GA26127@cookie.cs.uni-saarland.de> <4E143A9D.60000@inf.ethz.ch> Message-ID: Hi Benjamin, Benjamin Schindler writes: > So the only way to challenge this is consulting a lawyer/the FSF. A layer/FSF can only give an opinion. To really challenge this would require a court and a judge. Boris From rtc at cdl.uni-saarland.de Thu Jul 7 06:03:27 2011 From: rtc at cdl.uni-saarland.de (Peter Backes) Date: Thu Jul 7 06:03:32 2011 Subject: [xsd-users] License and Portability In-Reply-To: References: <20110701144135.GC30135@cookie.cs.uni-saarland.de> <20110701201026.GA28060@cookie.cs.uni-saarland.de> <20110706103057.GA26127@cookie.cs.uni-saarland.de> Message-ID: <20110707100326.GA14061@cookie.cs.uni-saarland.de> 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@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 From rtc at cdl.uni-saarland.de Thu Jul 7 06:17:48 2011 From: rtc at cdl.uni-saarland.de (Peter Backes) Date: Thu Jul 7 06:17:54 2011 Subject: [xsd-users] License and Portability In-Reply-To: <4E143A9D.60000@inf.ethz.ch> References: <20110701144135.GC30135@cookie.cs.uni-saarland.de> <20110701201026.GA28060@cookie.cs.uni-saarland.de> <20110706103057.GA26127@cookie.cs.uni-saarland.de> <4E143A9D.60000@inf.ethz.ch> Message-ID: <20110707101748.GB14061@cookie.cs.uni-saarland.de> Benjamin, On Wed, Jul 06, 2011 at 12:36:13PM +0200, Benjamin Schindler wrote: > 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. This is an argument from authority, and such arguments are always invalid. Just because I am not a lawyer does not mean that what I say is wrong. I may be wrong, sure. But such an argument from authority doesn't do anything to substantiate the claim *that* I am wrong. > I'm sure Boris has consulted the FSF over this matter so he is probably > in a good position. This is arguing with mere possibilities. Has Boris consulted the FSF? I have often discussed with the FSF, and usually they offer much better solutions than those used for XSD. Maybe the FSF said the XSD way faces no major problems (after all, XSD is uncontroversially Free Software), but from my impression, they wouldn't endorse or recommend such a soltuion. > Boris has decided to put the generated code under the GPL. So the only > way to challenge this is consulting a lawyer/the FSF. No, the way I am challenging it, by arguments, is the only way. If a lawyer or the FSF can challenge this claim then by using valid arguments, and it is the fact that these arguments are valid, not that they come from FSF/lawyer, that gives them power. They may have better, different arguments and/or disagree with what I say, but this is by no means a neccessity. And many of my arguments are independent from legal questions, for example that copyright on generated code is better disclaimed than claimed, that copyright on the header library is sufficient to do what Boris wants to achieve, and that the FLOSSE should better be replaced by something that tries not to be more clever than neccessary. Regards Peter -- Peter Backes, rtc@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 From rtc at cdl.uni-saarland.de Fri Jul 8 06:15:54 2011 From: rtc at cdl.uni-saarland.de (Peter Backes) Date: Fri Jul 8 06:15:59 2011 Subject: [xsd-users] License and Portability In-Reply-To: <4E1595ED.3050603@inf.ethz.ch> References: <20110701144135.GC30135@cookie.cs.uni-saarland.de> <20110701201026.GA28060@cookie.cs.uni-saarland.de> <20110706103057.GA26127@cookie.cs.uni-saarland.de> <4E143A9D.60000@inf.ethz.ch> <20110707101748.GB14061@cookie.cs.uni-saarland.de> <4E1595ED.3050603@inf.ethz.ch> Message-ID: <20110708101554.GA17312@cookie.cs.uni-saarland.de> Benjamin, On Thu, Jul 07, 2011 at 01:18:05PM +0200, Benjamin Schindler wrote: > Reread what I said - I never said you're wrong. I said you are not in a > position to make an informed statement and you just confirmed this by > saying "I may be wrong". Everyone may be wrong. I am as much in a position to make an "informed" (what does informedness matter anyway; what counts is the truth of what I say) statement as anyone else. Lawyers, experts, etc, they have no privileged access to the truth. Truth is absolute and the same for everyone, and I can only regard statements of the contrary as authoritarian. You provide no arguments and reject mine purely based on the claim that some people can make informed statements and some cannot, and I am among the latter. You are not in a position to make an informed statement on matters concerning the status, necessity and relevance of informed statements, to speak in your language. > Yes, you tried and failed. Boris does not intend to change the license > of the generated code. So the only option you have is to force him > change it by means of going to court. Or you just ignore it and wait for > him to sue you. But if you loose, you have a big problem Boris cannot give a license on the generated code because he doesn't have copyright on it in the first place. I quoted the GPL FAQ, which is unabiguous in this respect. Anyone who denies this is denying the obvious. I do not want to force Boris to do anything, I merely want to argue that his copyright claim has no basis. What consequences he draws from this is up to him. I cannot sue Boris because he has not done something illegal--"copyfraud" (claiming a copyright you don't have) is legal. Even if I could sue Boris I wouldn't do it. I am not a copyright troll. Boris has no way to sue me. There is freedom of speech. If I want to attack Boris' claim of copyright, I can do this. It's completely legal. > You're mixing "independent from legal" and copyright in one sentence? > This is ridiculous. We're dealing with copyright so it's by definition a > legal matter. I don't like to quarrel about words. But there is a difference between what is legal and what you should do. Even if Boris is right about his copyright claim, it doesn't mean he should make it. > I cannot tell whether the way Boris deals with it is the best way. But > he has made a decision and doesn't seem willing to change this. So > please just accept that? There is nothing to accept, I am merely stating the facts that Boris has no copyright claim on the generated code and doesn't need one. What Boris does because of that is up to him. XSD is Free Software, so there is no fundamental problem. But: - IMO, nobody should rely on the FLOSSE. People should release their software under GPLv2+ if they are using XSD, such that the FLOSSE is not needed. - Unclear and too-clever legal constructions like the FLOSSE should not be used. Simpler and more practical solutions should be used instead. - Nobody should and nobody ever needs to claim copyright on generated code, nobody should try to exploit such grey areas of the law, especially not Free Software. - Code should always be licensed "or any later version" for practical reasons, at least using a proxy (see GPLv3) if there are reservations against the FSF. XSD is great software and it's Free Software. Please don't read my statements as a *fundamental* criticism. There is no problem with using XSD. Regards Peter -- Peter Backes, rtc@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 From boris at codesynthesis.com Fri Jul 8 07:16:29 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Jul 8 07:19:10 2011 Subject: [xsd-users] License and Portability In-Reply-To: <20110708101554.GA17312@cookie.cs.uni-saarland.de> References: <20110701144135.GC30135@cookie.cs.uni-saarland.de> <20110701201026.GA28060@cookie.cs.uni-saarland.de> <20110706103057.GA26127@cookie.cs.uni-saarland.de> <4E143A9D.60000@inf.ethz.ch> <20110707101748.GB14061@cookie.cs.uni-saarland.de> <4E1595ED.3050603@inf.ethz.ch> <20110708101554.GA17312@cookie.cs.uni-saarland.de> Message-ID: Peter, Benjamin, Guys, this exchange is rapidly becoming off-topic so please take it off-list. Peter, seeing that we disagree about what is copyrightable and what is not, and it doesn't seem we will be able to convince each other either way, you have to choices: 1. Disregard our copyright claims. We, however, may decide to challenge this in a court of law. 2. Do not use XSD. Boris From bschindler at inf.ethz.ch Thu Jul 7 07:18:05 2011 From: bschindler at inf.ethz.ch (Benjamin Schindler) Date: Fri Jul 8 07:37:06 2011 Subject: [xsd-users] License and Portability In-Reply-To: <20110707101748.GB14061@cookie.cs.uni-saarland.de> References: <20110701144135.GC30135@cookie.cs.uni-saarland.de> <20110701201026.GA28060@cookie.cs.uni-saarland.de> <20110706103057.GA26127@cookie.cs.uni-saarland.de> <4E143A9D.60000@inf.ethz.ch> <20110707101748.GB14061@cookie.cs.uni-saarland.de> Message-ID: <4E1595ED.3050603@inf.ethz.ch> Peter, On 07/07/2011 12:17 PM, Peter Backes wrote: > Benjamin, > > On Wed, Jul 06, 2011 at 12:36:13PM +0200, Benjamin Schindler wrote: >> 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. > > This is an argument from authority, and such arguments are always > invalid. Just because I am not a lawyer does not mean that what I say > is wrong. I may be wrong, sure. But such an argument from authority > doesn't do anything to substantiate the claim *that* I am wrong. Reread what I said - I never said you're wrong. I said you are not in a position to make an informed statement and you just confirmed this by saying "I may be wrong". > >> I'm sure Boris has consulted the FSF over this matter so he is probably >> in a good position. > > This is arguing with mere possibilities. Has Boris consulted the FSF? > I have often discussed with the FSF, and usually they offer much better > solutions than those used for XSD. Maybe the FSF said the XSD way faces > no major problems (after all, XSD is uncontroversially Free Software), > but from my impression, they wouldn't endorse or recommend such a > soltuion. > >> Boris has decided to put the generated code under the GPL. So the only >> way to challenge this is consulting a lawyer/the FSF. > > No, the way I am challenging it, by arguments, is the only way. If a > lawyer or the FSF can challenge this claim then by using valid > arguments, and it is the fact that these arguments are valid, not that > they come from FSF/lawyer, that gives them power. They may have > better, different arguments and/or disagree with what I say, but this > is by no means a neccessity. Yes, you tried and failed. Boris does not intend to change the license of the generated code. So the only option you have is to force him change it by means of going to court. Or you just ignore it and wait for him to sue you. But if you loose, you have a big problem > > And many of my arguments are independent from legal questions, for > example that copyright on generated code is better disclaimed than > claimed, that copyright on the header library is sufficient to do what > Boris wants to achieve, and that the FLOSSE should better be replaced > by something that tries not to be more clever than neccessary. You're mixing "independent from legal" and copyright in one sentence? This is ridiculous. We're dealing with copyright so it's by definition a legal matter. I cannot tell whether the way Boris deals with it is the best way. But he has made a decision and doesn't seem willing to change this. So please just accept that? Cheers Benjamin > > Regards > Peter > From drago.krznaric at se.transport.bombardier.com Fri Jul 8 12:39:15 2011 From: drago.krznaric at se.transport.bombardier.com (drago.krznaric@se.transport.bombardier.com) Date: Fri Jul 8 12:40:41 2011 Subject: [xsd-users] Drago Krznaric is out of the office. Message-ID: I will be out of the office starting 2011-07-08 and will not return until 2011-07-25. I will respond to your message when I return. From psvaiter at superig.com.br Mon Jul 11 16:45:26 2011 From: psvaiter at superig.com.br (Patrick Svaiter) Date: Tue Jul 12 07:02:19 2011 Subject: [xsd-users] XSD - Error 2 trying to make hello world Message-ID: Hi, I don't know if it's the right channel to ask for help, but it is the one that I found most correct. I am trying to use XSD Data Biding on Ubuntu 10.10. I installed xerces-c++ from Ubuntu Software Center, as it is a requirement for XSD. I haven't set any environment variable as it is described if I had installed the binaries from their site. I thought the package manager already did that, but I don't know how it works. And then I downloaded XSD for 64-bit architecture, extracted to home/username/lib/ and tried to run hello world example. What I get when I try to make is: ../../../../bin/xsd cxx-parser hello.xsd ../../../../bin/xsd: 1: Syntax error: word unexpected (expecting ")") make: *** [hello-pskel.hxx] Error 2 As I get this error at the very first example, I find that maybe there's some misconfiguration or any bad installation of something. Is there any defect with my xsd binary file? Is there any configuration missing? What do I have to do? Is there any recommended location to extract files? Thanks in advance -- Patrick Svaiter From boris at codesynthesis.com Tue Jul 12 07:23:09 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Jul 12 07:25:48 2011 Subject: [xsd-users] XSD - Error 2 trying to make hello world In-Reply-To: References: Message-ID: Hi Patrick, Patrick Svaiter writes: > And then I downloaded XSD for 64-bit architecture, extracted to > home/username/lib/ and tried to run hello world example. > What I get when I try to make is: > > ../../../../bin/xsd cxx-parser hello.xsd > ../../../../bin/xsd: 1: Syntax error: word unexpected (expecting ")") > make: *** [hello-pskel.hxx] Error 2 This is very strange. When I try to run make for this example, my XSD command line looks very different. There is definitely some misconfiguration. Can you show me the command line you are using to compile this example? Can you also try to run the XSD compiler from the command line, something like this: ../../../../bin/xsd --version Boris From psvaiter at superig.com.br Tue Jul 12 11:15:55 2011 From: psvaiter at superig.com.br (Patrick Svaiter) Date: Tue Jul 12 11:19:39 2011 Subject: [xsd-users] XSD - Error 2 trying to make hello world In-Reply-To: References: Message-ID: 2011/7/12 Boris Kolpackov > Hi Patrick, > > Patrick Svaiter writes: > > > And then I downloaded XSD for 64-bit architecture, extracted to > > home/username/lib/ and tried to run hello world example. > > What I get when I try to make is: > > > > ../../../../bin/xsd cxx-parser hello.xsd > > ../../../../bin/xsd: 1: Syntax error: word unexpected (expecting ")") > > make: *** [hello-pskel.hxx] Error 2 > > This is very strange. When I try to run make for this example, my > XSD command line looks very different. There is definitely some > misconfiguration. Can you show me the command line you are using > to compile this example? Can you also try to run the XSD compiler > from the command line, something like this: > > ../../../../bin/xsd --version > > Boris > When I try to run the command above, from the directory /home/username/lib/xsd-3.3.0-x86_64-linux-gnu/bin I get this message. The program 'xsd' is currently not installed. You can install it by typing: sudo apt-get install mono-devel I shouldn't have to install anything else besides xerces and extract codesynthesis xsd, should I? Shouldn't this xsd file work by itself? About the example, what I did was go to examples/cxx/parser/hello folder and the command I used was just make. I did not modify anything from original files. -- Patrick Svaiter From boris at codesynthesis.com Tue Jul 12 11:24:17 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Jul 12 11:27:00 2011 Subject: [xsd-users] XSD - Error 2 trying to make hello world In-Reply-To: References: Message-ID: Hi Patrick, Patrick Svaiter writes: > When I try to run the command above, from the directory > /home/username/lib/xsd-3.3.0-x86_64-linux-gnu/bin I get this message. > > The program 'xsd' is currently not installed. You can install it by typing: > sudo apt-get install mono-devel Changing to the above directory and running just 'xsd' will result in the standard search directories (the ones in the PATH environment variable) being used to look for the program. You need to either use the full path or ./xsd. Can you try this exact command line and see if it works: /home/username/lib/xsd-3.3.0-x86_64-linux-gnu/bin/xsd --version Also, you installed a 64-bit XSD binary. Are you sure you are running a 64-bit version of Ubuntu? You can find out by running: uname -m If you see x86_64 then it is 64-bit. If it is not, install the i686 XSD binary instead. Boris From psvaiter at superig.com.br Tue Jul 12 12:37:15 2011 From: psvaiter at superig.com.br (Patrick Svaiter) Date: Tue Jul 12 14:13:31 2011 Subject: [xsd-users] XSD - Error 2 trying to make hello world In-Reply-To: References: Message-ID: Hi Boris, /home/username/lib/xsd-3.3.0-x86_64-linux-gnu/bin/xsd --version > You were right. My version of Ubuntu is 32-bit, although my CPU is 64-bit. I thought the architecture had to do with the cpu. Now the command above works. But I keep getting errors. Now this one: ~/lib/xsd-3.3.0-i686-linux-gnu/examples/cxx/parser/hello$ make g++ -I../../../../libxsd -W -Wall -O3 -c driver.cxx -o driver.o In file included from hello-pskel.hxx:62, from driver.cxx:8: ../../../../libxsd/xsd/cxx/xml/char-utf8.hxx:13: fatal error: xercesc/util/XercesDefs.hpp: No such file or directory compilation terminated. make: *** [driver.o] Error 1 Can you help me with that? Thank you for the quick response. -- Patrick Svaiter From boris at codesynthesis.com Tue Jul 12 14:12:51 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Jul 12 14:15:34 2011 Subject: [xsd-users] XSD - Error 2 trying to make hello world In-Reply-To: References: Message-ID: Hi Patrick, Patrick Svaiter writes: > xercesc/util/XercesDefs.hpp: No such file or directory Install the libxerces-c-dev Ubuntu package. Boris From psvaiter at superig.com.br Tue Jul 12 14:34:10 2011 From: psvaiter at superig.com.br (Patrick Svaiter) Date: Wed Jul 13 06:20:45 2011 Subject: [xsd-users] XSD - Error 2 trying to make hello world In-Reply-To: References: Message-ID: > > Install the libxerces-c-dev Ubuntu package. > Thank you very much, Boris. That works. -- Patrick Svaiter From bhartsb at gmail.com Wed Jul 13 12:40:42 2011 From: bhartsb at gmail.com (B Hart) Date: Wed Jul 13 12:40:50 2011 Subject: [xsd-users] linker errors Message-ID: I built the XERCES static library and I'm attempting to use it with the hello sample. I'm getting linker errors such as: Error 1 error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall xercesc_3_1::Wrapper4InputSource::~Wrapper4InputSource(void)" (__imp_??1Wrapper4InputSource@xercesc_3_1@@UAE@XZ) C:\Program Files\CodeSynthesis XSD 3.3\examples\cxx\tree\hello\hello.obj hello Any idea how I can resolve. I've included the library in the project. Thanks. From boris at codesynthesis.com Wed Jul 13 12:57:43 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Jul 13 13:00:20 2011 Subject: [xsd-users] linker errors In-Reply-To: References: Message-ID: Hi Brian, B Hart writes: > I built the XERCES static library and I'm attempting to use it with the > hello sample. I'm getting linker errors such as: > > Error 1 error LNK2001: unresolved external symbol > "__declspec(dllimport) public: virtual __thiscall > xercesc_3_1::Wrapper4InputSource::~Wrapper4InputSource(void)" Quoting the Xerces-C++ 3-series build instructions[1]: "If you are linking your application to the static Xerces-C++ library, then you will need to compile your application with the XERCES_STATIC_LIBRARY preprocessor macro defined in order to turn off the DLL import/export mechanism." So adding XERCES_STATIC_LIBRARY to the preprocessor defines should fix this. [1] http://xerces.apache.org/xerces-c/build-3.html Boris From bhartsb at gmail.com Wed Jul 13 14:29:20 2011 From: bhartsb at gmail.com (B Hart) Date: Thu Jul 14 06:07:57 2011 Subject: [xsd-users] Can't compile against XSD Re: Error 1 error MSB3721 Message-ID: I have a XSD that I attempted to compile and received the error below. I'm attaching the XSDs. The root element is EMSDataSet. Thank you. Error 1 error MSB3721: The command "xsd.exe cxx-tree --generate-serialization --output-dir "." --hxx-suffix ".hxx" --cxx-suffix ".cxx" --ixx-suffix ".ixx" --fwd-suffix "-fwd.hxx" --root-element "EMSDataSet" ..\NEMSIS_XSDs_v2.2.1\EMSDataSet.xsd" exited with code 1. C:\Program Files\CodeSynthesis XSD 3.3\etc\vc-10.0\xsd-cxx-tree.targets 45 6 NEMSISV2Reader Clicking on it shows: Lines="^%(CXX_Tree_Mapping_Rule_tlog.Source);@(CXX_Tree_Mapping_Rule_tlog->'%(Fullpath)')" /> References: Message-ID: Hi, B Hart writes: > I have a XSD that I attempted to compile and received the error below. I'm > attaching the XSDs. The root element is EMSDataSet. > > Error 1 error MSB3721: The command "xsd.exe cxx-tree > --generate-serialization --output-dir "." --hxx-suffix ".hxx" --cxx-suffix > ".cxx" --ixx-suffix ".ixx" --fwd-suffix "-fwd.hxx" --root-element > "EMSDataSet" ..\NEMSIS_XSDs_v2.2.1\EMSDataSet.xsd" exited with code 1. When I try to compile this schema, I get this error message: E00_ReferenceTables.xsd:4:122: error: unable to map XML Schema namespace 'http://www.nemsis.org' to C++ namespace E00_ReferenceTables.xsd:4:122: info: use the --namespace-map or --namespace-regex option to provide custom mapping You should have gotten it as well in your compilation window, before the one you showed above. Boris