digitalmars.D - template hiding suggestion !
- Walter Bright (80/85) Apr 20 2008 yours truly, who actually believe that one should be able to write
- Unknown W. Brackets (19/118) Apr 20 2008 There are also a number of reasons why open source software can be more
- dominik (5/5) Apr 20 2008 I've heard a nice "gem" last week from a microsoft consultant: (somethin...
- Yigal Chripun (24/123) Apr 20 2008 I completely agree with every word.
- e-t172 (4/31) Apr 20 2008 I so completely agree. However I don't understand one thing: you're
- Walter Bright (2/5) Apr 20 2008 I have to resolve the licensing issues first.
- BCS (2/10) Apr 20 2008 a.k.a. "sooner or later" ???
- Walter Bright (2/3) Apr 20 2008 Eventually I hope to do it.
-
BCS
(2/8)
Apr 20 2008
- Jarrett Billingsley (4/12) Apr 20 2008 That would never validate!
- Bill Baxter (6/10) Apr 20 2008 That would be truly a huge boon to the D community if it were possible
- Robert Fraser (2/4) Apr 20 2008 You can already do that with GDC... but no one does.
- Bill Baxter (5/10) Apr 20 2008 Note the words "reference D compiler". :-)
- Walter Bright (4/6) Apr 20 2008 I eschew complex build processes. If it cannot be built with:
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (9/16) Apr 21 2008 The only question being: "which dialect of make" ? :-P
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (3/7) Apr 21 2008 Fortunately you don't have to build GDC yourself, in order to use it.
- Hans W. Uhlig (4/8) Apr 20 2008 What licensing is an issue, I would probobly say, release the code that
Edward Diener wrote:There are a few, obviously misguided and benighted souls such asyours truly, who actually believe that one should be able to write software and sell it on the market, and that to do so one has the actual right of not having to distribute the source code, which one created from the biblical sweat of one's brow ( or ache of one's fingers, or thought of one's mind ). I have slowly come to the realization that making the source code available is *not* incompatible with maintaining one's intellectual property rights. Making the source code available is not the same thing as making it free for any use. The only reason to hide your source from your customers is if you've got trade secrets in there (or if your license prevents it). Otherwise, the source code being available is good for business as it shows you aren't distributing malware, it serves as a great advertisement for the quality of your work, it shows you have confidence in your product, it protects against some disaster causing you to lose your backup copies (!), customers can often help you fix errors, etc. Sure, some people will pirate it. But if they make money off of doing so, they are wide open to a big lawsuit. A real company won't take the risk. If it's some hobbyist dinking around, well, so what? I can tell you I'm getting sick and tired of closed source apps. For example, I attempted to install a major software company's crapware app. While it might be a good product underneath, the dammed thing attempts to take over my machine, installing things that always run upon startup, always "phoning home" over the internet, sending gawd knows what back to the parent company, nagging me about "activating" and "registering" it. It acts like it's doing me a huge favor by allowing me to use it at all. I just don't want to deal with that anymore. Open source products tend to come with an entirely different attitude - much more customer focussed.Doing this in C++ while writing templates is impossible in currentimplementations because the 'export' keyword, which hardly anyone ever wanted to implement anyway, except for Daveed Vandevoorde, never promises that the separation between template declarations and template definitions would enable one only to distribute the template declaration without the template definitions. But it was always possible to conceive that the template definitions could be "compiled" down into some intermediate unreadable format which could become part of the binary distribution, ala shared libs, static libs, exes etc.But since no one in C++ ever thought it important enough to protectthe template source as an intellectual right which should not need to be distributed in easily readable form, no on in C++ ever decided it was important enough to standardize the idea of some intermediate "compilable" form by which template source could be distributed but remain unread by the end user.Would it be possible that Mr. Walter Bright is sympathetic to thenotion that template source should be "compilable" down into some sort of unreadable format which enables the D compiler to read it but not others to discover its source form ? I realize that the very source code which might enable D to do this would itself need to be protected from prying eyes so that the format of the "compilable" template source could not be easily reverse engineered. Before someone cries that any format can be reverse engineered with enough effort, I want merely to say that no doubt .lib and .obj files can be reverse engineered to a certain extent but at some highly difficult level few, if any, are going to bother. S I see no reason why template source code could not be "obfuscated" in a similar way. The reason that obj files are so effective at hiding the source is that they are the proverbial "hamburger" that cannot be easily turned back into a cow. This is not so for any conceivable precompiled template form. Since templates don't even have semantics before they are instantiated, the precompiled form must be in the form of the syntax. It must necessarily have more information in it than, say, Java .class files do. And Java .class files have proven to be easily decompilable back into reasonable source. All it takes is one motivated person to crack your precompiled template format, and then everyone can see all of them. This is true even if you encrypt it. Look at what happened to DVD encryption. So frankly, it's a pipe dream to be able to hide template bodies in this way.As a user of libraries largely based on templates, whether C++ or D,once I have faith in the quality of the library I feel I have no need to look at the source code in order to use it successfully and the actual template declarations should be enough, from the user's point of view, to interact with the library. Unfortunately in C++ and D this is not the case due to the way templates are currently implemented. But I think it could be the case if D pursued the line of thought that the end user of the template code, as opposed to the compiler itself, really has no need to interact with the template definition, as opposed to the template declaration, in order to use the template successfully. I understand your concern about this, as I have felt the same way in the past. But I believe that thinking is obsolete, and that the advantages of making the source code available outweigh the disadvantages.
Apr 20 2008
There are also a number of reasons why open source software can be more profitable than closed source. http://www.simplemachines.org/about/whyfree.php In any case, the points of black markets/priacy below are also very important. Countless times, I've had to educate clients on the wins and losses of "activation" systems (speaking of cost to them.) Usually they are unprofitable. Instead of coming at piracy with things like encryption, hashing, call-home checks, legislation, etc. (all of which can easily be broken, flawed, or avoided) - I choose to simply charge for what cannot be pirated. Service. If I'm the best at what I do, I'll have no trouble with profit. For this reason, more and more companies (especially in my industry) are starting to put their products out in open source, because it's simply more profitable for them. Don't live in a cave, don't sit and say you want to sell it, just look at the numbers and do what takes you into the land of profit. -[Unknown] Walter Bright wrote:Edward Diener wrote: > There are a few, obviously misguided and benighted souls such as yours truly, who actually believe that one should be able to write software and sell it on the market, and that to do so one has the actual right of not having to distribute the source code, which one created from the biblical sweat of one's brow ( or ache of one's fingers, or thought of one's mind ). I have slowly come to the realization that making the source code available is *not* incompatible with maintaining one's intellectual property rights. Making the source code available is not the same thing as making it free for any use. The only reason to hide your source from your customers is if you've got trade secrets in there (or if your license prevents it). Otherwise, the source code being available is good for business as it shows you aren't distributing malware, it serves as a great advertisement for the quality of your work, it shows you have confidence in your product, it protects against some disaster causing you to lose your backup copies (!), customers can often help you fix errors, etc. Sure, some people will pirate it. But if they make money off of doing so, they are wide open to a big lawsuit. A real company won't take the risk. If it's some hobbyist dinking around, well, so what? I can tell you I'm getting sick and tired of closed source apps. For example, I attempted to install a major software company's crapware app. While it might be a good product underneath, the dammed thing attempts to take over my machine, installing things that always run upon startup, always "phoning home" over the internet, sending gawd knows what back to the parent company, nagging me about "activating" and "registering" it. It acts like it's doing me a huge favor by allowing me to use it at all. I just don't want to deal with that anymore. Open source products tend to come with an entirely different attitude - much more customer focussed. > Doing this in C++ while writing templates is impossible in current implementations because the 'export' keyword, which hardly anyone ever wanted to implement anyway, except for Daveed Vandevoorde, never promises that the separation between template declarations and template definitions would enable one only to distribute the template declaration without the template definitions. But it was always possible to conceive that the template definitions could be "compiled" down into some intermediate unreadable format which could become part of the binary distribution, ala shared libs, static libs, exes etc. > > But since no one in C++ ever thought it important enough to protect the template source as an intellectual right which should not need to be distributed in easily readable form, no on in C++ ever decided it was important enough to standardize the idea of some intermediate "compilable" form by which template source could be distributed but remain unread by the end user. > > Would it be possible that Mr. Walter Bright is sympathetic to the notion that template source should be "compilable" down into some sort of unreadable format which enables the D compiler to read it but not others to discover its source form ? I realize that the very source code which might enable D to do this would itself need to be protected from prying eyes so that the format of the "compilable" template source could not be easily reverse engineered. Before someone cries that any format can be reverse engineered with enough effort, I want merely to say that no doubt .lib and .obj files can be reverse engineered to a certain extent but at some highly difficult level few, if any, are going to bother. S I see no reason why template source code could not be "obfuscated" in a similar way. The reason that obj files are so effective at hiding the source is that they are the proverbial "hamburger" that cannot be easily turned back into a cow. This is not so for any conceivable precompiled template form. Since templates don't even have semantics before they are instantiated, the precompiled form must be in the form of the syntax. It must necessarily have more information in it than, say, Java .class files do. And Java .class files have proven to be easily decompilable back into reasonable source. All it takes is one motivated person to crack your precompiled template format, and then everyone can see all of them. This is true even if you encrypt it. Look at what happened to DVD encryption. So frankly, it's a pipe dream to be able to hide template bodies in this way. > As a user of libraries largely based on templates, whether C++ or D, once I have faith in the quality of the library I feel I have no need to look at the source code in order to use it successfully and the actual template declarations should be enough, from the user's point of view, to interact with the library. Unfortunately in C++ and D this is not the case due to the way templates are currently implemented. But I think it could be the case if D pursued the line of thought that the end user of the template code, as opposed to the compiler itself, really has no need to interact with the template definition, as opposed to the template declaration, in order to use the template successfully. I understand your concern about this, as I have felt the same way in the past. But I believe that thinking is obsolete, and that the advantages of making the source code available outweigh the disadvantages.
Apr 20 2008
I've heard a nice "gem" last week from a microsoft consultant: (something like) "I always use closed-source payed for applications, because there is no such thing as free lunch". I pointed out to him then that Red Hat workstations that we have are more expensive (support wise) than microsoft OS workstations we have, he couldn't explain the paradox.
Apr 20 2008
Walter Bright wrote:Edward Diener wrote:I completely agree with every word. I'd just like to add that there are many people that even though they bought a legitimate copy of a piece of software, they install a pirated copy instead. this way they did pay the company for the product so they have a clean conscience but they don't get all the headaches of registration/activation and calling the company asking for permission to reinstall the software each time you need to reformat your HDD.. The proper way to protect your copy rights (There is no such legal term as intellectual property. that's an oxymoron created by the RIAA folks and company to spread FUD) is through the legal system just like Walter said. any other means are ineffective, probably illegal and plain stupid as it drives away customers (1st rule of the market: "the customer is alway right" _not_ "the customer is a thief and a liar that should be sued and placed in prison for the rest of his natural life") since any sort of protection you try to put on your code is easily reversed this is time better spent elsewhere. this is illegal since the law clearly puts time limits on the copyright and if I can't read your code (or listen to your music, or ...) after the copyright has expired than you have put illegal restrictions on what is otherwise code in public domain. Even MS provides the source code of its .net platform to their clients. that is simply common sense. --YigalThere are a few, obviously misguided and benighted souls such asyours truly, who actually believe that one should be able to write software and sell it on the market, and that to do so one has the actual right of not having to distribute the source code, which one created from the biblical sweat of one's brow ( or ache of one's fingers, or thought of one's mind ). I have slowly come to the realization that making the source code available is *not* incompatible with maintaining one's intellectual property rights. Making the source code available is not the same thing as making it free for any use. The only reason to hide your source from your customers is if you've got trade secrets in there (or if your license prevents it). Otherwise, the source code being available is good for business as it shows you aren't distributing malware, it serves as a great advertisement for the quality of your work, it shows you have confidence in your product, it protects against some disaster causing you to lose your backup copies (!), customers can often help you fix errors, etc. Sure, some people will pirate it. But if they make money off of doing so, they are wide open to a big lawsuit. A real company won't take the risk. If it's some hobbyist dinking around, well, so what? I can tell you I'm getting sick and tired of closed source apps. For example, I attempted to install a major software company's crapware app. While it might be a good product underneath, the dammed thing attempts to take over my machine, installing things that always run upon startup, always "phoning home" over the internet, sending gawd knows what back to the parent company, nagging me about "activating" and "registering" it. It acts like it's doing me a huge favor by allowing me to use it at all. I just don't want to deal with that anymore. Open source products tend to come with an entirely different attitude - much more customer focussed.Doing this in C++ while writing templates is impossible in currentimplementations because the 'export' keyword, which hardly anyone ever wanted to implement anyway, except for Daveed Vandevoorde, never promises that the separation between template declarations and template definitions would enable one only to distribute the template declaration without the template definitions. But it was always possible to conceive that the template definitions could be "compiled" down into some intermediate unreadable format which could become part of the binary distribution, ala shared libs, static libs, exes etc.But since no one in C++ ever thought it important enough to protectthe template source as an intellectual right which should not need to be distributed in easily readable form, no on in C++ ever decided it was important enough to standardize the idea of some intermediate "compilable" form by which template source could be distributed but remain unread by the end user.Would it be possible that Mr. Walter Bright is sympathetic to thenotion that template source should be "compilable" down into some sort of unreadable format which enables the D compiler to read it but not others to discover its source form ? I realize that the very source code which might enable D to do this would itself need to be protected from prying eyes so that the format of the "compilable" template source could not be easily reverse engineered. Before someone cries that any format can be reverse engineered with enough effort, I want merely to say that no doubt .lib and .obj files can be reverse engineered to a certain extent but at some highly difficult level few, if any, are going to bother. S I see no reason why template source code could not be "obfuscated" in a similar way. The reason that obj files are so effective at hiding the source is that they are the proverbial "hamburger" that cannot be easily turned back into a cow. This is not so for any conceivable precompiled template form. Since templates don't even have semantics before they are instantiated, the precompiled form must be in the form of the syntax. It must necessarily have more information in it than, say, Java .class files do. And Java .class files have proven to be easily decompilable back into reasonable source. All it takes is one motivated person to crack your precompiled template format, and then everyone can see all of them. This is true even if you encrypt it. Look at what happened to DVD encryption. So frankly, it's a pipe dream to be able to hide template bodies in this way.As a user of libraries largely based on templates, whether C++ or D,once I have faith in the quality of the library I feel I have no need to look at the source code in order to use it successfully and the actual template declarations should be enough, from the user's point of view, to interact with the library. Unfortunately in C++ and D this is not the case due to the way templates are currently implemented. But I think it could be the case if D pursued the line of thought that the end user of the template code, as opposed to the compiler itself, really has no need to interact with the template definition, as opposed to the template declaration, in order to use the template successfully. I understand your concern about this, as I have felt the same way in the past. But I believe that thinking is obsolete, and that the advantages of making the source code available outweigh the disadvantages.
Apr 20 2008
Walter Bright a écrit :I have slowly come to the realization that making the source code available is *not* incompatible with maintaining one's intellectual property rights. Making the source code available is not the same thing as making it free for any use. The only reason to hide your source from your customers is if you've got trade secrets in there (or if your license prevents it). Otherwise, the source code being available is good for business as it shows you aren't distributing malware, it serves as a great advertisement for the quality of your work, it shows you have confidence in your product, it protects against some disaster causing you to lose your backup copies (!), customers can often help you fix errors, etc. Sure, some people will pirate it. But if they make money off of doing so, they are wide open to a big lawsuit. A real company won't take the risk. If it's some hobbyist dinking around, well, so what? I can tell you I'm getting sick and tired of closed source apps. For example, I attempted to install a major software company's crapware app. While it might be a good product underneath, the dammed thing attempts to take over my machine, installing things that always run upon startup, always "phoning home" over the internet, sending gawd knows what back to the parent company, nagging me about "activating" and "registering" it. It acts like it's doing me a huge favor by allowing me to use it at all. I just don't want to deal with that anymore. Open source products tend to come with an entirely different attitude - much more customer focussed.I so completely agree. However I don't understand one thing: you're saying open source is Good and closed source is Bad, and yet the DMD backend is still closed-source. Have I missed something ?
Apr 20 2008
e-t172 wrote:I so completely agree. However I don't understand one thing: you're saying open source is Good and closed source is Bad, and yet the DMD backend is still closed-source. Have I missed something ?I have to resolve the licensing issues first.
Apr 20 2008
Reply to Walter,e-t172 wrote:a.k.a. "sooner or later" ???I so completely agree. However I don't understand one thing: you're saying open source is Good and closed source is Bad, and yet the DMD backend is still closed-source. Have I missed something ?I have to resolve the licensing issues first.
Apr 20 2008
BCS wrote:a.k.a. "sooner or later" ???Eventually I hope to do it.
Apr 20 2008
Reply to Walter,BCS wrote:<G size=huge>a.k.a. "sooner or later" ???Eventually I hope to do it.
Apr 20 2008
"BCS" <ao pathlink.com> wrote in message news:55391cb32bf578ca711ae8b7876a news.digitalmars.com...Reply to Walter,That would never validate! <g size = "huge" />BCS wrote:<G size=huge>a.k.a. "sooner or later" ???Eventually I hope to do it.
Apr 20 2008
Walter Bright wrote:BCS wrote:That would be truly a huge boon to the D community if it were possible to run 'make' on the reference D compiler and get a working executable. If you cant get permission to release the back-end's source, at least try to get permission to redistribute it as a library. --bba.k.a. "sooner or later" ???Eventually I hope to do it.
Apr 20 2008
Bill Baxter wrote:That would be truly a huge boon to the D community if it were possible to run 'make' on the reference D compiler and get a working executable.You can already do that with GDC... but no one does.
Apr 20 2008
Robert Fraser wrote:Bill Baxter wrote:Note the words "reference D compiler". :-) And compiling GDC is far more involved than just running 'make'. The the process Walter uses to build DMD cannot possibly be as byzantine. --bbThat would be truly a huge boon to the D community if it were possible to run 'make' on the *reference D compiler* and get a working executable.You can already do that with GDC... but no one does.
Apr 20 2008
Bill Baxter wrote:And compiling GDC is far more involved than just running 'make'. The the process Walter uses to build DMD cannot possibly be as byzantine.I eschew complex build processes. If it cannot be built with: make I rewrite it.
Apr 20 2008
Walter Bright wrote:The only question being: "which dialect of make" ? :-P GCC uses autoconf/automake in order to be portable, which really just means there is an extra "configure" step before the "make" invocation. GDC's need to patch GCC is complex, but also automated. --anders 1. PREPARE: ./gcc/d/setup-gcc.sh && mkdir build 2. CONFIGURE: cd build && ../configure --enable-languages=d 3. BUILD: make bootstrapAnd compiling GDC is far more involved than just running 'make'. The the process Walter uses to build DMD cannot possibly be as byzantine.I eschew complex build processes. If it cannot be built with: make I rewrite it.
Apr 21 2008
Robert Fraser wrote:Fortunately you don't have to build GDC yourself, in order to use it. --andersThat would be truly a huge boon to the D community if it were possible to run 'make' on the reference D compiler and get a working executable.You can already do that with GDC... but no one does.
Apr 21 2008
Walter Bright wrote:BCS wrote:What licensing is an issue, I would probobly say, release the code that is yours and put in comments for what is removed. I bet you someone is willing to fill in the blanks.a.k.a. "sooner or later" ???Eventually I hope to do it.
Apr 20 2008