site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Hello, The copyright notice in that file only says: /* * Copyright (c) 2004-2007 Apple Inc. All rights reserved. */ /* * @OSF_COPYRIGHT@ */ -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Nov 22, 2008, at 2:38 AM, Jonas Maebe <jonas.maebe@elis.ugent.be> wrote: What is the full meaning of @OSF_COPYRIGHT@ in Mach header files? Does it only mean that the file was originally written by the Open Source Foundation, or does it also automatically mean that it is licensed under the license that you can see e.g. here: http://kernelsource.svn.sourceforge.net/viewvc/kernelsource/OSF-Mach/6.1/osf... ) The reason that I'm asking, is that for our compiler port for targeting the darwin/arm platform, I have to distribute a translation of Platforms/iPhoneOS.platform/Developer/SDKs/ iPhoneOS2.1.sdk/usr/include/mach/arm/_structs.h (in order to be able to properly deal with signals) 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. 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. 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. This email sent to site_archiver@lists.apple.com