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 the issue. 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 different directions. 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 PROTECTED] 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/