Jump to content


Photo
- - - - -

Protecting Code


8 replies to this topic

#1 andykay

andykay

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 204 posts
  • Gender:Male
  • Location:Cyberspace...looking for work

Posted 07 April 2009 - 03:04 AM

Native export allows you to export & import RUN TIME only versions of functionality that prohibits viewing function code...This has always worked as it should from v1.0.

Glovia, uses SL, which does not allow you to have a RT Only version of functionality where the code is not visible.

My company is going to be GIVING Glovia code (w00t) that I developed both at this job, but also code that I brought with me to my current job :mad: . The code that I developed after starting, I understand they can do with what they want, but how do I protect the core functionality I developed outside this job, and at the same time allow SL genning of other functions?

I've tried to Export in Native, removing the SL code, then Importing the RTO version back in Native. This only worked halfway in that functionality that has already been genned still worked. BUT, if I regen the functions in SL where we do our coding, since the Native code is now not in SL I get Gen Errors. I've tried all possible configurations of SL4U #8, but to no avail. I do not wish to gen all the functions that use my code in Native as, as poor as SL is, it's still better than Native.

Any ideas?


AK

Edited by andykay, 07 April 2009 - 03:05 AM.

THE LIGHT AT THE END OF THE TUNNEL IS THE HEADLAMP OF THE TRAIN THAT'S ABOUT TO HIT YOU!!!

#2 Richard Bassett

Richard Bassett

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 696 posts
  • Location:Rural France

Posted 07 April 2009 - 10:59 AM

I'm not absolutely clear what your 'problem' code is Andy, but, if you're talking about global logic and there is a requirement to regen functions referencing that global logic then the source code for the global logic has to be present - there is nothing you can do to 'fix' that, global logic is not 'independently compilable' in PROIV.

This is a longstanding problem of sorts - if global logic could be compiled independently there would probably be a bunch of add-on libraries available for PROIV from third parties because it might be commercially viable. However, as far as I know, this is not something at all likely to change.
Nothing's as simple as you think

#3 Chris Pepper

Chris Pepper

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 369 posts
  • Gender:Male
  • Location:United Kingdom

Posted 07 April 2009 - 01:50 PM

AFAIK the Superlayer bootstraps are entirely separate from the ProIV bootstraps. So you have Superlayer source which generates ProIV source which generates ProIV run-time.

A Function cannot exist at the Superlayer level in a "run-time form", because this is just a repository of source code.

#4 Chris Mackenzie

Chris Mackenzie

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 368 posts
  • Gender:Male
  • Location:Bristol, United Kingdom

Posted 11 April 2009 - 03:10 PM

as poor as SL is, it's still better than Native.

Any ideas?


Ideas? No, generally, I have no idea. But, in response to your comment: No, it isn't.

SL produces inefficient, unmaintainable code. Encourages bad programming practice and was always a bad idea.

jm2c.
The content and views expressed in this message are those
of the poster and do not represent those of any organisation.

#5 Glenn Meyers

Glenn Meyers

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 221 posts
  • Gender:Male
  • Location:St. Louis, MO, United States
  • Interests:I also raise African Gray Parrots and build hot rod automobiles.

Posted 15 April 2009 - 01:08 PM

If the client is just receiving the code, do your import/export from Native.
That will have all the functionality without giving away the source.

#6 DARREN

DARREN

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 395 posts
  • Gender:Male
  • Location:Florida,USA

Posted 15 April 2009 - 03:26 PM

if global logic could be compiled independently there would probably be a bunch of add-on libraries available for PROIV from third parties because it might be commercially viable. However, as far as I know, this is not something at all likely to change.


Richard,

I think that the functionality provided with server side objects in 6.2 now addresses this issue. Thus a PROIV function can reference an object which is independent of the PROIV code itself, much like an external subroutine used in the LINK command.
Things should be made as simple as possible, but not simpler

#7 Tony Waszkiewicz

Tony Waszkiewicz

    Expert

  • Members
  • PipPipPipPip
  • 174 posts
  • Gender:Male
  • Location:London, United Kingdom

Posted 17 April 2009 - 07:20 AM

"...My company is going to be GIVING Glovia code (w00t) that I developed both at this job, but also code that I brought with me to my current job :mad: . The code that I developed after starting, I understand they can do with what they want, but how do I protect the core functionality I developed outside this job..."

Andy,
Does your employer know that you are using code you "brought with you"? I doubt they would want to be reliant on a piece of code that they don't have the source and rights to.

#8 andykay

andykay

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 204 posts
  • Gender:Male
  • Location:Cyberspace...looking for work

Posted 17 April 2009 - 03:25 PM

I doubt they would want to be reliant on a piece of code that they don't have the source and rights to.


Tony,

You show me a ProIV programmer that says that they do not take with them the knowledge, ideas, and solutions learned from one job to another and I'll show you a wooden puppet with a VERY long nose. This is what makes one person more desireable than another when a company is considering 2 people for the same job...their knowledge base. If we/programmers did not take with us what we have learned from our previous experiences, then we'd all be newbies at the start of each job instead of someone who can hit the job running.

Technically, each site I implement the code at has the rights to the code, as the code has to be physically key stroked in at every job location I bring it to, because I don't make use prx/slx files to implement the functionality. For as I may leave empty handed when I leave one job for another...I never leave a job empty minded (w00t) ...Do you?


AK
THE LIGHT AT THE END OF THE TUNNEL IS THE HEADLAMP OF THE TRAIN THAT'S ABOUT TO HIT YOU!!!

#9 Glenn Meyers

Glenn Meyers

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 221 posts
  • Gender:Male
  • Location:St. Louis, MO, United States
  • Interests:I also raise African Gray Parrots and build hot rod automobiles.

Posted 17 April 2009 - 05:12 PM

The rights to ownersip of code is different in the US than in Europe.
Every state is different also.
In most states, if you do not sign a release any code you create is written by you and bleongs to you, not your employer.
This was the law in Illinios the last time I looked into it.
As it was explained to me by my lawyer, the law treats authorship as a copywrite. You develope it at your work, but unless there is a signed agreement the code goes with you to your next employer.
Youi allowing them to use the code maks it a gift, so that you cannot make them sotp using it when you leave.
Yopur bringing hte code into their environment without charge makes what your brought in a gift as well and it is possible you relinquished your right to have any say as to its disposition.
That was the law when I was running an independent company. I had to check because I was writing stuff for customers I planned to sell to others and I needed to make it clear to myself and to them who owned what.

Glenn



Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users