Re: FFI licensing [Was: Hello-C mailing list?]





Kevin Rosenberg wrote:
On 2005-06-29, Kenny Tilton <ktilton@xxxxxxxxxx> wrote:

[...]
Who knows where this will end up? All projects have friendly licenses and are free to borrow from each other. Hello-C by name may cease to exist or may end up with its own project. Meanwhile the CFFI developer has responded positively to Hello-C extending his work, so the source will be in a branch of the CFFI CVS tree for now.


Hope that is not too confusing. :)


Well, sorry to add to the confusion, but the licensing issue is not
clear, and that is my fault. I originally licensed UFFI under Franz's
Lesser Lisp GPL (LLGPL). However, I subsequently changed the license
to the more liberal BSD license. I updated the LICENSE file with this
information, but neglected to update license header in the individual
source files. I will rectify this discordance.

My inclination is complete the intended transition by change the
license test in the source files to a BSD license. However, that would
prevent UFFI from participating in the "borrowing" process you
mentioned.

IANAL, but:

(1) I do not see why BSD interferes with borrowing. I just read it again, nope, do not see a problem. The only constraint is preserving the copyright notice -- no problem there. If you mean reconciling the licenses, shucks, looks like we have BSD-MIT-MIT. Should not be too hard to sort out.

(2) When I forked from UFFI, I think you were LLGPL. Not sure because all I have is the source and I gather those got out of synch. I guess we could reconstruct when the fork took place one way or another. This matters because your change to BSD is not retroactive. Of course, any new development would fall under the BSD, so sufficient added-value makes the LLGPL code base unpalatable. Aside from that, the LLGPL-based release lives on under that license.


How would you feel about following the transition to a BSD
license for your UFFI fork?

I have no problem with BSD. I went with MIT on my stuff. CFFI looks like MIT.



PS Congratulations on the funding for lispnyc's summer of code

Thanks. And, as I said long ago when UFFI got me across what seemed like a vast barrier to my first C library, thanks to you for the uber-contrib that is UFFI. We will try to live up to that high standard with Fetter and "UFFI, The Next Generation" (CFFI or Hello-C).


--
Kenny

Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film

"If you plan to enter text which our system might consider to be obscene, check here to certify that you are old enough to hear the resulting output." -- Bell Labs text-to-speech interactive Web page

.



Relevant Pages

  • Re: Edwins prediction from one year ago.
    ... the idea the Mayor said Apple is going out of business. ... I've now shown that AT&T charged hefty license fees to use the AT&T code ... And Bill Joy never charge himself a licensing fee, ... BSD didn't belong to Bill Joy. ...
    (comp.sys.mac.advocacy)
  • Re: Some iPhone buyers were screwed double...
    ... store credit from Apple. ... "Sun paid a license fee to the University of California. ... Every version of BSD prior to that required an AT&T license. ...
    (comp.sys.mac.advocacy)
  • Re: Some iPhone buyers were screwed double...
    ... Will you never check your facts? ... Sun purchased and OS and then developed it. ... "Sun paid a license fee to the University of California. ... Every version of BSD prior to that required an AT&T license. ...
    (comp.sys.mac.advocacy)
  • Re: Some iPhone buyers were screwed double...
    ... store credit from Apple. ... Sun purchased and OS and then developed it. ... "Sun paid a license fee to the University of California. ... Every version of BSD prior to that required an AT&T license. ...
    (comp.sys.mac.advocacy)
  • Re: When will he admit he is wrong?
    ... California (who owned BSD, not Bill Joy), but they also needed one from ... BSD contained AT&T code and required a license from AT&T as ... "The BSD tapes contained AT&T source code and thus required a UNIX ... "The Berkeley copyright poses no restrictions on private or commercial ...
    (comp.sys.mac.advocacy)