Statically linked proprietary bit-sequences
Moderator: Forum Moderators
Statically linked proprietary bit-sequences
If I understand correctly some arguments I have read in restricted area, musicians have apparently submitted as GNU licensed bit-sequences sequences which contain proprietary 'samples' or which result from the compilation of various proprietary 'samples'. Is that correct?
I had the impression as a 'coder' (an author of instructions as to what compilations to make of what constituents in order to arrive at a variation suitable for an end-user/consumer's environment) that it was specifically not okay under the GPL to withhold any components (such as samples of code, bit-sequences of machine-instructions or encrypted material etc etc etc) necessary for the compilation or assembly of the end-user sequence of bits? Especially not to use samples of proprietary material?
Given the loopholes various 'artists' seem to want and back-porting them to other art-forms such as cryptology, algorithmics, robotics (causing organic peripherals and the digits of ones fingers and such to do things such as press keys on a keyboard and so on) the whole GPL could maybe be pretty much meaningless. One could use a disassembler to make 'samples' of binary code and 'type' them in a sequence given on handwritten notes one made along the way which, some claim, cannot be considered to be source code. Then not release one's proprietary 'samples' that one had bound to one's keys for purposes of 'playing' that 'composition'.
Or do like the painters/drawers: use layers. Instead of bytes, lets use eight 'layers' which when put together in a sequence of one bit from layer one followed by one bit from layer two etcetera looks exactly like an executable, and is in fact executable, but which is actually source code which I artistically created by layering eight proprietary files that I am not going to release...
Or I could perform an audio performance of my creation by using one sound for one and another for zero, record that performance, and compress it (to save space and bandwidth) as bits, and that is the 'source' because after all it is simply the compressed form of an audio recording of a sound-performance... that happens to be executable as machine-code on a specific kind of machine!
-MarkM-
I had the impression as a 'coder' (an author of instructions as to what compilations to make of what constituents in order to arrive at a variation suitable for an end-user/consumer's environment) that it was specifically not okay under the GPL to withhold any components (such as samples of code, bit-sequences of machine-instructions or encrypted material etc etc etc) necessary for the compilation or assembly of the end-user sequence of bits? Especially not to use samples of proprietary material?
Given the loopholes various 'artists' seem to want and back-porting them to other art-forms such as cryptology, algorithmics, robotics (causing organic peripherals and the digits of ones fingers and such to do things such as press keys on a keyboard and so on) the whole GPL could maybe be pretty much meaningless. One could use a disassembler to make 'samples' of binary code and 'type' them in a sequence given on handwritten notes one made along the way which, some claim, cannot be considered to be source code. Then not release one's proprietary 'samples' that one had bound to one's keys for purposes of 'playing' that 'composition'.
Or do like the painters/drawers: use layers. Instead of bytes, lets use eight 'layers' which when put together in a sequence of one bit from layer one followed by one bit from layer two etcetera looks exactly like an executable, and is in fact executable, but which is actually source code which I artistically created by layering eight proprietary files that I am not going to release...
Or I could perform an audio performance of my creation by using one sound for one and another for zero, record that performance, and compress it (to save space and bandwidth) as bits, and that is the 'source' because after all it is simply the compressed form of an audio recording of a sound-performance... that happens to be executable as machine-code on a specific kind of machine!
-MarkM-
- West
- Retired Lord of Music
- Posts: 1173
- Joined: October 30th, 2006, 7:24 am
- Location: In the philotic connections between ansibles.
- Contact:
Re: Statically linked proprietary bit-sequences
I'm really not sure what you're getting at with this post but to be honest I find your insinuations mildly insulting.
If what you're trying to say is, 'I don't think musicians should release music made with proprietary samples under the GPL', then fine, we can have that discussion. But I would appreciate if you could post your opinions in a more coherent and to-the-point manner (organic peripherals... what??). I really don't have the time nor the will to decipher your ramblings.
If what you're trying to say is, 'I don't think musicians should release music made with proprietary samples under the GPL', then fine, we can have that discussion. But I would appreciate if you could post your opinions in a more coherent and to-the-point manner (organic peripherals... what??). I really don't have the time nor the will to decipher your ramblings.
Re: Statically linked proprietary bit-sequences
As I understand it, this is rambling about a pivotal point of GPL - where does source turn into some result? Music is mentioned, as a starting point. But the rest of text is disconnected from that part. If you are trying to say "why the heck is music under gpl when the samples are not?" then just cut everything except first paragraph. The rest just obscures what you want to say. If it is not so, why post this here?
- West
- Retired Lord of Music
- Posts: 1173
- Joined: October 30th, 2006, 7:24 am
- Location: In the philotic connections between ansibles.
- Contact:
Re: Statically linked proprietary bit-sequences
Okay, for markm and everyone else who tends to opine that commercial samples should not be used in GPL'd music. Consider this.
Here, on the left, we have a sample library. Let's say EWQL.
On the right is a hardware synth, for example a good old Yamaha SY99.
Which one should I use for creating music that will be released under the GPL?
Here, on the left, we have a sample library. Let's say EWQL.
On the right is a hardware synth, for example a good old Yamaha SY99.
Which one should I use for creating music that will be released under the GPL?
Re: Statically linked proprietary bit-sequences
you probably forgot to add links in your last post, west
Fight key loggers: write some perl using vim
- West
- Retired Lord of Music
- Posts: 1173
- Joined: October 30th, 2006, 7:24 am
- Location: In the philotic connections between ansibles.
- Contact:
Re: Statically linked proprietary bit-sequences
It doesn't matter, really. The point is that one is software, used on a computer. The other is a hardware unit.
Re: Statically linked proprietary bit-sequences
I'm far from being an expert in this matter, but I find the objections don't make much sense. Maybe I'm wrong, but I think the GPL is a software license. It's the source code that's open. A piece of music is not software. When you say that we musicians put our music under the GPL, I understand that means we agree that our music will be distributed freely as part of a GPL software, and that, therefore, anyone will be able to use it the same way they can use the source code. It doesn't mean the source code of the music must be distributed too, because music does not have source code.
Music files are not like executable binaries. They are not the result of compiling source code. Unless you use Csound or something like that, you don't write source code and compile it to generate the music. Music files are like the source code itself. They are like a text file you distribute with your software. You didn't compile the text file. You distribute it as it is. The same happens with the music files. It doesn't matter how you made them. What if, instead of using a sample library, you used a real orchestra to play the music? In that case, the objections would obviously not apply, unless you want the clarinets, flutes and oboes to be under the GPL too. And isn't a sampler an instrument too, like the clarinet? When one buys a sample library, one acquires a license to use it as if it were an instrument. One can use it as one sees fit, except for distributing the samples as samples and selling them and giving them away as such. That means when samples are used in a musical piece, they cease to be samples as such.
The way I see it, starting this discussion is applying rules to something they are not applicable. In any case, the problem could probably be easily solved by using a license compatible with the GPL.
Music files are not like executable binaries. They are not the result of compiling source code. Unless you use Csound or something like that, you don't write source code and compile it to generate the music. Music files are like the source code itself. They are like a text file you distribute with your software. You didn't compile the text file. You distribute it as it is. The same happens with the music files. It doesn't matter how you made them. What if, instead of using a sample library, you used a real orchestra to play the music? In that case, the objections would obviously not apply, unless you want the clarinets, flutes and oboes to be under the GPL too. And isn't a sampler an instrument too, like the clarinet? When one buys a sample library, one acquires a license to use it as if it were an instrument. One can use it as one sees fit, except for distributing the samples as samples and selling them and giving them away as such. That means when samples are used in a musical piece, they cease to be samples as such.
The way I see it, starting this discussion is applying rules to something they are not applicable. In any case, the problem could probably be easily solved by using a license compatible with the GPL.
Re: Statically linked proprietary bit-sequences
Which has already been discussed to death.
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.