www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - template hiding suggestion !

reply Walter Bright <newshound1 digitalmars.com> writes:
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
next sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
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
prev sibling next sibling parent "dominik" <asd asd.com> writes:
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
prev sibling next sibling parent Yigal Chripun <yigal100 gmail.com> writes:
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.


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.

--Yigal
Apr 20 2008
prev sibling parent reply e-t172 <e-t172 akegroup.org> writes:
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
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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
parent reply BCS <ao pathlink.com> writes:
Reply to Walter,


 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.
 


a.k.a. "sooner or later" ???
Apr 20 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:

 a.k.a. "sooner or later" ???


Eventually I hope to do it.
Apr 20 2008
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Walter,


 BCS wrote:
 

 a.k.a. "sooner or later" ???
 


 Eventually I hope to do it.
 


<G size=huge>
Apr 20 2008
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"BCS" <ao pathlink.com> wrote in message 
news:55391cb32bf578ca711ae8b7876a news.digitalmars.com...

 Reply to Walter,


 BCS wrote:


 a.k.a. "sooner or later" ???


 Eventually I hope to do it.


 <G size=huge>


That would never validate!

<g size = "huge" />
Apr 20 2008
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:

 BCS wrote:

 a.k.a. "sooner or later" ???


 
 Eventually I hope to do it.


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.

--bb
Apr 20 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
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
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Robert Fraser wrote:

 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.


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.

--bb
Apr 20 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter Bright 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. 


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 bootstrap
Apr 21 2008
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Robert Fraser 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.


Fortunately you don't have to build GDC yourself, in order to use it.

--anders
Apr 21 2008
prev sibling parent "Hans W. Uhlig" <huhlig gmail.com> writes:
Walter Bright wrote:

 BCS wrote:

 a.k.a. "sooner or later" ???


 
 Eventually I hope to do it.


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.
Apr 20 2008