The release notes:

Release Notes for 4.6 formal build 1
------------------------------------

1. Introduction


This release of ACS Core is the first in a new set of products from 
ArsDigita.

All design, development, and architectural information is available on
http://developer.arsdigita.com/acs-java/

Full documentation is available at 
http://developer.arsdigita.com/acs-java/doc.

A high level product overview is available at
http://www.arsdigita.com/products/4x/46
 
The ACS Core is a platform on which developers extend application 
logic, 
user interface, and styling that together implement a website. The 
Core APIs 
insulate the site implementation from the data model, the hardware 
configuration, and the  web server. In the future, the same APIs will 
also 
isolate the site from the database vendor.

This release is free and publicly available under the ArsDigita 
Public License,
details of which are available at http://www.arsdigita.com/adpl.txt

Based on experience implementing sites for many different customers 
and 
industries, we believe that the product allows for efficient site 
development. 
Using this product, developers can focus on the elements that make a 
particular site interesting and unique.

This release also includes an early version of a new Content 
Management
System (CMS). Release notes and documentation for CMS are included in
http://developer.arsdigita.com/acs-java/doc/cms/release-notes.html


2. Installation and Development Notes

The product runs on a wide variety of configurations. Thus, there is
no general installation solution. At this time, there are solutions 
for
some special cases. 

Before installing the product, you should be familiar with the
concept of how Java code runs within a servlet engine environment,
how JDBC allows your code to connect to a database, and the basics
of configuring an http server. You will also need JDK 1.3.1, available
from http://java.sun.com.


Future plans call for the development of a more complete installer.

If you are developing and extending ACS Core on Unix systems, the
recommended configuration is to use the Tomcat servlet engine and
Oracle 8.1.7. Solaris x86 and Linux are both reasonable choices for
operating system.

A shell script, installer-lite, will simplify installation in this 
case.
You can find information about using it at
http://developer.arsdigita.com/acs-java/doc/infrastructure/installer

The ArsDigita development team has successfully used the product on
many other configurations, such as Caucho Resin 1.3.4. ACS Core has
been successfully developed and extended on Windows 2000. 
For details on these other configurations, see the documentation
at http://developer.arsdigita.com/acs-java/acs-core/doc

Manual build and installation instructions are located at
http://developer.arsdigita.com/acs-java/install.

Once you have an installed copy of ACS Core, the best way to
proceed is to read the QuickStart guide. It is available at
http://developer.arsdigita.com/acs-java/acs-core/doc/quickstart.html


3. Release Information

This release is intended to be for developers, and early adopters.

3.1 API Stability

There are four support levels for the ACS Core APIs: mature, stable,
experimental and unsupported. In addition, methods within the APIs
may have a different support level. The support level is explicitly
stated in the Javadoc for each Java package.

Application code written to a stable or mature API is upgradeable
to future versions of ACS Core without modification. Application
code written to experimental APIs may need to be changed when
upgrading. Unsupported APIs must not be used, they are only public
scope because of language or architectural details.
 
3.2 Non-upgradeable situations

  - Use of experimental or unsupported features may 
    upgradeable. This "support level" information is 
included
    in the Javadoc for each package and method. A stable or mature
    package or class may include experimental methods.

  - Currently, the persistence layer allows you to write
    direct SQL code as part of your customizations. Such code
    may not allow you to migrate to a different configuration.

3.3 Oracle "Thin" Driver cannot be used with ACS Core

The ACS persistence layer currently uses the JDBC API for LOBs, which
Oracle's Type IV (Thin) driver does not support.  The OCI driver does
support use of LOBs.

You must use the Oracle OCI driver.

3.4 General Stability

Known problems when running with a high user load may cause the
server to deadlock or crash. For that reason, the use of this
release for production deployment is not recommended.

3.5 ORA-3210 can occur when an Intel server uses a database running
on a Sparc CPU.

According to Oracle, the ORA-3210 issue with selecting CLOBs from 
a UTF8 database over Net8 from an Intel CPU to a Sparc CPU is 
resolved 
with Oracle 8.1.6.3.0, 8.1.7.1.0, and 9i.  We have verified this with 
8.1.7.1.0 and 9i.  There are no known issues with ACS Core
running with the OCI driver on those databases.

It is recommended that you upgrade any Oracle database 
intended for use with ACS Core to one of the supported versions. 
Patch sets 
are available at http://metalink.oracle.com. 

3.6 Globalization

Globalization support is inconsistent within ACS Core. Character
sets other than ISO 8859-1 may not work.

3.7 Upgrading from ACS 4.5

If you are using a prerelease version of ACS 4.6, you must drop and
reload your data model. There are no data migration tools provided
with this release. Future releases will provide such tools.

