Csound 5.10 is now available at Sourceforge.  At present there are no
Windows builds or manual but they will be added asap.


==John ffitch
------------------------------------------------------------------------
API
    The major version is increased to 2; affected csound.so as well
    (see note below)

Bug Fixes
    diskin bug fixed
    outo was broken regarding channel 6
    pitchamdf had bugs
    zfilter_i was broken
    islider32bit14 never worked
    Other bugs fixed that have not been reported publicly.

New Opcodes and Gens
    GEN20 type 6 now has option to set variance
    sone GEN as a plugin to mimic gen13 in Music360 (this may change
    in detail)
    ephasor -- new opcode

Other
    Dither on output implemented; rectangular and triangular dither
    available in some cases
    Locale set to C numeric to avoid , versus . problems
    Using "a" as the MIDI port in PortMIDI listens on all

Internals
    Time now counted internally in samples, overcoming a longstanding
    bug with rounding of time to k-rate
    Many internal changes related to branch prediction.  Some opcodes
    are substantially quicker.


Note on API Change

The API version has been increased to 2.0.  This means that Csound
5.10 is incompatible with applications ("front ends", "clients", or
"hosts") that were built for Csound 5.08 and earlier and that use API
version 1.x. These applications will need to be rebuilt to work with
the current and future versions of Csound.  Csound front ends written
in interpreted languages such as Python or Java may continue to work
without modification.  It may also be possible to keep both an earlier
version of the Csound library and an API 2.0 version on the same
machine together so that new and old Csound-based applications can run
side-by-side.  These changes do not in any way affect the
compatibility of Csound orchestras and scores: all old documents
should continue to work as before.


------------------------------------------------------------------------------
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

The older I get the less I understnad computers.  I know I changed the
status to Active but it seems to have changed back.  Should be visible
now.

==John ff

> El 22/12/08 06:22 jpff escribió:
>> Csound 5.10 is now available at Sourceforge.  At present there are no
>> Windows builds or manual but they will be added asap.
>
> Ehm, I can't seem to find it. Where is it??
>
>
> Saludos,
> Felipe Sateler
>

I still don't see it.
Unless i am looking at the wrong page.

Panos



On Dec 22, 2008, at 7:55 PM, jpff@cs.bath.ac.uk wrote:

> The older I get the less I understnad computers.  I know I changed the
> status to Active but it seems to have changed back.  Should be visible
> now.
>
> ==John ff
>
>> El 22/12/08 06:22 jpff escribió:
>>> Csound 5.10 is now available at Sourceforge.  At present there are  
>>> no
>>> Windows builds or manual but they will be added asap.
>>
>> Ehm, I can't seem to find it. Where is it??
>>
>>
>> Saludos,
>> Felipe Sateler
>>
>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"

Try

https://sourceforge.net/project/showfiles.php?group_id=81968&package_id=120482&release_id=647554

>
> I still don't see it.
> Unless i am looking at the wrong page.
>
> Panos
>
>

Part of the confusion my arise from the fact that if you go to  
csounds.com and then click through "downloads" to OSX, you end up at http://csound.sourceforge.net/#MacOSX
which doesn't have/point to the latest builds.

Perhaps that page could point to
http://sourceforge.net/project/showfiles.php?group_id=81968
(as well)?


John, thanks for all your contributions to this project during 2008,

David
On 23/12/2008, at 5:53 AM, jpff@cs.bath.ac.uk wrote:

> Try
>
> https://sourceforge.net/project/showfiles.php?group_id=81968&package_id=120482&release_id=647554
>
>>
>> I still don't see it.
>> Unless i am looking at the wrong page.
>>
>> Panos
>>
>>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>

________________________________________________
David Worrall.
- Experimental Polymedia:	www.avatar.com.au
- Education for Financial Independence: www.mindthemarkets.com.au
Australian research affiliations:
- Capital Markets Cooperative Research Centre: www.cmcrc.com
- Sonic Communications Research Group:	creative.canberra.edu.au/scrg

