Thread: RE: [Plib-devel] Licensing for Console Applications.

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

I cannot really make any comment other than the license
for plib (specifically sg and ssg) is one major reason
we don't use (and therefore contribute to) plib.  As
a rule it is very difficult to foresee what exact 
interpretation of [L]GPL we can expect even if we (or
our lawyers) feel we are adhering to the letter of the
license.  Adhering to the letter is usually not good
enough (as you allude to) and not being able to guarantee
that we can adhere to the spirit given all of the
varying levels of ideology involved with [L]GPL means
that we really cannot even consider using something like
PLIB (so we don't end up looking like we are "stealing"
from the community).  We don't want to end up a(nother)
Slashdot poster case for "big bad evil commercial company"
beating down the [L]GPL.

I know other people use PLIB in apps, but it has been 
our general approach to be much more skeptical of using
[L]GPL'd codes in our tools and applications.  However,
we do use and contribute to other open source (not necessarily
OpenSource(tm)) tools and libraries like ImageMagick, 
Lua, etc...

I do keep up with PLIB and mess around with in my spare
time.  I think it is a useful library and if we could use it
at work, I would think that we would have at least one developer
pretty much devoted to contributing to PLIB (or coordinating
contributions).  However, as it stands we are no longer really 
looking at PLIB because of the license.

I can't make a recommendation as to what license to use, but
I would think (thinking out loud) that restricting the new
license to consoles is not the way to go.  Proprietary APIs
exist on platforms other than consoles (and Windows), there 
are other embedded applications, and it would be difficult
to define "console" well enough to keep lawyers at bay. 

NOTE NOTE NOTE: A pretty much standard disclaimer applies.  We
have evaluated plib internally for a short time but do not use
it at DA.  I am not an official spokesman for Digital Anvil
and probably never will be, however I am one of the people that 
would be responsible for deciding things like this so I feel I 
can speak about with some amount of truth.  Having said all of
that this email contains forward-looking statements, blah blah
blah.

Paul

> -----Original Message-----
> From: Steve Baker [mailto:sjb...@ai...]
> Sent: Tuesday, June 13, 2000 12:28 AM
> To: PLIB-devel
> Subject: [Plib-devel] Licensing for Console Applications.
> 
> 
> 
> In recent months, I've had several requests from people who are
> writing applications for Games Consoles to change the PLIB
> license from L-GPL to (say) the Xfree license.
> 
> Normally, I'd just turn license change requests down flat - but
> in the case of a games console, the LGPL license is truly impossible
> for these people to adhere to.
> 
> LGPL requires two things that console software can't meet:
> 
> 1) The requirement that the end-user be able to re-link
>    the application against a newer version of the library
>    at some unspecified time in the future.
> 
> 2) The requirement that all changes and enhancements to the
>    library be offered back into the public domain.
> 
> Clearly (1) is impossible since there are no compilers or
> linkers that the end user can get a hold of - and in any
> case, the media space is limited - and very likely, companies
> like Sony and Nintendo would take a dim view of releasing
> the binaries of their libraries to the big wide world.
> 
> It *might* be possible to meet the letter of the license in
> this case - but the spirit behind LGPL is really meaningless
> in a console situation.
> 
> Requirement (2) is also impossible in many cases because
> the underlying operating system won't be running standard
> graphic library API's (although N64 has a kind of OpenGL
> macro library - and I'm told that there is an OpenGL-like
> API for PS2).
> 
> That means that modifications *MUST* be made to PLIB in
> order for it to work with console systems...but those
> modifications are *useless* for general purpose computers
> and will almost certainly contain calls to API's that
> are only released under NDA.
> 
> So, the question is:
> 
>  * Should we change PLIB's license to help out these people?
> 
> There are some subtle issues here:
> 
> 1) PLIB has had contributions from many people - all of whom
>    have to agree. (Well - at the very least, we have to make
>    an effort to contact those people to get permission).
> 
> 2) Do we want to change the license *only* for console apps
>    or should we simply give up and go to something like Xfree's
>    license for everything?  (I'm not really keen on that idea)
> 
> 3) Is there a better choice than Xfree's license?  I'd quite
>    like to retain some kind of a clause that says that users
>    of PLIB are required to offer enhancements back to the
>    OpenSource community *UNLESS* those changes are solely for
>    the purpose of porting to an inherently closed architecture
>    machine like an embedded processor or a game console.
> 
>    If a console application writer were to make (say) a nicer
>    PUI widget, I'd want that code to return to the public
>    version of PUI - but if he merely changed some OpenGL code
>    to plug into a proprietary rendering API, I could care less
>    about getting that change back...it would be more trouble
>    that it's worth to 99% of PLIB users.
> 
> So - what does everyone think?   I'm open to suggestions -
> especially from people who've actually contributed code.
> 
> BTW: Some people are using the very earliest versions
> of the PLIB component libraries. These were posted to
> my web site without any kind of formal license before
> I grouped them all together to form the PLIB package -
> which was when I placed it all under LGPL.
> 
> There have been at least three requests from various
> console/embedded applications writers - and so far I've
> had to disappoint them.
> 
> -- 
> Steve Baker                  http://web2.airmail.net/sjbaker1
> sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
> sj...@ht...      (work)
> 
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 