Subject: Re: [linux-audio-user] Finale for Linux
From: Chris Pickett (chris.pickett_AT_mail.mcgill.ca)
Date: Sun Jul 11 2004 - 23:34:23 EEST
Hi Rick,
Sorry for the delay responding. Since Thursday, have seen Ibrahim
Ferrer, Dianne Reeves, Carol Welsman, Peter Cincotti, Oliver Jones, and
Oscar Peterson at the Montreal Jazz Festival. CW was okay, the rest
were amazing!
RickTaylor_AT_Speakeasy.Net wrote:
> On 09-Jul-2004 Chris Pickett wrote:
> } RickTaylor_AT_Speakeasy.Net wrote:
> } > The GPL?
> }
> } All the GPL says is that you must promise to give the source code to
> } anybody you provide a binary to, for up to three years, and if they make
> } derivations and distribute binaries, they must also promise source code
> } to the recipients. Specifically, it does NOT say, "you must make all
> } GPL'd software you release available to the public, even if you haven't
> } given said public copies of your program." If you pay me $5000 for
> } GPL'd software, we can sign an agreement that I won't give it to anyone
> } else for 6 months, and neither will you, and we'll both still get the
> } source code. This is a key business point, IMO.
>
> I suppose you and I are reading this a bit differently.
>
> http://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic
I think that's consistent with what I wrote. Read the FAQ (or the
license itself) pretending you have been paid to develop GPL'd software
for a client, and ask yourself if you or they are required to give it to
anyone else. Also read the next next question about demanding a copy.
Section 6 does say, "You may not impose any further
restrictions on the recipients' exercise of the rights granted herein."
so that probably means you can't make them sign an NDA. It does sound
like you could work out a mutual understanding like, "if either of us
gives this to anyone else, our employment contract is void".
Anyway, I don't think this is necessarily "right" (especially if the
source _never_ gets released to the public), but if businessmen /
researchers are that worried about competition, it seems like a good
option for keeping ahead of the game a bit.
> } > I'm thinking more along the lines of a open source system with shareware
> } > apps.
> } > I think the system itself would go down the tubes if you started getting
> } > internal competition, etc.
> }
> } I guess ... I guess I've stopped distinguishing between system and
> } application. Is Mozilla part of the system? Or is it definitely an
> } application? Do you define application by replaceable, non-essential
> } part? What's essential? Is X essential? How about bash? Is the linux
> } kernel even essential? Can't you run this software with a different
> } kernel? I basically view everything as a set of interoperating programs
> } -- including the music stuff -- although I might concede that the kernel
> } is perhaps the only "true" system component.
>
> If it's essential for system operation {I think this has to include X because
> so many apps are dependant on it.} it's system. I imagine this could vary
> depending the function of the system... For the most part I think it's pretty
> clear cut.
I guess for me the components of a system are defined by ones'
workcycle, and would include a mastering tool and sequencer for an audio
system, and a photo editor in a graphics workstation. I spend 8-10
hours a day connected via ssh to a headless machine, without any X
forwarding at all -- X isn't really part of that system.
Moreover, I see a system as a collection of boxes, holding programs.
You can fill the boxes as you see fit, and organize them to work with
each other to achieve a goal. All of the boxes used to meet a given
goal are essential. There is no difference between them, except that
some will be used for almost every task (e.g. kernel box).
In a _good_ system, each box interacts easily with the others, and
redundancy between them is reduced. And, with open standards and open
source, it's easier to enhance or replace pieces that aren't working
well, for whatever reason.
However, non-free software companies often want to create vendor
lock-in, and they've shown a good way to do this is to decrease
interoperability between programs and flexibility in the system. They
allow for only one box per program, and furthermore make one subscribe
to their whole subsystem of boxes to get something usable. It's like
when Lego started making wall pieces instead of just individual blocks
to build them.
Cheers,
Chris
This archive was generated by hypermail 2b28 : Sun Jul 11 2004 - 23:45:32 EEST