Steve, if this is an internal package that never gets distributed, then no - it's your package and you do not need to release it.

If, however, you distribute it - sell it or give it - you must pass on the source code and give the receiver all the rights that you have over the code.

talli

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

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

I'm just summarizing the thoughts of the community as I understood them the last time we had a lengthy discussion about this.  And in that discussion there was recognition that  people might build proprietary packages on top of the toolkit for distribution.

This is a big gray area - it's not clear, for instance, that the LGPL is really necessary for libraries, GNU came up with it in order to make it clear they don't oppose commercial products linked to the GNU C library, as I understand it.

But I don't think you'd find anyone here suggesting you need to disclose your proprietary datamodel etc just because you're using OACS utilities and user verification.

Back in the old days, aD sure wrote a whole heck of lot of custom code for all of its many clients. Often that code was entirely propietary, owned by the clients who paid for it. Clearly the lawyers for both aD and aD's customers thought this was just fine. However, this was usually the typical "GPL ACS, plus custom code for our custom site which we don't distribute to anybody" case.

Now, there may have been some, but I personally don't recall any aD client who wanted to re-distribute their custom code. My guess is what Don says above would have been aD's (and aD's lawyer's) position as well, but I don't know. Maybe the other OpenACS consultancies have had a customer with this situation? It does sound like something a nervous-about-open-source IT manager would ask...

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. :)

- If the GPL is viral with regards to OpenACS package, and the "you know what" KM system was build on top of OpenACS, why has it been taken off this site ?

- Can we come to an agreement that allows packages that make use of OpenACS core (and it would be up to the community to define what makes it up), use a different license ?

I had to deal with the "custom packages" issue building custom system on top of ACS working for  http://www.competitiveness.com/ . We checked with some lawyers in Barcelona, Spain and Boston, US, and the key legal question seems to be the exact definition of "derived work".

The GPL says: "You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof [...]":
=> If you don't "distribute", you can do whatever you like.
=> A module that you have written from scratch does not "contain" GPLed code.
=> "Derived from" was interpreted by our lawyers as "other strange ways to include GPLed source" to prohibit for example the use of decompiled binary code etc.

So we have built several customer systems without worrying about the licence question. I would be happy to get challenged on this...

Additionally, please keep in mind that the GPL has not been tested in court yet, neither in the US nor in Europe. We all may get very surprised if SCO/Microsoft manages to succeed with their fud fight against Linux.
Worse: A recent analysis in Germany (http://www.vsi.de/inhalte/aktuell/studie_final.pdf) shows that the GPL is probably not enforceable under German law. Spanish law is even less restrictive, resulting for example in huge problems for the RIAA to close MP3 servers here...
So today it is highly unlikely that you have to suffer any consequences from violating the GPL, other than a bad "karma" in certain Open-Source communities...

Bests,
Frank

fraber@fraber.de, http://www.fraber.de/

Copyleft is protected by the established laws of copyright as copyleft is nothing more than copyright flipped on itself ("i transfer my copyright to everyone with the only requirement that everyone transfer their copyright to everyone else when distributing."). Anyone trying to disprove the GPL in a court of law would have to effectively disprove copyright. That would effectively undermine their own argument.

Check out Eben Moglen's work for a more complete discussion.

I don't know about Germany. If, as Malte says, that GPL3 will address this, I hope we will move to that when it finally comes out.

talli

I finally found the articles from Lawrence Rosen (general counsel for the Open Source Initiative) at SitePoint and LinuxJournal about "derivative works":
- http://www.sitepoint.com/print/public-license-explained
- http://www.linuxjournal.com/article/6366

Here is what I've learned:
- There _is_ a difference between static and dynamic linking. This is in line with our consultations mentioned before, but here it is explained in detail.
- Static linking (as in 'C') seems to imply the application of the "GPL reciprocity" and requires the linking code to be GPLed.
- Dynamic linking "unfortunately cannot force the GPL upon the derrivative work" as Stallmann himself has put it.
- The main criteria for dynamic linking is that the linking code could (in theory) also work with a different (proprietery) "library" (the OpenACS system). Static linking implies the generation of a combined executable file ('C' style a.out linking). According to this definition, OpenACS modules use "dynamic linking" (there is no joined executable, there are APIs that are designed for being called and these APIs could be reimplemented by a different system).
- There seem to be a certain distinction on how software is distributed. As mentioned before in this thread, including everything in a single TAR would indicate more "combined works", while separately distributable modules indicate independance.
- There seems to be a difference (as of 2003) between the "opinion" of the FSF and what it could legally enforce (atleast in the US). That would explain some confusion we had in earlier discussions.

The issues hasn't received a lot of attention in the last year, even though I believe it wasn't finally resolved...

Bests,
Frank

mailto:frank_dot_bergmann_at_project_dash_open_dot_com
http://www.project-open.com/