"Acknowledgment. All advertising or promotional materials, download pages, documentation, and/or physical media mentioning features or use of this software, and any redistributions in whatever form, must display the following acknowledgment in a reasonably prominent location: "This product includes software developed by ArsDigita Corporation for use in the ArsDigita Community System (ACS) (http://www.arsdigita.com/acs/)."

This is the one that strikes me up most, but there are probably other things. In the license it also says that "Except as required by the Acknowledgment section below, products derived from this software may not be called "ArsDigita Community System" or "ACS" and such names may not appear in the name of any such derived product without prior written permission of ArsDigita. To request written permission, contact info@arsdigita.com. "

I agree with Ben. OpenACS developers, please do not get close to ACS 4.6 until we give further recommendations. This is to avoid any problems to OpenACS as a project.

Or they could bundle up a new ACS Tcl release and make it available only under the new license, in which case we'd need to avoid it.

aD's business interest is in the Java version, though, so I doubt if they'll take steps of this sort.

This is very interesting, on another thread we had someone ask about the GPL and modifications to GPL'd software. I looked at the GNU FAQ on the subject, located at http://www.gnu.org/licenses/gpl-faq.html.

It clearly states

The GPL does not require you to release your modified version. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization.

But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the users, under the GPL.

Thus, the GPL gives permission to release the modified program in certain ways, and not in other ways; but the decision of whether to release it is up to you.

If ACS4.6 is a modified version of GPL software, is seems like it must be released as GPL as well. aD may be in violation of the GPL.

This is a major change (as I see it) in licencing of ACS and understandably some research and thinking should be done on the communitiy's part.

Of course, we could always forward it to RMS (who I'm guessing that didn't talk to before releasing this) and see what he thinks about it :)

Relations between the OpenACS and aD communities have not always been good, which is fine. We thought that they were ignoring an incredible resource of fans and they view us as ungrateful scabs. Oh well.

They are clearly not in favor of Free Software. That's too bad. My fear is that they are intentionally trying to screw OpenACS by intentionally limiting how much we can use their code. They could have at least pinged the gatekeepers to let them know what's going on.

aD has some really smart people over there who are committed to making good systems and are supportive of Free Software. It just seems that the management is screwy.

Bryan Quinn said: "I hope that you find the ACS useful in your development efforts."

So did we. And we hoped to have helped your development efforts. I hope things aren't as bad as they look.

talli

On there terms of licences, I generally don't look at software where the licences has been reviewed. GNU's web page usually gives a good overview of all the possible licences that are out there and points out where there are issues with it in (in their eyes).

With the increase in companies making their own "public licences" it
really becomes and issue.  In the case of some companies, I can understand it (Netscape/Apple had previous issues that restricted them) while others appear to be self-serving copyright restrictions using the "Something"PL mindshare.  I've seen (and heard) of a few projects running into problems with this and would hate to see this happen here (although I'm quite sure this is looked at by _current_ comtributers).

In terms of aD, I think OpenACS is firmly planted with a source base (in both 3.x and 4.x code) to continue moving forward, that depsite being treated as "scabs" if changes are needed, I don't see that as a concern.

The chief reason we switched to a MPL-derived license was so that people could add to it and release it under any license they want. I've been in a room with a possible development partner and he immediately said GPL would be unworkable for many of his clients.

If you write a package for ACS 4.6, you can release it however you want...

The modifications requiring you to credit ArsDigita are pretty much what they seem. The product costs millions to build and it is an attempt to get some advertising in return for this investment.

Those are the high level points; please do check it out the licence and give us feedback, esp. if you deem it completely unworkable. We don't suspect this is the case.

This is the first version of ACS we've release that has been heavily load tested. We use to try to apply some load on photo.net, but that because increasingly unworkable and then some of our clients had loads that peaked higher than photo.net. There is nothing like expecting a bunch of load and having no idea what the server can take (an experience I've had a few times and it was not fun, so I'm very glad we have the testing facility).

We are testing each release and working through issue at a time. Publically stating what we have found is our attempt at getting better about describing where the software is and what to expect. This is the starting point, and you will see regular releases with bug fixes and other improvements from here.

You'll find the architectures of TCL verses Java very different. So yes, the systems are clearly different as Don pointed and may support different needs depending on what you want. So, in that respect, we (ArsDigita) and I (because I wrote a lot of it:) are pysched to see the TCL version go on strong.

My response is just the broad overview. Cesar is putting together more information about the license and these questions. It will be available soon.  We are reading this thread so if there are more questions, please post.

(Sadly, I looked at these docs before the licensing issue was on
the table. Will I go blind now? Does it help that I didn't
understand most of the programming stuff?)

At any rate, is it OK for me to refer to these docs? As far as I can
tell, the only useful info in them (for our purposes) is the
requirements outline and a few comments about the datamodel.

What kind of legal problems will arise when OpenACS clones ACS 4.6+ modules??? (Vice versa this is clearly not a problem, because of the GPL of OpenACS)

With cloning I mean: OpenACS takes some ACS 4.6+ modules' datamodell and pageflow as a basis for a clone and rewrites all the java into tcl...

It would really be nice if some aD execs or lawyers could clarify this as they seem to be interested in a coexistence of OpenACS and ACS as Tracy mentioned.

As far as I can tell, ideas discussed on bboard are fair game (specifically, dealing with connect by - eventually I'm going to benchmark nested sets vs. precomputed sort keys and pick whichever is faster); I'm just avoiding code (anything that would go into a tarball distribution).

It's worth noting that you actually have more options under the MPL derived license than under the GPL - if you want to release a software product that uses the ACS, you can choose what license to use for your code.  Previously, it was all GPL only.  Because of this, I was personally thrilled when this license was selected (I had no part in the decision, but I think it's a great one).

