Forum OpenACS Improvement Proposals (TIPs): TIP #58 (Implemented): Add license value to package metadata

Proposal

Each package has a license. The license is recorded in the .info file for each major-minor release of OpenACS.

<license url="http://www.gnu.org/copyleft/gpl.html">GPL version 2</license>

License is visible in the Installer and when browsing the repository. License is recorded as a short string, suitable for display and sort/filter, and a url to the complete license.

Reasons

As third parties create non-GPL packages, we need a mechanism to differentiate packages during selection and installation.

Disadvantages

Volunteers will have to set license once for each existing package. New packages will need this field; this can be mitigated by including it in the default .info template.

Implementation

  • The APM needs to parse and display this new information when looking at local packages and when looking at lists of packages to install. A volunteer needs to do this.
  • The repository generator must parse and display this new information so that it is visible when browsing the repository.
  • The default template for new .info files needs to include the default.

Policy Implications

  • None. We only host GPL'd code at openacs.org.
Approve
Approve.
To save work, can we make the APM default to GPL for new packages? That would solve most cases.

Either way, Approved.

Approved.

Probably should say what to do for dual licensed code (two entries or one that says <license>GPL|SPL</license>)

What is SPL?
I like the idea. I'd prefer if it defaulted to GPL, as Dave suggested.

Under "Implementation" Joel says: "A volunteer needs to do this."  I was under the impression that when submitted a TIP, s/he either:

1) Implicitly volunteered to get the necessary work done.

or

2) Had someone in the OCT committed to get the work done.

This is to avoid TIPs that get approved but never get implemented because nobody ever committed to implementing it.

I thought this was described in TIP #2, but no. But I distinctly remember discussing this during the TIP process discussion last year. Am I wrong?

If I am correct, I'd say you need to post who is sponsoring (or committed to implementing) your TIP, if it gets approved.

-Roberto

I approve, but only if we have GPL compatible licenses as per http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses
Malte, we are not putting anything into CVS which is not GPL licensed. On the other hand, there is no requirement that packages be GPL compatible in general and if someone wants to distribute a package with a non GPL compatible license that is fine; so I am not sure what to make of your post.

One minor point, it's probably not a good idea to default the license. In general you want license choice to be made explicitly. Also, it should be a requirement to provide a license when creating a package and we should probably have a link explaining the OpenACS policy with respect to putting only GPL code into CVS. We should go through and add GPL to the existing packages though.

Finally, at least for the GPL, simply indicating something is under the GPL is not adaquate according to the license, you have to place the license text itself in the package as well (it's term 1 of the GPL). When we distributed things as a monolithic tarball it was fine to have it in the root, but now that we distribute packages individually, we should probably add the license to each one (as annoying as that might be).

Jeff, I was under the assumption from this TIP that we would support packages that are not licensed under the GPL *and* upload them to the CVS. If we are not, that's fine. Though I would not be so strict and demand GPL as the license, a GPL compatible license should be fine as well.
I think it's not really sensible to put something in to CVS with a GPL compatible license, since the first person who commits changes, retains copyright on those changes, and says their changes are only GPL licensed (which with a GPL compatible license is perfectly allowable and reasonable) coerces the license on the package to GPL.

You can fork any GPL compatible licensed code to a GPL licensed version in this way, which is the essence of what it means to be "GPL Compatible" and consequently I think in the interest of simplicity we should dispense with the pretext of allowing "GPL compatible" licenses in CVS.

If we did want to support alternate licenses in the code, we would probably have to have some way of having people formally accept that their changes fall under the compatible license. As it stands we probably should have people with commit sign something which says that and code or changes they commit are GPL licensed and possibly a "copyright disclaimer" (as mentioned in the GPL). See the Zope Contributor Agreement or the Mozilla contributor form for what something like this might look like.

Anyway, I don't want to be too pedantic about this license stuff, but I think we should get it right.

Approved
Marking approved and implemented.