Yes, the front page on Sourceforge always takes a day or two (or sometimes
seven) to be updated after a release.  The reason is that I am usually
trying to prepare some of the release packages too and I don't get to the
web page until afterwards.  (I also am never sure what the packages will be
called in advance and I don't like linking to files that are not there yet
-- we are still missing quite a few files for this release at this time).

I recommended that Csounds.com link to
http://csound.sourceforge.net/#Downloads some time ago and that seemed like
a good idea at the time because that page (hopefully) answers the question
of "Which one should I download?"  However, it must be maintained
separately, so it might not be a bad idea to include the link you suggest in
addition to the one that is there.  Another solution might be to include a
link to the new file release page in the announcement email ...

Sorry for the confusion.

Anthony Kozar
mailing-lists-1001 AT anthonykozar DOT net
http://anthonykozar.net/

DavidW wrote on 12/22/08 2:41 PM:

> Part of the confusion my arise from the fact that if you go to
> csounds.com and then click through "downloads" to OSX, you end up at
> http://csound.sourceforge.net/#MacOSX
> which doesn't have/point to the latest builds.
> 
> Perhaps that page could point to
> http://sourceforge.net/project/showfiles.php?group_id=81968
> (as well)?
> 
> 
> John, thanks for all your contributions to this project during 2008,
> 
> David
> On 23/12/2008, at 5:53 AM, jpff@cs.bath.ac.uk wrote:
> 
>> Try
>> 
>> https://sourceforge.net/project/showfiles.php?group_id=81968&package_id=12048
>> 2&release_id=647554

No worries Anthony - thanks for  your work on OSX related.
I haven't been following the latest to-and-fro re python + your scons- 
ing.
Can you say whether the latest sources are likely to compile the Lib  
on OSX10.5 that is accessible by mac python 2.5?
David

On 23/12/2008, at 8:49 AM, Anthony Kozar wrote:

> Yes, the front page on Sourceforge always takes a day or two (or  
> sometimes
> seven) to be updated after a release.  The reason is that I am usually
> trying to prepare some of the release packages too and I don't get  
> to the
> web page until afterwards.  (I also am never sure what the packages  
> will be
> called in advance and I don't like linking to files that are not  
> there yet
> -- we are still missing quite a few files for this release at this  
> time).
>
> I recommended that Csounds.com link to
> http://csound.sourceforge.net/#Downloads some time ago and that  
> seemed like
> a good idea at the time because that page (hopefully) answers the  
> question
> of "Which one should I download?"  However, it must be maintained
> separately, so it might not be a bad idea to include the link you  
> suggest in
> addition to the one that is there.  Another solution might be to  
> include a
> link to the new file release page in the announcement email ...
>
> Sorry for the confusion.
>
> Anthony Kozar
> mailing-lists-1001 AT anthonykozar DOT net
> http://anthonykozar.net/
>
> DavidW wrote on 12/22/08 2:41 PM:
>
>> Part of the confusion my arise from the fact that if you go to
>> csounds.com and then click through "downloads" to OSX, you end up at
>> http://csound.sourceforge.net/#MacOSX
>> which doesn't have/point to the latest builds.
>>
>> Perhaps that page could point to
>> http://sourceforge.net/project/showfiles.php?group_id=81968
>> (as well)?
>>
>>
>> John, thanks for all your contributions to this project during 2008,
>>
>> David
>> On 23/12/2008, at 5:53 AM, jpff@cs.bath.ac.uk wrote:
>>
>>> Try
>>>
>>> https://sourceforge.net/project/showfiles.php?group_id=81968&package_id=12048
>>> 2&release_id=647554
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>

________________________________________________
David Worrall.
- Experimental Polymedia:	www.avatar.com.au
- Education for Financial Independence: www.mindthemarkets.com.au
Australian research affiliations:
- Capital Markets Cooperative Research Centre: www.cmcrc.com
- Sonic Communications Research Group:	creative.canberra.edu.au/scrg
- MARCS Auditory Laboratories: marcs.uws.edu.au

