From: Weston S. <wes...@al...> - 2011-03-23 08:41:31
|
Hello, I am curious if there is any interest in GPL+LE/LP pic/pic16 headers? I ask because I need to add a few new pic16 devices to SDCC & GPUTILS, and I figure if I'm going to spend time to add my chips, I might be able to figure out some way to create the rest of the headers from the facts in the datasheets. But, I have no desire to waste my time on something people aren't interested in, so I figured I'd ask first. Let me know (It may take me a while, by the way). Thanks, Wes |
From: Rafael C. <me...@gm...> - 2011-03-24 11:48:04
|
Hello, On Wed, Mar 23, 2011 at 05:41, Weston Schmidt <wes...@al...> wrote: > Hello, > > I am curious if there is any interest in GPL+LE/LP pic/pic16 headers? I would love to see the pic headers such a this license. I could also help with some missing headers/defines that makes the code more friendly between compilers. In pic14 family, we have some definitions, but we don`t have them for pic16. > > I ask because I need to add a few new pic16 devices to SDCC & GPUTILS, and I > figure if I'm going to spend time to add my chips, I might be able to figure > out some way to create the rest of the headers from the facts in the > datasheets. > > But, I have no desire to waste my time on something people aren't interested > in, so I figured I'd ask first. > > Let me know (It may take me a while, by the way). > > Thanks, > Wes > > ------------------------------------------------------------------------------ > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > Regards, -- ___________ Rafael Campos o0 Methril 0o http://openblog.methril.net/ |
From: Weston S. <wes...@al...> - 2011-03-27 11:56:09
|
Rafael, Ok, good to hear. I'm working on the following path (for the chips I'm most interested in first): 1. Start with the PDF Datasheets (done with auto-downloader) 2. Identify the SFR table pages (currently manually, but ideally it would be automated) 3. Identify the Config table page (currently manually, but ideally it would be automated) 4. Use pdftohtml + perl script to convert the _facts_ stored in the PDF tables into csv files (done) 5. Inspect and correct the csv files (manual) 6. Run yet another perl script to convert the correct csv tables into an xml file for the part (not done yet) 7. Add configuration details + whatever else we want/need to the file. 8. At this point (if not before), the xml files will be under a different copyright because they don't contain any thing but facts from the original PDF, plus our customization (facts are not copyright-able) 9. Use the xml files to generate the header files for each part 10. Optional - it seems like a fair chunk of code for gputils could be generated from the xml definition files if we do it right. I do realize that xml isn't terribly popular with some people, so I'll explain my logic on using it. 1. I'm familiar with it. 2. There are pre-built parsers that can be used with it. 3. It offers flexibility to change & grow without too much pain. 4. It can always be translated into something more suitable. --Wes On Thu, Mar 24, 2011 at 4:39 AM, Rafael Campos <me...@gm...> wrote: > Hello, > > On Wed, Mar 23, 2011 at 05:41, Weston Schmidt > <wes...@al...> wrote: > > Hello, > > > > I am curious if there is any interest in GPL+LE/LP pic/pic16 headers? > I would love to see the pic headers such a this license. I could also > help with some missing headers/defines that makes the code more > friendly between compilers. In pic14 family, we have some definitions, > but we don`t have them for pic16. > > > > I ask because I need to add a few new pic16 devices to SDCC & GPUTILS, > and I > > figure if I'm going to spend time to add my chips, I might be able to > figure > > out some way to create the rest of the headers from the facts in the > > datasheets. > > > > But, I have no desire to waste my time on something people aren't > interested > > in, so I figured I'd ask first. > > > > Let me know (It may take me a while, by the way). > > > > Thanks, > > Wes > > > > > ------------------------------------------------------------------------------ > > Enable your software for Intel(R) Active Management Technology to meet > the > > growing manageability and security demands of your customers. Businesses > > are taking advantage of Intel(R) vPro (TM) technology - will your > software > > be a part of the solution? Download the Intel(R) Manageability Checker > > today! http://p.sf.net/sfu/intel-dev2devmar > > _______________________________________________ > > Sdcc-user mailing list > > Sdc...@li... > > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > > > > Regards, > > -- > ___________ > Rafael Campos > o0 Methril 0o > http://openblog.methril.net/ > |
From: Weston S. <wes...@al...> - 2011-03-29 08:07:52
|
OIgierd, Which chips are you interested in & I'll try them next? Sorry I didn't get your email directly, but hopefully this keeps it in the same thread. --Wes |
From: Olgierd E. <oe...@ei...> - 2011-03-24 12:26:26
|
I think it is interesting, I need to create a couple of header files also. OIgierd El 23/03/2011 4:41, Weston Schmidt escribió: > Hello, > > I am curious if there is any interest in GPL+LE/LP pic/pic16 headers? > > I ask because I need to add a few new pic16 devices to SDCC & GPUTILS, > and I figure if I'm going to spend time to add my chips, I might be > able to figure out some way to create the rest of the headers from the > facts in the datasheets. > > But, I have no desire to waste my time on something people aren't > interested in, so I figured I'd ask first. > > Let me know (It may take me a while, by the way). > > Thanks, > Wes > > > ------------------------------------------------------------------------------ > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar > > > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Olgierd E. <oe...@ei...> - 2011-03-29 11:46:44
|
Wes, I'm actually working with the 18F66j15, 18F65j10 and I plan to start using the 18F67j50 I have boards with the 66j15 and 65j10 so I can test the headers. I can help also building the files or doing other things Regards Olgierd On 29-03-2011 5:07, Weston Schmidt wrote: > OIgierd, > > Which chips are you interested in& I'll try them next? > > Sorry I didn't get your email directly, but hopefully this keeps it in the same thread. > > --Wes > > > > > ------------------------------------------------------------------------------ > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar > > > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Weston S. <wes...@al...> - 2011-03-30 09:10:23
|
Olgierd, Excellent - the datasheet for those chips was quite a bit different, so now the scripts are quite a bit better. I'm not sure where they will end up (sdcc/gputils/other), so I put up a small project on github so you can have access to what I'm up to. https://github.com/schmidtw/make-gpl-microchip-headers/wiki --Wes On Tue, Mar 29, 2011 at 4:47 AM, Olgierd Eysymontt <oe...@ei...> wrote: > Wes, I'm actually working with the 18F66j15, 18F65j10 and I plan to start > using the 18F67j50 > > I have boards with the 66j15 and 65j10 so I can test the headers. > > I can help also building the files or doing other things > > Regards > > Olgierd > > > On 29-03-2011 5:07, Weston Schmidt wrote: > > OIgierd, > > Which chips are you interested in & I'll try them next? > > Sorry I didn't get your email directly, but hopefully this keeps it in the same thread. > > --Wes > > > > > ------------------------------------------------------------------------------ > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar > > > _______________________________________________ > Sdcc-user mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > > > ------------------------------------------------------------------------------ > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > |
From: Raphael N. <rn...@we...> - 2011-03-30 09:36:15
|
Hi, > I am curious if there is any interest in GPL+LE/LP pic/pic16 headers? Well, yes! I just want to inform you that, IIRC, Microchip recently offered half a year or maybe a year ago (I believe after Borut asked them?) to somehow publish their device descriptions in some kind of XML database for use by gputils/sdcc/whoever. This would probably not solve the licensing issues towards making the files (L)GPL'able (not sure what license would be possible), but it would be an alternative source of data, e.g., for verifying your results. Unfortunately, I have no idea as to if or how or where said XML database is available already. Happy hacking Raphael |
From: Borut R. <bor...@gm...> - 2011-03-30 16:05:33
|
On 03/30/2011 11:20 AM, Raphael Neider wrote: > Hi, > >> I am curious if there is any interest in GPL+LE/LP pic/pic16 headers? > Well, yes! > > I just want to inform you that, IIRC, Microchip recently offered half a > year or maybe a year ago (I believe after Borut asked them?) to somehow > publish their device descriptions in some kind of XML database for use by > gputils/sdcc/whoever. > This would probably not solve the licensing issues towards making the > files (L)GPL'able (not sure what license would be possible), but it would > be an alternative source of data, e.g., for verifying your results. > Unfortunately, I have no idea as to if or how or where said XML database > is available already. > Yes, I exchanged several e-mails with them.They said several times that they'll give us access to the XML pic device database, but this never happened. But anyway, the pic .h and .c files, produced from the their XML database wold have the same legal limitations as the current ones, generated from MPASM include files: they can be used only for chips, produced by Microchip. So no GPL. I think the correct way to produce the GPL .h and .c files is directly from the documentation, as Wes suggested. But even for this approach I'm not sure if it is 100% legal. Has anybody take a detailed look into the documentation if there is a statement which prohibits such actions? Borut |
From: Kustaa N. <Kus...@pl...> - 2011-03-30 18:14:59
|
On 3/30/11 19:05, "Borut Razem" <bor...@gm...> wrote: > But anyway, the pic .h and .c files, produced from the their >XML database wold have the same legal limitations as the current ones, >generated from MPASM include files: they can be used only for chips, >produced by Microchip. So no GPL. So many things going on this paragraph, hard to know where to start. Copyright is about the end result, not about the process, ie no matter what you do or how you do it, if the end result is close enough to the original then it is a copy. Another aspect of copyright is originality, which in the context of copyright law means 'something that required some creativity to produce', ie not every variation of a something is original art in the meaning of the act, thus not every man made thing is copyrighted. The threshold is low, much lower than the inventive step requirement in patents for example, but it is there. Thirdly copyright protects the non-utilitarian aspects of the art work, it protects the form not function. There is no copyright on the shape of a piston or engine block (unless they are exceptionally artistic!), there maybe patents or that BMW logo might be trademarked, but copyright, I don't think so. Now lets look at the existing header files (just had a look at pic18f2455.h) in the light of the above. Take for example this fragment: extern __sfr __at (0xF62) SPPDATA; typedef union { struct { unsigned DATA : 8; }; } __SPPDATA_t; extern volatile __SPPDATA_t __at (0xF62) SPPDATAbits; The form of this fragment is determined by the C-language standard, so there is no originality there. The hex addresses are purely functional, so no copyright there. The names SPPDATA might have some originality in the choice of the acronym/mnemonic, but since that is really the only way to refer to that register, its the name of the thing, you cannot separate the function from the form and thus this is not copyrighted. I believe no single word or name has ever been considered copyrighted. So I see no way the above fragment can be copyrighted. How about the comments? Well there might be something in there if the comments would somehow be original but they seem to be very much like any other similar comment in hundreds of header files. No copyright there. How about copyright as a collection of items that in themselves are not copyrightable? Or the order of definitions on those files? I do not think that would pass the originality threshold. So in my view there is no copyright on those header files and the question of license is moot. No copyright => no one can enforce any license. > >I think the correct way to produce the GPL .h and .c files is directly >from the documentation, as Wes suggested. The process of how you make a 'copy' makes no difference. >But even for this approach I'm not sure if it is 100% legal. Again, no matter how you produce a copy of a copyrighted work, distribution of that copy is the prerogative of the copyright holder and they can allow it or forbid it. They can allow it for free or under almost any term they want. The permission can be explicit or implicit, as if a thing has been in circulation for a long time and they have know about it and not acted upon the infringement they may loose the copyright. >Has anybody take a detailed look into the >documentation if there is a statement which prohibits such actions? At least on the 2455/2550/4455/4550 datasheet there is no such statement, it only says "(c)2006 All rights reserved". So it can be argued that Microchip has created an implied license to use those names and addresses in anyway we see fit when they published them, what else purpose there could be for publishing them. But I do not believe the names and address are copyrighted in the first place, so weather they approved or forbid it is moot as they have no control over it. br Kusti |
From: Borut R. <bor...@gm...> - 2011-03-30 20:43:34
|
Kustaa, thanks for the detailed explanation of copyrights! Probably such an approach would be good for the court, but there is an other point of view: moral rights. We all know that there is a lot more then hex addresses and register names we are talking about. I think Microchip is not concerned about include files themselves, but about copying / stealing of the knowhow (resources, time, money...) they are investing into the development of pic MCUs. The statement that the include files can be used only with their own chips is just an additional measure of protection. This statement is even not written in the .inc files: they wrote it when I asked them about the licensing status, but I believe we should respect it anyway. I already explained them that we have scripts to convert MPASM include files to .c and .h files. This is not a problem for them, they just want that the statement is valid for the generated files too. Maybe you are right and legally we don't have to obey them, but this is their moral right which we have to respect. This is my personal opinion which can also be changed if somebody shows (and convinces) me that I'm wrong. P.S.: and this is also why I wrote that I'm not 100% sure: there is no big difference if the files are generated from XML database, .inc files or from documentation... Borut On 03/30/2011 08:14 PM, Kustaa Nyholm wrote: > On 3/30/11 19:05, "Borut Razem"<bor...@gm...> wrote: >> But anyway, the pic .h and .c files, produced from the their >> XML database wold have the same legal limitations as the current ones, >> generated from MPASM include files: they can be used only for chips, >> produced by Microchip. So no GPL. > So many things going on this paragraph, hard to know where to start. > > Copyright is about the end result, not about the process, ie no matter > what you > do or how you do it, if the end result is close enough to the original then > it is a copy. > > Another aspect of copyright is originality, which in the context of > copyright law means 'something that required some creativity to produce', > ie not every variation of a something is original art in the meaning of > the act, > thus not every man made thing is copyrighted. The threshold is low, much > lower > than the inventive step requirement in patents for example, but it is > there. > > Thirdly copyright protects the non-utilitarian aspects of the > art work, it protects the form not function. There is no copyright > on the shape of a piston or engine block (unless they are exceptionally > artistic!), there maybe patents or that BMW logo might be trademarked, > but copyright, I don't think so. > > Now lets look at the existing header files (just had a look at > pic18f2455.h) > in the light of the above. > > Take for example this fragment: > > extern __sfr __at (0xF62) SPPDATA; > typedef union { > struct { > unsigned DATA : 8; > }; > } __SPPDATA_t; > extern volatile __SPPDATA_t __at (0xF62) SPPDATAbits; > > > The form of this fragment is determined by the C-language standard, so > there is no originality there. The hex addresses are purely functional, > so no copyright there. The names SPPDATA might have some originality > in the choice of the acronym/mnemonic, but since that is really the > only way to refer to that register, its the name of the thing, > you cannot separate the function from the form and thus this is not > copyrighted. I believe no single word or name has ever been considered > copyrighted. > > So I see no way the above fragment can be copyrighted. > > How about the comments? > > Well there might be something in there if the comments would somehow > be original but they seem to be very much like any other similar comment > in hundreds of header files. > > No copyright there. > > How about copyright as a collection of items that in themselves > are not copyrightable? Or the order of definitions on those files? > > I do not think that would pass the originality threshold. > > So in my view there is no copyright on those header files and the > question of license is moot. > > No copyright => no one can enforce any license. > >> I think the correct way to produce the GPL .h and .c files is directly > >from the documentation, as Wes suggested. > > The process of how you make a 'copy' makes no difference. > >> But even for this approach I'm not sure if it is 100% legal. > Again, no matter how you produce a copy of a copyrighted work, distribution > of that copy is the prerogative of the copyright holder and they can > allow it or forbid it. They can allow it for free or under almost any > term they want. The permission can be explicit or implicit, as if > a thing has been in circulation for a long time and they have know about > it and not acted upon the infringement they may loose the copyright. > > >> Has anybody take a detailed look into the >> documentation if there is a statement which prohibits such actions? > At least on the 2455/2550/4455/4550 datasheet there is no such statement, > it only says "(c)2006 All rights reserved". So it can be argued that > Microchip > has created an implied license to use those names and addresses in anyway > we see fit when they published them, what else purpose there could be > for publishing them. But I do not believe the names and address are > copyrighted > in the first place, so weather they approved or forbid it is moot as they > have no control over it. > > br Kusti > |
From: Kustaa N. <Kus...@pl...> - 2011-03-30 21:26:58
|
On 3/30/11 23:43, "Borut Razem" <bor...@gm...> wrote: >Kustaa, > >thanks for the detailed explanation of copyrights! >Probably such an approach would be good for the court, but there is an >other point of view: moral rights. Yes there is the question of moral. > >We all know that there is a lot more then hex addresses and register >names we are talking about. I don't agree. As far as the header files are concerned that is all there is to it. > I think Microchip is not concerned about >include files themselves, Yes I'm sure they have concerns, but they is their problem. >but about copying/ stealing of the knowhow >(resources, time, money...) stealing is quite a strong word especially when connected with money in the context we are discussing. In no way could anyone be stealing money. Stealing resources/time is also way too strong to my liking, even if if the headers were copyrighted, which I deny, copying them would not take anything from them. >they are investing into the development of >pic MCUs. Sure, and law gives them, for a good reason, a variety of options to protect their investment, such as trade secrets, patents, trade marks, copyright. >The statement that the include files can be used only with >their own chips is just an additional measure of protection. Yes, that is their attempt, but since they are not original works of art the copyright law offers no protection. >This >statement is even not written in the .inc files: This would not help them in the court. > they wrote it when I >asked them about the licensing status, but I believe we should respect >it anyway. If we respect it we can never have GPL or any other headers as anything reasonable we will create will be close enough to their files to be considered copies. >I already explained them that we have scripts to convert >MPASM include files to .c and .h files. This is not a problem for them, >they just want that the statement is valid for the generated files too. See, they want to claim that they own the names and addresses which they can't and which would in my mind be wrong in the moral sense as well. > >Maybe you are right and legally we don't have to obey them, but this is >their moral right which we have to respect. I strongly disagree with that view. There is are no moral grounds giving them monopoly and exclusive right to those hex addresses and names of the registers. Indeed that would be against good of the society as it would hinder technical progress and economical growth. > >This is my personal opinion which can also be changed if somebody shows >(and convinces) me that I'm wrong. I hope I did! > >P.S.: and this is also why I wrote that I'm not 100% sure: there is no >big difference if the files are generated from XML database, .inc files >or from documentation... See where respecting their "moral right" leads to, no one could ever create any software that links to another software if trivial headers that are purely technical/functional in nature were copyrighted, that is clearly not the intention of the law and society. The explicitly allows reverse engineering to ensure compatibility and society encourages competition but if you cannot create those headers you have no compatibility and no competition. br Kusti |
From: Philipp K. K. <pk...@sp...> - 2011-03-30 22:02:16
|
Am 30.03.2011 23:26, schrieb Kustaa Nyholm: > >> I already explained them that we have scripts to convert >> MPASM include files to .c and .h files. This is not a problem for them, >> they just want that the statement is valid for the generated files too. > > See, they want to claim that they own the names and addresses which they > can't > and which would in my mind be wrong in the moral sense as well. Using the documentation instead of the XML database / MPASM include files IMO seems more likely to be legal wrt. to database copyright. > >> >> Maybe you are right and legally we don't have to obey them, but this is >> their moral right which we have to respect. > > I strongly disagree with that view. There is are no moral grounds giving > them monopoly and exclusive right to those hex addresses and names of > the registers. > Indeed that would be against good of the society as it > would hinder technical progress and economical growth. So is most of copyright and patent law. Philipp |
From: Weston S. <wes...@al...> - 2011-03-30 18:31:56
|
Preface: I'm not a layer. I read the copyright information sections in several of the datasheets. The datasheets do not impose any additional terms like the license that applies to the MPLAB code bundle (which I also read). I also asked PJ from Groklaw about facts in a datasheet (this doesn't constitute legal advice, but is a second opinion): "Facts are not copyrightable, but a collection of facts in a certain order, etc. could be, not the facts themselves but their arrangement in the whole." So my interpretation is that by extracting the facts, breaking the presentation into a different arrangement (xml file, arbitrary ordering, etc.) constitutes a new work that can be copyrighted separately (the facts in my documents are still not copyright-able, so someone else could do exactly the same thing with my work). --Wes |
From: Borut R. <bor...@gm...> - 2011-03-30 21:05:39
|
If this is so, there is no need to regenerate the files: we can just put our copyright on the existing ones and declare that they are GPLed... Borut On 03/30/2011 08:31 PM, Weston Schmidt wrote: > Preface: I'm not a layer. > > I read the copyright information sections in several of the > datasheets. The datasheets do not impose any additional terms like > the license that applies to the MPLAB code bundle (which I also > read). I also asked PJ from Groklaw about facts in a datasheet (this > doesn't constitute legal advice, but is a second opinion): > > "Facts are not copyrightable, but a collection of facts in a certain > order, etc. could be, not the facts themselves but their arrangement > in the whole." > > So my interpretation is that by extracting the facts, breaking the > presentation into a different arrangement (xml file, arbitrary > ordering, etc.) constitutes a new work that can be copyrighted > separately (the facts in my documents are still not copyright-able, so > someone else could do exactly the same thing with my work). > > --Wes |
From: Kustaa N. <Kus...@pl...> - 2011-03-30 21:38:05
|
On 3/31/11 00:05, "Borut Ražem" <bor...@gm...> wrote: >If this is so, there is no need to regenerate the files: we can just put >our copyright on the existing ones and declare that they are GPLed... Nothing can be copyrighted: copyright comes into being by the creative process of creating original stuff. It either comes out of that process or not. Putting any number of copyright texts will not change the status of the file and if the file does not have a copyright, stamping it GPL will not work either as the only moral / enforceable hold GPL has over the source file is copyright. Of course you can put anything onto a non copyrighted text but the it has no legal power, just deterring power. Perhaps someone might claim damages if they feel that the misleading information has caused them harm. I would be in in favor of generating the files by any means from the info on the data sheets and stating that they are in the public domain. br Kusti >On 03/30/2011 08:31 PM, Weston Schmidt wrote: >>"Facts are not copyrightable, but a collection of facts in a certain >> order, etc. could be, not the facts themselves but their arrangement >> in the whole." Could be, but I don't think there is any artistic merit in the order they are presented or the source code formatting, unless very special. Heck, run the through a pretty printer and they format is totally machine generated with no originality. >> So my interpretation is that by extracting the facts, breaking the >> presentation into a different arrangement (xml file, arbitrary >> ordering, etc.) constitutes a new work that can be copyrighted >> separately (the facts in my documents are still not copyright-able, so >> someone else could do exactly the same thing with my work) Yes I think we can do that and might be slightly more safe than just copying the stuff from Microchip .inc files (or from where ever they currently come) but No, they are still not copyrighted. br Kusti |
From: Philipp K. K. <pk...@sp...> - 2011-03-30 22:04:08
|
Am 30.03.2011 23:37, schrieb Kustaa Nyholm: > >> On 03/30/2011 08:31 PM, Weston Schmidt wrote: >>> "Facts are not copyrightable, but a collection of facts in a certain >>> order, etc. could be, not the facts themselves but their arrangement >>> in the whole." > > Could be, but I don't think there is any artistic merit in the order > they are presented or the source code formatting, unless very special. > Heck, run the through a pretty printer and they format is totally machine > generated with no originality. > Database rights, which typically are weaker than ordinary copyright (i.e. they expire earlier) AFAIK do not require any artistic merit or creativity. Philipp |
From: Alain M. <al...@po...> - 2011-03-30 22:58:57
|
DANGER... DANGER... I have been silently following this and then it truck me!!! Libraries and headers thar generate at least ONE byte cannot be GPL!!! Some people use compilers to create comercial products, and it that byte goes along it becomes "derived work" and cannot be protected... Please use BSD/MIT (or MPL if you don't want it to be completly free) For the compiler GPL is ok because no byte of the compiler executable gets *into* the compiled code !!! THANKS Alain Em 30-03-2011 18:37, Kustaa Nyholm escreveu: > On 3/31/11 00:05, "Borut Ražem"<bor...@gm...> wrote: >> If this is so, there is no need to regenerate the files: we can just put >> our copyright on the existing ones and declare that they are GPLed... > > > > Nothing can be copyrighted: copyright comes into being by the creative > process > of creating original stuff. It either comes out of that process or not. > > Putting any number of copyright texts will not change the status of the > file and if the file does not have a copyright, stamping it GPL will > not work either as the only moral / enforceable hold GPL has over > the source file is copyright. > > Of course you can put anything onto a non copyrighted text but the it > has no legal power, just deterring power. Perhaps someone might claim > damages if they feel that the misleading information has caused them harm. > > I would be in in favor of generating the files by any means from the > info on the data sheets and stating that they are in the public domain. > > br Kusti > > >> On 03/30/2011 08:31 PM, Weston Schmidt wrote: >>> "Facts are not copyrightable, but a collection of facts in a certain >>> order, etc. could be, not the facts themselves but their arrangement >>> in the whole." > > Could be, but I don't think there is any artistic merit in the order > they are presented or the source code formatting, unless very special. > Heck, run the through a pretty printer and they format is totally machine > generated with no originality. > > >>> So my interpretation is that by extracting the facts, breaking the >>> presentation into a different arrangement (xml file, arbitrary >>> ordering, etc.) constitutes a new work that can be copyrighted >>> separately (the facts in my documents are still not copyright-able, so >>> someone else could do exactly the same thing with my work) > > Yes I think we can do that and might be slightly more safe than just > copying the stuff from Microchip .inc files (or from where ever they > currently come) but No, they are still not copyrighted. > > br Kusti > > > > ------------------------------------------------------------------------------ > Create and publish websites with WebMatrix > Use the most popular FREE web apps or write code yourself; > WebMatrix provides all the features you need to develop and > publish your website. http://p.sf.net/sfu/ms-webmatrix-sf > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > |
From: Weston S. <wes...@al...> - 2011-03-30 23:49:28
|
Yep. I believe this has been handled by the GPL+LE license used by various other parts of the SDCC project. |
From: Kustaa N. <Kus...@pl...> - 2011-03-31 04:34:52
|
On 3/31/11 01:58, "Alain Mouette" <al...@po...> wrote: >DANGER... DANGER... >I have been silently following this and then it truck me!!! > >Libraries and headers thar generate at least ONE byte cannot be GPL!!! >Some people use compilers to create comercial products, and it that byte >goes along it becomes "derived work" and cannot be protected... That is not true even if FSF would love it to be. One byte cannot be copyrighted. But this is semantics and you are very right here, that is why I advocated putting the headers into the public domain, that would be a service to the mankind. > Please use BSD/MIT (or MPL if you don't want it to be completly free) BSD and MIT will work for me too. > >For the compiler GPL is ok because no byte of the compiler executable >gets *into* the compiled code !!! That is an interesting topic to debate also! Arguably the compiler copies (in the code generator) pieces of code that are arguably part of the compiler executable (in one form or an other) and if those fragments were copyrighted this could spread the infection to the compiled code too.... but I don't think that this would hold in court. Good points Alain! br Kusti |
From: Borut R. <bor...@gm...> - 2011-03-31 05:07:17
|
We already went through this dicussion for sdcc libraries and the decision was GPL+LE. So please serch & replace GPL with GPL+LE in my previous posts ;-) Borut On 03/31/2011 12:58 AM, Alain Mouette wrote: > DANGER... DANGER... > I have been silently following this and then it truck me!!! > > Libraries and headers thar generate at least ONE byte cannot be GPL!!! > Some people use compilers to create comercial products, and it that byte > goes along it becomes "derived work" and cannot be protected... > > Please use BSD/MIT (or MPL if you don't want it to be completly free) > > For the compiler GPL is ok because no byte of the compiler executable > gets *into* the compiled code !!! > > THANKS > Alain > > Em 30-03-2011 18:37, Kustaa Nyholm escreveu: >> On 3/31/11 00:05, "Borut Ražem"<bor...@gm...> wrote: >>> If this is so, there is no need to regenerate the files: we can just put >>> our copyright on the existing ones and declare that they are GPLed... >> >> >> Nothing can be copyrighted: copyright comes into being by the creative >> process >> of creating original stuff. It either comes out of that process or not. >> >> Putting any number of copyright texts will not change the status of the >> file and if the file does not have a copyright, stamping it GPL will >> not work either as the only moral / enforceable hold GPL has over >> the source file is copyright. >> >> Of course you can put anything onto a non copyrighted text but the it >> has no legal power, just deterring power. Perhaps someone might claim >> damages if they feel that the misleading information has caused them harm. >> >> I would be in in favor of generating the files by any means from the >> info on the data sheets and stating that they are in the public domain. >> >> br Kusti >> >> >>> On 03/30/2011 08:31 PM, Weston Schmidt wrote: >>>> "Facts are not copyrightable, but a collection of facts in a certain >>>> order, etc. could be, not the facts themselves but their arrangement >>>> in the whole." >> Could be, but I don't think there is any artistic merit in the order >> they are presented or the source code formatting, unless very special. >> Heck, run the through a pretty printer and they format is totally machine >> generated with no originality. >> >> >>>> So my interpretation is that by extracting the facts, breaking the >>>> presentation into a different arrangement (xml file, arbitrary >>>> ordering, etc.) constitutes a new work that can be copyrighted >>>> separately (the facts in my documents are still not copyright-able, so >>>> someone else could do exactly the same thing with my work) >> Yes I think we can do that and might be slightly more safe than just >> copying the stuff from Microchip .inc files (or from where ever they >> currently come) but No, they are still not copyrighted. >> >> br Kusti |
From: Sébastien L. <sq...@gm...> - 2011-03-31 07:39:20
|
at this point of the discussion, what about asking microchip about what they think? Sebastien |
From: Alain M. <al...@po...> - 2011-03-31 14:35:04
|
Ok, but what is LE? Google could not help, nor even SDCC's site... Could you send a link (or the licence)? Thanks, Alain Em 31-03-2011 02:07, Borut Razem escreveu: > We already went through this dicussion for sdcc libraries and the > decision was GPL+LE. So please serch& replace GPL with GPL+LE in my > previous posts ;-) > > Borut > > > On 03/31/2011 12:58 AM, Alain Mouette wrote: >> DANGER... DANGER... >> I have been silently following this and then it truck me!!! >> >> Libraries and headers thar generate at least ONE byte cannot be GPL!!! >> Some people use compilers to create comercial products, and it that byte >> goes along it becomes "derived work" and cannot be protected... >> >> Please use BSD/MIT (or MPL if you don't want it to be completly free) >> >> For the compiler GPL is ok because no byte of the compiler executable >> gets *into* the compiled code !!! >> >> THANKS >> Alain >> >> Em 30-03-2011 18:37, Kustaa Nyholm escreveu: >>> On 3/31/11 00:05, "Borut Ražem"<bor...@gm...> wrote: >>>> If this is so, there is no need to regenerate the files: we can just put >>>> our copyright on the existing ones and declare that they are GPLed... >>> >>> >>> Nothing can be copyrighted: copyright comes into being by the creative >>> process >>> of creating original stuff. It either comes out of that process or not. >>> >>> Putting any number of copyright texts will not change the status of the >>> file and if the file does not have a copyright, stamping it GPL will >>> not work either as the only moral / enforceable hold GPL has over >>> the source file is copyright. >>> >>> Of course you can put anything onto a non copyrighted text but the it >>> has no legal power, just deterring power. Perhaps someone might claim >>> damages if they feel that the misleading information has caused them harm. >>> >>> I would be in in favor of generating the files by any means from the >>> info on the data sheets and stating that they are in the public domain. >>> >>> br Kusti >>> >>> >>>> On 03/30/2011 08:31 PM, Weston Schmidt wrote: >>>>> "Facts are not copyrightable, but a collection of facts in a certain >>>>> order, etc. could be, not the facts themselves but their arrangement >>>>> in the whole." >>> Could be, but I don't think there is any artistic merit in the order >>> they are presented or the source code formatting, unless very special. >>> Heck, run the through a pretty printer and they format is totally machine >>> generated with no originality. >>> >>> >>>>> So my interpretation is that by extracting the facts, breaking the >>>>> presentation into a different arrangement (xml file, arbitrary >>>>> ordering, etc.) constitutes a new work that can be copyrighted >>>>> separately (the facts in my documents are still not copyright-able, so >>>>> someone else could do exactly the same thing with my work) >>> Yes I think we can do that and might be slightly more safe than just >>> copying the stuff from Microchip .inc files (or from where ever they >>> currently come) but No, they are still not copyrighted. >>> >>> br Kusti > > > ------------------------------------------------------------------------------ > Create and publish websites with WebMatrix > Use the most popular FREE web apps or write code yourself; > WebMatrix provides all the features you need to develop and > publish your website. http://p.sf.net/sfu/ms-webmatrix-sf > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > |
From: Raphael W. <rap...@if...> - 2011-03-31 15:09:10
|
On Thu, 31 Mar 2011 16:34:55 +0200, Alain Mouette <al...@po...> wrote: > Ok, but what is LE? Google could not help, nor even SDCC's site... > > Could you send a link (or the licence)? LE == Library Exception http://www.gnu.org/licenses/gcc-exception.html -- Dipl.-Medieninf. Raphael Wimmer Wiss. Mitarbeiter / Research Assistant Doktorand / PhD student Ludwig-Maximilians-Universität München E-Mail: rap...@if... LFE Medieninformatik Skype: real_raphman Amalienstr. 17 / Raum 206 WWW: http://www.medien.ifi.lmu.de 80333 München Tel: +49 (89) 2180-4659 Germany Fax: +49 (89) 2180-99-4659 |
From: Sébastien L. <sq...@gm...> - 2011-03-31 14:45:53
|
Please RTFM @ http://sourceforge.net/apps/trac/sdcc/wiki/Library%20License%20Selection ;-) Cheers Sebastien 2011/3/31 Alain Mouette <al...@po...> > Ok, but what is LE? Google could not help, nor even SDCC's site... > > Could you send a link (or the licence)? > > Thanks, > Alain > > Em 31-03-2011 02:07, Borut Razem escreveu: > > We already went through this dicussion for sdcc libraries and the > > decision was GPL+LE. So please serch& replace GPL with GPL+LE in my > > previous posts ;-) > > > > Borut > > > > > > On 03/31/2011 12:58 AM, Alain Mouette wrote: > >> DANGER... DANGER... > >> I have been silently following this and then it truck me!!! > >> > >> Libraries and headers thar generate at least ONE byte cannot be GPL!!! > >> Some people use compilers to create comercial products, and it that byte > >> goes along it becomes "derived work" and cannot be protected... > >> > >> Please use BSD/MIT (or MPL if you don't want it to be completly free) > >> > >> For the compiler GPL is ok because no byte of the compiler executable > >> gets *into* the compiled code !!! > >> > >> THANKS > >> Alain > >> > >> Em 30-03-2011 18:37, Kustaa Nyholm escreveu: > >>> On 3/31/11 00:05, "Borut Ražem"<bor...@gm...> wrote: > >>>> If this is so, there is no need to regenerate the files: we can just > put > >>>> our copyright on the existing ones and declare that they are GPLed... > >>> > >>> > >>> Nothing can be copyrighted: copyright comes into being by the creative > >>> process > >>> of creating original stuff. It either comes out of that process or not. > >>> > >>> Putting any number of copyright texts will not change the status of the > >>> file and if the file does not have a copyright, stamping it GPL will > >>> not work either as the only moral / enforceable hold GPL has over > >>> the source file is copyright. > >>> > >>> Of course you can put anything onto a non copyrighted text but the it > >>> has no legal power, just deterring power. Perhaps someone might claim > >>> damages if they feel that the misleading information has caused them > harm. > >>> > >>> I would be in in favor of generating the files by any means from the > >>> info on the data sheets and stating that they are in the public domain. > >>> > >>> br Kusti > >>> > >>> > >>>> On 03/30/2011 08:31 PM, Weston Schmidt wrote: > >>>>> "Facts are not copyrightable, but a collection of facts in a certain > >>>>> order, etc. could be, not the facts themselves but their arrangement > >>>>> in the whole." > >>> Could be, but I don't think there is any artistic merit in the order > >>> they are presented or the source code formatting, unless very special. > >>> Heck, run the through a pretty printer and they format is totally > machine > >>> generated with no originality. > >>> > >>> > >>>>> So my interpretation is that by extracting the facts, breaking the > >>>>> presentation into a different arrangement (xml file, arbitrary > >>>>> ordering, etc.) constitutes a new work that can be copyrighted > >>>>> separately (the facts in my documents are still not copyright-able, > so > >>>>> someone else could do exactly the same thing with my work) > >>> Yes I think we can do that and might be slightly more safe than just > >>> copying the stuff from Microchip .inc files (or from where ever they > >>> currently come) but No, they are still not copyrighted. > >>> > >>> br Kusti > > > > > > > ------------------------------------------------------------------------------ > > Create and publish websites with WebMatrix > > Use the most popular FREE web apps or write code yourself; > > WebMatrix provides all the features you need to develop and > > publish your website. http://p.sf.net/sfu/ms-webmatrix-sf > > _______________________________________________ > > Sdcc-user mailing list > > Sdc...@li... > > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > > > > > ------------------------------------------------------------------------------ > Create and publish websites with WebMatrix > Use the most popular FREE web apps or write code yourself; > WebMatrix provides all the features you need to develop and > publish your website. http://p.sf.net/sfu/ms-webmatrix-sf > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |