Re: The APSL and Export Controls
Chip Salzenberg writes:
> According to Joey Hess:
> > I think you're quite right, this is another thing that makes the APSL
> > non-free. There's even precedent; IIRC packages have been kicked out of
> > debian in the past for having copyrights that explicitly said they couldn't
> > be used in embargoed countries.
> For those of you who don't kno me: I'm a member of the board of OSI.
> Speaking for myself, not on behalf of OSI: Yes, this part of the APSL
> needs to change. We're working with Apple on APSL mods, and the export
> limit provision is already on the agenda.
> Unfortunately, Apple _is_ a large corporation; I don't expect to see
> changes in the APSL quickly. It'll take a few months at least before
> APSL 1.1 (or 2.0? :-)) is released.
I appreciate your interest in this, and I'm glad that the OSI is aware of
I would suggest that there are larger problems in the OSD itself: the
Debian Free Software Guidelines were written for the benefit of people
already working within the free software community, to try to articulate
some quantity of shared understanding about what properties were
characteristic of "free software". But this document abruptly moved from
a set of "Guidelines" to a "Definition", which is now being used as though
it were a legal document by many people and entities who are completely
unfamiliar with free software. If the current OSD is all they see, there's
a lot of room for confusion, perhaps because of the number of things the
DFSG took for granted.
It is a very tricky situation in many ways. Now that there is an Open
Source bandwagon to be jumped on, the number of different public licenses
is exploding, and many of these licenses seem to be coming from an
entirely different direction than (say) the GPL. This is a recipe for
endless controversy, if only because the lawyers writing each new public
license seem to be able to dream up new license terms which never even
crossed the minds of the people who conferred on the DFSG.
It's easy to get the impression that the lawyers who write many of these
licenses don't _actually_ want to give up some sort of "control" over the
code, and are looking for loopholes in the OSD. (I'm not picking on
Apple here; I got precisely the same impression when I was asked to comment
on a draft license for a project in my group at Lawrence Berkeley Lab.
There, as I understand it, the license had been written from scratch by a
lawyer unfamiliar with free software and Open Source, who simply referred
to the OSD as his only guide. The result was that, where the OSD did not
explicitly forbid some condition, the license would include it.) It's
really not a good thing that people would be searching for loopholes this
way, but I expect the problem will only get worse.
If "Open Source" is going to continue to be a useful and meaningful term,
I think the OSI needs to be careful to hold users of the term to high
standards; otherwise, the term could gradually become diluted in many
Incidentally, the "Why this matters" part of my essay was added late last
night in a hurry, and hasn't been edited nearly as much as the rest. I
just wanted to have something there to try to indicate (to Mac developers
unfamiliar with free software) where I was coming from in criticizing
Apple's actions. What it most needs is to be made a little shorter. :-)
Seth David Schoen / email@example.com
He said, "This is what the king who will reign over you will do." And they
said, "Nay, but we will have a king over us, that we also may be like all the
nations." (1 Sam 8) http://ishmael.geecs.org/~sigma/ http://www.loyalty.org/