On 12/30/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
> On 12/29/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
>> I think that for DK we have to deal with their patent and the license
>> for Implementing the Specification.
> [...]
> IANAL...

Nor do I, and if I understand ASF rules we cannot decide ourselves this
issue. There is a list of licenses that we are allowed to include.

those are all *copyright* licenses

the Yahoo! license is a *patent* license

THis is not listed, so we have to ask and wait for approval (right?).

not sure it's works quite like that

any committer can subscribe and ask questions on legal discuss. if
there's consensus, then that's probably good enough.

but this is not a simple question about copyright. you need to
prepared for the answer that: this is a policy question, not legal and
so is a matter for the board, the membership and for cliff (the legal
VP). going by past experience, it takes a lot of talking before any
consensus will emerge and even longer to frame a written policy :-/

Guillermo pointed out the DKIM specification but I don't know how it
relates to Domain Keys. I see that Apache SpamAssassing is listed
between implementations of the DKIM specification.

Maybe DKIM is something different and released under different
licensings (it is being proposed to ietf and probably cannot contain the
reciprocal patent issue)

possibly

or that SpamAssassin PMC already solved the
legal issues related to including DKIM.

or they are not aware of them

I only found this related message on the SA-dev list:
http://www.nabble.com/DKIM-IPR-details-updated-tf301386.html#a843058

the archive to search is legal-discuss

(i'll search my archives once james IMAP is fast enough to handle 2Gs
of email data ;-)

 > i think that a CLA or a software grant would be more appropriate in
 > this case but JIRA's the usual first port of call.

I agree, but I think it is really fast to at least attach to JIRA, and
this will give us the opportunity to review the code and understand how
much code it is.
I think, for example, we could also consider creating an ad-hoc project
(like jSPF).

+1

 > since my reading of the licenses indicates that it's safe to develop,
 > one possibility would be to offshore the development whilst the legal
 > issues are sorted out.
 >
 > googlecode's fast and uses subversion. svn:externals could be used to
 > easily create a composite source. discussions would be fine on this
 > list but the code would be offshore for the time being. i'd be happy
 > to help Tom apply appropriate headers and check that the statements
 > required by Yahoo! are in the right place.
 >
 > opinions?
 >
 > - robert

I don't like too much the use of svn:externals. Either way we'll have to
wait for the legal issues to be resolved in order to try to release.

sorry for not explaining fully: i meant to suggest starting a project
which imported the last james release and added the extra function not
vice-versa. those who want james+domain-keys and are happy with the
reciprocal licensing could obtain it from this new project.

once any legal issue were sorted out, the code could be imported using
a software grant

I thought that legally we could also include it in ASF repository while
we resolve the legal issues and that this is only blocking for releases
(like the svn:external).

depends on the issue

releases are particularly important. releases have greater liability,
visibility and are difficult to recall. so, it's *really* important
that no release goes out with legal issues.

but checking in code with known legal issues is a bad idea both for
the committer personally and for apache. apache cannot protect any
committer who commits code with legal issues. for copyright, that
easy: all code should be original code created for apache or should be
imported via the incubator and a software grant. for patents, it is
almost impossible for any developer to avoid unintentional
infringement. if you know that code is patent encumbered then that's a
different issue.

i would expect the pmc to exercise oversight. if informed later about
a legal issue, it's usually best to remove access to the code first
and work through the legalities second.

the major issue is that james would need to change from the AL2.0 to a
composite license (AL2.0+Yahoo!). not sure that the board would be
very happy about this.

Btw if you want to take care of this issue (both technical and legal) we
would really appreciate this.

i can't promise to take care of it but i'll try to help out...

Maybe writing to the SpamAssassing PMC and to Cliff Schmidt (cliffs at
ASF) is the fastest path: would you mind taking care of this?

i'll look into it...

BTW the right thing to do is post the question to legal-discuss rather
than cliff personally

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to