I think the latest sources should build a functional Python interface
library on OS X 10.5 with the Apple-supplied Python 2.5.  This is working
for me just fine and I have even tested it a little.

If you meant a user-installed MacPython 2.5 then that is possibly a
different issue as SConstruct currently assumes that if you are building
Csound on 10.5 with Python 2.5 that you are using the Apple Python.  A
different version of MacPython (say 2.6) would likely work fine.

Anthony

DavidW wrote on 12/22/08 5:05 PM:

> No worries Anthony - thanks for  your work on OSX related.
> I haven't been following the latest to-and-fro re python + your scons-
> ing.
> Can you say whether the latest sources are likely to compile the Lib
> on OSX10.5 that is accessible by mac python 2.5?
> David

jpff wrote on 12/22/08 4:22 AM:

> Csound 5.10 is now available at Sourceforge.  At present there are no
> Windows builds or manual but they will be added asap.

As mentioned on the other list, I am still working on putting together files
for OS X 10.5.  I am finding it to be more work than expected for a number
of reasons.  In fact, I do not think that I will be able to complete it
tomorrow now either.  And since I will be visiting with family for the
holidays from the 24th until after the first of the year, I don't think I
will be able to finish until after then.  Apologies for the delays.

I do have a few questions about what to include, etc.  As Christmas is
nearly upon us and I will not be dealing with these issues until after Jan
1st, there is no rush in replying.

First, an easy question:  which of the gettext database files need to be
installed (*.po ?, *.mo ?) and where should they be installed?  Do they need
to maintain the directory structure that is in CVS with subdirectories for
each language?

Second, I got bogged down today trying to ensure that my package contains
proper copyright notices and license files for Csound and all of the
included third-party libraries.  Nearly all of Csound's dependencies have
licenses that require inclusion of their copyright notices and terms within
the documentation that is included with any distribution of those libraries
whether in binary or source form.  So, I am putting together a long ReadMe
that duplicates these notices and a directory containing copies of all of
the licenses to include in the installer and alongside the Csound library
once installed.  Does this sound reasonable?  (I did this with the OS 9
distributions but there were a lot fewer libraries for it).

Third, I have compiled all of Csound's dependencies from source code and
plan to include many of them in the Csound distribution for OS X 10.5 (as I
believe Victor does) to avoid the problems of missing libraries for end
users.  Currently, this includes libsndfile, portaudio, portmidi, liblo,
libfltk, fluidsynth, libintl, and libpng as dynamic libraries.  Four of
these (libsndfile, libfltk, fluidsynth, and libintl) are under the LGPL and
liblo is under the GPL with an exception for Csound.  Since I include binary
libraries of these in the package, their licenses will require us to also
make the source code available for download from "the same place".

Where should I upload these source packages?  I will likely use the same
versions of the libraries for many different Csound releases, so it does not
make sense to keep duplicating these source archives in every file release
of Csound that we make on Sourceforge.  Third-party source archives could go
in a "file release package" other than "csound5" (I mean this in the
Sourceforge sense).  They might go in project web space too but I am not
sure that that is acceptable use under Sourceforge policies.