I'm surprised that none of you have run into business problems dealing with GPLed software.  I have personally seen a client refuse to use the ACS because they were convinced that the GPL virus clauses could cause them to make all of the content (pictures, mostly) they posted on their ACS site be GPLed.  It was an absurd concern and I got to brief them on why they were wrong (derivative work blah blah blah), but their lawyers were never satisfied - they had heard the GPL was infectious and couldn't get beyond that.  I suspect not having the virus clauses will make sales a bit smoother and open up new options *for everyone* in product development.

from http://www.gnu.org/philosophy/netscape-npl.html

Essentially the GPL says that the restrictions it places on code are the only restrictions which may be placed on the code.  Intentionally incompatible, it's a philosophy thing.

As for having OpenACS 4 use ACS 4.6/5.0, I'm surprised to see this is a concern since I thought everyone here felt aD was headed in the wrong direction.  I don't know if any options exist for using ACS4.6/5.0 on a GPL project beyond writing modules that run on ACS 4.6/5.0, which you can then distribute with whatever license you'd like.  (See flaw #2 at the previous link, which I don't see as a flaw).

The only goal is to improve OpenACS as widely and quickly as possible for competitive reasons. Therefore it really wouldn't be clever to neglect the innovative potential of aD developers. This is directed towards innovative ideas, datamodel, pageflow of ACS 4.6+. As Don put it: The ONLY thing that we were not quite comfortable with was Java and NOT aD's innovative potential.

In my opinion aD's move towards Java+Apache+ADPL is reasonable from a business perspective. BUT in order to avoid this kind of discussion (and maybe further frustration towards aD) aD's execs should have released effects of the ADPL on OpenACS together with Bryan's post!!!

#2
I don't see how it's possible to learn programming from a bunch of losers who don't have a single compelling product. Open acs4 only works on oracle. (Oh that's right, it is just acs4.2) and acs 3.2.4 is just weak.

#3
I challenge any of you to name one thing you've contributed that is in ACS.

Thid, until you reveal your identity, you remain some hopeless 13-year-old kid.  In the eyes of everyone reading this bboard, you are a complete moron.  Why not prove us all wrong and just tell us who you are?

"#1 I programmed 4 times more of ACS than the rest of you combined when I worked there. Farkas you suck. We fired you for using windows. I guess the GPL doesn't mean anything to you."

"#2 I don't see how it's possible to learn programming from a bunch of losers who don't have a single compelling product. Open acs4 only works on oracle. (Oh that's right, it is just acs4.2) and acs 3.2.4 is just weak."

"#3 I challenge any of you to name one thing you've contributed that is in ACS."

Anyway, now that I've answered your, uh, questions (or points), I'm curious if you'll respond to a couple of mine:

1. From your viewpoint, is the shedding of a Moose's antlers a metaphor for the move from Tcl to Java?
2. Do you identify with Moose generally or just certain ones? (Alternate link for dog lovers.)
3. Are you a fan of any of Dr. Seuss's other works?

The section on whether gleaming concepts from ACS 4.6 constitutes the
creation of a derivative work thus covered under the ADPL is murky at
best, and is not something on which I'm ready to take any risk.

Thus, I reiterate my strong request: if you are developing for
OpenACS, please do *not* take a look at ACS 4.6 source code. This is
no longer "pending further review": we cannot take the risk of
violating the ADPL.

Code, sure. Page flow, dubious. But data models? I have a hard time grasping how copyright can be extended to include thought processes. Even if someone did lay claim to the contents of a .sql file under a copyright, there is no underlying claim to the data model. Re-implement the same data model in a different way, (using a different "expression" of the idea) and no copyright violation has occurred.

Copyright is about expression. If you want to protect process and design, you have to patent. Can I copyright how an internal combusion engine works? No - but I can write a textbook about it, and protect that.

Thank you. Rant over.

Kjell's argument is irrelevant because the code's not only protected by copyright, but by license.

It would be good to replicate it throughout the OpenACS 4 porting
information as well (maybe a link to the news item).


Oh yeah, it probably should be in this FAQ, too: http://
openacs.org/faq/one?scope=public&faq_id=6

Thanks,

This is a really sad state of affairs. In the beginning, people were drawn to ArsDigita precisely because Philip gave so much away in terms of insights on how to write better code. Now, the very same community that was built from that generosity can't look at anything from ArsDigita for fear that doing so will jeopardize what has grown from it.

In essence, until and unless ArsDigita solves this licensing problem, they have completely cut themselves off from the community.

Let it go. It's time to move forward.

When visionaries leave companies, guess what they take with them? I worked for Jim Clark during his waning days at SGI. The company has never been the same since he left. They lost market share, got dropped from the S&P 500 for "lack of representation" and have recently traded as low as $0.50 per share. I had a great time working there, but I've moved along since then.

If you really want to rant about ArsDigita, I suggest you visit this site which specializes in that sort of stuff.