Re: [RAT REPORT] - 30 files with an unknown or no License Header
Hi Jan, hi Jürgen, as I wrote, license headers in main/ooxml/source/framework/JavaPartManager/.classpath main/ooxml/source/framework/JavaPartManager/.project main/ooxml/source/framework/OOXMLViewer/.classpath main/ooxml/source/framework/OOXMLViewer/.project are indeed missing. They were not included in the patch. They are no real binaries, but xml-files. Do they need a license at all? I see other .classpath or .project files listed in rat-excludes. But the files main/ooxml/source/framework/JavaOOXMLParser/.settings/org.eclipse.jdt.core.prefs main/ooxml/source/framework/JavaPartManager/.settings/org.eclipse.jdt.core.prefs are listed in https://svn-master.apache.org/repos/asf/openoffice/trunk/main/rat-excludes So I do not know, why the Rat Report reports missing licenses for them. Is there a problem having a dot in the name of a subdirectory? Or is there an error in the way how they are listed in rat-excludes? Kind regards Regina jan i schrieb: Hi. Newest rat report still shows the same 6 files as being a problem. http://ci.apache.org/projects/openoffice/rat-output.html rgds jan i. On 18 June 2015 at 20:19, jan i j...@apache.org wrote: Thanks for applying the patch. I will check the next RAT-Scan to see if the files sill appear. rgds jan I. On 18 June 2015 at 19:36, Regina Henschel rb.hensc...@t-online.de wrote: Hi Jan, jan i schrieb: HI. did anybody note the rat-scan output, seems we have 6 files still that are a problem (a probably should be deleted): Unapproved Licenses: /home/buildslave19/slave19/openofficeorg-nightly-rat/build/main/ooxml/source/framework/JavaOOXMLParser/.settings/org.eclipse.jdt.core.prefs /home/buildslave19/slave19/openofficeorg-nightly-rat/build/main/ooxml/source/framework/JavaPartManager/.classpath /home/buildslave19/slave19/openofficeorg-nightly-rat/build/main/ooxml/source/framework/JavaPartManager/.project /home/buildslave19/slave19/openofficeorg-nightly-rat/build/main/ooxml/source/framework/JavaPartManager/.settings/org.eclipse.jdt.core.prefs /home/buildslave19/slave19/openofficeorg-nightly-rat/build/main/ooxml/source/framework/OOXMLViewer/.classpath /home/buildslave19/slave19/openofficeorg-nightly-rat/build/main/ooxml/source/framework/OOXMLViewer/.project I had submitted the patch from Gavin McDonald. But that patch contains the lines Index: main/ooxml/source/framework/JavaPartManager/.classpath === Cannot display: file marked as a binary type. svn:mime-type = application/xml Index: main/ooxml/source/framework/JavaPartManager/.project === Cannot display: file marked as a binary type. svn:mime-type = application/xml and Index: main/ooxml/source/framework/OOXMLViewer/.classpath === Cannot display: file marked as a binary type. svn:mime-type = application/xml Index: main/ooxml/source/framework/OOXMLViewer/.project === Cannot display: file marked as a binary type. svn:mime-type = application/xml so for those no change exists in the patch. I read that, but did not notice the consequence. The files main/ooxml/source/framework/OOXMLViewer/.settings/org.eclipse.jdt.core.prefs +main/ooxml/source/framework/SchemaParser/.settings/org.eclipse.jdt.core.prefs should have entries in rat-excludes, at least I see that in the commit message of r1684976. Kind regards Regina rgds jan i. On 16 June 2015 at 08:27, Jürgen Schmidt jogischm...@gmail.com wrote: On 11/06/15 18:23, jan i wrote: On 8 June 2015 at 16:58, Regina Henschel rb.hensc...@t-online.de wrote: Hi Jürgen, is it OK to commit the patch? if it not ok to commit the patch, then I wonder how the files was committed in the first place. If it is not ok, then the files should be deleted. We cannot have files in trunk without the proper ALv2 license. Furthermore we cannot make a release with these files. I recommend applying the patch. Deleting the files might have sideeffects. No it have no sideeffect and yes it is ok to apply the patch. As I explained before these files are part of the started but currently stopped new OOXML framework. It's part of the parser generator ... Anyway it is a eclipse project in Java and the license headers were simply forgotten in the first shot. If you want a Java tooling that would have created C++ stubs and parser for doing the ground work for OOXML parsing ... Again these files should not be part of y source release and can be filtered out as some other things as well. Applying the patch and adding the license header is even better and more clean for future purpose. Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail:
Re: [RAT REPORT] - 30 files with an unknown or no License Header
Hi. Newest rat report still shows the same 6 files as being a problem. http://ci.apache.org/projects/openoffice/rat-output.html rgds jan i. On 18 June 2015 at 20:19, jan i j...@apache.org wrote: Thanks for applying the patch. I will check the next RAT-Scan to see if the files sill appear. rgds jan I. On 18 June 2015 at 19:36, Regina Henschel rb.hensc...@t-online.de wrote: Hi Jan, jan i schrieb: HI. did anybody note the rat-scan output, seems we have 6 files still that are a problem (a probably should be deleted): Unapproved Licenses: /home/buildslave19/slave19/openofficeorg-nightly-rat/build/main/ooxml/source/framework/JavaOOXMLParser/.settings/org.eclipse.jdt.core.prefs /home/buildslave19/slave19/openofficeorg-nightly-rat/build/main/ooxml/source/framework/JavaPartManager/.classpath /home/buildslave19/slave19/openofficeorg-nightly-rat/build/main/ooxml/source/framework/JavaPartManager/.project /home/buildslave19/slave19/openofficeorg-nightly-rat/build/main/ooxml/source/framework/JavaPartManager/.settings/org.eclipse.jdt.core.prefs /home/buildslave19/slave19/openofficeorg-nightly-rat/build/main/ooxml/source/framework/OOXMLViewer/.classpath /home/buildslave19/slave19/openofficeorg-nightly-rat/build/main/ooxml/source/framework/OOXMLViewer/.project I had submitted the patch from Gavin McDonald. But that patch contains the lines Index: main/ooxml/source/framework/JavaPartManager/.classpath === Cannot display: file marked as a binary type. svn:mime-type = application/xml Index: main/ooxml/source/framework/JavaPartManager/.project === Cannot display: file marked as a binary type. svn:mime-type = application/xml and Index: main/ooxml/source/framework/OOXMLViewer/.classpath === Cannot display: file marked as a binary type. svn:mime-type = application/xml Index: main/ooxml/source/framework/OOXMLViewer/.project === Cannot display: file marked as a binary type. svn:mime-type = application/xml so for those no change exists in the patch. I read that, but did not notice the consequence. The files main/ooxml/source/framework/OOXMLViewer/.settings/org.eclipse.jdt.core.prefs +main/ooxml/source/framework/SchemaParser/.settings/org.eclipse.jdt.core.prefs should have entries in rat-excludes, at least I see that in the commit message of r1684976. Kind regards Regina rgds jan i. On 16 June 2015 at 08:27, Jürgen Schmidt jogischm...@gmail.com wrote: On 11/06/15 18:23, jan i wrote: On 8 June 2015 at 16:58, Regina Henschel rb.hensc...@t-online.de wrote: Hi Jürgen, is it OK to commit the patch? if it not ok to commit the patch, then I wonder how the files was committed in the first place. If it is not ok, then the files should be deleted. We cannot have files in trunk without the proper ALv2 license. Furthermore we cannot make a release with these files. I recommend applying the patch. Deleting the files might have sideeffects. No it have no sideeffect and yes it is ok to apply the patch. As I explained before these files are part of the started but currently stopped new OOXML framework. It's part of the parser generator ... Anyway it is a eclipse project in Java and the license headers were simply forgotten in the first shot. If you want a Java tooling that would have created C++ stubs and parser for doing the ground work for OOXML parsing ... Again these files should not be part of y source release and can be filtered out as some other things as well. Applying the patch and adding the license header is even better and more clean for future purpose. Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RAT REPORT] - 30 files with an unknown or no License Header
HI. did anybody note the rat-scan output, seems we have 6 files still that are a problem (a probably should be deleted): Unapproved Licenses: /home/buildslave19/slave19/openofficeorg-nightly-rat/build/main/ooxml/source/framework/JavaOOXMLParser/.settings/org.eclipse.jdt.core.prefs /home/buildslave19/slave19/openofficeorg-nightly-rat/build/main/ooxml/source/framework/JavaPartManager/.classpath /home/buildslave19/slave19/openofficeorg-nightly-rat/build/main/ooxml/source/framework/JavaPartManager/.project /home/buildslave19/slave19/openofficeorg-nightly-rat/build/main/ooxml/source/framework/JavaPartManager/.settings/org.eclipse.jdt.core.prefs /home/buildslave19/slave19/openofficeorg-nightly-rat/build/main/ooxml/source/framework/OOXMLViewer/.classpath /home/buildslave19/slave19/openofficeorg-nightly-rat/build/main/ooxml/source/framework/OOXMLViewer/.project rgds jan i. On 16 June 2015 at 08:27, Jürgen Schmidt jogischm...@gmail.com wrote: On 11/06/15 18:23, jan i wrote: On 8 June 2015 at 16:58, Regina Henschel rb.hensc...@t-online.de wrote: Hi Jürgen, is it OK to commit the patch? if it not ok to commit the patch, then I wonder how the files was committed in the first place. If it is not ok, then the files should be deleted. We cannot have files in trunk without the proper ALv2 license. Furthermore we cannot make a release with these files. I recommend applying the patch. Deleting the files might have sideeffects. No it have no sideeffect and yes it is ok to apply the patch. As I explained before these files are part of the started but currently stopped new OOXML framework. It's part of the parser generator ... Anyway it is a eclipse project in Java and the license headers were simply forgotten in the first shot. If you want a Java tooling that would have created C++ stubs and parser for doing the ground work for OOXML parsing ... Again these files should not be part of y source release and can be filtered out as some other things as well. Applying the patch and adding the license header is even better and more clean for future purpose. Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RAT REPORT] - 30 files with an unknown or no License Header
Thanks for applying the patch. I will check the next RAT-Scan to see if the files sill appear. rgds jan I. On 18 June 2015 at 19:36, Regina Henschel rb.hensc...@t-online.de wrote: Hi Jan, jan i schrieb: HI. did anybody note the rat-scan output, seems we have 6 files still that are a problem (a probably should be deleted): Unapproved Licenses: /home/buildslave19/slave19/openofficeorg-nightly-rat/build/main/ooxml/source/framework/JavaOOXMLParser/.settings/org.eclipse.jdt.core.prefs /home/buildslave19/slave19/openofficeorg-nightly-rat/build/main/ooxml/source/framework/JavaPartManager/.classpath /home/buildslave19/slave19/openofficeorg-nightly-rat/build/main/ooxml/source/framework/JavaPartManager/.project /home/buildslave19/slave19/openofficeorg-nightly-rat/build/main/ooxml/source/framework/JavaPartManager/.settings/org.eclipse.jdt.core.prefs /home/buildslave19/slave19/openofficeorg-nightly-rat/build/main/ooxml/source/framework/OOXMLViewer/.classpath /home/buildslave19/slave19/openofficeorg-nightly-rat/build/main/ooxml/source/framework/OOXMLViewer/.project I had submitted the patch from Gavin McDonald. But that patch contains the lines Index: main/ooxml/source/framework/JavaPartManager/.classpath === Cannot display: file marked as a binary type. svn:mime-type = application/xml Index: main/ooxml/source/framework/JavaPartManager/.project === Cannot display: file marked as a binary type. svn:mime-type = application/xml and Index: main/ooxml/source/framework/OOXMLViewer/.classpath === Cannot display: file marked as a binary type. svn:mime-type = application/xml Index: main/ooxml/source/framework/OOXMLViewer/.project === Cannot display: file marked as a binary type. svn:mime-type = application/xml so for those no change exists in the patch. I read that, but did not notice the consequence. The files main/ooxml/source/framework/OOXMLViewer/.settings/org.eclipse.jdt.core.prefs +main/ooxml/source/framework/SchemaParser/.settings/org.eclipse.jdt.core.prefs should have entries in rat-excludes, at least I see that in the commit message of r1684976. Kind regards Regina rgds jan i. On 16 June 2015 at 08:27, Jürgen Schmidt jogischm...@gmail.com wrote: On 11/06/15 18:23, jan i wrote: On 8 June 2015 at 16:58, Regina Henschel rb.hensc...@t-online.de wrote: Hi Jürgen, is it OK to commit the patch? if it not ok to commit the patch, then I wonder how the files was committed in the first place. If it is not ok, then the files should be deleted. We cannot have files in trunk without the proper ALv2 license. Furthermore we cannot make a release with these files. I recommend applying the patch. Deleting the files might have sideeffects. No it have no sideeffect and yes it is ok to apply the patch. As I explained before these files are part of the started but currently stopped new OOXML framework. It's part of the parser generator ... Anyway it is a eclipse project in Java and the license headers were simply forgotten in the first shot. If you want a Java tooling that would have created C++ stubs and parser for doing the ground work for OOXML parsing ... Again these files should not be part of y source release and can be filtered out as some other things as well. Applying the patch and adding the license header is even better and more clean for future purpose. Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RAT REPORT] - 30 files with an unknown or no License Header
Hi Jan, jan i schrieb: HI. did anybody note the rat-scan output, seems we have 6 files still that are a problem (a probably should be deleted): Unapproved Licenses: /home/buildslave19/slave19/openofficeorg-nightly-rat/build/main/ooxml/source/framework/JavaOOXMLParser/.settings/org.eclipse.jdt.core.prefs /home/buildslave19/slave19/openofficeorg-nightly-rat/build/main/ooxml/source/framework/JavaPartManager/.classpath /home/buildslave19/slave19/openofficeorg-nightly-rat/build/main/ooxml/source/framework/JavaPartManager/.project /home/buildslave19/slave19/openofficeorg-nightly-rat/build/main/ooxml/source/framework/JavaPartManager/.settings/org.eclipse.jdt.core.prefs /home/buildslave19/slave19/openofficeorg-nightly-rat/build/main/ooxml/source/framework/OOXMLViewer/.classpath /home/buildslave19/slave19/openofficeorg-nightly-rat/build/main/ooxml/source/framework/OOXMLViewer/.project I had submitted the patch from Gavin McDonald. But that patch contains the lines Index: main/ooxml/source/framework/JavaPartManager/.classpath === Cannot display: file marked as a binary type. svn:mime-type = application/xml Index: main/ooxml/source/framework/JavaPartManager/.project === Cannot display: file marked as a binary type. svn:mime-type = application/xml and Index: main/ooxml/source/framework/OOXMLViewer/.classpath === Cannot display: file marked as a binary type. svn:mime-type = application/xml Index: main/ooxml/source/framework/OOXMLViewer/.project === Cannot display: file marked as a binary type. svn:mime-type = application/xml so for those no change exists in the patch. I read that, but did not notice the consequence. The files main/ooxml/source/framework/OOXMLViewer/.settings/org.eclipse.jdt.core.prefs +main/ooxml/source/framework/SchemaParser/.settings/org.eclipse.jdt.core.prefs should have entries in rat-excludes, at least I see that in the commit message of r1684976. Kind regards Regina rgds jan i. On 16 June 2015 at 08:27, Jürgen Schmidt jogischm...@gmail.com wrote: On 11/06/15 18:23, jan i wrote: On 8 June 2015 at 16:58, Regina Henschel rb.hensc...@t-online.de wrote: Hi Jürgen, is it OK to commit the patch? if it not ok to commit the patch, then I wonder how the files was committed in the first place. If it is not ok, then the files should be deleted. We cannot have files in trunk without the proper ALv2 license. Furthermore we cannot make a release with these files. I recommend applying the patch. Deleting the files might have sideeffects. No it have no sideeffect and yes it is ok to apply the patch. As I explained before these files are part of the started but currently stopped new OOXML framework. It's part of the parser generator ... Anyway it is a eclipse project in Java and the license headers were simply forgotten in the first shot. If you want a Java tooling that would have created C++ stubs and parser for doing the ground work for OOXML parsing ... Again these files should not be part of y source release and can be filtered out as some other things as well. Applying the patch and adding the license header is even better and more clean for future purpose. Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RAT REPORT] - 30 files with an unknown or no License Header
On 11/06/15 18:23, jan i wrote: On 8 June 2015 at 16:58, Regina Henschel rb.hensc...@t-online.de wrote: Hi Jürgen, is it OK to commit the patch? if it not ok to commit the patch, then I wonder how the files was committed in the first place. If it is not ok, then the files should be deleted. We cannot have files in trunk without the proper ALv2 license. Furthermore we cannot make a release with these files. I recommend applying the patch. Deleting the files might have sideeffects. No it have no sideeffect and yes it is ok to apply the patch. As I explained before these files are part of the started but currently stopped new OOXML framework. It's part of the parser generator ... Anyway it is a eclipse project in Java and the license headers were simply forgotten in the first shot. If you want a Java tooling that would have created C++ stubs and parser for doing the ground work for OOXML parsing ... Again these files should not be part of y source release and can be filtered out as some other things as well. Applying the patch and adding the license header is even better and more clean for future purpose. Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RAT REPORT] - 30 files with an unknown or no License Header
On 8 June 2015 at 16:58, Regina Henschel rb.hensc...@t-online.de wrote: Hi Jürgen, is it OK to commit the patch? if it not ok to commit the patch, then I wonder how the files was committed in the first place. If it is not ok, then the files should be deleted. We cannot have files in trunk without the proper ALv2 license. Furthermore we cannot make a release with these files. I recommend applying the patch. Deleting the files might have sideeffects. rgds jan i. Kind regards Regina Jürgen Schmidt schrieb: On 06/05/15 14:45, jan i wrote: On 6 May 2015 at 14:14, Gavin McDonald gmcdon...@apache.org wrote: Hi All, http://ci.apache.org/projects/openoffice/rat-output.html shows 30 files that need attention in getting valid license headers adding. A quick look shows to me that we should probably insert ASF license Headers in all of those files. If nobody gets to it before me I’ll provide a patch to that effect. I just had a look, all the files should really have ALv2 added. I wonder what happened, because I know a couple of these files used to have ALv2. I will take a look at svn log later. The archives however is covered by the general LICENSE file, when we make a distribution. Patches are welcome. rgds jan I. the files were from a new project that is currently stalled, I believe the headers were simply forgotten. They are not part of the office yet and if they are in the source tarball it is just a mistake. Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RAT REPORT] - 30 files with an unknown or no License Header
Hi Jürgen, is it OK to commit the patch? Kind regards Regina Jürgen Schmidt schrieb: On 06/05/15 14:45, jan i wrote: On 6 May 2015 at 14:14, Gavin McDonald gmcdon...@apache.org wrote: Hi All, http://ci.apache.org/projects/openoffice/rat-output.html shows 30 files that need attention in getting valid license headers adding. A quick look shows to me that we should probably insert ASF license Headers in all of those files. If nobody gets to it before me I’ll provide a patch to that effect. I just had a look, all the files should really have ALv2 added. I wonder what happened, because I know a couple of these files used to have ALv2. I will take a look at svn log later. The archives however is covered by the general LICENSE file, when we make a distribution. Patches are welcome. rgds jan I. the files were from a new project that is currently stalled, I believe the headers were simply forgotten. They are not part of the office yet and if they are in the source tarball it is just a mistake. Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
[PATCH] - Re: [RAT REPORT] - 30 files with an unknown or no License Header
Hi All, Following on from this then I decided to add License headers to all but two of the 30 files, the remainder having entries in the rat-excludes file, so this patch attached should clear up our RAT report as it stands. Below is a svn st list of modified files and please find attached a patch. HTH Gav… — M main/ooxml/source/framework/JavaOOXMLParser/.classpath M main/ooxml/source/framework/JavaOOXMLParser/.project M main/ooxml/source/framework/JavaPartManager/.classpath M main/ooxml/source/framework/JavaPartManager/.project M main/ooxml/source/framework/JavaPartManager/src/org/apache/openoffice/ooxml/framework/part/ContentType.java M main/ooxml/source/framework/JavaPartManager/src/org/apache/openoffice/ooxml/framework/part/ContentTypes.java M main/ooxml/source/framework/JavaPartManager/src/org/apache/openoffice/ooxml/framework/part/IReferenceProvider.java M main/ooxml/source/framework/JavaPartManager/src/org/apache/openoffice/ooxml/framework/part/OOXMLPackage.java M main/ooxml/source/framework/JavaPartManager/src/org/apache/openoffice/ooxml/framework/part/Package.java M main/ooxml/source/framework/JavaPartManager/src/org/apache/openoffice/ooxml/framework/part/Part.java M main/ooxml/source/framework/JavaPartManager/src/org/apache/openoffice/ooxml/framework/part/PartManager.java M main/ooxml/source/framework/JavaPartManager/src/org/apache/openoffice/ooxml/framework/part/PartManagerPrototype.java M main/ooxml/source/framework/JavaPartManager/src/org/apache/openoffice/ooxml/framework/part/PartName.java M main/ooxml/source/framework/JavaPartManager/src/org/apache/openoffice/ooxml/framework/part/RelatedParts.java M main/ooxml/source/framework/JavaPartManager/src/org/apache/openoffice/ooxml/framework/part/RelationshipType.java M main/ooxml/source/framework/JavaPartManager/src/org/apache/openoffice/ooxml/framework/part/parser/ContentTypesParser.java M main/ooxml/source/framework/JavaPartManager/src/org/apache/openoffice/ooxml/framework/part/parser/ParserFactory.java M main/ooxml/source/framework/JavaPartManager/src/org/apache/openoffice/ooxml/framework/part/parser/RelationshipParser.java M main/ooxml/source/framework/OOXMLViewer/.classpath M main/ooxml/source/framework/OOXMLViewer/.project M main/ooxml/source/framework/SchemaParser/.classpath M main/ooxml/source/framework/SchemaParser/.project M main/ooxml/source/framework/SchemaParser/src/org/apache/openoffice/ooxml/schema/generator/html/code.js M main/ooxml/source/framework/SchemaParser/src/org/apache/openoffice/ooxml/schema/generator/html/display.css M main/ooxml/source/framework/SchemaParser/src/org/apache/openoffice/ooxml/schema/generator/html/linking-template.html M main/ooxml/source/framework/SchemaParser/src/org/apache/openoffice/ooxml/schema/generator/html/template.html M main/rat-excludes rat-license.patch Description: Binary data On 7 May 2015, at 8:06 am, Jürgen Schmidt jogischm...@gmail.com wrote: On 06/05/15 14:45, jan i wrote: On 6 May 2015 at 14:14, Gavin McDonald gmcdon...@apache.org wrote: Hi All, http://ci.apache.org/projects/openoffice/rat-output.html shows 30 files that need attention in getting valid license headers adding. A quick look shows to me that we should probably insert ASF license Headers in all of those files. If nobody gets to it before me I’ll provide a patch to that effect. I just had a look, all the files should really have ALv2 added. I wonder what happened, because I know a couple of these files used to have ALv2. I will take a look at svn log later. The archives however is covered by the general LICENSE file, when we make a distribution. Patches are welcome. rgds jan I. the files were from a new project that is currently stalled, I believe the headers were simply forgotten. They are not part of the office yet and if they are in the source tarball it is just a mistake. Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [RAT REPORT] - 30 files with an unknown or no License Header
On 06/05/15 14:45, jan i wrote: On 6 May 2015 at 14:14, Gavin McDonald gmcdon...@apache.org wrote: Hi All, http://ci.apache.org/projects/openoffice/rat-output.html shows 30 files that need attention in getting valid license headers adding. A quick look shows to me that we should probably insert ASF license Headers in all of those files. If nobody gets to it before me I’ll provide a patch to that effect. I just had a look, all the files should really have ALv2 added. I wonder what happened, because I know a couple of these files used to have ALv2. I will take a look at svn log later. The archives however is covered by the general LICENSE file, when we make a distribution. Patches are welcome. rgds jan I. the files were from a new project that is currently stalled, I believe the headers were simply forgotten. They are not part of the office yet and if they are in the source tarball it is just a mistake. Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RAT REPORT] - 30 files with an unknown or no License Header
On 6 May 2015 at 14:14, Gavin McDonald gmcdon...@apache.org wrote: Hi All, http://ci.apache.org/projects/openoffice/rat-output.html shows 30 files that need attention in getting valid license headers adding. A quick look shows to me that we should probably insert ASF license Headers in all of those files. If nobody gets to it before me I’ll provide a patch to that effect. I just had a look, all the files should really have ALv2 added. I wonder what happened, because I know a couple of these files used to have ALv2. I will take a look at svn log later. The archives however is covered by the general LICENSE file, when we make a distribution. Patches are welcome. rgds jan I. HTH Gav…
