Forum OpenACS Q&A: GPL and the use of GPLed Code in Commercial Products
the German "Heise Newsticker" is reporting about the commercial use of the GPLed "Ethereal" packet sniffer by the commercial "Etherpeek" product of "Wildpackets". I want to raise the issue, because there are similar situations with the relationship between OpenACS and several companies in its community.
http://www.heise.de/newsticker/meldung/59174
(Anybody knows where the Babelfish has gone?)
Here is the summary: Etherpeek takes advantage of the Ethereal package decoders. Etherpeek does not include or distribute the Ethereal packages. Instead, Etherpeek asks the user to install Ethereal separately and then calls the Ethereal API. So Etherpeek seems to comply with the legal side of the GPL. They don't distribute any GPLed source code. However, there are Ethereal developers who coplain that Etherpeek violates the spirit of the GPL.
Project/Open does something similar: We have created closed-source packages that call the APIs of the GPLed OpenACS packages. We believe that we don't violate (in legal terms) the GPL. See the previous discussions below:
https://openacs.org/forums/message-view?message_id=115603
https://openacs.org/forums/message-view?message_id=124433
[start of defense speach]
I frankly believe that "pure" open-source software won't work in many areas, particularly where the target users are technologically unsophisticated. Project/Open operates in one of those areas. Our (potential) customers expect "turn key solutions", starting from a Windows installer and ending at automatic software updates and a commercial help line etc. So we are investing a lot of time in "productifying" the open-source base system in order to create the expected solution. And this "productification" process is _extremely_ boring and unpleaseant (such as debugging Windows installers and writing up documentation...) We wouldn't and couldn't do this if we wouldn't be able to charge money for it.
However, we try to satisfy the "spirit" of the GPL by providing the base product for free to all users and by limiting the closed-source code to very specific extension modules (in our case: Translation Freelance Database and Translation Quality).
We limit the redistribution of our free code, but this is to be able to engage distributors in a "Partnership", where we would provide them with tech support, marketing marterial etc. in exchange for 20% of their service revenues. Please note that we are talking about the fact that these redistributors are making a considerable money with a ready-to-install solution.
[end of defense speach]
Also, please note that there are several pieces of GPLed P/O code that have not yet (fully) been taken advantage of by the OpenACS community:
- The Windows installer
- The Project/Open Core module (basicy the port of the ACS 3.4 Intranet to OpenACS 5.1 and PostgreSQL)
- A dynamic and configurable menu system (part of P/O Core)
- A dynamic and configurable report system (a bit similar to list-builder, part of P/O Core)
- The "Automatic Software Update Service"
Bests,
Frank
What I'd like to dive into is the comment about the GPLed code that has not made it back into OpenACS.
The windows installer is a very good contribution. Sadly not many within the community seem to have the enthusiasm with windows that the marketing people have. So, unless someone is willing to publish a windows installer with the latest OpenACS and .LRN code in a regular fashion, nothing will come of it. But if you commit yourself to this endeavour you can be pretty sure the community will be grateful for it. As long as the installer contains an option to say "Install P/O", "Install .LRN", "Install pure OpenACS".
I had a look at the dynamic and configurable menu system and I think portals is better. Though there is one advantage, and I'm not sure Don has changed that in the portal package: You could add permissions to portlet instances, therefore controling who can see what portal page / menu. But maybe I looked at something different in P/O and the menu system is something utterly different. Maybe you can quickly tell us the benefits of this menu system of yours so we could evaluate what we could use of it.
Regarding the report system, what is the difference between listbuilder and your report system? What can we learn from the report system? What are pieces that are missing in listbuilder which we could add to it?
publish a windows installer with the latest OpenACS and
.LRN code in a regular fashion
We would commit to this for every 6-9 months if there is somebody who can tell us what version of the code to include and who would perform the testing of the OpenACS and .Lrn stuff. That means: I can take the responsibility for the installer, but I dont't want to have to inquire whether we've got the right versions together. That's really not our job...
maybe I looked at something different in P/O
Maybe. The Menus are really just menus, generated from the database. I haven't seen something like this in OpenACS yet.
You are probably refering to the P/O "components". The main difference between the OpenACS portal and "components" is that you can add/modify components at the system runtime. That means: You can install a new package and this package can add stuff to the pages of another package.
what is the difference between listbuilder and your report system?
The same as before: "Binding Time". Imagine if the number of columns of the listbuilder could be changed via a maintenance screen or by another module. Listbuider is static. That means that you have to modify its code to add a new column.
Bests,
Frank
I honestly had no idea that you had GPL'd any of your work.
I for one would be very interested in working to roll some of this stuff back in to the open-acs as packages.
In particular I'd like to see elements of the original intranet package rolled back in (particularly the HR type stuff) and the menu system (though I personally dislike menus and regard them as superfluous, I recognise that some customers are menu junkies).
How much time would I need to set aside to acheive this, and would you be willing to support the effort?
Regards
Richard
I honestly had no idea that you had GPL'd any of your work.
Sure, I mean, "P/O Core" is basicly a port of the ACS 3.4 Intranet to OpenACS 5.1 & PostgreSQL. So we had to release this under the GPL. Othewise we would have violated the license (and not only the "spirit"...).
particularly the HR type stuff
We have moved the "HR stuff" into a separate package "intranet-hr", which is (obviously) also GPLed.
Also, we have taken on the ArsDigita "burne rate calculation" stuff from Philip and extended it with some serious "management accounting" stuff. It now features a variety of different types of invoices etc. and profit & loss calculation per project and customer. Check the "PO Finance User Guide".
I'd like to see elements of the original intranet package
rolled back
This depends on what you call "roll back". Everything is now based on these "dynamic listbuilder" thing that we use to keep the core extensible (it keeps the field information and pieces of the SQL query in DB-tables, so that extension modules can modify and extend it). Check http://www.project-open.org/doc/ for developer documentation. "Rolling back" would be very straight forward if you would keep this architecture, but would be very, very heavy if you would try to convert it to the OpenACS listbuilder. All modules together have some 350 .tcl + 160 .adp files, so it could be 35-70 days to do so (asuming 5-10 files/day, man, that's heavy stuff...)
Here is how to get the complete source:
http://www.project-open.org/download/latest/
Installing P/O on a standard PostgreSQL system should be a matter of seconds rather then minutes. The latest tagged CVS version is v3-0-0-0-3, but HEAD currently only includes bugfixes, so it's save to use.
The header of the files contain the copyright and the GPL/ non-GPL information (fairly consistently).
some customers are menu junkies
Well, yes, we're trying to sell the system to "stupid windows users", so you'll be (hopefully!) surprised by the level of integration. Menus are just one part of it.
Bests,
Frank
- Menus: Menus are tabs in the tabbed subsite view or portal pages in portals. All systems allow the dynamic extension of the functionality. The subsite and menu view limits this to packages (at the moment), the portal system is more dynamic in this regard, though it does not support submenus as the subsite and menu system allow. Ideally subpages should be implemented in portals. Franks documentation is at http://www.project-open.org/doc/intranet-core/menus.html.
- Components: Components are basically portlets. Within Frank's system they are stored in the database. With .LRN the portlets are stored in the file system and served from there. Usually the OpenACS approach is to keep as much information stored in /lib includes, so both portlets as well as other systems (e.g. Frank's component system) could access it. Would be nice to see Frank switch to this model.
- Dynamic Views: This is something that is missing at the moment from Listbuilder and is something we are going to add to it. The ability to enable / disable certain columns in a list view is great. Where it get's interesting though is when you want to add special columns that are derived from other packages. I guess this needs some thinking on how to implement it best (I assume callbacks again, but making callbacks dynamically hook into listbuilder with dynamic extension of the SQL query, can be challanging :)).
- Categories: The OpenACS is considerably better. Don't bother :).
- Permissions are mostly the same with regards to functionality though the implementation is considerably different. Here is a quote from Franks documentation (http://www.project-open.org/doc/intranet-core/permissions.html) why he did not use ACS Permissions:
"The complexity of evaluating and storing permission permissions needs to be considerably below O(n * m) with n=number of objects and m=number of users in order to be suitable for organizations with up to 100.000 users and up to 100.000.000 business objects to be managed. (I wouldn't be practical for example to apply the OpenACS permissions system directly to a filestorage with 10.000.000 files and 10.000 users, because its denormalization triggers would build an O(n * m) denormalized index)."
- Offices / Customers. This can be represented by the contacts package of Matthew Geddert with the additional benefit that you can extend the fields dynamically. I assume it should even be possible using callbacks to add a field e.g. to a contact like billable_p if the invoicing module is installed. Obviously this needs a small change in AMS.
- Projects. Well, there is project-manager and Frank did not like the look of it whereas I do not like the datamodell / technical implementation of Frank so it is up to anyone to decide what is best. We are working on PM together with Jade and others adding dynamic types support for attributes of tasks and projects, enhancing permissions (Richard) and generally making it more friendly to use (UI Changes).
So, in total, there is much to learn from Frank's approach and it is sad that the communication did not happen consistently some time ago, as this leaves us with fundamentally different technologies that are incompatible with each other, though they can coexist. But with regards to community effort, it is either support the P/O way of doing things or support the OpenACS way.
I basicly agree with Maltes views, and thanks for the "translation".
Even though: I think that our categories are better... :)
Just a joke. Forget it. Talking seriously: There are some duplicated models between OpenACS and P/O. However, I've carefully studied the OpenACS stuff before branching off, so there were some very good reasons why I choose to invest so much effort in "simply duplicating functionality". These differences mainly are related to runtime-extensibility and a higher usability (newby-proofness).
Runtime Extensibility:
This is a simple issues with big consequences. For example, it means that you can't update a standard OpenACS system via "CVS update" or "APM upgrade". OpenACS would loose most of its customizations. In contrast, P/O stores (most of) these customizations in the DB, effectively preserving them between updates. This is essential if you want to sell (not only in monetary terms) a "product"/"solution" instead of a "toolbox". Is this better or worse? Depends. Our model is more complex. But Malte is right, it's just a different way. However, we won't be able to revert to the Portlet model for these reasons.
GUI, Integration and User Friendlyness
Malte says:
Offices / Customers. This can be represented [...]Completely correct. Toolbox against solution. OpenACS follows the toolbox approach, which is perfectly aligned with the way of how most people in the community use OpenACS (how they earn money with it). However, you should not expect that anybody outside the community is going to use the combination of project-manager plus contacts. Or mix in some stuff from e-Commerce? These options are not usable out-of-the-box and they are not integrated. I don't say that there are _no_ links between the modules. But there are many processes that are not integrated. And that is a very, very tough barrier for everybody outside the OpenACS community.
Anyway, I really like how we come down in this discussion to the differences between OpenACS and P/O. This is why I feel that we are not really violating "the spirit" of the GPL. We have discarded and redesigned a considerable part of the OpenACS kernel in order to provide users with a "solution". This "solution" focus is something that is not valuated very much in this community (I believe in open-source communities in general).
Btw., I think that there is actually a vey similar conflict going on right now between the OpenACS community and (some users of) dotLrn, if I'm allowed to comment on this as an outsider 😊
Bests,
Frank
"We would commit to this for every 6-9 months if there is somebody who can tell us what version of the code to include and who would perform the testing of the OpenACS and .Lrn stuff. That means: I can take the responsibility for the installer, but I dont't want to have to inquire whether we've got the right versions together. That's really not our job..."
Thanks for this, I think this would be a great contribution.
I will discuss it with the dotLRN consortium people, but I think we could give you a complete spec for the distro every 6 months or so.
Thanks again for all your contributions.
Rafael
but I think we could give you a complete spec for the
distro every 6 months or so
Well, it's a little bit more to that then just implementing specs. I see it from our installer. Most of the time is spent on testing and configuring a reasonable "preconfigurated" data model, fixing the bug, preparing the installer and repeating the cycle. I don't know if you want to do this for dotLrn, but this was really the killer improvement for P/O, because potential customers can play around with an existing system, instead of imagining one.
So we would need support for the full [test - report - fix - build again] cycle:
- Specs, that should be fairly straight forward. Also, having a working system build according to the specs would be cool.
- Testing resources: We would need some people who could check the installer on different OSs and go through a Test Plan. They should be able to report installer bugs with a fairly high degree of insight into the system.
- Test Plan: This could be a simple one, just checking the dotLrn specific installer options. But I would recommend to include a general application testing as well to make sure that the basic application functionality is running. We've got a fairly big Excel sheet with several hundered test cases for a human tester.
- Preconfigured database contents: Do you want to offer this? This is a lot of work, but users love it, because they can _see_ a running system, and don't have to imagine one...
- "Cohabitation" with P/O: We would have to include all installation options in a single installer, similar to the current one: "Core OpenACS", "dotLrn", "Project/Consutling" and "Project/Translation" plus some preconfigured systems for each option.
- Organizing resources: I would't like a situation where we would have to ask around, begging people for help. Let's face it, "Windows" and "testing" is probably the combination of the two most boring and annoying concepts in this community. Only "documentation" could be worse...
- Apropos, what about documentation? 😊
- Release schedule: We would have to - more or less - coordinate release schedules of dotLrn with P/O. However, this should't be a difficult issue, if we asume that the Windows installer is always going to be somehow outdated.
So, this was basicly a brief writeup of the issue that we are facing...
Please keep in mind that we are no experts in the dotLrn functionality (and probably won't become).
Here are some references to previous discussions:
https://openacs.org/forums/message-view?message_id=274634
https://openacs.org/forums/message-view?message_id=213806
Bests,
Frank
Your Project Open stuff may and probably does have real and necessary technical design differences from other OpenACS packages, but I don't think that's the reason.
Pre-configured database content for demos and testing is
really, really cool
So you installed P/O using the Windows installer? It's one of the main features in our "sales process". And yes, every tester has the same base. And large pieces of TCL code are only activated once there are contents in the DB. However, putting the content together took us several weeks, and it requires special testing in conjunction with the installer.
I don't see why whether you save custom code in the
filesystem or in the RDBMS has any necessary relationship
with run-time extensibility
Please check for reference:
https://openacs.org/forums/message-view?message_id=239510 and
http://www.project-open.com/whitepapers/Project-Open-Architecture.pdf (the last slides)
The summary is: There are many types of customizations. The most critical type is probably the extension of "business objects" by additional fields and associated tables. Such an extions also implies (in a highly integrated GUI such as the one in P/O) that you show the extension information together with the original information on the object's "view page" and "list page". Extension modules need to modify these pages. So, how would you do this with listbuilder or portlets with the metadata under CVS control? What about two or more packages modifying a business object?
As an example: Please check the P/O Windows installer and install the "Project/Translation" preconfig (10 minutes on a WinXP box). On the "Projects" list page you can see in the last column a summary of number of "words" from a translation project. If you go to the "view page" of this project, you will see that there are translation information on the same page. However, you won't see these fields and "components" if you choose the "Project/ Consulting" option (please dont't use the preconfig, it's the same as P/T at the moment ...), .
This is a kind of issue that doesn't seem to get much attention in the OpenACS community because of the dominating "toolkit" approach. And that's ok, no problem. However, P/O (and a few other companies offering "products" and "solutions" around OpenACS) really struggle with this.
real and necessary technical design differences from other
OpenACS packages, but I don't think that's the reason
Loads of suspicion... Well, no surprise taking into account my previous posting. And yes, we moved away from the OpenACS core in some cases for licensing reasons (to be able to have "clean-room engineered" modules that don't fall under the GPL). However, the "P/O Architecture" slides were written long before we actually started the work, and "extensibility" was the main reason to discard listbuilder and portlets.
Bests,
Frank
No, I haven't tried your Windows installer; I don't have to use it to know that good automated pre-loaded database content should be really useful for demos and testing. I have heard from some people who have used your Windows installer though, and they were very positive.
Btw, I'm not sure why you seem to be worrying so much about GPL issues. AFAICT your company's Project Open work is well within the bounds of the GPL, and the OpenACS project has a long (informal, but long) history of saying that proprietary applications built on top of OpenACS are perfectly fine.
Really, the only question is how well or poorly your work will integrate with and be leveraged by other users of OpenACS and vice versa; nothing much to do with license issues, GPL or otherwise.
AFAICT your company's Project Open work is well within
the bounds of the GPL
Wildpackets are working "well withing the bounds of the GPL", and got this quite negative press... So it's really just prevention here.
The situation with P/O is actually a bit trickier, because of the term "derived work" in the GPL and its interpretation by different parties. For example the distribution of proprietary P/O code together with GPLed code in the Windows installer is a slightly grey area where some people might argue that it extablishes a "derived work". So this is why the installer has to differentiate between the different installation options to make clear that it is just a "collection" (similar to a RedHat Linux CD Distribution) and not a single piece of work. Here is the reference to the detailed study:
https://openacs.org/forums/message-view?message_id=278014
you seem to be worrying so much about GPL issues
We are talking with investors and in this context there is hardly anything more critical then the question of whether the code is ours or not and whether we can prevent others from redistributing our code if necessary...
Also, I've been doing some consulting work for two other "OpenACS companies" (I don't know if they want to be named) and they are facing very similar questions related to the distribution of products based on OpenACS.
Really, the only question is how well or poorly your work
will integrate with and be leveraged by other users of
OpenACS and vice versa; nothing much to do with license
issues, GPL or otherwise.
Well, good point, I hope we are showing true community spirit in this sense...
Bests,
Frank
The design sounds good to me (we discussed it in Madrid) so this is one piece I do not think we'll be taking from Project Open ...
And I'll be working over summer to integrate the portal tab navigation code with the dynamic subsite navigation work done by xarg.
