Re: Licence issues in hyphenation patterns
J.Pietschmann wrote: [..] BTW we should track down and delete all binary distribution no.xml appears first in FOP 0.19.0. containing the compiled hyph file from the three GPL sources. The source distributions are not an immediate risk and can be The source distribution also includes fop.jar kept. Who has access to the distro repository? I think it's sufficient to remove the patterns (both .xml and .hyp) from the distributions in question and then add an 'a' after the version number. What do you think? Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
+1 On 25.02.2003 15:42:02 Christian Geisert wrote: I think it's sufficient to remove the patterns (both .xml and .hyp) from the distributions in question and then add an 'a' after the version number. What do you think? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
On Sat, 22 Feb 2003, Peter B. West wrote: As long as we are still able to recover complete historical binary distributions. If a problem arises over a past distribution, we are far better off if we can refer to the actual distribution, even if that is no longer available for general distribution. If you are worried about such things - you can -always- ask the secretary of the board (Jim Jagielski) to put something on file. On paper, or digital - with a date and to be kept for prosetiry. I.e. as an incorperated foundation we have the framework for such things. Dw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
On Fri, 21 Feb 2003, J.Pietschmann wrote: I am donating the hyphenation file to the ASF, and although it would be nice to keep the copyright, I think that would hamper future enhancements, or not? As long as you don't choose to revoke the license for all future and past versions (rather than forking or whatever), there wouldn't be a problem. This was recently extensively If you guys want to play it safe; which I strongly suggest you do - then work with the pmc to do document this in a simple 'grant'. I've attached a copy. You simply fill this out out and simply fax/snail it to the ASF. The correct address is at: http://www.apache.org/foundation/contact.html As the description in exhibit A you put something like: 'name of the file(s) (plain, tar or zip)' 'description of what is in them' md5 checksum or if you feel very heroic you could put them on CD and mail that by snail mail. But md5's are fine too. You can also reference a message on a mailing list: Exhibit A The code as contained in the message of Friday, 21 February 2003, 00:12:05 +0100, with message-ID: [EMAIL PROTECTED] as send by Peter Poo [EMAIL PROTECTED] to the mailing list [EMAIL PROTECTED] with an md5=12890341289037123489 Note that committers doing their own code imports do not have to do 'grant's - as their code is already covered by a blanket statement they've made when they became a committer. This is when we accept stuff from a third party. Dw License Agreement This License Agreement is entered into as of the ___ day of , __ by ___ (Licensor), in favor of The Apache Software Foundation, a Delaware nonstock membership corporation (the Foundation). WHEREAS, Licensor owns or has sufficient rights to contribute the software source code and other related intellectual property as itemized on Exhibit A (Software) under the terms of this agreement to the Foundation for use within Foundation software development projects (Projects). NOW, THEREFORE, FOR GOOD AND VALUABLE CONSIDERATION, the receipt and legal sufficiency of which are hereby acknowledged, the parties hereto, intending to be legally bound, agree as follows: 1. Subject to the terms and conditions of this License, Licensor hereby grants to the Foundation: a) a non-exclusive, worldwide, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, distribute and sublicense, internally and externally, the Software and such derivative works, in source code and object code form; and, b) a non-exclusive, worldwide, royalty-free, irrevocable patent license under Licensed Patents to make, use, sell, offer to sell, import and otherwise transfer the Software in source code and object code form. Licensed Patents mean patent claims owned by Licensor which are necessarily infringed by the use or sale of the Software alone. 2. Licensor represents that, to Licensor's knowledge, Licensor is legally entitled to grant the above license. Licensor agrees to notify the Foundation of any facts or circumstances of which Licensor becomes aware and which makes or would make Licensor's representations in this License Agreement inaccurate in any respect. 3. This Software is provided AS-IS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. NEITHER THE LICENSOR NOR ITS SUPPLIERS WILL BE LIABLE TO THE FOUNDATION OR ITS LICENSEES FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OR DISTRIBUTION OF THE WORK OR THE EXERCISE OF ANY RIGHTS GRANTED HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. This License Agreement is the entire agreement of the parties with respect to its subject matter, and may only be amended by a writing signed by each party. This License Agreement may be executed in one or more counterparts, each of which shall be considered an original. IN WITNESS WHEREOF, Licensor has executed this License Agreement as of the date first written above. LICENSOR: Signed By: _ Print Name: Title: _ Representing: __ Exhibit A List of software and other intellectual property covered by this agreement: - To unsubscribe, e-mail: [EMAIL PROTECTED] For
Re: Licence issues in hyphenation patterns
Jeremias Maerki wrote: The important part for us is that the LPPL is not viral, with the exception of the filename prohibition. In particular it allows distributing derived work (read: binary FOP distributions) without the code. Yes, but see point 4, for example. That will be difficult for the compiled hyphenation patterns. We can place a LICENSE file mentioning the exceptions and providing the required pointers (if necessary) into the binary distribution. The point was that the LPPL does not infect the whole distribution summarily. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
Jeremias Maerki wrote: On 20.02.2003 23:58:48 J.Pietschmann wrote: BTW we should track down and delete all binary distribution containing the compiled hyph file from the three GPL sources. The source distributions are not an immediate risk and can be kept. Who has access to the distro repository? Good thought! As long as we are still able to recover complete historical binary distributions. If a problem arises over a past distribution, we are far better off if we can refer to the actual distribution, even if that is no longer available for general distribution. -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
Victor Mote wrote: I don't think the LPPL works at all for us. The preamble says: You may distribute a complete, unmodified copy of The Program. Distribution of only part of The Program is not allowed. Well, as I already wrote in another post, it's not really clear what The Program is in the context of the hyphenation files. The case I examined had *only* the hyphenation file in the directory the URL pointed to, with no visible affilations to any other files from either the context nor the file itself (did not mention ..is part of The Program or something. I concluded The Program is in this case the hyphenation file itself. Also I think the preamble refers to *unmodified* files. Derived works seems not to be covered there. The important part for us is that the LPPL is not viral, with the exception of the filename prohibition. In particular it allows distributing derived work (read: binary FOP distributions) without the code. BTW we should track down and delete all binary distribution containing the compiled hyph file from the three GPL sources. The source distributions are not an immediate risk and can be kept. Who has access to the distro repository? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
Jeremias Maerki wrote: You could be right about apply the Apache licence. Does everbody agree in this case? Unless the old license somehow prevents it, we can choose any license we like for any Derived Work we can claim copyright for (golly... though shalt not and a sentence with a preposition, lest they think you come from Texas... :-) J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
[EMAIL PROTECTED] wrote: Creating patterns for Portuguese is much simpler than with English. Thank you for the explanation. I *knew* there should be something easier than english. Or german. Or hungarian, FTM. There is still an unresolved issue: why do so many people still use english? :-) Actually I did this in my spare time, and only some months later I came to use it in a company project that used FOP (with my influence, of course). So the file is not property of Petrobrás, it is mine. Good to hear! But my employee wouldn't care anyway. Petrobrás' business is oil, not software, You wouldn't believe where PHBs go searching for something to squeeze money out of when funds run short... I am donating the hyphenation file to the ASF, and although it would be nice to keep the copyright, I think that would hamper future enhancements, or not? As long as you don't choose to revoke the license for all future and past versions (rather than forking or whatever), there wouldn't be a problem. This was recently extensively discussed on slashdot in response to an interview with a real lawyer. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
[EMAIL PROTECTED] wrote: I am donating the hyphenation file to the ASF, and although it would be nice to keep the copyright, I think that would hamper future enhancements, or not? As long as you don't choose to revoke the license for all future and past versions (rather than forking or whatever), there wouldn't be a problem. This was recently extensively discussed on slashdot in response to an interview with a real lawyer. From a quick look at the contributors license (I couldn't find a link that works) it appears that when code is contributed to the ASF the copyright is granted to the ASF. THe contributor does reserve remaining rights, title and interest. I don't know if code contributed under this agreement is the same as code contributed with normal patches etc., maybe it is implied? Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
On 20.02.2003 23:58:48 J.Pietschmann wrote: Victor Mote wrote: I don't think the LPPL works at all for us. The preamble says: You may distribute a complete, unmodified copy of The Program. Distribution of only part of The Program is not allowed. Well, as I already wrote in another post, it's not really clear what The Program is in the context of the hyphenation files. The case I examined had *only* the hyphenation file in the directory the URL pointed to, with no visible affilations to any other files from either the context nor the file itself (did not mention ..is part of The Program or something. I concluded The Program is in this case the hyphenation file itself. I agree. Also I think the preamble refers to *unmodified* files. Derived works seems not to be covered there. The important part for us is that the LPPL is not viral, with the exception of the filename prohibition. In particular it allows distributing derived work (read: binary FOP distributions) without the code. Yes, but see point 4, for example. That will be difficult for the compiled hyphenation patterns. BTW we should track down and delete all binary distribution containing the compiled hyph file from the three GPL sources. The source distributions are not an immediate risk and can be kept. Who has access to the distro repository? Good thought! Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
On 17.02.2003 17:36:13 Victor Mote wrote: Jeremias Maerki wrote: Todos, as I see them: - Remove all incompatible hyphenation files from CVS which are not clear to be ok. - Find Apache-compatible hyphenation files. I found a generic TeX distribution that came with my Red Hat (the relevant files are installed into /usr/share/texmf/tex/generic/hyphen). I /think/ these are standard generic TeX files, which would be subject to Knuth's license, which IMO is Apache-compatible. It seems like the best approach is to start with these, let contributors modify them as necessary. They contain do not change caveats from Knuth, but after reading his various papers on the subject, IMO, the purpose of this is to maintain TeX compatibility among diverse systems. People are free to take his work as a starting place, but you cannot use the name TeX. I've tried to locate the sources you mentioned on the net, but haven't succeeded. Can you give us a URL? - Contact the authors of non-GPL and non-LPPL hyphenation files for permission to use and redistribute their hyphenation files. This would be unnecessary if we start with the right base build from there. - Maybe write a parser for Tex hyphenation files so they can be directly read by FOP (without conversion to XML, so people can download the hyphenation files themselves and make them responsible to follow the individual licences) I have no objection to this, but the conversion does not look very complicated, and if we distribute our own, then there is no need for it. Also, if we build our own, we should credit Knuth TeX, but also explicitly reference the Apache license in the files, so that contributors know they are contributing under that license. Well, that depends on the licence. We cannot just simply credit Knuth TeX and apply the Apache licence. Jörg's analysis of the situation is pretty accurate IMO. This is a non-trivial matter. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
J.Pietschmann [EMAIL PROTECTED] Sorry for being unclear and short-spoken, I didn't meant to offend you. Jeez, I was not. I think _I_ was not clear when posting the files. However, did you really start with an empty file in an editor and typed in all the pattern strings? There are Original Works. If someone creates a new file by typing stuff into an editor he creates an Original Work. Running the hyphenation pattern programm on a properly marked up dictionary or corpus is probably also creating an Original Work, with certain caveats (it wasn't, for example, if the dictionary was marked up by someone else for the sole purpose of serving as input for the hyphenation pattern program). [...] Again, you probably used some data to derive the patterns, be it a corpus or a TeX file. [...] Creating patterns for Portuguese is much simpler than with English. While hyphenation in English is driven by etymology and is highly irregular (hence the pattern generator procedures), in Portuguese it is dictated solely by prosody and is highly regular. Only a few pathologic cases with irregular pronunciation must be treated as exceptions. So what I did was to write patterns for all possible combinations of letters. Again, that was possible because there are lexical rules restricting the valid combinations. When a new word enters a Portuguese dictionary, it must conform to these rules -- for example, basket became basquete, because 'k' is not part of our alphabet and words cannot end with a 't'. This happens with other languages as well, (e.g. Spanish and Turkish), and this affects the size of the hyphenation files, which are much smaller. And while the English hyphenation patterns can fail for some new strange word that depparts statistically from the others, the Portuguese patterns work with any word, past or future, that conforms to the current (2003 AD) Portuguese lexical rules. That means the only other works I used to write the files were: - a Portuguese grammar, listed in the file; - a Portuguese dictionary, to check some spellings, also referenced; - the FOP documentation and a file describing the TEX algorithm (I thought it wasn't necessary to reference that). In this file you generously transferred your copyright to the ASF (this fact crept into my brain only after I committed the file). Actually I did this in my spare time, and only some months later I came to use it in a company project that used FOP (with my influence, of course). So the file is not property of Petrobrás, it is mine. But my employee wouldn't care anyway. Petrobrás' business is oil, not software, we only keep to us software that carries proprietary technology (our petrochemical process simulator, for example). I am donating the hyphenation file to the ASF, and although it would be nice to keep the copyright, I think that would hamper future enhancements, or not? Sorry, I'm not much into this legal stuff, it alocates too many neurons, and my resources are scarse... :-) = Marcelo Jaccoud Amaral Petrobrás (http://www.petrobras.com.br) mailto:[EMAIL PROTECTED] = I'm not tense, I'm just terribly, terribly alert. Para: [EMAIL PROTECTED] 18/02/2003 19:23 cc: Favor responder aAssunto: Re: Licence issues in hyphenation patterns fop-dev [EMAIL PROTECTED] wrote: I didn't modify the old pt.xml file, I wrote a new one entirely from scratch. ... The original TEX file was made by Paulo Rezende, now back in Brazil (at Unicamp), and it was converted by Paulo Soares (working presently in Portugal), who I contacted at the time. He posted no objection of us replacing the file. Asking him was nice, but from a legal point of view, he can't sue anyone for replacing his file by something else :-) J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Licence issues in hyphenation patterns
Jeremias Maerki wrote: I found a generic TeX distribution that came with my Red Hat (the relevant files are installed into /usr/share/texmf/tex/generic/hyphen). I /think/ these are standard generic TeX files, which would be subject to Knuth's license, which IMO is Apache-compatible. It seems like the best approach is to start with these, let contributors modify them as necessary. They contain do not change caveats from Knuth, but after reading his various papers on the subject, IMO, the purpose of this is to maintain TeX compatibility among diverse systems. People are free to take his work as a starting place, but you cannot use the name TeX. I've tried to locate the sources you mentioned on the net, but haven't succeeded. Can you give us a URL? I don't know where they are on the net, but I'll be happy to email them to you. Or, if you have a Red Hat distribution, you might be able to find them there. Also, if we build our own, we should credit Knuth TeX, but also explicitly reference the Apache license in the files, so that contributors know they are contributing under that license. Well, that depends on the licence. We cannot just simply credit Knuth TeX and apply the Apache licence. Jörg's analysis of the situation is pretty accurate IMO. This is a non-trivial matter. Maybe I missed something in Joerg's analysis, or maybe I forgot to summarize the Knuth/TeX license. Essentially, it is this: Use this software for anything that you wish, but don't modify it and call it TeX. In other words, Knuth retains control over TeX, but has no objection to anyone taking that code starting another project with it -- he just doesn't want any confusion over what is TeX. I agree that it is a non-trivial matter, and that we need to respect everyone's rights, so if I have misunderstood something, please set me straight. Otherwise, I think we really can simply apply the Apache license to that work. The credits are simple courtesy. I just think it is better to start with something that works, even if incomplete, and have contributors add to it to make it complete, than to try to mess with the other licenses. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
On 18.02.2003 22:07:13 J.Pietschmann wrote: snip/ The LPPL'd hyphenation have to be checked thouroughly because of LPPL 1. Condition 2 does not apply. Condition 7 is fulfilled by keeping the file under LPPL. 3 is probably trivially ok as mentioned above. 4, 5 and 6 can be easily checked and corrected, and 8(B) should be easy too. I can look into it this weekend. Thank you, that'd be great! It didn't occur to me that we could leave the licence of some source files as is. I thought that would only apply to third-party JARs. Nonetheless, before I'd like to allow any LPPL file to reside in our repository I want the approval from the board or licencing@. At least the process of officially approving other licences and publishing the results for all to see has kicked off. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
On 19.02.2003 17:56:27 Victor Mote wrote: Jeremias Maerki wrote: I found a generic TeX distribution that came with my Red Hat (the relevant files are installed into /usr/share/texmf/tex/generic/hyphen). I /think/ these are standard generic TeX files, which would be subject to Knuth's license, which IMO is Apache-compatible. It seems like the best approach is to start with these, let contributors modify them as necessary. They contain do not change caveats from Knuth, but after reading his various papers on the subject, IMO, the purpose of this is to maintain TeX compatibility among diverse systems. People are free to take his work as a starting place, but you cannot use the name TeX. I've tried to locate the sources you mentioned on the net, but haven't succeeded. Can you give us a URL? I don't know where they are on the net, but I'll be happy to email them to you. Or, if you have a Red Hat distribution, you might be able to find them there. Would you email them to me? Thanks! Also, if we build our own, we should credit Knuth TeX, but also explicitly reference the Apache license in the files, so that contributors know they are contributing under that license. Well, that depends on the licence. We cannot just simply credit Knuth TeX and apply the Apache licence. Jörg's analysis of the situation is pretty accurate IMO. This is a non-trivial matter. Maybe I missed something in Joerg's analysis, or maybe I forgot to summarize the Knuth/TeX license. Essentially, it is this: Use this software for anything that you wish, but don't modify it and call it TeX. In other words, Knuth retains control over TeX, but has no objection to anyone taking that code starting another project with it -- he just doesn't want any confusion over what is TeX. I agree that it is a non-trivial matter, and that we need to respect everyone's rights, so if I have misunderstood something, please set me straight. Otherwise, I think we really can simply apply the Apache license to that work. The credits are simple courtesy. I just think it is better to start with something that works, even if incomplete, and have contributors add to it to make it complete, than to try to mess with the other licenses. It's ok. I thought there would be more than this single sentence attached to the sources. I just wanted to check on the original licence. You could be right about apply the Apache licence. Does everbody agree in this case? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Licence issues in hyphenation patterns
Jeremias Maerki wrote: On 18.02.2003 22:07:13 J.Pietschmann wrote: snip/ The LPPL'd hyphenation have to be checked thouroughly because of LPPL 1. Condition 2 does not apply. Condition 7 is fulfilled by keeping the file under LPPL. 3 is probably trivially ok as mentioned above. 4, 5 and 6 can be easily checked and corrected, and 8(B) should be easy too. I can look into it this weekend. Thank you, that'd be great! It didn't occur to me that we could leave the licence of some source files as is. I thought that would only apply to third-party JARs. Nonetheless, before I'd like to allow any LPPL file to reside in our repository I want the approval from the board or licencing@. At least the process of officially approving other licences and publishing the results for all to see has kicked off. I don't think the LPPL works at all for us. The preamble says: You may distribute a complete, unmodified copy of The Program. Distribution of only part of The Program is not allowed. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
And, well, I hope our PetroBras friend changed enough of the pt.xml to claim copyright, as he assigned it summarily to the ASF... nice, but a real legal burden! I checked it in, but now I think I should have asked for a paper first. I didn't modify the old pt.xml file, I wrote a new one entirely from scratch. If you diff the files you can see that very clearly. The old one didn't even take accented characters into consideration (he claimed so, but the patterns contained no accented characters), and produced a lot of errors. It also defined some words in the exception section which where hyphenated incorrectly. The original TEX file was made by Paulo Rezende, now back in Brazil (at Unicamp), and it was converted by Paulo Soares (working presently in Portugal), who I contacted at the time. He posted no objection of us replacing the file. (In fact, he doesn't use FOP at all and actually works in a rival project...) = Marcelo Jaccoud Amaral Petrobrás (http://www.petrobras.com.br) mailto:[EMAIL PROTECTED] = A História é uma velhota que se repete sem cessar. Eça de Queiroz, in Cartas de Inglaterra - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
Christian Geisert wrote: And IMHO (and IANAL etc.) this is the crux as the Apache Software License does not forbid renamming the files. Yes, that's hairsplitting and comletly against common sense but remember we're talking about legal issues her. I meant the following LPPL condition: 3. You must not distribute the modified file with the filename of the original file. (from http://www.latex-project.org/lppl.txt) Because the FOP files end in .xml rather than .tex, we conform at least technically. The idea was probably to avoid the confusion of having several hyphde.tex files floating around, vaguely similar to the prohibition of using Apache for products derived from ASF code. A binary distribution is another matter because of the compiled *.hyph files, which are obviously derived. But again it should Hu? Above you said the XML files are also derived. What's the difference between source and binary distribution? The XML files (at least the file I examined) had a pointer to the original file, as required by LPPL 8(B). The binaries obviously don't have it, so we have to put this elsewhere preferably in the place where it's mentioned that certain compiled hyph files derived from LPPL'd files. I'm not sure whether our hyph compilation consitutes a mechanical transformation, which causes the result to be another representation of the Original Work so that it inherits the copyright and the license of the source, or whether the serialized class is a Derived Work, where we could claim copyright and set license conditions. The LPPL'd hyphenation have to be checked thouroughly because of LPPL 1. Condition 2 does not apply. Condition 7 is fulfilled by keeping the file under LPPL. 3 is probably trivially ok as mentioned above. 4, 5 and 6 can be easily checked and corrected, and 8(B) should be easy too. I can look into it this weekend. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
[EMAIL PROTECTED] wrote: I didn't modify the old pt.xml file, I wrote a new one entirely from scratch. ... Sorry for being unclear and short-spoken, I didn't meant to offend you. However, did you really start with an empty file in an editor and typed in all the pattern strings? The issues are as follows. There are Original Works. If someone creates a new file by typing stuff into an editor he creates an Original Work. Running the hyphenation pattern programm on a properly marked up dictionary or corpus is probably also creating an Original Work, with certain caveats (it wasn't, for example, if the dictionary was marked up by someone else for the sole purpose of serving as input for the hyphenation pattern program). Mechanically transforming an Original Work creates another represenation of this work, for example changing Unix LF to DOS CRLF, or changing ISO-8859-9 encoding into UTF-8 encoding. You can't claim copyright to the result of such a transformation. In order to claim copyright you have to do some non-trivial processing, preferably involving some manual work. This creates a Derived Work (unless you mutilated the original thouroughly enough that you again created an Original Work). Whether cutpaste significant portions of a TeX hyphenation file into a thin XML frame can be considered a Mechanical Transformation or whether it is non-trivial enough to make a Derived Work has yet to be decided in court. Adding hyphenation exceptions should suffice though. Anyway, I suppose you can claim copyright for the file you submitted. This is, however, not yet the end of the story. Again, you probably used some data to derive the patterns, be it a corpus or a TeX file. You'll have to check (and/or decide) whether you produced an Original Work, i.e. you did by far the most work yourself, and none of your data sources prohibited you by any means to perform this work, or whether you created a Derived Work. In the second case, the license of your source data may place restrictions on your work in case you want to have it distributed (nobody can prevent you from using basically anything in private). For example, if you used an LPPL'd TeX file as source, you can choose the license of your work (LPPL isn't as viral as GPL), but you can't place it for example under APL because of the file name restriction. You are forced to either put your work under LPPL again, or an amended APL, or roll your own. This is *still* not everything. You supplied a whole file, not a patch. In this file you generously transferred your copyright to the ASF (this fact crept into my brain only after I committed the file). You have to be legally entitled to do so. If making file was part of your work, or related to your work, you should check your contract whether you can claim copyright for your work yourself and do what you want with it, common practice is that by signing your contract you give up everything to your employer. In this case the ASF needs a paper signed by you and your boss which explicitely states that the copyright for the file was assigned to the ASF. You can find a template here http://jakarta.apache.org/site/agreement.html Note that small patches are different, in this case I as a committer create a Derived Work, and unless you as the patch submitter put a viral licence into it, I can put the result under APL (implicitely), and I already have sent in a paper assigning my copyright away. Well, to keep it short, I'd vote to spare you the paperwork if you tell us that you have the right to put the file under the Apache license and assign the copyright to the ASF (you can keep it if you want). The original TEX file was made by Paulo Rezende, now back in Brazil (at Unicamp), and it was converted by Paulo Soares (working presently in Portugal), who I contacted at the time. He posted no objection of us replacing the file. Asking him was nice, but from a legal point of view, he can't sue anyone for replacing his file by something else :-) J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
Jeremias Maerki wrote: On 15.02.2003 18:05:31 Christian Geisert wrote: [..] sidenote While doing a quick search for other hyphenation optiones I've found a hyphenation dictionary which is based on the TeX hyphenation tables and licensed under GNU LGPL ... /sidenote Do you have a link? LGPL is not unproblematic as could be seen in recent http://whiteboard.openoffice.org/lingucomponent/download_dictionary.html?JServSessionIdservlets=v100ota723#hyphenation See README in hyph_de_DE.zip But I'm not proposing to use those patterns, I was just wondering if it's ok to re-license it under LGPL. discussions on community@. I would want clearance from higher up before we used and (a different topic) redistributed the hyphenation patterns. I can take this to the PMC and to licencing if necessary. +1 [..] Todos, as I see them: - Remove all incompatible hyphenation files from CVS which are not clear to be ok. So remove everything excpet fi, pl and pt? - Find Apache-compatible hyphenation files. Would be the best solution. - Contact the authors of non-GPL and non-LPPL hyphenation files for permission to use and redistribute their hyphenation files. Could be troublesome (for example the german pattern file mentions three authors) Any volunteers? - Maybe write a parser for Tex hyphenation files so they can be directly read by FOP (without conversion to XML, so people can download the hyphenation files themselves and make them responsible to follow the individual licences) IIUC we don't have to change the way the pattern are read, the problem is the distribuition. For example it should be ok if we create a new SourceForge project with just the hyphenation patterns and license it under LPPL. Then people could download the jar, put it in the lib dir and everything should be fine. - Maybe adjust FOP so it is more flexible reading hyphenation files. - Add something to future release notes about hyphenation. Jeremias Maerki Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
On 17.02.2003 16:16:55 Christian Geisert wrote: Jeremias Maerki wrote: On 15.02.2003 18:05:31 Christian Geisert wrote: [..] sidenote While doing a quick search for other hyphenation optiones I've found a hyphenation dictionary which is based on the TeX hyphenation tables and licensed under GNU LGPL ... /sidenote Do you have a link? LGPL is not unproblematic as could be seen in recent http://whiteboard.openoffice.org/lingucomponent/download_dictionary.html?JServSessionIdservlets=v100ota723#hyphenation See README in hyph_de_DE.zip But I'm not proposing to use those patterns, I was just wondering if it's ok to re-license it under LGPL. Interesting. discussions on community@. I would want clearance from higher up before we used and (a different topic) redistributed the hyphenation patterns. I can take this to the PMC and to licencing if necessary. +1 [..] Todos, as I see them: - Remove all incompatible hyphenation files from CVS which are not clear to be ok. So remove everything excpet fi, pl and pt? Yep, can you do that or shall I? - Find Apache-compatible hyphenation files. Would be the best solution. - Contact the authors of non-GPL and non-LPPL hyphenation files for permission to use and redistribute their hyphenation files. Could be troublesome (for example the german pattern file mentions three authors) Any volunteers? I can try. - Maybe write a parser for Tex hyphenation files so they can be directly read by FOP (without conversion to XML, so people can download the hyphenation files themselves and make them responsible to follow the individual licences) IIUC we don't have to change the way the pattern are read, the problem is the distribuition. No. The patterns in FOP are currently in some XML format. The patterns found on the web are in an ASCII format. FOP needs to be adjusted so it can read the ASCII files directly, I think. For example it should be ok if we create a new SourceForge project with just the hyphenation patterns and license it under LPPL. Then people could download the jar, put it in the lib dir and everything should be fine. If the patterns from OpenOffice work with our hyphenation system then we just need to make sure we can read them and point our users to that location. - Maybe adjust FOP so it is more flexible reading hyphenation files. - Add something to future release notes about hyphenation. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns (was: HyphenationTree bug and Portuguese hyphenation file update)
* Jeremias Maerki; [EMAIL PROTECTED] on 14 Feb, 2003 wrote: tr.xml Can't find original file. No licence. Check with author. Well, since I sent out the Turkish hyphenation file I should know where it comes right. The trhyphen.tex is installed from the SuSE 8.1 distro toganm@earth:~/hangar rpm -qf /usr/share/texmf/tex/generic/hyphen/trhyph.tex tetex-beta.20020207-254 the trhyph.tex file has the following header % A mechanically generated Turkish Hyphenation table for TeX, % using the University of Washington diacritical coding % developed by P. A. MacKay for the Ottoman Texts Project. % Slightly modified by H. Turgut Uyar. Turgut Uyar has the following addres based on google search [EMAIL PROTECTED] Would you like to contact him directly or do you want me to do so ? Although I think you can explain the needs and requirements better than I can -- Togan Muftuoglu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns (was: HyphenationTree bug and Portuguese hyphenation file update)
I can do that. Thanks for the info. On 17.02.2003 16:47:17 Togan Muftuoglu wrote: * Jeremias Maerki; [EMAIL PROTECTED] on 14 Feb, 2003 wrote: tr.xml Can't find original file. No licence. Check with author. Well, since I sent out the Turkish hyphenation file I should know where it comes right. The trhyphen.tex is installed from the SuSE 8.1 distro toganm@earth:~/hangar rpm -qf /usr/share/texmf/tex/generic/hyphen/trhyph.tex tetex-beta.20020207-254 the trhyph.tex file has the following header % A mechanically generated Turkish Hyphenation table for TeX, % using the University of Washington diacritical coding % developed by P. A. MacKay for the Ottoman Texts Project. % Slightly modified by H. Turgut Uyar. Turgut Uyar has the following addres based on google search [EMAIL PROTECTED] Would you like to contact him directly or do you want me to do so ? Although I think you can explain the needs and requirements better than I can Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
Jeremias Maerki wrote: [..] So remove everything excpet fi, pl and pt? Yep, can you do that or shall I? I'll do it. [..] IIUC we don't have to change the way the pattern are read, the problem is the distribuition. No. The patterns in FOP are currently in some XML format. The patterns found on the web are in an ASCII format. FOP needs to be adjusted so it can read the ASCII files directly, I think. I was thinking about distributing our .hyp files via SourceForge under LPPL. Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
On 17.02.2003 17:11:42 Christian Geisert wrote: Jeremias Maerki wrote: [..] So remove everything excpet fi, pl and pt? Yep, can you do that or shall I? I'll do it. Thanks! [..] IIUC we don't have to change the way the pattern are read, the problem is the distribuition. No. The patterns in FOP are currently in some XML format. The patterns found on the web are in an ASCII format. FOP needs to be adjusted so it can read the ASCII files directly, I think. I was thinking about distributing our .hyp files via SourceForge under LPPL. That seems awkward. It would be much easier to just point our users to OpenOffice or some FTP directory. Is it really necessary from a performance point of view to create the .hyp files? Does anyone know? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Licence issues in hyphenation patterns
Jeremias Maerki wrote: Todos, as I see them: - Remove all incompatible hyphenation files from CVS which are not clear to be ok. - Find Apache-compatible hyphenation files. I found a generic TeX distribution that came with my Red Hat (the relevant files are installed into /usr/share/texmf/tex/generic/hyphen). I /think/ these are standard generic TeX files, which would be subject to Knuth's license, which IMO is Apache-compatible. It seems like the best approach is to start with these, let contributors modify them as necessary. They contain do not change caveats from Knuth, but after reading his various papers on the subject, IMO, the purpose of this is to maintain TeX compatibility among diverse systems. People are free to take his work as a starting place, but you cannot use the name TeX. - Contact the authors of non-GPL and non-LPPL hyphenation files for permission to use and redistribute their hyphenation files. This would be unnecessary if we start with the right base build from there. - Maybe write a parser for Tex hyphenation files so they can be directly read by FOP (without conversion to XML, so people can download the hyphenation files themselves and make them responsible to follow the individual licences) I have no objection to this, but the conversion does not look very complicated, and if we distribute our own, then there is no need for it. Also, if we build our own, we should credit Knuth TeX, but also explicitly reference the Apache license in the files, so that contributors know they are contributing under that license. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
Christian Geisert wrote: Jeremias Maerki wrote: - Remove all incompatible hyphenation files from CVS which are not clear to be ok. So remove everything excpet fi, pl and pt? Ouch. I don't think we can distribute FOP without english hyphenation. I just had another look at the LPPL and the other files. The LPPL file I examined seems to be harmless. The license says we can distribute the hyphenation XML file as derived from the original TeX hyphenation file as long as there is a pointer/URL to the original The Program. It's not quite clear to me what The Program is in case of the hyphenation file, but it doesn't seem to include much more than the hyphenation file itself, in this case, as there isn't much more in the directory. The only other condition is that the file must have another name (no problem). I think we are safe for the source distribution including LPPL hyphenation files. A binary distribution is another matter because of the compiled *.hyph files, which are obviously derived. But again it should be safe if we include a prominent remark in a README or LICENSE that the distribution contains such and such stuff defrived from foobar files, and provide URLs to the original TeX files. Of course, getting the XML files under the Apache license would save us this hassle. As for the other files, I think es.xml is safe too. While there's mentioned the source was taken from Lout, it does not put it automatically under GPL, and there is a license further down the file which reads roughly like the artistic license. The really problematic files are cs.xml, sk.xml and no.xml, which are explicit GPL. I don't think there is harm for the ASF if these files are distributed as-is with a source distribution, but compiling them into a *.hyphs into a jar would make the entire binary distribution GPL! Mind numbing... And, well, I hope our PetroBras friend changed enough of the pt.xml to claim copyright, as he assigned it summarily to the ASF... nice, but a real legal burden! I checked it in, but now I think I should have asked for a paper first. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
J.Pietschmann schrieb: [..] Ouch. I don't think we can distribute FOP without english hyphenation. Sure we *can* ;-) But if it's a good thing ... I just had another look at the LPPL and the other files. The LPPL file I examined seems to be harmless. The license says we can distribute the hyphenation XML file as derived from the original TeX hyphenation file as long as there is a pointer/URL to the original The Program. It's not quite clear to me what The Program is in case of the hyphenation file, but it doesn't seem to include much more than the hyphenation file itself, in this case, as there isn't much more in the directory. The only other condition is that the file must have another name (no problem). And IMHO (and IANAL etc.) this is the crux as the Apache Software License does not forbid renamming the files. Yes, that's hairsplitting and comletly against common sense but remember we're talking about legal issues her. I think we are safe for the source distribution including LPPL hyphenation files. A binary distribution is another matter because of the compiled *.hyph files, which are obviously derived. But again it should Hu? Above you said the XML files are also derived. What's the difference between source and binary distribution? [..] As for the other files, I think es.xml is safe too. While there's mentioned the source was taken from Lout, it does not put it automatically under GPL, and there is a license further down the file which reads roughly like the artistic license. Ok. [..] And, well, I hope our PetroBras friend changed enough of the pt.xml to claim copyright, as he assigned it summarily to the ASF... nice, but a real legal burden! I checked it in, but now I think I should have asked for a paper first. So I'll remove it for RC2 and it will hopefully be resolved till the final release. I had another look at the files and the following seem to be ok too: en_GB.xml - may be freely distributed. it.xml - Use of the original work granted by the author Christian P.S. Yes I'm rushing a bit but I'll be on holiday from tomorrow till sunday and I want to make the RC before leaving. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns (was: HyphenationTree bug andPortuguese hyphenation file update)
) Permission is hereby granted to copy and distribute this material provided that the ) copies are not made or distributed for commercial or lucrative purpose, and that ) the contents are not changed in any way. I agree. Should probably take a look at it and if we cannot distribute then remove them. Maybe we could try to make them available in some other way. I used the license above because the old file did so. I think they came as is from the TEX sources, and the original licenses where kept. But my hyphenation file was written from scratch, and I have no objection to changing the license to match FOP's. However, I would like to add a matching Portuguese translation to the file, to keep consistency. Which license is to be used for the hyphenation files? The same used for the Java code, I supose? = Marcelo Jaccoud Amaral Petrobrás (http://www.petrobras.com.br) mailto:[EMAIL PROTECTED] = A História é uma velhota que se repete sem cessar. Eça de Queiroz, in Cartas de Inglaterra Keiron Liddle [EMAIL PROTECTED]Para: [EMAIL PROTECTED] om cc: Assunto: Re: Licence issues in hyphenation patterns (was: 13/02/2003 23:52 HyphenationTree bug and Portuguese hyphenation file Favor responder a update) fop-dev I'd say we can't keep something like that within our codebase because it contradicts the Apache licence. It is entirely possible that someone sells a product that uses FOP. That wouldn't violate the Apache licence but the licence of this hyphenation file. Recent discussions on various Apache mailing lists show that we shouldn't include anything in our codebase that uses a licence that is not officially approved. I agree. Should probably take a look at it and if we cannot distribute then remove them. Maybe we could try to make them available in some other way. I wasn't aware that the hyphenation patterns had their own licences. So, the obvious conclusion is that we need to check every one of these files and remove the ones that are not compatible with the Apache licence. That includes checking where the files came from. Just for reference: http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns (was: HyphenationTree bug and Portuguese hyphenation file update)
That's correct. When you donate source code (be it Java or something else) to a project of the Apache Foundation it gets the Apache licence. You must also be entitled to transfer the rights on the code to Apache Foundation. For example, when you write code when working for a company you may not donate any code to the Apache Foundation unless your employer is ok with this. So if you do have written this hyphenation file from scratch and you are entitled to transfer the rights over to Apache we're ok. We just have to remove that copyright notice and add in the Apache Licence. Of course, you may leave your name in there if you want. On 14.02.2003 13:06:01 jaccoud wrote: I used the license above because the old file did so. I think they came as is from the TEX sources, and the original licenses where kept. But my hyphenation file was written from scratch, and I have no objection to changing the license to match FOP's. However, I would like to add a matching Portuguese translation to the file, to keep consistency. Which license is to be used for the hyphenation files? The same used for the Java code, I supose? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns (was: HyphenationTree bug and Portuguese hyphenation file update)
I'd say we can't keep something like that within our codebase because it contradicts the Apache licence. It is entirely possible that someone sells a product that uses FOP. That wouldn't violate the Apache licence but the licence of this hyphenation file. Recent discussions on various Apache mailing lists show that we shouldn't include anything in our codebase that uses a licence that is not officially approved. I wasn't aware that the hyphenation patterns had their own licences. So, the obvious conclusion is that we need to check every one of these files and remove the ones that are not compatible with the Apache licence. That includes checking where the files came from. Just for reference: http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing On 13.02.2003 21:07:14 J.Pietschmann wrote: [EMAIL PROTECTED] wrote: I posted a correction for a bug in HyphenationTree.java and an updated Portuguese hyphenation file some time ago (June 2002). Since I cannot be a direct developer (my company firewall prevents me from using CVS), someone (sorry, I do not remember who) took upon himself the job of modifying the source and updating the hyphenation file. IT was probably committed to HEAD only. I've applied the patch to HyphenationTree.java. There is a small problem in pt.xml: ) Permission is hereby granted to copy and distribute this material provided that the ) copies are not made or distributed for commercial or lucrative purpose, and that ) the contents are not changed in any way. Oddly enough, the replaced file has a similar license. Keiron, Arved: is this allowed in the repository? Recently they stomped on LGPS on infrastructure, but this seems to be even more restrictive? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns (was: HyphenationTree bug and Portuguese hyphenation file update)
I'd say we can't keep something like that within our codebase because it contradicts the Apache licence. It is entirely possible that someone sells a product that uses FOP. That wouldn't violate the Apache licence but the licence of this hyphenation file. Recent discussions on various Apache mailing lists show that we shouldn't include anything in our codebase that uses a licence that is not officially approved. I agree. Should probably take a look at it and if we cannot distribute then remove them. Maybe we could try to make them available in some other way. I wasn't aware that the hyphenation patterns had their own licences. So, the obvious conclusion is that we need to check every one of these files and remove the ones that are not compatible with the Apache licence. That includes checking where the files came from. Just for reference: http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
