[License-review] Legacy Approval, Licnese of Jam

Mon Apr 26 19:52:16 UTC 2021

On Mon, Apr 26, 2021 at 1:14 PM McCoy Smith <mccoy at lexpan.law> wrote:
>
> Given that this license does not grant the right to modify (or in US law
> parlance, make derivative works), I wonder if it fails OSD 3. I think it
> does, although perhaps it impliedly grants a modification right by saying
> that "modifications" must be marked even though it doesn't grant the right
> to make modifications?
> There are other issues with this one (patent rights, which I think recently
> OSI likes to see something like an express license) and the effectiveness of
> the warranty disclaimer, but if it fails the OSD, it is not approvable.

I don't know the history or usage of this particular license, but
there are what must be many hundreds of legacy licenses similar to
this one that have been treated as equivalent to simple permissive
FOSS licenses. They are found in packages regarded as "open source" in
all mainstream Linux distributions (many of them licensed under the
GPL or LGPL).

Based on some quick research I don't think the Fedora argyllcms
package makes use of jam but someone can correct me if that's wrong.
It didn't seem as though jam was in Fedora other than as part of
boost.

The approach Fedora, and I think the other Linux distributions with
similar licensing policies, have taken is to treat charitably
sufficiently old licenses that context suggests were meant to grant
permissions equivalent to what we'd regard as FOSS today, but which
may have been drafted naively to refer (for example) to "use" and not
explictly grant (for example) a right to prepare derivative works. In
other words, it is arguably not practical or appropriate to apply
present-day drafting standards to licenses from a sufficiently early
era in the history of FOSS licensing. If you say licenses of this sort
are not open source, that would mean that many packages assumed to be
open source are actually only partly open source, and perhaps even
embody some sort of FOSS license violation. In this case it is clear
from the license text that "use" was meant to encompass permission to
modify.

There are other cases where legacy licenses have later come to be seen
as non-FOSS, the best example of which may be the Sun RPC license.
(See: https://spot.livejournal.com/315383.html) But those are cases
where it is impossible to read the license as being consistent with
normative definitions of FOSS.

I don't know if OSI should start granting legacy approval to the large
numbers of licenses of this sort, but I see some benefits to moving
OSI approval closer to the reality of how "open source" is understood
in the community.

The strongest objection I see to granting legacy approval here is why
the OSI should start with *this* license when there are plenty of
others in the same category that are probably more frequently
encountered.

Richard

>
> > -----Original Message-----
> > From: License-review <license-review-bounces at lists.opensource.org> On
> > Behalf Of Jack Hill
> > Sent: Sunday, April 25, 2021 2:34 PM
> > To: license-review at lists.opensource.org
> > Subject: [License-review] Legacy Approval, Licnese of Jam
> >
> > As a licensee of Jam, I'm asking for legacy approval of the following
> > terms:
> >
> > """
> > License is hereby granted to use this software and distribute it freely,
> as long
> > as this copyright notice is retained and modifications are clearly marked.
> >
> > ALL WARRANTIES ARE HEREBY DISCLAIMED.
> > """
> >
> > This is the license used by Jam [0] and its forks [1][2][3] (n.b. the
> boost
> > version is also distributed under the Boost license). Outside of Boost, I
> don't
> > believe this build tool is widely used. However, it is needed to build at
> least
> > one important open source package: the Argyll Color Management System.
> > Argyll is the only open source package that I know of that can generate
> color
> > calibration profiles, so it is critically important for the use of open
> source
> > software in fields where that is important.
> >
> > I believe that the proliferation category for this license is
> > Other/Miscellaneous.
> >
> > In other discussions [4] I've had about this license, the problematic
> points
> > were what "distribute freely" meant, and how modifications could be
> clearly
> > marked. The Argyll fork of Jam marks modifications as follows:
> >
> > """
> > This if "Argyll-Jam", a simple derivative of the "FT-Jam" build tool,
> based and
> > 100% compatible with Jam 2.5. See http://www.freetype.org/jam/ for more
> > details about FT-Jam.
> >
> > This is the "FT-Jam" 2.5.2 release, with minor ArgyllCMS tweaks, and the
> > ArgyllCMS V1.3.3 Jambase as the default rule set.
> >
> > Note that you'll find the original Jam README in the file README.ORG """
> >
> > [0] https://www.perforce.com/documentation/jam-documentation
> > [1] https://www.freetype.org/jam/index.html
> > [2] http://www.argyllcms.com/doc/Compiling.html
> > [3]
> > https://www.boost.org/doc/libs/1_76_0/tools/build/doc/html/index.html#b
> > bv2.jam
> > [4] https://lists.gnu.org/archive/html/guix-devel/2021-04/msg00436.html
> >
> > Best,
> > Jack
> >
> > _______________________________________________
> > The opinions expressed in this email are those of the sender and not
> > necessarily those of the Open Source Initiative. Communication from the
> > Open Source Initiative will be sent from an opensource.org email address.
> >
> > License-review mailing list
> > License-review at lists.opensource.org
> > http://lists.opensource.org/mailman/listinfo/license-
> > review_lists.opensource.org
>
>
> _______________________________________________
> The opinions expressed in this email are those of the sender and not necessarily those of the Open Source Initiative. Communication from the Open Source Initiative will be sent from an opensource.org email address.
>
> License-review mailing list
> License-review at lists.opensource.org
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>

--