Finally, while we are not required by the licenses to make source archives
available for portaudio, portmidi, libpng, STK, Lua, or Boost, it seems in
the spirit of open source software to also duplicate these along side the
other third-party dependencies.  (I'm not sure whether it is required by
Sourceforge's "source code availability" policy either).  Additionally, it
would make life easier for Csound users who want to compile Csound
themselves.  Does anyone have any objections to this?

I can see two issues with it myself.  First, all together these libraries
total about 60 MB even in compressed form (60+ percent of which is Boost and
gettext).  At a minimum, this suggests that each library should be uploaded
separately, i.e. not all in one giant archive.  Second, I think each of us
is using a different set of library versions.  So we might need to upload a
source archive for each library for each developer who is including that
library in compiled form within his Csound packages.  This will further
multiply the number of non-Csound packages being uploaded and may obviate
the need for some kind of organization (e.g. documenting which version of
libsndfile was used in each Csound package, etc.).
 
As usual, my email has gone on a lot longer than anticipated.  Please share
your thoughts and comments on these issues over the next couple of weeks.
(Comments from library developers like Erik who are on this list are
especially welcome).  Thanks!

Happy Holidays to all Csound developers and Csound users!!
 
Anthony Kozar
mailing-lists-1001 AT anthonykozar DOT net
http://anthonykozar.net/

Very sorry -- I meant to send this to the developer's list!  Please direct
any replies to that list.  Thanks.

Anthony

Anthony Kozar wrote on 12/23/08 3:31 AM:

> As mentioned on the other list, I am still working on putting together files
> for OS X 10.5.

To all Csound developers,

Felipe, thanks very much for your reply.  My own thoughts are below.  I
apologize for the length of this exposition but I have had numerous
discussions regarding licensing issues surrounding Csound in the past and I
want to fully present the case for the actions that I am advocating so that
I hopefully do not have to have this discussion again.  (I reordered the
topics to put the longest one at the end).

Thanks.

Felipe Sateler wrote on 12/30/08 1:28 PM:

> El 23/12/08 05:31 Anthony Kozar escribió:
>> First, an easy question:  which of the gettext database files need to be
>> installed (*.po ?, *.mo ?) and where should they be installed?  Do they
>> need to maintain the directory structure that is in CVS with subdirectories
>> for each language?
> 
> This depends on what is written in Top/getstring.c. There has to be a call to
> bindtextdomain pointing to where you install them. Perhaps it should be
> defined by a macro in SConstruct?

The current code for init_getstring() appears to do nothing.  Does it even
make sense to install the localized strings under these circumstances?
(Sorry, I don't have any idea how gettext works).

void init_getstring(void)
{
    const char  *s;

/*     s = csoundGetEnv(NULL, "CS_LANG"); */
/*     if (s == NULL)              /\* Default locale *\/ */
/*       setlocale (LC_MESSAGES, ""); */
/*     else  */
/*       setlocale (LC_MESSAGES, s);    /\* Set to particular value *\/ */
/*    textdomain("csound5"); */  /* This is not needed when using dgettext
*/
    /* bind_textdomain_codeset("csound5", "UTF-8"); */
#ifdef never
    /* This is experimental; where should these be?? */
    bindtextdomain("csound5", "/home/jpff/Sourceforge/csound5/po");
#endif
}

>> Four of
>> these (libsndfile, libfltk, fluidsynth, and libintl) are under the LGPL and
>> liblo is under the GPL with an exception for Csound.  Since I include
>> binary libraries of these in the package, their licenses will require us to
>> also make the source code available for download from "the same place".
>> 
>> Where should I upload these source packages?

> I think that a separate file release package is better. Ideally, every
> developer would use the same versions of the libraries, but it is probably
> more trouble than it's worth. I also wonder if libraries hosted on
> sourceforge would still need to be copied in csound's space, or a mere link
> to their own package release suffices.

This last bit is a very good question as a number of the libraries have
source code hosted by Sourceforge (PortMidi, liblo, Boost, libpng, Loris,
Pd, and DSSI).  I will inquire with someone at Sourceforge as to what they
think about this issue.  Perhaps we can just link to some of the other
projects' file downloads (especially Boost since its huge!).

Of the libraries not on Sourceforge, we will need to provide source packages
at least for any LGPL and GPL libraries for which we distribute binaries.
We [everyone in general] have had this discussion before and I recall
leaving it hanging with a question about whether the availability of the
source code on other sites relieves us of the need to post it ourselves.
Section 4 of the LGPL answers this question:

    "4. You may copy and distribute the Library (or a portion or derivative
    of it, under Section 2) in object code or executable form under the
    terms of Sections 1 and 2 above provided that you accompany it with the
    complete corresponding machine-readable source code, which must be
    distributed under the terms of Sections 1 and 2 above on a medium
    customarily used for software interchange.

    "If distribution of object code is made by offering access to copy from
    a designated place, then offering equivalent access to copy the source
    code from the same place satisfies the requirement to distribute the
    source code, even though third parties are not compelled to copy the
    source along with the object code."

Access "from the same place" is generally interpreted as meaning the same
server since you cannot guarantee that the source code will remain available
on someone else's site.  (Note that (L)GPL v.3 apparently have different
rules in this regard than (L)GPL v.2).

