Forum OpenACS Q&A: Re: Packages and the GPL

Collapse
4: Re: Packages and the GPL (response to 1)
Posted by Bart Teeuwisse on 08/13/03 07:06 PM

Steve,

I find my self in a similar position. I my new job with Praesagus, we are developing a commercial product on top of (Open)ACS. Our approach is to feed all improvements to OpenACS back to the community thereby respecting the GPL license of OpenACS.

At the same time, all custom packages build on top of OpenACS are proprietary to Praesagus. Furthermore, I've made some changes to the request processor of OpenACS to allow it to run pre-compiled Tcl code. Code pre-compiled with the ActiveState's Tcl Dev Kit is no longer readable by humans and can be used to protect the interlectual property of proprietary Tcl code. ADP, XQL and SQL pages can not be compiled but at least the business logic embeded in the Tcl code is protected.

Pre-compiled Tcl files have extension .tbc. These files could be renamed to .tcl files again but for manageability of product releases I have modified the request processor of OpenACS so that it handles .tbc files in addition to regular .tcl files.

AOLserver 4 is required to run pre-compiled code in OpenACS because each pre-compiled .tbc file starts of with:

if {[catch {package require tbcload 1.4} err] == 1} {
    error "The TclPro ByteCode Loader is not available or does not support the correct version"
}

I can commit these changes to the OpenACS CVS if the community supports proprietary development on top of OpenACS.

/Bart

Collapse
5: Re: Packages and the GPL (response to 4)
Posted by Steve Manning on 08/13/03 09:39 PM
Bart

I am very keen to promote the use of OpenACS within the company. We are a retail solutions provider with our core products being in J2EE. However, the 'powers that be' are disillusioned with the time it takes to develop a J2EE solution. I have proposed OACS as an alternative for the web based reporting and maintenance apps that we develop and this upcoming project is being seen as an opportunity to show what OACS can do.

As you say, we would ensure that any work on OpenACS or any work on packages released under the GPL would be made available to the community, but there are times when a specialist package developed to work with our Java based EPOS solution would need to remain proprietry. This approach would allow the OpenACS community to benefit from an increased pool of commercial developers which in itself is not a bad thing.

I don't wish to offend anyone. I am grateful for the huge contibutions made under the GPL and on a personal basis I will release my work to the community (if I ever manage to produce anything the community wants) but I feel that adoption by some commercial organisations would be restricted if they cannot produce a mix of proprietry and  GPL'd code.

By the way using TCl Dev Kit is an intersting solution to IP protection.

    Steve

Collapse
11: Re: Packages and the GPL (response to 4)
Posted by Andrew Piskorski on 08/16/03 01:26 PM
Bart, I'd personally always always always want the source available (even if under a non-open license) to any OpenACS package that's critical to my business operations.

But, that's neither here nor there: Being able to load byte code compiled Tcl files sounds like it could be an important performance enhancement for some people.

Collapse
12: Praesagus and CMP (response to 4)
Posted by Andrew Piskorski on 08/16/03 01:54 PM
Bart, btw, CMP using the OpenACS toolkit, eh? Sounds cool.

Back when I was a photolithography Process Engineer, the general feeling seemed to be that CMP was mostly black magic, hard to control, not really understood - so don't let yourself get transferred to the CMP group. Too bad all the newer CMOS processes (.20 micron and less, I think) seemed to really need CMP, even back in 1999. :)

So I can see how there could be a real market for software to help with CMP manufacturability. :)