On Jan 27, 2008 10:44 PM, Daniel Schmitt
<myloginislongerthanyours(a)gmail.com> wrote:
>
> On Jan 27, 2008 9:59 PM, Marek <mlf.conv(a)gmail.com> wrote:
>
>
>
> >
> >
> >
> > But let's have a look at these statements from the GPL:
> >
> > "...if you distribute copies of such a program, whether gratis or for a fee..."
> > "... You may charge a fee for the physical act of transferring a copy..."
> >
> > 1. Basically "You may charge a fee for the physical act of transferring a copy..." translates to "You may *only* charge a fee for the physical act of transferring a copy..." as the GPL doesn't state that you may charge for the computer program or any other services related to it other than distribution and providing warranty. Otherwise such statement made by the GPL would be *invalid*.
>
>
> This interpretation is at odds with the FSF's own interpretation. Check http://www.fsf.org/licensing/licenses/gpl-faq.html#DoesTheGPLAllowMoney to get it directly from the gnu's mouth, so to speak.
Show me one example in GPLv2 which would tell me that i can charge for
*a copy*, not for *distributing a copy*(!).
The FSF clearly uses wrong wording (see my FedEx example) because they
are always talking about encouraging *distribution*
http://www.gnu.org/philosophy/selling.html:
Quote:
"--> Selling <-- Free Software
Many people believe that the spirit of the GNU project is that you
should not charge *money for distributing copies* of software, or that
you should charge as little as possible — just enough to cover the
cost.
Actually we encourage people who *redistribute free software* to
charge as much as they wish or can. If this seems surprising to you,
please read on."
Please note : Selling software != Distributing for charge and there
are *many* ways to sell software (even while not distributing it at
all).
>
>
>
>
> As for the original topic: under the GPLv2, anyone can build hardware around a piece of GPLed software as long as they offer to give the full source, including any modifications they made, to anyone asking for it, at cost.
Nope. If the software represents a substantial part of the hw based
product, you are not charging for distribution of the software, you
are charging for the entire *product * which would be useless without
the software. If there are software *alternatives* that are easily
installable on your hardware and you chose to prefer one of them, then
you're only distributing the sw along with the hw you are selling.
>
>
>
>
> The restrictions desired by the LS crew therefore do require additional terms beyond the GPL, and the resulting license is not compatible with the GPL. These are undisputed facts.
Undisputed facts? :) Search for "we believe" in ->
http://www.fsf.org/licensing/licenses/gpl-faq.html
>
>
> The one mildly interesting question is whether this state of affairs makes LS non-free; reinterpreting a license it doesn't even use is not going to clarify that.
It's free for users to study, modify the code and run the code for
any purpose, to distribute it to others, whether modified or not.
And see the coincidence, these rules apply to LinuxSampler whether
with or without exception.
GPL is not public domain, it's not charity for midsize or big companies.
In general, the GPL enforces third parties to *give back*. If you
can't give back code, you can give back money(the only exception
being, you're encouraged to distribute, for that sake you can earn a
few bucks if you're able to).
Marek
On Jan 27, 2008 9:59 PM, Marek <mlf.conv(a)gmail.com> wrote:
>
> But let's have a look at these statements from the GPL:
> "...if you distribute copies of such a program, whether gratis or for a
> fee..."
> "... You may charge a fee for the physical act of transferring a copy..."
>
> 1. Basically "You may charge a fee for the physical act of transferring a
> copy..." translates to "You may *only* charge a fee for the physical act of
> transferring a copy..." as the GPL doesn't state that you may charge for
> the computer program or any other services related to it other than
> distribution and providing warranty. Otherwise such statement made by the
> GPL would be *invalid*.
>
This interpretation is at odds with the FSF's own interpretation. Check
http://www.fsf.org/licensing/licenses/gpl-faq.html#DoesTheGPLAllowMoney to
get it directly from the gnu's mouth, so to speak.
As for the original topic: under the GPLv2, anyone can build hardware around
a piece of GPLed software as long as they offer to give the full source,
including any modifications they made, to anyone asking for it, at cost.
Under the GPLv3 the same thing holds, with the additional stipulation that
if the hardware is field-upgradeable, anyone must be able to do it (e.g. if
the device checks for a cryptographic signature before executing the code,
the seller must provide the required key along with the source).
The restrictions desired by the LS crew therefore do require additional
terms beyond the GPL, and the resulting license is not compatible with the
GPL. These are undisputed facts. The one mildly interesting question is
whether this state of affairs makes LS non-free; reinterpreting a license it
doesn't even use is not going to clarify that.
Daniel.
Hi!
Audun Halland and I have been thinking about a set of related problems.
The first result is the following proposal, meant to gather feedback
from the community.
I'm posting about this to both LAD and LAU, but separately. Hopefully we
can keep it technical here and have the user POV on LAU :)
Please feel encouraged to come up with additional use cases and
implementation ideas.
You can read the following with a little bit of markup on
http://thorwil.wordpress.com/2008/01/26/jack-synthesizer-manager-proposal/
or the same text right here:
JSM, the JACK Synthesizer Manager
We propose a programm that acts as a proxy between sequencing software
and both software and hardware sythesizers. Among the goals are unified
patch selection and making projects more portable.
If we get the impression that the JSM is something that both
developers and users will find handy and use, then development might
start real soon.
In this text, we avoid going into technical details to foster free
thought and discussion.
Use Cases
1. Patch selection
Goal: Choose patches from all available hardware and software
synthesizers.
Giorgio uses a single means to select a patch among all patches of
all of his software and hardware synthesizers. He uses meta-data to find
the right patch. The right connections are made automatically.
2. Computer as syntheszier
Goal: Use the computer as a compound synthesizer in a live performance.
Hiromi has her keyboard connected to her laptop live on stage. She
uses several soft-synths via keyboard-split and layering. A few selected
parameters are bound to the wheels of the keyboard. After each song, she
switches from one setup to the next with least effort.
3. Collaboration
Goal: Exchange projects without having to change settings back and
forth.
Alice and Bob take turns on working on a project. They use different
hardware but don't have to manually change connections and choose
patches on each turn because of an abstraction layer.
MIDI Interface Ports
The problem with MIDI interface ports is that the hardware on the other
side and its setup might change. Or be entirely different if people
exchange projects. An abstraction layer can make this more comfortable
to handle.
The JSM takes care of the mapping between software ports and MIDI
interface ports. It can work on a per MIDI channel level.
Patches and Instrument Definitions
Patches and controllers are chosen by name; the user doesn't have to
deal with cryptic numbers. For kit-programms, name mappings are given
(e.g. bass drum on C1).
Patch selection happens by a single means, offering all available
patches (JACK apps, plugins, hardware). Making the required MIDI and
audio connections is automated as far as possible.
Categorization
Categories help to find the right patch among many. When exchanging
projects, they help to replace unavailable patches with similar ones.
Virtual/Compound Synthesizers
>From the outside, the computer can be dealt with like a single compound
synthesizer. Different synthesizers can be triggered from ranges on a
single keyboard (key splits). Synthesizers can be layered. The whole
setup can be switched with programm changes.
JACK to ALSA Bridge
JSM could be the de facto JACK MIDI to ALSA MIDI bridge. No Jack
"SYSTEM" midi ports, the jack world only sees the devices offered by
JSM.
--
Audun Halland and Thorsten Wilms
Now that the list traffic seems to have calmed down a bit I'd like to draw
attention to another, less controversial (hah!) subject... LASH. Please bear
with me the mandatory introduction:
The Finnish Centre for Open Source Solutions [0] along with a number of
Finnish companies (yes, Nokia's in) is hosting an annual event called
Summercode [1] this year for the third time. As you probably guessed it's a
lot like Google's Summer of Code, but I've understood that it's meant solely
for university students.
The students file applications detailing the project they wish to work on and
the goals they aim to reach. The winning applicants are granted three months
of paid (about 1800 euros/month) development time beginning from June.
For me, this represents an opportunity to get the mostest perfectest summer
job I can possibly imagine. I'm planning on submitting an application for
re-implementing LASH as a D-Bus service (it's Hip, Cool and Popular), and I'm
hoping I'll get lots and lots of feedback from the lot of you for carving out
my application.
Below are the goals in descending order which I believe matter the most. (I'm
in debt to Dave Robillard for sorting out the priorities to me.)
- Turn LASH into a D-Bus service daemon.
- Unify the client and server APIs
- New features, API changes, etc.
The last one is bound to be flammable, and I'm hoping that the feedback I get
will help me concentrate my efforts on what the developers and users think is
most important. Can't do everything in 3 months' time anyway.
The deadline for applications is February 20th, and I want mine to capture the
essence of creative cross-functional combinations of community synergies and
foresight for stimulating innovation.
Thanks,
Juuso
[0] http://www.coss.fi/web/coss/about
[1] http://www.coss.fi/web/coss/developers/summercode/faq
Fons Adriaensen:
> I've been searching for real-time audio processing tool that would
> permit rapid prototyping, for at least two years now, and I haven't
> found anything that up to the requirements.
>
That is interesting. Which requirements do you miss
from snd-rt? (I have a list myself, but it may not
contain the same as the one you have...)
Grame - Centre National de Creation Musicale - is pleased to announce
the release of Faust 0.9.9.3.
Faust AUdio STreams is a powerful and expressive functional programming
language for realtime audio signal processing. The Faust compiler
translates DSP specifications into efficient C++ code.
A variety of platforms and plugin formats are supported. A single Faust
specification can be used to easily generate JACK and ALSA applications,
as well as LADSPA, MAX/MSP, PD, Q, SC and VST plugins.
In addition to C++ code, the Faust compiler can also generate SVG
block-diagram representations as well as XML descriptions. To easily
test the compiler before installing it, please refer to
http://faust.grame.fr.
The Faust distribution can be downloaded at
http://sourceforge.net/projects/faudiostream
------------
What's new :
------------
- New architecture files :
. vst2p4.cpp (VST-2.4 architecture file),
. vsti-mono.cpp (mono VSTi synth architecture file),
. matlabplot.cpp (architecture file to plot data in Matlab or Octave
format).
- New scripts for a very easy generation of executable applications :
. faust2alsa (call the faust compiler and g++ to produce an Alsa
application),
. faust2jack (call the faust compiler and g++ to produce a Jack
application),
. faust2plot (call the faust compiler and g++ to produce an plot
application),
. faust2svg (call the faust compiler to produce SVG block-diagrams),
. faust2firefox,(faust2svg + display with firefox)
. faust2octave (faust2plot + display with octave)
- New libraries :
. filter.lib (Faust filters library)
. effect.lib (Faust effects library)
- faust2pd updated to Q 7.8,
- Improved metadata management : tags are no more limited to a
predifined set, metadata are now reported as comments in the generated
C++ code
- Support for new --simple-names option when drawing block-diagrams
.
------------
Bugs fixed :
------------
- out-of-order generation of complex mutual recursions corrected
- Lexer modified to support multiplateform end of line
- Erroneous code sharing corrected
---------------
Acknowledgments
---------------
We are grateful to all the contributors of this new release, with
special mentions to Albert Graef and Julius O. Smith. Keep sending us
remarks, suggestions, bug reports and contributions.
Hi all!
I just wanted to share some of the new developments and demo made with
Clam. It's mostly about a 3D audio (it seems a hot topic in linux-audio
nowadays)
http://parumi.wordpress.com/2008/01/25/3d-audio-and-clam/
Cheers!
Pau
PS: As Albert Graef said, a new release is near. It's just a matter of
finishing the multi-platform packages and documentation.
Okay, I'll see if I can make up for my awful post from before with a
constructive question.
If you wanted to quickly prototype an idea for a DSP routine, how would
you go about it? It would need to work in real-time, but it wouldn't
really need to be super-efficient for testing ideas.
Thank you for the help.
-- Darren
Hi everyone,
and interesting thread has been going on the olpc devel list.
It would be interesting to get your comments on one
of the statements that were posted there (I'll
leave you to check the thread on the list archives
http://lists.laptop.org/pipermail/devel/).
This particular e-mail goes (in response to me asking why they
were complaining about alsa and asking for OSS:
"OSS in general, or OSS on Linux? He did say "OSS 4", which is
the current version of the API. Solaris and all *BSD use it,
along with random SysV-like things. As far as sound on the
UNIX-like platforms goes, OSS is the standard. Probably it
ought to be proposed for the next POSIX/UNIX standard.
You can read Hannu's take on the matter in his blog. This
entry is particularly informative, but note that the code
has since been released under the GPL.
http://4front-tech.com/hannublog/?p=5
More on the ALSA defects:
http://lkml.org/lkml/2007/7/6/397
Basically we got swindled. ALSA has not been the utopia that
it was claimed to be. ALSA sucks. It's not even documented."
Hannu's text sometimes reads as propaganda. But it would be
nice to hear the opinion of other developers. As far as I am concerned,
for about five years now I have not even looked at OSS anymore.
But should I reconsider?
Thanks
Victor
Hi,
There is a Free Software event in south of France this summer.
We would like to make a place for libre audio and libre culture, which
includes conferences and workshop around the tools (softwares), the
diffusion (medias, communities, ...), the licences, the users (examples of
audio studio using free technologies, examples of libre artits, ... )
So don't hesitate to send your propositions
Here is the official call for conference :
>From 1st to 5th July 2008, the Ninth Libre Software Meeting(9th LSM) will
take place in Mont-de-Marsan, in south of France. Hundreds of conferences,
workshops and showings will be programmed.
To maintain the interest of the public, it is important for LSM to renew the
content of different themes. So, if you participate in a new or unknown
project, if you wish to share your passion and your libre software
experience, we will gladly welcome you during LSM 2008.
We start a large call for communications on the following axes :
- thematic conferences - all subjects are interesting, particularly
those we have not thought about ...
- projects or libre softwares presentations
- workshop animations (development, initiation, ... )
To propose to the public a rich and various content, please send your
propositons, suggestions and ideas before February 8th to appel2008 at
rmll.info
*Contacts :* (program directors)
Nicolas Ducoulombier : nicolas at ldd.fr <nicolas%20at%20ldd.fr>
Christophe Merlet : redfox at redfoxcenter.org<redfox%20at%20redfoxcenter.org>
The definite programme, theme list, conferences and contributors will be
highly influenced by the feedback we will get from this call for
contributions.
Do not hesitate to participate and give worthy projects wide visibility.
--
Benjamin Coudrin
benjamin.coudrin(a)gmail.com
(+33)6.09.11.00.83
