[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[amibroker] Re: Why are there so few?



PureBytes Links

Trading Reference Links

> If someone really wants to protect their intellectual property and 
> has deemed it worth protecting, they should convert their ideas 
>into 
> dlls or have them converted by someone. Dll fullfills the needs of 
> protection totally and is far more secured.

IMO commercial add-ons are a good thing because they offer me choices.

If I did run a commercial trading site I would consider that DLL's 
and pay per view, behind walls, would offer as much 
protection as can be expected in this day and age although I wouldn't 
expect it to be 100% secure.

Commercial extras could add a lot of value to AB.

IMO the real reason there isn't a lot around is because the market is 
too small ... only 8000 AB users .... most of us self motivated and 
hard to impress ... some of our budget already dedicated to AB and 
data .... there is only a handful who have the money and inclination 
to buy add-ons.

There aren't many commercial DLL's around because it doesn't pay much.

There aren't a lot of free ones around because we are all too 
busy ... community effort takes an incredible amount of time, as I 
found out at the UKB.

brian_z 



--- In amibroker@xxxxxxxxxxxxxxx, "Paul Ho" <paul.tsho@xxx> wrote:
>
> AFL protection - Protectionism vs Free distribution
> 
> We have seen many examples. Linix is a freely distributed 
> OS, and much of its growth is attributed free distribution of 
source 
> code. Linix's core developers didn't have the budget or man power 
to 
> grow its market without tapping into the overall community for 
> free contributions. Microsoft on the other hand, strongly believes 
> in its inhouse developed edge and tried to guard it as much as 
> possible, by keeping it as secret as the laws allow it. 
> 
> Open source is always the fastest way to spread the use of a 
> software product. Take a look in the AFL library, I would argue 
that 
> most afls posted are small, rudimentary and often specific their 
its 
> purposes, their utility relies on the fact that they can be easily 
> customised, and the open source serves as documentation on what 
> needs to be done. They are completely open to the adopters 
> imagination. When AFL becomes encrypted, or protected, they 
> become canned, and has to be used as it is. For any canned product 
> to be out in the public, regardless whether it is free of charge or 
> not, it has to cater to all or most of its users need, and not just 
> the writers. There is a huge effort on the writers part to analyse 
> the needs of the type of users that he wants to target. They called 
> that system analysis in software development. Then he has to 
develop 
> it, and then carry out all sort of tests, more than ever. Because 
> now protected, no users can contributed to any debugging whatever. 
> After all that is done, the writer has to thoroughly document with 
> user guide, reference guide, etc. Because no one will know how to 
> use it otherwise. With the exception of the few who are selling 
> their ware, most will not want to go through that trouble and shy 
> away from contributing. By the way, any encrypted afl will be 
> cracked within day, if not hours. We have encrypted vbscript and 
> jscript today, they are neither secured or popular. 
> 
> If answering a few question for curious users on how to modify 
> author's code is tieing up the author's time. Then canning AFL is a 
> sure way to killing all his time!
> 
> If someone really wants to protect their intellectual property and 
> has deemed it worth protecting, they should convert their ideas 
into 
> dlls or have them converted by someone. Dll fullfills the needs of 
> protection totally and is far more secured. without forcing a new 
> barrier onto the masses.
> 
> In my view, afl protectionsim is aiming at guarding the fortune of 
> the few, because there will be very few who will wants to use it. 
> the majority will be just happy to share the ideas, no matter how 
> small, freely and easily, or not at all.
> 
> If AFl protectionism becomes reality, Tim will soon be asking Why 
> are there so few AFLs. LOL! In another twisted way, I have answered 
> once more why there are so few dll.
> 
> --- In amibroker@xxxxxxxxxxxxxxx, "bruce1r" <brucer@> wrote:
> >
> > Progster -
> > 
> > Your response addressed DLL's and made good points about 
> intellectual
> > property, but IMO you might have missed a point and been a little 
> off
> > the larger target.
> > 
> > I think that the larger question is protection of AFL's.  This is
> > something that Howard Bandy and I discussed with Tomasz at the
> > conference in Feb.  I'm going to delve into it a little here 
> because I
> > think that it is time to air it again, then I'll offer a quick 
> point
> > about DLL's.
> > 
> > Many have AFL's (trading systems, AND utilities) that they would
> > release if they could protect them.  There are two reasons for
> > protecting the source - one obvious and one not so obvious -
> > 
> > 1. To charge for the code and for the intellectual property.  The
> > market will decide if the price is reasonable or not.
> > 
> > 2. To protect the source.  Many times others will mod the source 
> and
> > then tie up author's time with questions about how the original
> > software worked OR why the modified software doesn't work.  This 
> is a
> > real problem.  I have released a fair amount of AB code in another
> > venue and can relate this problem firsthand.
> > 
> > My impression is that Tomasz is reluctant to incorporate AFL
> > protection for a couple of reasons.  I won't try to speak for 
him, 
> but
> > I think that one of his reasons is that he feels that protected 
> code
> > that possibly had a charge would impede the sharing of code.  To 
> that
> > all that I can ask is - how much is not now being released because
> > this facility doesn't exist.  Howard and I and others have tried 
to
> > emphasize this.
> > 
> > Now to DLL's.  Certainly code can be placed in a DLL to hide it.  
> It
> > is also fairly easy to protect it.  It is just a pain and a
> > productivity hit to convert AFL to a DLL just to protect it.  And 
> in
> > the end, any protection can be broken by a determined hacker. 
> > Protection tends to fall into two categories -
> > 
> > 1. Wrappers for EXE's and DLL's that implement keyed protection 
for
> > existing binaries and require no changes.  The protection may or 
> may
> > not be machine unique. For example, ASPROTECT
> > 
> > 2. Embedded protection calls that require changes to the app.  
> Several
> > libraries available - some open such as ACTIVELOCK
> > 
> > Anyway, I'd be interested in others thoughts on this issue.
> > 
> > -- Bruce R
> > 
> > --- In amibroker@xxxxxxxxxxxxxxx, "progster01" <progster@> wrote:
> > >
> > > The discussion so far on "Why so few?" DLLs seems pretty much
> > > on-target to me.
> > > 
> > > I would add:
> > > 
> > > Ability to program a non-trivial DLL is a marketable skill that 
> takes
> > > a long time to develop.
> > > 
> > > There are certainly a number of fine examples of free 
> contribution to
> > > the AB community in the DLL area (e.g. RMath, for one).  
> > > 
> > > One can only feel gratitude and appreciation for such "above and
> > > beyond" contributions.
> > > 
> > > However, capable DLL authors have the same 24/7/365 limitations 
> as
> > > everyone else, and must confront a simple choice about 
how/where 
> to
> > > spend their time and effort: getting paid, or not getting paid.
> > > 
> > > Since DLL writing is (almost) platform agnostic, DLL writers in 
> the
> > > trading area will have a tendency to code for platforms that 
> provide
> > > built-in support for locking a DLL to a customer or software ID.
> > > 
> > > I would predict that such "commercializing" integration 
features 
> would
> > > result in a distinct increase in the number of commercial DLLs
> > > available for AB.
> > >
> >
>



------------------------------------

**** IMPORTANT ****
This group is for the discussion between users only.
This is *NOT* technical support channel.

*********************
TO GET TECHNICAL SUPPORT from AmiBroker please send an e-mail directly to 
SUPPORT {at} amibroker.com
*********************

For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/

For other support material please check also:
http://www.amibroker.com/support.html

*********************************
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/amibroker/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/amibroker/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:amibroker-digest@xxxxxxxxxxxxxxx 
    mailto:amibroker-fullfeatured@xxxxxxxxxxxxxxx

<*> To unsubscribe from this group, send an email to:
    amibroker-unsubscribe@xxxxxxxxxxxxxxx

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/