From: <Joe...@mi...> - 2010-09-21 17:03:01
|
Borut and gang, Here's the email thread, released, to share and discuss. :-) Thanks for being so persnickety! Now you are all named. Let me know what you decide. Best Regards, Joe Drzewiecki Microchip Technology, Inc. 2355 W. Chandler Blvd. Chandler, AZ (480) 792-7012 Joe.Drzewiecki@Microchip.com <mailto:Joe.Drzewiecki@Microchip.com> P please consider the environment before printing this email THIS E-MAIL TRANSMISSION, AND ANY DOCUMENTS, FILES OR PREVIOUS E-MAILS ATTACHED TO IT, IS CONFIDENTIAL INFORMATION INTENDED ONLY FOR THE USE OF THE NAMED RECIPIENT(S). ANY DISSEMINATION, DISTRIBUTION OR DUPLICATION OF THIS TRANSMISSION IS STRICTLY PROHIBITED. If you believe you have received this e-mail in error, please notify the Sender and delete the e-mail from your system. DISCLAIMER OF LIABILITY: This transmittal and any accompanying information is for suggestion only and is provided "AS IS". It shall not be deemed to modify Microchip's standard warranty for its products. It is your responsibility to ensure that this information meets your requirements. MICROCHIP DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED STATUTORY OR OTHERWISE, INCLUDING BUT NOT LIMITED TO MERCHANTABILITY, FITNESS FOR PURPOSE, NON-INFRINGEMENT, QUALITY, OR CONDITION. MICROCHIP PROVIDES THIS INFORMATION CONDITIONALLY UPON YOUR ACCEPTANCE OF THESE TERMS. To the fullest extent allowed by law, Microchip's liability shall not exceed the amount of fee, if any, that you have paid directly to Microchip for development of this information and associated services. ________________________________ From: Borut Razem [mailto:bor...@si...] Sent: Monday, September 20, 2010 11:25 PM To: Joe Drzewiecki - C11694 Subject: Re: Fwd: RE: gpasm - MPASM include files license Hi Joe, thanks for the response. See my comments below. I'm also asking you for the permission to share your mails with other sdcc developers, specially to discuss the request about exclusive use with authentic Microchip devices. The attached statement at the end of your mail (... "IS CONFIDENTIAL INFORMATION INTENDED ONLY FOR THE USE OF THE NAMED RECIPIENT(S)") explicitly prevents it. You can also CC your mails directly to the sdcc development mailinig list sdc...@li... or join the mailing list at https://lists.sourceforge.net/lists/listinfo/sdcc-devel. Best regards, Borut On 09/21/2010 01:21 AM, Joe...@mi... wrote: Borut, I would like to provide you with our XML repository, which contains all of the information you need to construct the header/linker files. Using the header files (an intermediate representation) to generate your files is too prone for error for my liking. We will update the XML repository regularly so that you will always have the best data that we have. If you start from the XML repository, as Microchip desires, I would be glad to provide it. Yes, I'm definitely interested on XML repository. Is it available from the web? If not, please provide it to me. But this is out of scope for the sdcc 3.0.0 release... For the files you generate, I have one request: The header files should state that they are only to be used with authentic Microchip devices This is the hard one: I don't know if the requies is in spirit and compatible with GPL. I'm affraid it is not, but I have to check... If you want to issue them under the GPL+LE license, I have no objection. I your request is compatible with GPL, we can add an additional exception, stating that "the file can be used only with authentic Microchip devices". I would like you to offer the latest XML repository for use without the restrictions of the GPL+LE license - basically free for any use that involves authentic Microchip devices. Best Regards, Joe Drzewiecki Microchip Technology, Inc. 2355 W. Chandler Blvd. Chandler, AZ (480) 792-7012 Joe.Drzewiecki@Microchip.com <mailto:Joe.Drzewiecki@Microchip.com> P please consider the environment before printing this email THIS E-MAIL TRANSMISSION, AND ANY DOCUMENTS, FILES OR PREVIOUS E-MAILS ATTACHED TO IT, IS CONFIDENTIAL INFORMATION INTENDED ONLY FOR THE USE OF THE NAMED RECIPIENT(S). ANY DISSEMINATION, DISTRIBUTION OR DUPLICATION OF THIS TRANSMISSION IS STRICTLY PROHIBITED. If you believe you have received this e-mail in error, please notify the Sender and delete the e-mail from your system. DISCLAIMER OF LIABILITY: This transmittal and any accompanying information is for suggestion only and is provided "AS IS". It shall not be deemed to modify Microchip's standard warranty for its products. It is your responsibility to ensure that this information meets your requirements. MICROCHIP DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED STATUTORY OR OTHERWISE, INCLUDING BUT NOT LIMITED TO MERCHANTABILITY, FITNESS FOR PURPOSE, NON-INFRINGEMENT, QUALITY, OR CONDITION. MICROCHIP PROVIDES THIS INFORMATION CONDITIONALLY UPON YOUR ACCEPTANCE OF THESE TERMS. To the fullest extent allowed by law, Microchip's liability shall not exceed the amount of fee, if any, that you have paid directly to Microchip for development of this information and associated services. ________________________________ From: Borut Razem [mailto:bor...@si...] Sent: Sunday, August 29, 2010 12:33 AM To: Joe Drzewiecki - C11694 Cc: John O Battle Subject: Re: Fwd: RE: gpasm - MPASM include files license Hello Joe, thanks for your willingness to collaborate. SDCC uses MPLAB include files indirectly: we have inc2h.pl, inc2h-pic16.pl and pic18fam-h-gen.pl perl scripts (see http://sdcc.svn.sourceforge.net/viewvc/sdcc/trunk/sdcc/support/scripts/) which generate C source and header files, distributed as a part of SDCC library. (see http://sdcc.svn.sourceforge.net/viewvc/sdcc/trunk/sdcc/device/include/pi c/ http://sdcc.svn.sourceforge.net/viewvc/sdcc/trunk/sdcc/device/lib/pic/li bdev/ http://sdcc.svn.sourceforge.net/viewvc/sdcc/trunk/sdcc/device/include/pi c16/ http://sdcc.svn.sourceforge.net/viewvc/sdcc/trunk/sdcc/device/lib/pic16/ libdev/) We decided to release the SDCC library under an open source license, which allows to use it in proprietary (non open source) projects in the next SDCC release. Currently the library files are released mainly under GPL or LGPL. We chose the GPL+LE license (see https://sourceforge.net/apps/trac/sdcc/wiki/Library%20License%20Selectio n). You can see the current sdcc library license change status at https://sourceforge.net/apps/trac/sdcc/wiki/Files%20and%20Licenses We would like to release the pic device library files under the GPL+LE license too, but we think we can't do it without your permission, since they are generated from MPLAB include files (which doesn't contain any info about licensing conditions). The license will be applied only on the generated sdcc library files. The original MPLAB include files licensing will not be affected. So I'm kindly asking you for permission to release pic device files, generated from MPLAB include files and included in sdcc library, under the GLP+LE license by adding the GPL+LE comment to them (see https://sourceforge.net/apps/trac/sdcc/wiki/SDCC%20library%20source%20fi le%20license%20header). If you don't agree with the GPL+LE license or you have additional questions / propositions / requirements / concerns / anything, please don't hesitate to contact me or the sdcc developers mailing list at sdc...@li.... Sincerely Yours, Borut On 07/29/2010 07:29 PM, John O Battle wrote: - -------- Original Message -------- Subject: RE: gpasm - MPASM include files license Date: Thu, 29 Jul 2010 09:12:52 -0700 From: <Joe...@mi...> <mailto:Joe...@mi...> To: <job...@ca...> <mailto:job...@ca...> , <Don...@mi...> <mailto:Don...@mi...> , <Vincent.Sheard@Microchip.com> <mailto:Vincent.Sheard@Microchip.com> John, We're going one better. We're setting up a web site where the entire device database is presented in XML (among other things). We can post the header and include files as well at the time of release of every compiler or MPASM. It will take a little doing, but hell, you can't use them with any other device - why should we care about letting GPASM and SDCC use them? The only thing is going to be a question of synchronization. The release schedule is pretty haphazard right now. The SDCC and GPASM guys are going to have to keep an eagle eye out and when we update them on the open-source web site, they'll have to snarf them. Is that fair enough? Joe P.S., BTW, I am the guy Borut wants to talk to. Feel free to give him my name and email address. We'd like to forge (:) a closer alliance with those guys. - -----Original Message----- From: John O Battle [mailto:job...@ca...] Sent: Thursday, July 29, 2010 8:14 AM To: Donna Mason - C08830; Joe Drzewiecki - C11694; Vincent Sheard - C10252 Subject: Fwd: gpasm - MPASM include files license Donna Any way we (Microchip) can help/cooperate with this effort? I think working with these guys would be good PR for microchip and would make some friends in the process. John - -------- Original Message -------- Subject: gpasm - MPASM include files license Date: Wed, 28 Jul 2010 21:33:56 +0200 From: Borut Razem <bor...@si...> <mailto:bor...@si...> Reply-To: <gn...@li...> <mailto:gn...@li...> To: gnupic <gn...@li...> <mailto:gn...@li...> CC: Sdcc-Devel <sdc...@li...> <mailto:sdc...@li...> Hi, I wold like to know what is the status of using / distributing Microchip MPASM include files with gpasm: - - is there any "official" statement from Microchip that the include files can be used with gpasm? - - has anybody contact the Microchip to clarify this issue? - - does anybody know a contact person or address at Microchip where I can send an e-mail to get answers about the matter? I'm asking this because there is no copyright notice (Microchip is mentioned, but not explicitly as a copyright holder) nor any licensing terms in include files. Sdcc project is using MPASM include files to produce device specific headers and c source files which are part of sdcc run-time libraries. One of goals for the upcoming sdcc 3.0 release is to release the sdcc library under the GPL+LE (see http://sourceforge.net/apps/trac/sdcc/wiki/Library%20License%20Selection ), so that it can be used with closed source (proprietary) software. Part of this task is also clarification of licensing status of MPASM include files. Best regards, Borut -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMUbqMAAoJELejoBGAt4nRlg8H/01ADtOx69SL0pT3Hl2M70Zr NtaT8IUU6zNZrGCLXcpeUj/MoklhBaGGI+qx2PJPfnno6cajeJTd0dw+oWuXKpQX oNssyzbtu8kYews1PsgWZU6hssr3Dc/niBN/OOlN0+xoPTiJ95uxhOMSZViBYUVS aP5GHL8TpoPAa/1cJneL6kjcG8yOMi0xvhwgLxanzaL9VRxtXeacuhsTQKlEIpaD vRRq/BFqcOJptrvAtdzJm0RejIz18sPjak4Vsm2JIHHF6YAbZ4Cjg8Dhv77/1bjp C7PZ3gKzHlsGaoZPsI1YvGtE/3gkQ8yxvxrYxErTOO0ZxiaILncpzE/DxOoFzFQ= =AD/U -----END PGP SIGNATURE----- |
From: Philipp K. K. <pk...@sp...> - 2010-09-22 19:17:35
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 21.09.2010 19:02, schrieb Joe...@mi...: > Borut and gang, > > > > Here’s the email thread, released, to share and discuss. J > > Thanks for being so persnickety! > > Now you are all named. > > > > Let me know what you decide. This looks like a difficult situation. It seems we do not have any free PIC headers. While the copyrightability of headers and (even more so) of that XMl database is questionable, some jurisdictions have additional database protection laws that could apply in this case. It seems we cannot replace the headers by something free in the short term. The XML database offered probably will give us the highest-quality (from a purely technical perspective, leaving our worlds horrible laws aside) way of getting header files. They probably would be no less free than the exisitng ones. We should have a way of getting clean sdcc tarballs and an additional tarball for the tainted headers. This would make life for distributions (e.g. Debian could only distribute the tainted headers in non-free, and probably wouldn't want to touch them at all) easier. In the long term we would want to have header untainted header files, which could go into the main tarball. In the medium term we would want untainted header files at least where a compatible chip not made by Microchip Technology Inc. exists. Philipp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyaVjcACgkQbtUV+xsoLpqYgQCgysdmTpiV7AjQoQFWW23Au4Bh RPkAn2pVXMUVoJsxgZJoUxW4McrvQQV2 =9G2U -----END PGP SIGNATURE----- |
From: Borut R. <bor...@si...> - 2010-09-22 20:58:01
|
Philipp, so you are 100% sure that the "only to be used with authentic Microchip devices" requirement is not GPL compatible? I haven't re-read the GPL license yet, so if you already know which statement in the license is in contradiction with the requirement, please let me know. Borut On 09/22/2010 09:17 PM, Philipp Klaus Krause wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 21.09.2010 19:02, schrieb Joe...@mi...: > >> Borut and gang, >> >> >> >> Here’s the email thread, released, to share and discuss. J >> >> Thanks for being so persnickety! >> >> Now you are all named. >> >> >> >> Let me know what you decide. >> > This looks like a difficult situation. It seems we do not have any free > PIC headers. While the copyrightability of headers and (even more so) of > that XMl database is questionable, some jurisdictions have additional > database protection laws that could apply in this case. > > It seems we cannot replace the headers by something free in the short > term. The XML database offered probably will give us the highest-quality > (from a purely technical perspective, leaving our worlds horrible laws > aside) way of getting header files. They probably would be no less free > than the exisitng ones. > > We should have a way of getting clean sdcc tarballs and an additional > tarball for the tainted headers. This would make life for distributions > (e.g. Debian could only distribute the tainted headers in non-free, and > probably wouldn't want to touch them at all) easier. > > In the long term we would want to have header untainted header files, > which could go into the main tarball. > > In the medium term we would want untainted header files at least where a > compatible chip not made by Microchip Technology Inc. exists. > > Philipp > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkyaVjcACgkQbtUV+xsoLpqYgQCgysdmTpiV7AjQoQFWW23Au4Bh > RPkAn2pVXMUVoJsxgZJoUxW4McrvQQV2 > =9G2U > -----END PGP SIGNATURE----- > |
From: Philipp K. K. <pk...@sp...> - 2010-09-22 21:21:01
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 22.09.2010 22:57, schrieb Borut Razem: > Philipp, > > so you are 100% sure that the "only to be used with authentic Microchip > devices" requirement is not GPL compatible? I rarely hurts to re-read the GPL. However AFAIK adding additional restrictions to the GPL is always GPL-incompatible, unless explicitly allowed by the GPL (e.g. AGPL conversion clause in GPL v3). Outside of the GPL world it would violate e.g. clause 6 of the Debian Free Software guidelines (DFSG), and thus not be allowed into Debian main (and since Debian considers the GPL to be DFSG-free, this means Debian considers the restriction GPL-incompatible). But without looking at the legal texts, the restriction would be against the spirit of free software, and freedom in general. There are PIC clones not made by microchip. There even are free implementations of the PIC architecture, some of them compatible with specific PIC devices, such as the 16C55 or 16F84. It would be absurd if free sdcc could not legally generate code for certain chips depending on who manuifactured the hardware. Most absurd, if sdcc could not legally generate code for free hardware compatible with Microchip's PICs. Philipp ²A few minutes of search found three free PIC implementations: http://opencores.org/project,ppx16 http://opencores.org/project,risc16f84 http://opencores.org/project,minirisc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyaczQACgkQbtUV+xsoLppSDgCfWceOSY0bjxcBgX0nB2L8FwOM 0lUAn0M+6ERzoIxdYOVScZXmkbqAkkS5 =Tf2m -----END PGP SIGNATURE----- |
From: Borut R. <bor...@si...> - 2010-09-24 05:20:37
|
Philipp, thank you for the explanation. I propose to create a non-free (or something like that) directory at the same level as include and lib are, and put all anon-free header files and libraries there, retaining the same structure: lib/pic/*.lib: free pic libraries include/pic/*.h: free pic header files non-free/lib/pic/*.lib: non free pic libraries non-free/include/pic/*.h: non free pic header files This is makes life easy for the package maintainers: just put the contents of the non-free directory in a separate package. Developers should add additional paths to the sdcc command line: -I /usr/local/sdcc/non-free/include/pic -L /usr/local/sdcc/non-free/lib/pic We could also introduce a sdcc command line option, for exeample --non-free, to tell sdcc to automatically search header and library files also in the non-free directory. Comments? Borut On 09/22/2010 11:20 PM, Philipp Klaus Krause wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 22.09.2010 22:57, schrieb Borut Razem: > >> Philipp, >> >> so you are 100% sure that the "only to be used with authentic Microchip >> devices" requirement is not GPL compatible? >> > I rarely hurts to re-read the GPL. However AFAIK adding additional > restrictions to the GPL is always GPL-incompatible, unless explicitly > allowed by the GPL (e.g. AGPL conversion clause in GPL v3). > > Outside of the GPL world it would violate e.g. clause 6 of the Debian > Free Software guidelines (DFSG), and thus not be allowed into Debian > main (and since Debian considers the GPL to be DFSG-free, this means > Debian considers the restriction GPL-incompatible). > > But without looking at the legal texts, the restriction would be against > the spirit of free software, and freedom in general. > > There are PIC clones not made by microchip. There even are free > implementations of the PIC architecture, some of them compatible with > specific PIC devices, such as the 16C55 or 16F84. > > It would be absurd if free sdcc could not legally generate code for > certain chips depending on who manuifactured the hardware. Most absurd, > if sdcc could not legally generate code for free hardware compatible > with Microchip's PICs. > > Philipp > > ²A few minutes of search found three free PIC implementations: > http://opencores.org/project,ppx16 > http://opencores.org/project,risc16f84 > http://opencores.org/project,minirisc > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkyaczQACgkQbtUV+xsoLppSDgCfWceOSY0bjxcBgX0nB2L8FwOM > 0lUAn0M+6ERzoIxdYOVScZXmkbqAkkS5 > =Tf2m > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > > |
From: Philipp K. K. <pk...@sp...> - 2010-09-24 10:44:31
|
Am 24.09.2010 07:20, schrieb Borut Razem: > Philipp, thank you for the explanation. > > I propose to create a non-free (or something like that) directory at the > same level as include and lib are, and put all anon-free header files > and libraries there, retaining the same structure: > > lib/pic/*.lib: free pic libraries > include/pic/*.h: free pic header files > > non-free/lib/pic/*.lib: non free pic libraries > non-free/include/pic/*.h: non free pic header files > > This is makes life easy for the package maintainers: just put the > contents of the non-free directory in a separate package. > > Developers should add additional paths to the sdcc command line: -I > /usr/local/sdcc/non-free/include/pic -L /usr/local/sdcc/non-free/lib/pic > > We could also introduce a sdcc command line option, for exeample > --non-free, to tell sdcc to automatically search header and library > files also in the non-free directory. > > Comments? > > Borut The proposed solution looks OK to me for now. I consider this issue important enough that it has to be solved before the 3.0.0 release. Philipp |
From: Borut R. <bor...@si...> - 2010-09-24 19:16:40
|
On 09/24/2010 12:44 PM, Philipp Klaus Krause wrote: > > The proposed solution looks OK to me for now. I consider this issue > important enough that it has to be solved before the 3.0.0 release. > > I agree with you, but unfortunately I'll be absent from tomorrow until 2010-10-02, so I won't be able to do the changes, and the RC1 deadline is planned for 2010-10-03... Is anybody else willing to do it? If not, we will have to shift the RC1 at least for few days... The task seems to be easy at the first glance, but it has consequences at least on: - library build process (Makefiles) - snapshot build process and packaging (tar balls, win32 zip package and win32 setup package) - regression testing of pic* tragets Borut |
From: Frieder F. <fri...@we...> - 2010-10-07 21:50:39
|
Hi Borut, Am 24.09.2010 12:44, schrieb Philipp Klaus Krause: >> We could also introduce a sdcc command line option, for exeample >> --non-free, to tell sdcc to automatically search header and library >> files also in the non-free directory. >> >> Comments? can something be done about the naming of that option? I would like it to be _much_ more specific like: --use-non-free-headers --use-non-free-libraries or preferably: --use-non-free-pic-headers so it directly points to the stuff not being free. This would help to avoid non-free creeping in. This would make unequivocal that there is no non free SDCC but instead it is just SDCC being used to compile non free code. If an SDCC option matching the pattern "--use-non-free-*" is used to compile the source then preprocessor defines like "SDCC_OPTION_USE_NON_FREE" and "SDCC_OPTION_USE_NON_FREE_*" or something similar would make sense? Sorry for the last minute request. (I got aware by Bugs item #3080422) Greetings, Frieder |
From: Borut R. <bor...@si...> - 2010-10-08 05:40:13
|
Hello Philipp, On 10/07/2010 11:47 PM, Frieder Ferlemann wrote: > Hi Borut, > > Am 24.09.2010 12:44, schrieb Philipp Klaus Krause: > >>> We could also introduce a sdcc command line option, for exeample >>> --non-free, to tell sdcc to automatically search header and library >>> files also in the non-free directory. >>> >>> Comments? >>> > > can something be done about the naming of that option? > I would like it to be _much_ more specific like: > > --use-non-free-headers > --use-non-free-libraries > Actually is both: headers and libraries, so it should be --use-non-free-headers-and-libraries, which is definitely too long. Maybe we could use --use-non-free-libraries in general sense, since both *.h and .lib files are part of a library? Or maybe just --use-non-free? > or preferably: > --use-non-free-pic-headers > > No. Non-free is meant for all targets. Courrently we have only pic* non-free libraries, but this can change in the future. > so it directly points to the stuff not being free. > This would help to avoid non-free creeping in. > > This would make unequivocal that there is no non free SDCC > but instead it is just SDCC being used to compile > non free code. > > > If an SDCC option matching the pattern > "--use-non-free-*" is used to compile the source then > preprocessor defines like > "SDCC_OPTION_USE_NON_FREE" and > "SDCC_OPTION_USE_NON_FREE_*" > or something similar would make sense? > > Currently the SDCC_NON_FREE preprocessor symbol is defined if --non-free command line option is used. I'd skip the _OPTION_ part to make it shorter, so it would be SDCC_USE_NON_FREE_LIBRARIES (which again seems too long to me) or SDCC_USE_NON_FREE. > Sorry for the last minute request. > (I got aware by Bugs item #3080422) > > But you agreed with the introduction of --non-free in your mail to sdcc-devel on 2010-09-24!? Or you yust didn't know that I already implemented it? Now I leave the final decision of the "non-free" commamd line option and preprocessor symbol names to you. Please let me know ASAP. Borut |
From: Frieder F. <fri...@we...> - 2010-10-08 16:58:29
|
Hi Borut, Am 08.10.2010 07:39, schrieb Borut Razem: > > On 10/07/2010 11:47 PM, Frieder Ferlemann wrote: > > Actually is both: headers and libraries, so it should be > > --use-non-free-headers-and-libraries, which is definitely too long. > > Maybe we could use --use-non-free-libraries in general sense, since both > > *.h and .lib files are part of a library? Or maybe just --use-non-free? Both would be fine with me. > > Currently the SDCC_NON_FREE preprocessor symbol is defined if --non-free > > command line option is used. I'd skip the _OPTION_ part to make it > > shorter, so it would be SDCC_USE_NON_FREE_LIBRARIES (which again seems > > too long to me) or SDCC_USE_NON_FREE. Both would be fine. > > But you agreed with the introduction of --non-free in your mail to > > sdcc-devel on 2010-09-24!? Or you yust didn't know that I already > > implemented it? I was very busy lately and didn't look. Sorry for that. Thanks for your work!!! Greetings, Frieder |
From: Borut R. <bor...@si...> - 2010-10-09 06:41:23
|
Hi Frieder, > But you agreed with the introduction of --non-free in your mail to > sdcc-devel on 2010-09-24!? Or you yust didn't know that I already > implemented it? I have to apologize: it wasn't you who agreed with the solution I proposed, it was Philipp. Sorry to both of you! > Both would be fine with me. I was afraid that you will answer in this manner, that is why I wrote "Now I leave the final decision of the "non-free" command line option and preprocessor symbol names to you.". Many times is easier (and funnier) to implement a feature then to give it a name (similar to babies :-) But I have and other idea: the whole story is not about the libraries but about licenses, so the naming could be --use-non-gpl and SDCC_USE_NON_GPL, which should be defined when "compiling the software which is not licensed under a GPL compatible license". And in this case a new question arises: should I rename the lib and include dirs from non-free to non-gpl too? And PLEASE don't answer with "Both would be fine" again ;-) Borut On 10/08/2010 06:58 PM, Frieder Ferlemann wrote: > Hi Borut, > > Am 08.10.2010 07:39, schrieb Borut Razem: > >>> On 10/07/2010 11:47 PM, Frieder Ferlemann wrote: >>> Actually is both: headers and libraries, so it should be >>> --use-non-free-headers-and-libraries, which is definitely too long. >>> Maybe we could use --use-non-free-libraries in general sense, since both >>> *.h and .lib files are part of a library? Or maybe just --use-non-free? >>> > Both would be fine with me. > > >>> Currently the SDCC_NON_FREE preprocessor symbol is defined if --non-free >>> command line option is used. I'd skip the _OPTION_ part to make it >>> shorter, so it would be SDCC_USE_NON_FREE_LIBRARIES (which again seems >>> too long to me) or SDCC_USE_NON_FREE. >>> > Both would be fine. > > >>> But you agreed with the introduction of --non-free in your mail to >>> sdcc-devel on 2010-09-24!? Or you yust didn't know that I already >>> implemented it? >>> > I was very busy lately and didn't look. Sorry for that. > > Thanks for your work!!! > > Greetings, > Frieder > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2& L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > > |
From: Frieder F. <fri...@we...> - 2010-10-09 09:40:00
|
Hi Borut, Am 09.10.2010 08:41, schrieb Borut Razem: > > Both would be fine with me. > > I was afraid that you will answer in this manner, that is why I wrote > "Now I leave the final decision of the "non-free" command line option > and preprocessor symbol names to you.". Many times is easier (and > funnier) to implement a feature then to give it a name (similar to > babies :-) I'd prefer --use-non-free (over --use-non-free-libraries) > But I have and other idea: the whole story is not about the libraries > but about licenses, so the naming could be --use-non-gpl and > SDCC_USE_NON_GPL, which should be defined when "compiling the software > which is not licensed under a GPL compatible license". "--use-non-free" is about licenses too. The advantage of "non-free" is that it has a direct mapping towards the needs of Debian and Debian derived distributions. "--use-non-gpl" seems to be not a good match because a) BSD licensed (or public domain) libraries would also be non-gpl b) "--use-non-gpl" seems to imply for me that if you don't specify this option then SDCC would use/link GPL code (as opposed to GPL+LE code) and thus bind the user to also distribute the source to his binary. We'd have to explain. > And in this case a new question arises: should I rename the lib and > include dirs from non-free to non-gpl too? >From my point of view yes, the option and the directory names should be consistent. > And PLEASE don't answer with "Both would be fine" again ;-) Better?) Greetings, Frieder |
From: Borut R. <bor...@si...> - 2010-10-09 15:04:07
|
Frieder, so --use-non-free and SDCC_USE_NON_FREE it will be. Thanks for your precise answer! Borut On 10/09/2010 11:39 AM, Frieder Ferlemann wrote: > Hi Borut, > > Am 09.10.2010 08:41, schrieb Borut Razem: > >> > Both would be fine with me. >> >> I was afraid that you will answer in this manner, that is why I wrote >> "Now I leave the final decision of the "non-free" command line option >> and preprocessor symbol names to you.". Many times is easier (and >> funnier) to implement a feature then to give it a name (similar to >> babies :-) >> > I'd prefer --use-non-free (over --use-non-free-libraries) > > >> But I have and other idea: the whole story is not about the libraries >> but about licenses, so the naming could be --use-non-gpl and >> SDCC_USE_NON_GPL, which should be defined when "compiling the software >> which is not licensed under a GPL compatible license". >> > "--use-non-free" is about licenses too. The advantage of "non-free" is > that it has a direct mapping towards the needs of Debian and Debian > derived distributions. > > "--use-non-gpl" seems to be not a good match because > a) BSD licensed (or public domain) libraries would also be non-gpl > b) "--use-non-gpl" seems to imply for me that if you don't specify > this option then SDCC would use/link GPL code (as opposed to GPL+LE code) > and thus bind the user to also distribute the source to his binary. > We'd have to explain. > > >> And in this case a new question arises: should I rename the lib and >> include dirs from non-free to non-gpl too? >> > > From my point of view yes, the option and the directory names should > be consistent. > > >> And PLEASE don't answer with "Both would be fine" again ;-) >> > Better?) > > Greetings, > Frieder > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2& L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > > |
From: Philipp K. K. <pk...@sp...> - 2010-09-22 21:25:40
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 22.09.2010 22:57, schrieb Borut Razem: > Philipp, > > so you are 100% sure that the "only to be used with authentic Microchip > devices" requirement is not GPL compatible? Clause 6 of GPLv2 (GPLv3 is a bit more verbose, see clause 7 and 10): "You may not impose any further restrictions on the recipients' exercise of the rights granted herein" Philipp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyadE0ACgkQbtUV+xsoLppE4wCg4nlGCTmqvEVgFObTc14GkzWU MqMAnAu17inBO6m96qkBEx0p/kLdUssq =H3tV -----END PGP SIGNATURE----- |
From: Walter B. <wa...@by...> - 2010-09-22 23:13:06
|
>> This looks like a difficult situation. It seems we do not have any free >> PIC headers. While the copyrightability of headers and (even more so) of >> that XMl database is questionable, some jurisdictions have additional >> database protection laws that could apply in this case. >> Copyrights have considerable strength. Copyrights have advantages as well as it protects open source software from violations. It would be a good idea to respect the copyrights on the header files. Be careful about just duplicating headers. Rewritten headers may still violate copyrights on the original material. I am not a lawyer but this is an area that care needs to be taken. Regards, Walter Banks |
From: Borut R. <bor...@si...> - 2010-10-17 16:21:23
|
Hi Joe, your requirement: "The header files should state that they are only to be used with authentic Microchip devices" is not GPL compatible: in clause 6 of GPLv2 (GPLv3 is a bit more verbose, see clause 7 and 10) is written: "You may not impose any further restrictions on the recipients' exercise of the rights granted herein". So we decided to put all pic device description header and library files, derived from Microchip include files into a separate non-free directory ("free" as in "free speech," not as in "free beer"). This also makes the life of Debian package mangers easier, since non-free files can be easily packaged in as separate packages, in order to be in conformity with Debian Free Software guidelines (DFSG). We also added the --non-free sdcc command line option, which enables sdcc to search for include and lib files under the non-free directory (non-free/include, non-free/lib). This means that user can not use the Microchip derived lib & include files by mistake with non-Microchip devices. The restriction is also documented in the sdcc manual (sddcman.lyx, sdccman.pdf and sdccman html documents). I hope that we choose the optimal way to protect your (Microchip) interests, interests of FOSS developers, and the interests of closed source developers. We are still very much interested to change our device description lib & header files generation system to use the XML repository after the sdcc 3.0.0 release, but I still don't know how to access / get the repository... Best regards, Borut On 09/21/2010 07:02 PM, Joe...@mi... wrote: > > Borut and gang, > > Here's the email thread, released, to share and discuss. J > > Thanks for being so persnickety! > > Now you are all named. > > Let me know what you decide. > > /Best Regards,/ > > /Joe Drzewiecki/ > > Microchip Technology, Inc. > > 2355 W. Chandler Blvd. > > Chandler, AZ > > (480) 792-7012 > > //Joe.Drzewiecki@Microchip.com// <mailto:Joe.Drzewiecki@Microchip.com> > > P please consider the environment before printing this email > > THIS E-MAIL TRANSMISSION, AND ANY DOCUMENTS, FILES OR PREVIOUS E-MAILS > ATTACHED TO IT, IS CONFIDENTIAL INFORMATION INTENDED ONLY FOR THE USE > OF THE NAMED RECIPIENT(S). ANY DISSEMINATION, DISTRIBUTION OR > DUPLICATION OF THIS TRANSMISSION IS STRICTLY PROHIBITED. > > If you believe you have received this e-mail in error, please notify > the Sender and delete the e-mail from your system. > > DISCLAIMER OF LIABILITY: > > This transmittal and any accompanying information is for suggestion > only and is provided "AS IS". It shall not be deemed to modify > Microchip's standard warranty for its products. It is your > responsibility to ensure that this information meets your requirements. > > MICROCHIP DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED STATUTORY OR > OTHERWISE, INCLUDING BUT NOT LIMITED TO MERCHANTABILITY, FITNESS FOR > PURPOSE, NON-INFRINGEMENT, QUALITY, OR CONDITION. MICROCHIP PROVIDES > THIS INFORMATION CONDITIONALLY UPON YOUR ACCEPTANCE OF THESE TERMS. > > To the fullest extent allowed by law, Microchip's liability shall not > exceed the amount of fee, if any, that you have paid directly to > Microchip for development of this information and associated services. > > ------------------------------------------------------------------------ > > *From:* Borut Razem [mailto:bor...@si...] > *Sent:* Monday, September 20, 2010 11:25 PM > *To:* Joe Drzewiecki - C11694 > *Subject:* Re: Fwd: RE: gpasm - MPASM include files license > > Hi Joe, > > thanks for the response. > > See my comments below. > > I'm also asking you for the permission to share your mails with other > sdcc developers, specially to discuss the request about exclusive use > with authentic Microchip devices. > > The attached statement at the end of your mail (... "IS CONFIDENTIAL > INFORMATION INTENDED ONLY FOR THE USE OF THE NAMED RECIPIENT(S)") > explicitly prevents it. > > You can also CC your mails directly to the sdcc development mailinig > list sdc...@li... > <mailto:sdc...@li...> or join the mailing list at > https://lists.sourceforge.net/lists/listinfo/sdcc-devel. > > > Best regards, > Borut > > > On 09/21/2010 01:21 AM, Joe...@mi... > <mailto:Joe...@mi...> wrote: > > Borut, > > I would like to provide you with our XML repository, which contains > all of the information you need to construct the header/linker files. > > Using the header files (an intermediate representation) to generate > your files is too prone for error for my liking. > > We will update the XML repository regularly so that you will always > have the best data that we have. > > If you start from the XML repository, as Microchip desires, I would be > glad to provide it. > > > Yes, I'm definitely interested on XML repository. Is it available from > the web? If not, please provide it to me. But this is out of scope for > the sdcc 3.0.0 release... > > > For the files you generate, I have one request: > > The header files should state that they are only to be used with > authentic Microchip devices > > > This is the hard one: I don't know if the requies is in spirit and > compatible with GPL. I'm affraid it is not, but I have to check... > > > If you want to issue them under the GPL+LE license, I have no objection. > > > I your request is compatible with GPL, we can add an additional > exception, stating that "the file can be used only with authentic > Microchip devices". > > > I would like you to offer the latest XML repository for use without > the restrictions of the GPL+LE license -- basically free for any use > that involves authentic Microchip devices. > > /Best Regards,/ > > /Joe Drzewiecki/ > > Microchip Technology, Inc. > > 2355 W. Chandler Blvd. > > Chandler, AZ > > (480) 792-7012 > > //Joe.Drzewiecki@Microchip.com// <mailto:Joe.Drzewiecki@Microchip.com> > > P please consider the environment before printing this email > > THIS E-MAIL TRANSMISSION, AND ANY DOCUMENTS, FILES OR PREVIOUS E-MAILS > ATTACHED TO IT, IS CONFIDENTIAL INFORMATION INTENDED ONLY FOR THE USE > OF THE NAMED RECIPIENT(S). ANY DISSEMINATION, DISTRIBUTION OR > DUPLICATION OF THIS TRANSMISSION IS STRICTLY PROHIBITED. > > If you believe you have received this e-mail in error, please notify > the Sender and delete the e-mail from your system. > > DISCLAIMER OF LIABILITY: > > This transmittal and any accompanying information is for suggestion > only and is provided "AS IS". It shall not be deemed to modify > Microchip's standard warranty for its products. It is your > responsibility to ensure that this information meets your requirements. > > MICROCHIP DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED STATUTORY OR > OTHERWISE, INCLUDING BUT NOT LIMITED TO MERCHANTABILITY, FITNESS FOR > PURPOSE, NON-INFRINGEMENT, QUALITY, OR CONDITION. MICROCHIP PROVIDES > THIS INFORMATION CONDITIONALLY UPON YOUR ACCEPTANCE OF THESE TERMS. > > To the fullest extent allowed by law, Microchip's liability shall not > exceed the amount of fee, if any, that you have paid directly to > Microchip for development of this information and associated services. > > ------------------------------------------------------------------------ > > *From:* Borut Razem [mailto:bor...@si...] > *Sent:* Sunday, August 29, 2010 12:33 AM > *To:* Joe Drzewiecki - C11694 > *Cc:* John O Battle > *Subject:* Re: Fwd: RE: gpasm - MPASM include files license > > Hello Joe, > > thanks for your willingness to collaborate. > > SDCC uses MPLAB include files indirectly: we have inc2h.pl, > inc2h-pic16.pl and pic18fam-h-gen.pl perl scripts (see > http://sdcc.svn.sourceforge.net/viewvc/sdcc/trunk/sdcc/support/scripts/) > which generate C source and header files, distributed as a part of > SDCC library. > (see > http://sdcc.svn.sourceforge.net/viewvc/sdcc/trunk/sdcc/device/include/pic/ > http://sdcc.svn.sourceforge.net/viewvc/sdcc/trunk/sdcc/device/lib/pic/libdev/ > http://sdcc.svn.sourceforge.net/viewvc/sdcc/trunk/sdcc/device/include/pic16/ > http://sdcc.svn.sourceforge.net/viewvc/sdcc/trunk/sdcc/device/lib/pic16/libdev/) > > We decided to release the SDCC library under an open source license, > which allows to use it in proprietary (non open source) projects in > the next SDCC release. Currently the library files are released mainly > under GPL or LGPL. We chose the GPL+LE license (see > https://sourceforge.net/apps/trac/sdcc/wiki/Library%20License%20Selection). > > You can see the current sdcc library license change status at > https://sourceforge.net/apps/trac/sdcc/wiki/Files%20and%20Licenses > > We would like to release the pic device library files under the GPL+LE > license too, but we think we can't do it without your permission, > since they are generated from MPLAB include files (which doesn't > contain any info about licensing conditions). The license will be > applied only on the generated sdcc library files. The original MPLAB > include files licensing will not be affected. > > So I'm kindly asking you for permission to release pic device files, > generated from MPLAB include files and included in sdcc library, under > the GLP+LE license by adding the GPL+LE comment to them (see > https://sourceforge.net/apps/trac/sdcc/wiki/SDCC%20library%20source%20file%20license%20header). > > If you don't agree with the GPL+LE license or you have additional > questions / propositions / requirements / concerns / anything, please > don't hesitate to contact me or the sdcc developers mailing list at > sdc...@li... > <mailto:sdc...@li...>. > > Sincerely Yours, > Borut > > > > > On 07/29/2010 07:29 PM, John O Battle wrote: > > - -------- Original Message -------- > Subject: RE: gpasm - MPASM include files license > Date: Thu, 29 Jul 2010 09:12:52 -0700 > From:<Joe...@mi...> <mailto:Joe...@mi...> > To:<job...@ca...> <mailto:job...@ca...>,<Don...@mi...> <mailto:Don...@mi...>, > <Vincent.Sheard@Microchip.com> <mailto:Vincent.Sheard@Microchip.com> > > John, > > We're going one better. > We're setting up a web site where the entire device database is > presented in XML (among other things). > > We can post the header and include files as well at the time of release > of every compiler or MPASM. It will take a little doing, but hell, you > can't use them with any other device - why should we care about letting > GPASM and SDCC use them? > > The only thing is going to be a question of synchronization. The release > schedule is pretty haphazard right now. The SDCC and GPASM guys are > going to have to keep an eagle eye out and when we update them on the > open-source web site, they'll have to snarf them. Is that fair enough? > > Joe > P.S., BTW, I am the guy Borut wants to talk to. Feel free to give him my > name and email address. We'd like to forge (:) a closer alliance with > those guys. > - -----Original Message----- > From: John O Battle [mailto:job...@ca...] > Sent: Thursday, July 29, 2010 8:14 AM > To: Donna Mason - C08830; Joe Drzewiecki - C11694; Vincent Sheard - > C10252 > Subject: Fwd: gpasm - MPASM include files license > > Donna > > Any way we (Microchip) can help/cooperate with this effort? I think > working with these guys would be good PR for microchip and would make > some friends in the process. > > John > > - -------- Original Message -------- > Subject: gpasm - MPASM include files license > Date: Wed, 28 Jul 2010 21:33:56 +0200 > From: Borut Razem<bor...@si...> <mailto:bor...@si...> > Reply-To:<gn...@li...> <mailto:gn...@li...> > To: gnupic<gn...@li...> <mailto:gn...@li...> > CC: Sdcc-Devel<sdc...@li...> <mailto:sdc...@li...> > > Hi, > > I wold like to know what is the status of using / distributing Microchip > MPASM include files with gpasm: > - - is there any "official" statement from Microchip that the include > files can be used with gpasm? > - - has anybody contact the Microchip to clarify this issue? > - - does anybody know a contact person or address at Microchip where I > can > send an e-mail to get answers about the matter? > > I'm asking this because there is no copyright notice (Microchip is > mentioned, but not explicitly as a copyright holder) nor any licensing > terms in include files. > > Sdcc project is using MPASM include files to produce device specific > headers and c source files which are part of sdcc run-time libraries. > One of goals for the upcoming sdcc 3.0 release is to release the sdcc > library under the GPL+LE (see > http://sourceforge.net/apps/trac/sdcc/wiki/Library%20License%20Selection > ), > so that it can be used with closed source (proprietary) software. Part > of this task is also clarification of licensing status of MPASM include > files. > > Best regards, > Borut > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJMUbqMAAoJELejoBGAt4nRlg8H/01ADtOx69SL0pT3Hl2M70Zr > NtaT8IUU6zNZrGCLXcpeUj/MoklhBaGGI+qx2PJPfnno6cajeJTd0dw+oWuXKpQX > oNssyzbtu8kYews1PsgWZU6hssr3Dc/niBN/OOlN0+xoPTiJ95uxhOMSZViBYUVS > aP5GHL8TpoPAa/1cJneL6kjcG8yOMi0xvhwgLxanzaL9VRxtXeacuhsTQKlEIpaD > vRRq/BFqcOJptrvAtdzJm0RejIz18sPjak4Vsm2JIHHF6YAbZ4Cjg8Dhv77/1bjp > C7PZ3gKzHlsGaoZPsI1YvGtE/3gkQ8yxvxrYxErTOO0ZxiaILncpzE/DxOoFzFQ= > =AD/U > -----END PGP SIGNATURE----- > > > |
From: <Joe...@mi...> - 2010-10-18 16:19:34
|
Borut, gentlepeople, If you are interested in the XML repository, I can make that happen. Let me get it worked out with the right people. Best Regards, Joe Drzewiecki Microchip Technology, Inc. 2355 W. Chandler Blvd. Chandler, AZ (480) 792-7012 Joe.Drzewiecki@Microchip.com <mailto:Joe.Drzewiecki@Microchip.com> P please consider the environment before printing this email THIS E-MAIL TRANSMISSION, AND ANY DOCUMENTS, FILES OR PREVIOUS E-MAILS ATTACHED TO IT, IS CONFIDENTIAL INFORMATION INTENDED ONLY FOR THE USE OF THE NAMED RECIPIENT(S). ANY DISSEMINATION, DISTRIBUTION OR DUPLICATION OF THIS TRANSMISSION IS STRICTLY PROHIBITED. If you believe you have received this e-mail in error, please notify the Sender and delete the e-mail from your system. DISCLAIMER OF LIABILITY: This transmittal and any accompanying information is for suggestion only and is provided "AS IS". It shall not be deemed to modify Microchip's standard warranty for its products. It is your responsibility to ensure that this information meets your requirements. MICROCHIP DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED STATUTORY OR OTHERWISE, INCLUDING BUT NOT LIMITED TO MERCHANTABILITY, FITNESS FOR PURPOSE, NON-INFRINGEMENT, QUALITY, OR CONDITION. MICROCHIP PROVIDES THIS INFORMATION CONDITIONALLY UPON YOUR ACCEPTANCE OF THESE TERMS. To the fullest extent allowed by law, Microchip's liability shall not exceed the amount of fee, if any, that you have paid directly to Microchip for development of this information and associated services. ________________________________ From: Borut Razem [mailto:bor...@si...] Sent: Sunday, October 17, 2010 9:21 AM To: Development chatter about sdcc Cc: Joe Drzewiecki - C11694 Subject: Re: [sdcc-devel] FW: Fwd: RE: gpasm - MPASM include files license Hi Joe, your requirement: "The header files should state that they are only to be used with authentic Microchip devices" is not GPL compatible: in clause 6 of GPLv2 (GPLv3 is a bit more verbose, see clause 7 and 10) is written: "You may not impose any further restrictions on the recipients' exercise of the rights granted herein". So we decided to put all pic device description header and library files, derived from Microchip include files into a separate non-free directory ("free" as in "free speech," not as in "free beer"). This also makes the life of Debian package mangers easier, since non-free files can be easily packaged in as separate packages, in order to be in conformity with Debian Free Software guidelines (DFSG). We also added the --non-free sdcc command line option, which enables sdcc to search for include and lib files under the non-free directory (non-free/include, non-free/lib). This means that user can not use the Microchip derived lib & include files by mistake with non-Microchip devices. The restriction is also documented in the sdcc manual (sddcman.lyx, sdccman.pdf and sdccman html documents). I hope that we choose the optimal way to protect your (Microchip) interests, interests of FOSS developers, and the interests of closed source developers. We are still very much interested to change our device description lib & header files generation system to use the XML repository after the sdcc 3.0.0 release, but I still don't know how to access / get the repository... Best regards, Borut On 09/21/2010 07:02 PM, Joe...@mi... wrote: Borut and gang, Here's the email thread, released, to share and discuss. :-) Thanks for being so persnickety! Now you are all named. Let me know what you decide. Best Regards, Joe Drzewiecki Microchip Technology, Inc. 2355 W. Chandler Blvd. Chandler, AZ (480) 792-7012 Joe.Drzewiecki@Microchip.com <mailto:Joe.Drzewiecki@Microchip.com> P please consider the environment before printing this email THIS E-MAIL TRANSMISSION, AND ANY DOCUMENTS, FILES OR PREVIOUS E-MAILS ATTACHED TO IT, IS CONFIDENTIAL INFORMATION INTENDED ONLY FOR THE USE OF THE NAMED RECIPIENT(S). ANY DISSEMINATION, DISTRIBUTION OR DUPLICATION OF THIS TRANSMISSION IS STRICTLY PROHIBITED. If you believe you have received this e-mail in error, please notify the Sender and delete the e-mail from your system. DISCLAIMER OF LIABILITY: This transmittal and any accompanying information is for suggestion only and is provided "AS IS". It shall not be deemed to modify Microchip's standard warranty for its products. It is your responsibility to ensure that this information meets your requirements. MICROCHIP DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED STATUTORY OR OTHERWISE, INCLUDING BUT NOT LIMITED TO MERCHANTABILITY, FITNESS FOR PURPOSE, NON-INFRINGEMENT, QUALITY, OR CONDITION. MICROCHIP PROVIDES THIS INFORMATION CONDITIONALLY UPON YOUR ACCEPTANCE OF THESE TERMS. To the fullest extent allowed by law, Microchip's liability shall not exceed the amount of fee, if any, that you have paid directly to Microchip for development of this information and associated services. ________________________________ From: Borut Razem [mailto:bor...@si...] Sent: Monday, September 20, 2010 11:25 PM To: Joe Drzewiecki - C11694 Subject: Re: Fwd: RE: gpasm - MPASM include files license Hi Joe, thanks for the response. See my comments below. I'm also asking you for the permission to share your mails with other sdcc developers, specially to discuss the request about exclusive use with authentic Microchip devices. The attached statement at the end of your mail (... "IS CONFIDENTIAL INFORMATION INTENDED ONLY FOR THE USE OF THE NAMED RECIPIENT(S)") explicitly prevents it. You can also CC your mails directly to the sdcc development mailinig list sdc...@li... or join the mailing list at https://lists.sourceforge.net/lists/listinfo/sdcc-devel. Best regards, Borut On 09/21/2010 01:21 AM, Joe...@mi... wrote: Borut, I would like to provide you with our XML repository, which contains all of the information you need to construct the header/linker files. Using the header files (an intermediate representation) to generate your files is too prone for error for my liking. We will update the XML repository regularly so that you will always have the best data that we have. If you start from the XML repository, as Microchip desires, I would be glad to provide it. Yes, I'm definitely interested on XML repository. Is it available from the web? If not, please provide it to me. But this is out of scope for the sdcc 3.0.0 release... For the files you generate, I have one request: The header files should state that they are only to be used with authentic Microchip devices This is the hard one: I don't know if the requies is in spirit and compatible with GPL. I'm affraid it is not, but I have to check... If you want to issue them under the GPL+LE license, I have no objection. I your request is compatible with GPL, we can add an additional exception, stating that "the file can be used only with authentic Microchip devices". I would like you to offer the latest XML repository for use without the restrictions of the GPL+LE license - basically free for any use that involves authentic Microchip devices. Best Regards, Joe Drzewiecki Microchip Technology, Inc. 2355 W. Chandler Blvd. Chandler, AZ (480) 792-7012 Joe.Drzewiecki@Microchip.com <mailto:Joe.Drzewiecki@Microchip.com> P please consider the environment before printing this email THIS E-MAIL TRANSMISSION, AND ANY DOCUMENTS, FILES OR PREVIOUS E-MAILS ATTACHED TO IT, IS CONFIDENTIAL INFORMATION INTENDED ONLY FOR THE USE OF THE NAMED RECIPIENT(S). ANY DISSEMINATION, DISTRIBUTION OR DUPLICATION OF THIS TRANSMISSION IS STRICTLY PROHIBITED. If you believe you have received this e-mail in error, please notify the Sender and delete the e-mail from your system. DISCLAIMER OF LIABILITY: This transmittal and any accompanying information is for suggestion only and is provided "AS IS". It shall not be deemed to modify Microchip's standard warranty for its products. It is your responsibility to ensure that this information meets your requirements. MICROCHIP DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED STATUTORY OR OTHERWISE, INCLUDING BUT NOT LIMITED TO MERCHANTABILITY, FITNESS FOR PURPOSE, NON-INFRINGEMENT, QUALITY, OR CONDITION. MICROCHIP PROVIDES THIS INFORMATION CONDITIONALLY UPON YOUR ACCEPTANCE OF THESE TERMS. To the fullest extent allowed by law, Microchip's liability shall not exceed the amount of fee, if any, that you have paid directly to Microchip for development of this information and associated services. ________________________________ From: Borut Razem [mailto:bor...@si...] Sent: Sunday, August 29, 2010 12:33 AM To: Joe Drzewiecki - C11694 Cc: John O Battle Subject: Re: Fwd: RE: gpasm - MPASM include files license Hello Joe, thanks for your willingness to collaborate. SDCC uses MPLAB include files indirectly: we have inc2h.pl, inc2h-pic16.pl and pic18fam-h-gen.pl perl scripts (see http://sdcc.svn.sourceforge.net/viewvc/sdcc/trunk/sdcc/support/scripts/) which generate C source and header files, distributed as a part of SDCC library. (see http://sdcc.svn.sourceforge.net/viewvc/sdcc/trunk/sdcc/device/include/pi c/ http://sdcc.svn.sourceforge.net/viewvc/sdcc/trunk/sdcc/device/lib/pic/li bdev/ http://sdcc.svn.sourceforge.net/viewvc/sdcc/trunk/sdcc/device/include/pi c16/ http://sdcc.svn.sourceforge.net/viewvc/sdcc/trunk/sdcc/device/lib/pic16/ libdev/) We decided to release the SDCC library under an open source license, which allows to use it in proprietary (non open source) projects in the next SDCC release. Currently the library files are released mainly under GPL or LGPL. We chose the GPL+LE license (see https://sourceforge.net/apps/trac/sdcc/wiki/Library%20License%20Selectio n). You can see the current sdcc library license change status at https://sourceforge.net/apps/trac/sdcc/wiki/Files%20and%20Licenses We would like to release the pic device library files under the GPL+LE license too, but we think we can't do it without your permission, since they are generated from MPLAB include files (which doesn't contain any info about licensing conditions). The license will be applied only on the generated sdcc library files. The original MPLAB include files licensing will not be affected. So I'm kindly asking you for permission to release pic device files, generated from MPLAB include files and included in sdcc library, under the GLP+LE license by adding the GPL+LE comment to them (see https://sourceforge.net/apps/trac/sdcc/wiki/SDCC%20library%20source%20fi le%20license%20header). If you don't agree with the GPL+LE license or you have additional questions / propositions / requirements / concerns / anything, please don't hesitate to contact me or the sdcc developers mailing list at sdc...@li.... Sincerely Yours, Borut On 07/29/2010 07:29 PM, John O Battle wrote: - -------- Original Message -------- Subject: RE: gpasm - MPASM include files license Date: Thu, 29 Jul 2010 09:12:52 -0700 From: <Joe...@mi...> <mailto:Joe...@mi...> To: <job...@ca...> <mailto:job...@ca...> , <Don...@mi...> <mailto:Don...@mi...> , <Vincent.Sheard@Microchip.com> <mailto:Vincent.Sheard@Microchip.com> John, We're going one better. We're setting up a web site where the entire device database is presented in XML (among other things). We can post the header and include files as well at the time of release of every compiler or MPASM. It will take a little doing, but hell, you can't use them with any other device - why should we care about letting GPASM and SDCC use them? The only thing is going to be a question of synchronization. The release schedule is pretty haphazard right now. The SDCC and GPASM guys are going to have to keep an eagle eye out and when we update them on the open-source web site, they'll have to snarf them. Is that fair enough? Joe P.S., BTW, I am the guy Borut wants to talk to. Feel free to give him my name and email address. We'd like to forge (:) a closer alliance with those guys. - -----Original Message----- From: John O Battle [mailto:job...@ca...] Sent: Thursday, July 29, 2010 8:14 AM To: Donna Mason - C08830; Joe Drzewiecki - C11694; Vincent Sheard - C10252 Subject: Fwd: gpasm - MPASM include files license Donna Any way we (Microchip) can help/cooperate with this effort? I think working with these guys would be good PR for microchip and would make some friends in the process. John - -------- Original Message -------- Subject: gpasm - MPASM include files license Date: Wed, 28 Jul 2010 21:33:56 +0200 From: Borut Razem <bor...@si...> <mailto:bor...@si...> Reply-To: <gn...@li...> <mailto:gn...@li...> To: gnupic <gn...@li...> <mailto:gn...@li...> CC: Sdcc-Devel <sdc...@li...> <mailto:sdc...@li...> Hi, I wold like to know what is the status of using / distributing Microchip MPASM include files with gpasm: - - is there any "official" statement from Microchip that the include files can be used with gpasm? - - has anybody contact the Microchip to clarify this issue? - - does anybody know a contact person or address at Microchip where I can send an e-mail to get answers about the matter? I'm asking this because there is no copyright notice (Microchip is mentioned, but not explicitly as a copyright holder) nor any licensing terms in include files. Sdcc project is using MPASM include files to produce device specific headers and c source files which are part of sdcc run-time libraries. One of goals for the upcoming sdcc 3.0 release is to release the sdcc library under the GPL+LE (see http://sourceforge.net/apps/trac/sdcc/wiki/Library%20License%20Selection ), so that it can be used with closed source (proprietary) software. Part of this task is also clarification of licensing status of MPASM include files. Best regards, Borut -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMUbqMAAoJELejoBGAt4nRlg8H/01ADtOx69SL0pT3Hl2M70Zr NtaT8IUU6zNZrGCLXcpeUj/MoklhBaGGI+qx2PJPfnno6cajeJTd0dw+oWuXKpQX oNssyzbtu8kYews1PsgWZU6hssr3Dc/niBN/OOlN0+xoPTiJ95uxhOMSZViBYUVS aP5GHL8TpoPAa/1cJneL6kjcG8yOMi0xvhwgLxanzaL9VRxtXeacuhsTQKlEIpaD vRRq/BFqcOJptrvAtdzJm0RejIz18sPjak4Vsm2JIHHF6YAbZ4Cjg8Dhv77/1bjp C7PZ3gKzHlsGaoZPsI1YvGtE/3gkQ8yxvxrYxErTOO0ZxiaILncpzE/DxOoFzFQ= =AD/U -----END PGP SIGNATURE----- |