Which license would be most appropriate for the C standard headers? I'm
not sure that the LLVM license with the advertising clause would be the
best bet, since those headers get compiled into end-user's applications,
but IANAL. Personal preference would be public domain, or MIT/X license
if the no-liability stuff is considered important, but I'll use whatever
the project leads say I should. (Some of these headers are so small and
are just directly taken from the standard's wording that I'm not even
sure copyright is applicable, but meh.)
Also, here is the C99 stdbool.h I wrote as an example. Please let me
know if this is the format you'd like these headers to be in. Mostly,
are the include guards acceptable in format, and is the comment block
acceptable in detail, or is something missing? (Other than the
license.) Should there be more comments for the macro definitions
themselves, or are suitably small, simple, obvious, self-documenting
things like that acceptable to leave without description?
Which license would be most appropriate for the C standard headers? I'm
not sure that the LLVM license with the advertising clause would be the
best bet, since those headers get compiled into end-user's applications,
but IANAL. Personal preference would be public domain, or MIT/X license
if the no-liability stuff is considered important, but I'll use whatever
the project leads say I should.
Something like Boost's license, I'd say. And it can't be public
domain, see lj16 :
"there is nothing that permits the dumping of intellectual property
into the public domain — except as happens in due course when any
applicable copyrights expire"
(Some of these headers are so small and
are just directly taken from the standard's wording that I'm not even
sure copyright is applicable, but meh.)
I wonder how close they can get without being derivative works of the
standard...
Which license would be most appropriate for the C standard headers? I'm
not sure that the LLVM license with the advertising clause would be the
best bet
The LLVM License doesn't have the BSD advertising clause.
, since those headers get compiled into end-user's applications,
but IANAL. Personal preference would be public domain, or MIT/X license
if the no-liability stuff is considered important, but I'll use whatever
the project leads say I should.
Something like Boost's license, I'd say. And it can't be public
domain, see http://www.rosenlaw.com/lj16.htm :
"there is nothing that permits the dumping of intellectual property
into the public domain — except as happens in due course when any
applicable copyrights expire"
Excellent link, lots of food for thought.
I'd prefer to keep it simple, either the LLVM license, if possible, a straight-bsd or MIT license, etc.
I will extract some free legal advice from apple lawyers and get back to you. In the meantime, please pick something simple (like you have) and we will resolve the issue in parallel with implementation. Thanks!
Also, here is the C99 stdbool.h I wrote as an example. Please let me
know if this is the format you'd like these headers to be in. Mostly,
are the include guards acceptable in format,
The include guard needs to start with _ to avoid polluting the user's namespace.
and is the comment block
acceptable in detail, or is something missing? (Other than the
license.)
We'll resolve the license issue separately, but other than that I think it looks fine. Any other opinions?
Should there be more comments for the macro definitions
themselves, or are suitably small, simple, obvious, self-documenting
things like that acceptable to leave without description?
It would be nice to cite the standard for the various pieces :). Other than that, it looks great.
Where should this go in the clang tree? I don't think putting it in clang/include/... makes sense, how about a top level stdincludes directory or something?
The LLVM License doesn't have the BSD advertising clause.
My apologies, I should have said the "endorsement" clause, not the
"advertising" clause. My non-marketeer brain has a tough time
distinguishing the two sometimes.
> Something like Boost's license, I'd say. And it can't be public
> domain, see lj16 :
> "there is nothing that permits the dumping of intellectual property
> into the public domain — except as happens in due course when any
> applicable copyrights expire"
Excellent link, lots of food for thought.
I didn't put much faith in that page due to a complete lack of
references, so I searched around a bit, and it seems accurate. Here's a
much more obtuse but better defended essay on public domain. It
includes a section on public domain software and why it's not really
possible to to do with today's laws:
The gist of the arguments against public domain dedication are that
modern law goes so far as to protect authors against putting works in
the public domain, because the author might not understand what he's
doing until it's too late. The laws have become very pro-producer,
con-consumer (which, etymologically, I find freaking hilarious).
I will extract some free legal advice from apple lawyers and get back
to you. In the meantime, please pick something simple (like you
have) and we will resolve the issue in parallel with implementation.
Thanks!
The include guard needs to start with _ to avoid polluting the user's
namespace.
Righty. That was what the LLVM_CLANG_ bit was for, but an extra _ won't
hurt.
> Should there be more comments for the macro definitions
> themselves, or are suitably small, simple, obvious, self-documenting
> things like that acceptable to leave without description?
It would be nice to cite the standard for the various pieces :).
Gotcha, will do.
Where should this go in the clang tree? I don't think putting it in
clang/include/... makes sense, how about a top level stdincludes
directory or something?
I was wondering about that. How about std/c/ ? Later on one could add
std/objc/, std/cxx/, etc as needed.
I was also wondering where these headers should be installed. GCC puts
them in its own private target-specific path, but we're not doing the
target-specific header stuff. Would $(prefix)/include/llvm/std/c/ be
acceptable, or what?
Thanks, that's a good site to know. You might be interested in
Rosen's book instead, which (having read the treeware version, I was
quite surprised to find out) is available online at oslbook . I knew of the short article, so
I didn't go hunting in the book, but the book does site U.S.C. fairly
often. It's not law-school rigorous, but I appreciate the grounding
it gave me in the concepts and issues. (Of course, you may also be
past that.)
I was wondering about that. How about std/c/ ? Later on one could add
std/objc/, std/cxx/, etc as needed.
Or nonstd/objc/
Speaking of which, is there any effort within Apple to standardize the
ObjC language? Would the clang project be a sane place to make such
an effort if not?
Where should this go in the clang tree? I don't think putting it in
clang/include/... makes sense, how about a top level stdincludes
directory or something?
I was wondering about that. How about std/c/ ? Later on one could add
std/objc/, std/cxx/, etc as needed.
Why not put them all together in one place? There are not a huge number of these total (maybe a dozen certainly less than two) so I don't think it's that big of a deal.
I was also wondering where these headers should be installed. GCC puts
them in its own private target-specific path, but we're not doing the
target-specific header stuff. Would $(prefix)/include/llvm/std/c/ be
acceptable, or what?
I don't really have any idea what clang's disk footprint should be when installed. I haven't thought that far ahead
However, wherever they go, it would be nice to be able to find them relative to the clang executable or something. On a related note, Anton K (over on llvmdev) is working on rewriting the llvmc compiler driver, to make it more sane. Once that is farther along, it should be easier to understand how we hook this together.