>> Finally, while we are not required by the licenses to make source archives
>> available for portaudio, portmidi, libpng, STK, Lua, or Boost, it seems in
>> the spirit of open source software to also duplicate these along side the
>> other third-party dependencies.  (I'm not sure whether it is required by
>> Sourceforge's "source code availability" policy either). [...]
>> Does anyone have any objections to this?

> A possibility is that every distributor uploads his version of the libraries
> to a new "csound deps" release package (with the version encoded in the name
> to not overwrite other's). Then for each package a list of the versions used
> would be provided along with a notice of where to find these, so any
> interested party could easily retrieve the same versions.

This is a good idea.  For any source code packages that we make available,
it is important that they be the exact version that was used to compile a
particular Csound component, whether modified or not.  If a given package is
unmodified, then I can download all appropriate versions to upload them to
Sourceforge as necessary.  I have noticed though that a couple of projects
do not seem to keep older versions around (STK for one).  Any modified
libraries would have to be zipped up by the Csound developer who modified
them.  I will also ask the Sourceforge folks about whether we need to upload
source code for libraries under MIT or BSD-style licenses.

>> Nearly all of Csound's dependencies have
>> licenses that require inclusion of their copyright notices and terms within
>> the documentation that is included with any distribution of those libraries
>> whether in binary or source form.  So, I am putting together a long ReadMe
>> that duplicates these notices [...]

> It does. We in Debian work around this problem by each package shipping it's
> own copyright notice. Since you are bundling all of them, it seems a nice
> thing to do to include all copyright statements (although most aren't
> required).

I will go ahead with including all of these notices then.  I will probably
add these files to CVS to make it easier for other packagers to include them
also.

Just to be clear though, I am under the impression that duplicating most of
these notices and licenses is required.  For libsndfile, FLTK, and other
LGPL libraries, section 4 of the LGPL would apply to distributing a binary
of those libraries.  Section 4 reads in part

    "You may copy and distribute the Library (or a portion or derivative of
    it, under Section 2) in object code or executable form under the terms
    of Sections 1 and 2 above"

So, I interpret this as meaning you have to follow sections 1 & 2 in
addition to section 4 when distributing one of these libraries with Csound.
Section 1 says in part

    "You may copy and distribute verbatim copies of the Library's complete
    source code as you receive it, in any medium, provided that you
    conspicuously and appropriately publish on each copy an appropriate
    copyright notice and disclaimer of warranty; keep intact all the notices
    that refer to this License and to the absence of any warranty; and
    distribute a copy of this License along with the Library."

Section 6 would apply to distributing any program using an LGPL library
(such as Csound) and it requires that

    "You must give prominent notice with each copy of the work that the
     Library is used in it and that the Library and its use are covered by
     this License. You must supply a copy of this License."

So, I interpret all of this to mean that we must accompany binary copies of
LGPL libraries that we distribute alongside Csound with their copyright
notices, warranty disclaimers, references to the LGPL license, and a copy of
the LGPL license.  And I interpret it to mean that we must accompany any
copy of Csound itself with a notice stating that Csound uses those libraries
and that they are also covered under the LGPL.  liblo will have similar
requirements since it is under the GPL.

The PortAudio, PortMidi, Lua and STK licenses are all essentially the same.
They might be a little ambiguous as they state:

    "The above copyright notice and this permission notice shall be included
     in all copies or substantial portions of the Software."

Whether or not a binary library derived from the source code constitutes "a
copy of the Software" would be significant.  It seems safest to just include
the copyright notice and license.

Pd and SWIG are both under a BSD-style license.  The interface wrappers
might be considered derivative works of SWIG since the auto-generated output
includes portions of the SWIG source code.  csoundapi~ only needs the Pd
main header file to compile.  Since these are border-line cases,  the
following paragraph of the BSD license may or may not apply:

    "2. Redistributions in binary form must reproduce the above
    copyright notice, this list of conditions and the following
    disclaimer in the documentation and/or other materials provided
    with the distribution."

The Python wrapper and Python opcodes might be considered derivative works
of Python and the Python license says in part:

   "PSF hereby grants Licensee a nonexclusive, royalty-free, world-wide
   license to reproduce, analyze, test, perform and/or display publicly,
   prepare derivative works, distribute, and otherwise use Python 2.4 alone
   or in any derivative version, provided, however, that PSF's License
   Agreement and PSF's notice of copyright, i.e., "Copyright (c) 2001, 2002,
   2003, 2004 Python Software Foundation; All Rights Reserved" are retained
   in Python 2.4 alone or in any derivative version prepared by Licensee."

The Boost license is an exception as it clearly exempts binary-only
distributions:

    "The copyright notices in the Software and this entire statement,
    including the above license grant, this restriction and the following
    disclaimer, must be included in all copies of the Software, in whole or
    in part, and all derivative works of the Software, unless such copies or
    derivative works are solely in the form of machine-executable object
    code generated by a source language processor."

The libpng license also does not require duplication of the copyright notice
for binary distributions.  But it does say "If you use this source code in a
product, acknowledgment is not required but would be appreciated."

In conclusion, I see a need to reproduce the copyright and/or license
information for every Csound dependency except Boost and libpng.  But it
would not hurt to include those as well.

Thanks for reading.

Anthony Kozar
mailing-lists-1001 AT anthonykozar DOT net
http://anthonykozar.net/


------------------------------------------------------------------------------
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Thanks, Michael, for sharing your thoughts.  I think it is important that we
all try to come to a consensus about what is required of us by the licenses
of the software that we are distributing.  As is probably obvious, I
currently have concerns that we are not meeting our obligations and these
concerns are delaying my completion of the release packages for 5.10.

I would like to open a Sourceforge Support Request to have them review our
situation and make recommendations concerning what is necessary to comply
with the third-party licenses.  Would that be alright?

More comments below if you enjoy the nitty-gritty details ...

Anthony


Michael Gogins wrote on 1/4/09 10:35 AM:

> I think these recommendations for license compliance go far beyond
> what is legally and morally required,

I disagree.  I have spent many hours (days really) over the past few years
reading these licenses and various commentaries about them on the net (such
as the FSF's GPL/LGPL FAQ page) and I think we are probably not yet in full
compliance with some of them.

> go far beyond what other recognized open source projects provide,

I think this varies a lot.  There are many Linux distros that are a very
conscientious about providing matching source code packages for every binary
package that they distribute.  But I have seen projects too, even on
Sourceforge, where source code is not made available when I think that it
should be.  (e.g. The JackOSX project on SF appears not to make any source
code releases).  Surely, since the practices of others are inconsistent, we
cannot rely on those examples to know what our obligations are.

> would impose an unnecessary burden on Csound developers,

I am concerned about this too because of the large number of dependencies of
a "full" Csound distribution.  For this reason I am willing to take on the
burdens of uploading third-party source packages if that becomes necessary
and documenting which packages correspond to which versions of Csound.  This
will of course require the cooperation of the rest of the team: keeping me
informed of which versions of third-party libraries that each of you are
using so that I can download and re-upload them and providing me with any
modifications that you make to sources or build scripts (which will
hopefully be minimal or zilch).

> and definitely should not be adopted.
> 
> The clear intention of the license is to enable a user of our binaries
> to obtain sources from the same location and recompile or modify those
> binaries. That is currently quite possible, and people have done
> exactly that in the past.

When you say "the license", I am not sure whether you are thinking of only
Csound's license or of the dependencies' licenses as well.  I don't think
that Csound's license requires us to make source code for dependencies
available if they are dynamically linked.  However, I hope that it is clear
that the issue here is not compliance with Csound's license but with the
licenses of those third-party libraries that we are distributing with the
Mac OS X and (I assume) Windows Csound packages.  Also, it is unclear to me
whether or not Sourceforge's "Source Code Availability" policy applies to
third-party binaries that we include for the convenience of our users.
 
> I am sure that most open source or free software people recognize
> SourceForge as "one location". I think reading "the same place" as
> "the same server" is excessively legalistic.

Regarding all of SF as "the same place" is fine with me and I will gladly
accept confirmation from SF that we need do nothing or that we need merely
link to other projects on SF in order to satisfy their license requirements.
But what about the libraries that are not on Sourceforge (particularly the
LGPL ones such as libsndfile, fluidsynth, gettext, etc.)?

Regarding the interpretation of the phrase "offering equivalent access to
copy the source code from the same place" in the LGPL, the Free Software
Foundation previously had this FAQ answer on their website (it refers to the
last paragraph of section 3 of the GPL v2 which contains the same wording as
section 4 of version 2.1 of the LGPL):



The FSF appears to have reconsidered this for (L)GPL v3 but several of
Csound's dependencies are currently under LGPL v2 or v2.1.  See this URL for
the v3 interpretation:



> My evidence for this is that nobody complains about it
> with other projects. I've done enough looking through various forums
> and news groups to resolve other issues, that I would have run into
> such complaints if they were at all common.

I generally refrain from complaining about the laxness of other people's
projects because it is time-consuming and "not my place."  But as a
contributor to Csound -- particularly as someone who helps builds packages
for distribution -- I feel a need to be more conscientious.

> It is true that there could be slight differences in sources, and some
> debugging or adjustment might be required to get a working build. But
> I am certain this does not violate the terms of the license.

LGPL v2.x says that the "corresponding source code" must be made available.
See this FAQ item:



> I am completely committed to the open source nature of Csound, and to
> obeying all legal and moral requirements of the license. I was one of
> those who lobbied for the LGPL license for Csound, and I agreed with
> and implemented the decision to remove VST sources and binaries from
> SourceForge. But I think these suggestions about archiving sources for
> third party libraries are unreasonable and unneccesary.

I know that you are committed to Csound and keeping it open source and I
respect and appreciate your contributions and your willingness to remove the
VST materials.  I am committed to the open source philosophy in my
development work too and I am trying to ensure that we are meeting all of
our obligations to the third-party developers who have indirectly made the
modern Csound system possible.  They deserve recognition and credit for
their work and I think that we may be neglecting to even mention that we are
using some of their libraries in the documentation of our Csound
distributions.  By fully complying with each of the licenses, I think we
will achieve all of these goals.

> Csound has become a rather complex project. Keeping it usable and
> making it possible to continue developing it require eliminating
> unnecessary complications -- so that desirable complications will
> remain possible.

I agree -- Csound is complex and we must keep it usable!  I do not want OS X
users to have to find and install libraries from other sites merely to be
able to run Csound.  I hope that we can keep the burden on us as developers
to a minimum.

Best regards,

Anthony Kozar
mailing-lists-1001 AT anthonykozar DOT net
http://anthonykozar.net/


------------------------------------------------------------------------------
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Michael Gogins wrote on 1/5/09 3:29 PM:

> About opening a support request for reviewing our license policies, I
> think that is a good idea.

Great.  If no one else is opposed, I will draft a letter and send it to all
developers for review before submitting it to SF.

> I have reviewed at the third party source code and license situation
> at Open Sound World, Pure Data, SuperCollider, CLAM, and CSL, which
> are some of the major open source audio software projects comparable
> in some sense with Csound in scope:

> SuperCollider provides libsndfile sources. I do not know if
> SuperCollider has additional third party dependencies.

I only see libsndfile binaries in the source download for SC.  The Windows
build instructions also describe using portaudio, portmidi, fftw3, and the
ASIO SDK (!) which are presumably compiled into SC binaries but no source
code is included that I could find.  Anyways ...

Anthony Kozar
mailing-lists-1001 AT anthonykozar DOT net
http://anthonykozar.net/


------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

It never occurred to me that we might need to provide source packages for
the manual either.  I've always assumed the source availability policy
applied to software only.  I will add a question about this to the SF
Support Request.

Thanks.

Anthony

Andres Cabrera wrote on 1/6/09 9:55 AM:

> Hi,
> 
> On Tue, Jan 6, 2009 at 9:43 AM, Felipe Sateler  wrote:
> 
>> Sourceforge is rather lax in enforcing its requirements, probably because
>> they
>> have too manyh projects to monitor all of them. For example, csound itself is
>> failing to comply with the manual: html, pdf and chm versions are provided
>> without a corresponding source release. Sourceforge policy requires source
>> releases, and explicitly mentions that cvs is not an acceptable alternative.
>> I think that providing the sources is required for compliance.
>> 
> I was not aware of this. Will do src packages from now on.


------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Felipe Sateler wrote on 1/6/09 9:43 AM:

> The old (v2) GPL FAQ says:
> 
>> The GPL says you must offer access to copy the source code "from the same
>> place"; that is, next to the binaries. However, if you make arrangements
>> with another site to keep the necessary source code available, and put a
>> link or cross-reference to the source code next to the binaries, we think
>> that qualifies as "from the same place".
> 
> So I think it is acceptable to just build a page that points to the libraries
> pages, where the source code is available, indicating what versions were
> used. Of course, this would only work for libraries where the csound devs
> have not modified the source code.

Possibly.  See below.

> These would have to be uploaded to csound
> space. Also, for projects where we can't be reasonably sure the source code
> will remain available, it would be good to have the source code too (eg, the
> STK case, where old releases are not available).

Yes.  The old STK downloads might still be there but they are not linked to.
The same is true for libsndfile.  When I go to Erik's site, I can find no
links to old versions, but if I guess at the file names, I can usually
download them.  I personally would not feel that linking to these "hidden"
downloads is reliable enough to satisfy the LGPL requirements -- the owner
of the other site might decide to "clean out" their download directory at
any time.

> I believe we can at least
> assume that sourceforge-hosted projects will keep the source code available
> (because of the policy requirements of sourceforge and that you can't really
> delete projects on sourceforge).

Yes and no.  While SF almost never deletes files once they become available,
they do allow project admins to hide old file releases.  This effectively
removes them for anyone who does not know the exact filename of a release.
(You used to be able to browse the download directory for a SF project, but
I cannot see how to do so anymore).  So, if we link directly to a source
code package of another project, that link should continue to work, but if
we only link to the project page, people may be unable to find the source
code later.

>> Also, it is unclear to me
>> whether or not Sourceforge's "Source Code Availability" policy applies to
>> third-party binaries that we include for the convenience of our users.
> 
> What sourceforge requires is on top of what the licenses require. The licenses
> explicitly require distribution of source code (or a way to acquire them).

So, even if we can make arrangements with other internet sites to maintain
the source packages that we would link to, that might not meet SF's
policies.
 
> As per the same FAQ:
> 
>> To make a reasonable effort to comply, you need to make a positive
>> arrangement with the other site, and thus ensure that the source will be
>> available there for as long as you keep the binaries available.
> 
> So I think a mere confirmation from those projects that source code will be
> available as long as we distribute binaries (that is, forever :)).

I had not seriously considered trying to make these sorts of arrangements.
But if someone on the team wants to do so, then that could be an option too
(depending on SF's response).
 
> Also, that other projects are not complying doesn't mean that compliance is
> not necessary. It just means the requirements are not being currently
> enforced.

Another question -- which I am not sure I would want to ask -- is how far
back should we try to correct this situation?  It seems reasonable to me, if
not strictly according to the "letter of the law", to make an effort to
comply with license and policy requirements for the current and future
releases.  But to go back and try to rectify the situation for all previous
Csound 5 releases would be a real chore and a "waste" of developer time.
This would be in keeping with past changes to our distribution policies.
(e.g. We stopped distributing CsoundVST but did not remove old downloads).

Anthony Kozar
mailing-lists-1001 AT anthonykozar DOT net
http://anthonykozar.net/


------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net