Forum OpenACS Q&A: Packages and the GPL

Request notifications

Collapse
Posted by Steve Manning on
Hi

I have been getting to grips with OACS at home and have even managed an install on the office intranet to provide some basic services. We now have a commercial project coming up which requires access through various means to a Postgres DB for historical sales analysis etc.

One of the required access methods is a web interface and although the db will not be part of OACS my boss has agreed that we can use OACS to provide the authentication, authorisation and to make use of the templates and other nifty features of OACS.

I'd like to create our bits and pieces as a package as this keeps everything neat. However, the question has arisen as to whether we are required to release our package under the GPL if it makes use of the features of the OACS framework but doesn't change them. In other words would this be viewed as a derived work?

I have searched the forums over the question of the GPL and there are plenty of threads. This thread (http://openacs.org/forums/message-view?message_id=25558) would seem to imply that the considered opinion is that packages do not have to be GPL'd but it is encouraged. I guess what I'm looking for is a decision from the OACS community as to the GPL cut-off point for package development (if there is one). It would be useful to have the official position in a FAQ or on the license page so that we all know where we stand.

By the way, the search for 'gpl' grenades at the bottom of the forth page :( although you can go back to the third then select 5 from the page list - just thougght you'd like to know.

TIA

    Steve

Collapse
2: Re: Packages and the GPL (response to 1)
Posted by Talli Somekh on
Assuming that you are writing this package on top of the OpenACS and is statically linked (that is it requires the OpenACS to run):

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

Collapse
3: Re: Packages and the GPL (response to 2)
Posted by Bart Teeuwisse on
Talli,

I would think one could license the new package differently than the GPL licensed OpenACS core. The new package doesn't alter the open source OpenACS code and as such is not obliged to make the code of the new package available. I guess this is a matter of semantics. Is the package an extension (and thus alteration) of open source code or is it a new piece of software that happens to require open source software?

/Bart

Collapse
4: Re: Packages and the GPL (response to 1)
Posted by Bart Teeuwisse on

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
6: Re: Packages and the GPL (response to 1)
Posted by Don Baccus on
In the past we've said the OpenACS core is much like the Linux kernel - you don't *link* with it and commercial products can be released on top of it as long as you don't modify and distribute changes to our code.

Or distribute our code as part of your package.

In other words, if you release a nice tarball of everything rolled together then you're distributing our code and would have to release your package under the GPL, too.

But if you're not distributing your package, or if you distribute the package by itself (requiring anyone to install OpenACS separately) then you're OK.

We encourage new packages - especially those of general interest - to be GPL'd for hopefully obvious reasons: we all benefit by being able to build on the work done by community members for clients or employers.

But we recognize that it's not always possible to release code under the GPL ...

Collapse
5: Re: Packages and the GPL (response to 4)
Posted by Steve Manning on
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
7: Re: Packages and the GPL (response to 6)
Posted by Steve Manning on
Don,

Thanks for that, your a saint. I'm probably being pedantic but when you say 'distribute our code as part of your package' you don't include calls to the OpenACS core like [ad_conn user_id] in this?

For most of our customers, we would do the installation. Presumably this is still ok provided the standard OACS install is performed then our package is installed on top.

Finally, I appreciate that this gpl question has been asked before, so if yours is the official view is there any chance of placing your statement somewhere prominent on openacs.org so thats its available for all to see.

    Steve

Collapse
8: Re: Packages and the GPL (response to 1)
Posted by Don Baccus on
I can't say that mine's the "official" view because we don't have an "official" structure, though we shall at some point.

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.

Collapse
9: Re: Packages and the GPL (response to 1)
Posted by Jun Yamog on
Hi,

I just try to use common sense.  I am not a legal expert.  But in my first hand example.  I worked with Bart and Praesagus.  The project required some wizard type of UI.  I needed to do heavy modification to the wizard procs.  Since the original wizard procs was part of OACS, it was common sense to give it back to the community.  Right even before I put it back, Brad had an earlier copy of the modified wizard.  Brad needed the new features and also Brad put in more features than what Praesagus needed.

Since it was returned back to the community, it made Brad's life easier (I hope).  Brad's new changes may also benefit Praesagus when Bart back ports them.

Anyway if you can release things in GPL, you will never know that someone out there may reuse and improve the code.  Also I think packages maybe licensed not in GPL if needed, well just common sense thinking (not sure legally).

BTW are we GPL or LGPL?  It says in the front page we are GPL.  Just to verify.

Collapse
10: Re: Packages and the GPL (response to 1)
Posted by Andrew Piskorski on
Steve, writing "[ad_conn user_id]" is your code. The fact that it happens to call the ad_conn proc, the implementation of which is part of OpenACS, is no different than the fact that Oracle running on Linux makes function calls to the Linux kernel.

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

Collapse
11: Re: Packages and the GPL (response to 4)
Posted by Andrew Piskorski on
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
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. :)

Collapse
13: Re: Packages and the GPL (response to 1)
Posted by Talli Somekh on
The thing is that OACS core is not licensed under the LGPL - it's GPL and the GPL is viral. As a result, i suppose the question is whether we have APIs that are abstracted enough to allow dynamically linked applications to sit on top of them.

Being familiar with the Praesagus system, I would say that they may be in the clear.

talli

Collapse
14: Re: Packages and the GPL (response to 1)
Posted by Malte Sussdorff on
Two things come into my mind here:

- 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 ?

Collapse
15: Re: Packages and the GPL (response to 14)
Posted by Jarkko Laine on
Malte,

I think the problem with SN was that it was one of the proprietary custom systems Andy mentioned, that were never supposed to be distributed.

Like Talli said, there's no problem keeping your OpenACS-based code closed source as long as you're keeping it to yourself. AFAIK there was some misconception which led to the ******** source being published in the first place.

Collapse
16: Re: Packages and the GPL (response to 1)
Posted by Frank Bergmann on
Hi,

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

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

Collapse
17: Re: Packages and the GPL (response to 16)
Posted by Malte Sussdorff on
I'm not so much concerned about the legal side of things. I had a lot of talks with people in Germany about the GPL and the study is an accurate display of the thinking in Germany. It will be very hard to enforce the GPL here. This is why there is already work for version 3 of the GPL to make the spirit of the GPL work in various countries.

What I'm interested in is to provide modules for use in a non commercial setting for free but charge a license for the commercial end-use. Look at the previous mysql license or the ideas behind ximian connector.

Collapse
18: Re: Packages and the GPL (response to 1)
Posted by Talli Somekh on
The argument of "the GPL has not been tested in court" is a myth in the open source and free software world. It's not been tested because no one has been dumb enough to try it, at least in the US.

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

Collapse
19: Re: Packages and the GPL (response to 18)
Posted by Dirk Gomez on

Germany (and the rest of continental Europe) has the droit d'auteur. You cannot transfer your copyright here e.g. if you join a company and hack away some time, you own the copyright to the code you wrote. You just don't own the license.

The philosophy of the GPL seems to be at odds with the German law. Last time I talked to RMS I asked him about this and he told me that it's a non-issue. For the Germans: You may want to get this book Open Source Software von Till Jäger, Axel Metzger

Collapse
Posted by Frank Bergmann on
Hi,

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/