Re: Meaning of @OSF_COPYRIGHT@
Re: Meaning of @OSF_COPYRIGHT@
- Subject: Re: Meaning of @OSF_COPYRIGHT@
- From: Jonas Maebe <email@hidden>
- Date: Sat, 22 Nov 2008 20:56:47 +0100
On 22 Nov 2008, at 19:48, Terry Lambert wrote:
On Nov 22, 2008, at 2:38 AM, Jonas Maebe <email@hidden>
wrote:
/*
* @OSF_COPYRIGHT@
*/
I cannot find any document anywhere explaining what this marker
means. If it does mean that it is licensed like the Mach kernel
sources on Sourceforge, then there is no problem for me to
distribute the file (the license forbids taking away that
permission, and the iPhone SDK license agreement also explicitly
mentions that in those cases the NDA/no distribution/no derivative
works/... requirements do not apply).
There is no way you will get an official anser to a question like
this on a mailing list. This is not an official support channel,
even if people who happen to work at Apple sometimes hang out here
and post personal opinions. For an official answer, you should
contact DTS and ask.
I did contact DTS with a licensing question several years ago (about
permission to distribute translations of the Apple Universal
Interfaces), and they redirected me to email@hidden. I sent an
email there, and never even got an acknowledgement of my request.
About a month ago, I again sent them an email asking whether or not
APSL-licensed files in the iPhone SDK can be modified and
redistributed under the APSL terms now that the NDA is lifted. Again,
I have not heard anything back.
So as far as I can tell, email@hidden is a black hole (except
maybe if you represent a million dollar customer of Apple or so). I
still have some hopes regarding my second mail because someone at
Apple was going to poke them about it. Still, they obviously have
other things to do than answering requests from an individual open
source developer (regardless of how many commercial companies use our
product).
Furthermore, the @OSF_COPYRIGHT@ tag also appears in many regular
Darwin files (e.g., in 517 of the xnu-1228.7.58 files). Since several
people responsible for the packaging and releasing of Darwin sources
are here, I hoped that they could give an indication of what it means
(maybe just a reference to some licensing document somewhere on the
Darwin site that Google doesn't index).
In these xnu files, @OSF_COPYRIGHT@ does in fact appear to be always
followed by the full OSF license in linked to in my original mail.
Maybe some sort of license stripping was done for the iPhone SDK to
avoid marking certain iPhone-specific files as APSL. Or conversely,
maybe only the tags are present in Apple's internal sources and simply
no license /insertion/ was performed based on these tags -- one more
reason why I think the Darwin packagers may be able to answer my
question, even if only in the sense that "based on this tag we insert
this text into the sources when preparing them for distribution. The
OSF license would however remain applicable in such situations (since
that one is not Apple's call to remove).
All that said, were I in your position, I would side-step the issue
entirely by doing a machine translation at install time, which is
the time-honored approach to dealing with license issues by not
dealing with them. Perl, Ruby, Python, etc., all take this approach.
For this particular header file (which is fortunately the only one
which I need from the iPhone SDK for our base run time library), that
would indeed be an option since it is so simple. General machine
translation of C headers usually breaks down horribly in my experience
though. But maybe gen_bridge_metadata(1) manages to work around most
quirks.
It would still be a pain though, since we normally distribute a
compiled version of all our units (it's a Pascal compiler, producing
natively compiled code). Since this header file is necessary for the
system unit on which everything else depends, we'd have to distribute
the sources instead, somehow find a way to get Installer.app to ask
for the location of the iPhone SDK, and then translate that header and
compile/install everything. That's not really user-friendly (not for
us as developers, nor for our users).
Not distributing anything at all (or worse, distributing a file that
may make me and them liable for copyright infringement lawsuits by
Apple) is obviously even less user-friendly, hence my question to see
what my options are.
I'd also like to point out from a signals perspective that the
contents of the sigcontext and mcontext are supposed to be opaque,
and other than their size, unless you are a debugger, you should not
be introspecting their contents. If you are not a debugger, then you
should be trying to write your code in such a way that not even the
size matters outside of libc itself to let the structures change
out from under you without breaking your code, if at all possible.
I have tried that when I did the initial port to Mac OS X, 5 years ago
or so, and failed. The situation is currently like this:
1) an fpu exception, or sigsegv, sigbus, ... occurs
2) the OS raises a mach exception, which is then converted into a unix/
bsd signal
3) we catch the signal using a handler installed at startup of the app
4) we determine the nature of the signal and where it occurred
5) we change the context of the signal (here's where we need the
structures) so that it will return to our own run time error handler.
We also store the necessary information (exception nature, pc where it
occurred, stack pointer at the exception time) in some register fields
of the context struct (which are interpreted as parameters in the run
time error handler)
6) we return from the signal handler
7) the kernel resumes execution in our run time error handler
8) we generate the appropriate language exception
My initial version used some form of (sig)longjmp instead of steps 5
to 7 to hand over control to our run time system, but that does not
work for fpu exceptions (at least not on PPC). The reason was that as
long as you did not return from a signal handler, fpu exceptions
remained disabled (well, you could re-enable them in the fpscr, but
the kernel dropped them on floor as soon as they occurred again
afterwards). I can't immediately find again where this happens in xnu,
but if you are interested I could try to look it up again.
I'm not sure what alternatives I have to convert hardware/OS
exceptions into language exceptions (at least not if I want to be able
to provide backtraces to the consumers of those exceptions, like we do
right now).
Thanks,
Jonas
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden