source code stat?
Daniel Stenberg
I was browsing throught the SVN repo the other day and I noticed there seems
to be some code showing up in there.
What's the status now? Can we build and run anything on a Linux host to try it
out soon?
Further, I noticed several binary sound codec files with no source code
available. What's the license/redistribution rights for these?
--
Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Michael Gao
Code was designed to be able to be built and run on Linux host, without
A/V support though, thus the GUI and other stuff can be tested out.
Basically this is controlled by a compiler flag, however current code
base may not fully support this yet.
Code status:
--BSP:
It is ready for kernel load/run on Dev board, TFTP/NFS support is there,
framebuffer is ready. But Video-in and Audio support is not there yet,
USB is not there either.
--Main application:
Plugin frame work is there, good enough to load plugins and
decode/encode. Nano-X support porting done, Neuros Widget sets
completed, GUI structure with XIM, and Video/Framebuffer overlap support
is there. JPG/BMP/GIF support is there.
Main application (linux-r3-main-app) is ready to be built and run on Dev
board.
Code is not stripped yet, may not be able to sit in 4MB flash.
--Plugins
MP4/ASF/AVI/WMV/MP3/AAC/OGG/WMA decoder plugins with
MPEG4/MPEG2/DivX/WMV video and MP3/AAC/AC3/G726/OGG/WMA audio codec are
there.
MP4/ASF/AVI encoder plugins with MPEG4 video and MP3 audio codec are
there.
Current plugins are built on top of Codec vendor's source/binaries,
Neuros is only able to release them in binary format per the agreement
with the vendor. The binary can go with GPLed source released by Neuros.
Dev/Daughter Board Status:
--Dev board:
All parts except Video-in/Audio-Codec/USB have been tested and working.
10MB Ethernet issue is there but should be minor per Bob. A couple more
boards are in the way from Taiwan to China.
--Daughter board:
First two boards have been built and tested in US, first one built in
China will be completed on 03/06.
Limited number (6?) of Dev/Daughter board sets will be ready for the
community by 03/12.
/MG
Linus Nielsen Feltzing
> Current plugins are built on top of Codec vendor's source/binaries,
> Neuros is only able to release them in binary format per the agreement
> with the vendor. The binary can go with GPLed source released by Neuros.
What exactly are the licensing requirements from the vendor? How are the
plugins built upon the binaries, and how are the plugins loaded and
linked? I smell licensing problems here.
Linus
Michael Gao
main-app. Main-app will link and run even without any of these plugins
but will lack most of the multimedia functionality for obvious reasons.
Plugins themselves statically link with vendor lib and reference some of
vendor's source code as well.
It is entirely possible to build plugin without referencing vendor's
lib/soure at all, for example, audio codec on ARM side, visual plugin on
ARM side etc. And in these cases, Neuros will release plugin source code
as well.
---excerpt of the license---
...
4. LICENSEE is allowed to provide publicly accessible API entry points
that allow LICENSOR's Licensed Materials to execute provided the
following constraints are applied:
· All LICENSOR Software Licensed Materials for ARM926 must be
distributed in Object Code only.
· All LICENSOR Software Licensed Materials for DSP must be integrated
with LICENSEE's software materials and distributed in hex (executable)
format only. No distribution of LICENSOR's DSP Objects is allowed.
· All but the essential symbolic information must be removed from the
Object Code provided to LICENSEE's customers or 3rd Party Developer's
Network. The remaining symbols should be renamed as to not compromise
the purpose of the specific software function.
· LICENSEE will act in good faith to protect and honor
· As required by LICENSOR, LICENSEE will demonstrate the materials
discussed in this section can only execute on LICENSEE's Licensed
Product.
· The software that implements the public API can only be disclosed to
the extent that is does not compromise any of the conditions listed in
this section.
...
> ------------------------------------------------------------
> Mail was checked for spam by the Freeware Edition of No Spam Today!
> The Freeware Edition is free for personal and non-commercial use.
> You can remove this notice by purchasing a full license! To order
> or to find out more please visit: http://www.no-spam-today.com
Linus Nielsen Feltzing
> Plugins are released as .so and will be dynamically loaded by the
> main-app. Main-app will link and run even without any of these plugins
> but will lack most of the multimedia functionality for obvious reasons.
As I see it, you will violate the GPL if you release a firmware with the
plugins as .so files.
Quote from the GPL FAQ:
"If the program dynamically links plug-ins, and they make function calls
to each other and share data structures, we believe they form a single
program, which must be treated as an extension of both the main program
and the plug-ins. This means the plug-ins must be released under the GPL
or a GPL-compatible free software license, and that the terms of the GPL
must be followed when those plug-ins are distributed.
If the program dynamically links plug-ins, but the communication between
them is limited to invoking the `main' function of the plug-in with some
options and waiting for it to return, that is a borderline case."
I haven't examined your plugin API, but I think it may be hard to
restrict the plugin interface to resemble the borderline example above.
Of course, the usual IANAL exclaimer applies here... :-)
Linus
Daniel Stenberg
> ---excerpt of the license---
What wasn't covered in that excerpt (or what I failed to grasp from it) is if
the rest of the world is also also allowed to redistribute these object files
under the same rules?
I'm quite sad to see you taking yet another step away from open source and
(the spirit of) GPL. I know you're of course entitled to make your own
decisions and everything but I don't see a lot of differences between your
open source effort and the Linux-based firmwares done by Cowon, iriver,
Archos, Toshiba etc. (Yes, there are _some_ differences but the similarities
are much bigger IMHO.)
--
-=- Daniel Stenberg -=- http://daniel.haxx.se -=-
ech`echo xiun|tr nu oc|sed 'sx\([s\x]\)\([\xoi]\)xo un\2\1 is xg'`ol
Michael Gao
'and they make function calls to each other...', it seems we are at the
border line, plugins do not call anything from the main-app in our case.
main-app accesses plugins through a single API, from which further
access can be achieved with different parameters or dereferenced
function pointers.
Michael Gao
> On Mon, 6 Mar 2006, Michael Gao wrote:
>
> > ---excerpt of the license---
>
> What wasn't covered in that excerpt (or what I failed to grasp from it) is if
> the rest of the world is also also allowed to redistribute these object files
> under the same rules?
>
· As required by LICENSOR, LICENSEE will demonstrate the materials
discussed in this section can only execute on LICENSEE's Licensed
Product.
Not sure if this has a leg from a lawyer or whoever's point of view, as
long as these objects execute on 'Licensed Product', which is DM320
based Neuros product, they should be able to be redistributed.
> I'm quite sad to see you taking yet another step away from open source and
> (the spirit of) GPL. I know you're of course entitled to make your own
> decisions and everything but I don't see a lot of differences between your
> open source effort and the Linux-based firmwares done by Cowon, iriver,
> Archos, Toshiba etc. (Yes, there are _some_ differences but the similarities
> are much bigger IMHO.)
>
Sadly true, but between designing everything from scratch or MS
approach, I don't see a better solution (well, for audio only
application, it is possible to port Rockbox to ARM side,
Neuros/Community then needs to design the DSP side codec as we discussed
before). I know Joe is learning SW in his spare time, shall we wait? :)
andrew fresh
>
> hmmm, IANAL either... ;-)
>
> 'and they make function calls to each other...', it seems we are at the
> border line, plugins do not call anything from the main-app in our case.
> main-app accesses plugins through a single API, from which further
> access can be achieved with different parameters or dereferenced
> function pointers.
Possibly easy solution, but I don't know what the 'linux-r3-main-app'
includes. But how about release the 'linux-r3-main-app' that accesses
the plugins under a license that isn't as restrictive as the GPL?
Something like the BSD license or something. If the
'linux-r3-main-app' is all Neuros IP it shouldn't be an issue getting
the OK.
I don't know if there is something that the GPL would give Neuros that
a different license wouldn't, but Neuros makes money on the hardware,
not the software right?
It might even involve making too much stuff more free than the GPL
allows, so I don't know how it would work, but I am just throwing out
the idea.
l8rZ,
--
andrew - ICQ# 253198 - JID: afr...@jabber.org
Proud member: http://www.mad-techies.org
BOFH excuse of the day: Electrons on a bender
Björn Stenberg
> I don't know if there is something that the GPL would give Neuros that
> a different license wouldn't,
Generally, GPL is chosen for one of two reasons:
1) You consider it to be the most suitable license for your original work (i.e. you don't want to allow companies to sell modified versions of your work without sharing their changes).
2) You want to use GPL-licensed code that someone else has written.
In Neuros' case, I guess both reasons apply.
--
Björn
Joe Born
for the time being. There simply are no open source substitutes. I'm
hopeful that we can change that over time and as you know, we're working
towards open compilers for the DSP, etc. In the meantime we can
certainly use open source audio codecs on the arm side, etc.
AFAIK, there aren't any other options to support video. Am I missing
something?
Joe
-----Original Message-----
From: Neuros-DM3...@googlegroups.com
[mailto:Neuros-DM3...@googlegroups.com] On Behalf Of Daniel
Stenberg
Sent: Monday, March 06, 2006 5:48 AM
To: Neuros-DM3...@googlegroups.com
Subject: Re: source code stat?
On Mon, 6 Mar 2006, Michael Gao wrote:
> ---excerpt of the license---
What wasn't covered in that excerpt (or what I failed to grasp from it)
is if
the rest of the world is also also allowed to redistribute these object
files
under the same rules?
I'm quite sad to see you taking yet another step away from open source
and
(the spirit of) GPL. I know you're of course entitled to make your own
decisions and everything but I don't see a lot of differences between
your
open source effort and the Linux-based firmwares done by Cowon, iriver,
Archos, Toshiba etc. (Yes, there are _some_ differences but the
similarities
are much bigger IMHO.)
--
-=- Daniel Stenberg -=- http://daniel.haxx.se -=-
ech`echo xiun|tr nu oc|sed 'sx\([s\x]\)\([\xoi]\)xo un\2\1 is xg'`ol
------------------------------------------------------------
Björn Stenberg
> Well I don't think we have any choice but to use the proprietary plugins
> for the time being. There simply are no open source substitutes.
You sound as if the choice is yours to make. Is it, really?
Here are two simple questions:
1. Do you intend to integrate GPL-licensed code written by others in your application?
2. If so, how do you intend to legally combine that with your closed-source modules?
I don't _want_ to be a pain in your behind, but I still can't see that you are taking the licensing issues seriously. Voilating the GPL is no less serious than violating any of Microsoft's licenses. It's a federal crime! You can't just wing it and see what happens. You need to research the issues and take real decisions.
--
Björn
Nathan True
It is my belief that the use of proprietary self-contained libraries on the ARM side can be argued convincingly in a court of law to not be an "extension" of GPL code. As for the DSP-side code, communicating with a separate CPU is going to be far less of a link than running on the same CPU and as such will be less of an issue than proprietary ARM-side code.
There are, however, some issues in the GPL concerning the distribution of source code. I quote:
For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.Thus, if the proprietary ARM/DSP modules are shipped with the unit, and the firmwares built by the source code and/or distributed as upgrades via the Neuros website do NOT contain the proprietary modules (say, the modules are stored in a separate flash partition), you do not need to distribute source code for those modules and can thus fulfill both the terms of the GPL and of the proprietary code vendor.
My apologies to the Open Source idealists out there, but Neuros is a business that ultimately needs to make its decisions in favor of profits (even if only so its employees and their families get paid). Thus your alternatives such as "cancelling the project completely" and "writing open-source codecs for everything before launching the products" are simply not viable (the latter because it would take too much development time for a product that may already be losing out on the bleeding edge, and the former I suppose to be obvious).
Nate
Daniel Stenberg
> My apologies to the Open Source idealists out there, but Neuros is a
> business that ultimately needs to make its decisions in favor of profits
Of course. But the grand promise about being the first or only (or similar)
portable music player that is developed Open Source is going further and
further away from the truth.
And _that_ promise is what brought lots of us mailing list readers here.
There's of course a lot of Neuros users and others who don't care about Open
Source or anything and think whatever Joe and Neuros do is fine and cool and
everything, and perhaps it is, but I'd like the cards to be played openly. The
Neuros DM320 based products are not becoming very much open source if this
development is gonna keep on in this direction.
Daniel Stenberg
> There simply are no open source substitutes.
I'm still curious if other parties are also allowed to redistribute those
binary objects in your SVN repository. The license excerpt didn't clarify
that.
Nathan True
Neuros will be furthering open-source even if it harbors proprietary modules, and I go so far as to assert that the actions of Neuros toward the benefice of open-source software would go further with the inclusion of said modules than it would without.
Consider, if you will, that without these proprietary modules, the next-generation Neuros product line shall either be delayed for an indeterminate amount of time as open-source modules are developed, or that the product line shall release on time without support for the most popular of formats.
In the first case, where the product line is delayed:
- The personal media player market may become saturated, such that anyone who would buy a personal media player purchases a non-Neuros product. The Neuros product line (in the worst case) fails or is unprofitable.
- Attraction to the Neuros line of products is annulled. No further open-source developers join the Neuros project and no extensions to the open-source products such as Linux or Nano-X are developed due to Neuros' actions.
- As a consequence of the previous two items, few developers are available to code the requisite open-source modules and such modules take a long time to complete.
- The combination of these three items results in a cycle that is unlikely to spell either product success for Neuros or significant contribution to the open-source environment.
- The Neuros product line does not support any popular video formats and is as such passed over by users shopping for personal media players.
- No developers are attracted to the project because it is not currently in an "attractive" state - they would have to purchase a $500 product which does not meet their personal media needs, and the code to do so would be in such an infant state that very few open-source developers will be attracted.
- As such, no development occurs to the benefice of open source software and Neuros does not have a leg to stand on profit-wise.
Now, to examine my proposal. In this case, Neuros licenses and distributes proprietary modules in a separate flash partition on the Neuros devices themselves and does not include any proprietary object code in the source distribution (here I assume sufficient compiler-fu is performed such that programs can be compiled to dynamically link to the modules without the object code being present). Consider, then, the following:
- The Neuros product line releases to general fanfare. Hailed as the first open-source media player effort, Slashdot, Digg, and numerous other news sites sing its praises, much to the publicity of Neuros and its concomitant products.
- A large amount of consumers (a fraction of which shall become interested developers) flock to the product, much to the profit of Neuros and to the benefice of the project as far as new developers are concerned.
- The third-party addon community for Neuros products flourishes and ensures added value to consumers. This increases sales of the devices and causes a lot of open-source code to be created and released.
Open-source righteousness will not help the open-source cause at this juncture in time. Joe has already promised that Neuros would make efforts to create open-source versions of modules once the product line takes off - shall this not be the end you envisioned?
Vladimir Pantelic
> "extension" of GPL code. As for the DSP-side code, communicating with a
> separate CPU is going to be far less of a link than running on the same
> CPU and as such will be less of an issue than proprietary ARM-side code.
Yes, the DSP side stuff could be OK with the GPL
> My apologies to the Open Source idealists out there, but Neuros is a
> business that ultimately needs to make its decisions in favor of profits
> (even if only so its employees and their families get paid). Thus your
> alternatives such as "cancelling the project completely" and "writing
> open-source codecs for everything before launching the products" are
> simply not viable (the latter because it would take too much development
> time for a product that may already be losing out on the bleeding edge,
> and the former I suppose to be obvious).
Beside the DSP stuff you got audio decoders and file format parsers and
there are open source alternatives for almost all of them, like MAD for MP3,
liba52 for AC3, faad for AAC, ffmpeg for WMA, AVI, ASF, MP4. So actually
you could use a lot of existing open source, no? As you plan to make an
open source device, you are not banned from using open source codecs.
Regards,
Nathan True
Chairman Gao, is this the case?
Daniel Stenberg
> In the set of actions I understand you to be promoting, the open-source
> environment is not improved, and other media players which are not
> open-source (windows-based!) go mainstream.
I'm not promoting any actions - besides adhering to licenses. I'm mostly
asking about and pointing out deviances from what I used to view as promises.
Vladimir Pantelic
> The issues here being that these will all be compiled for ARM, rendering
> useless the DSP unless the ARM-side of the proprietary modules can be
> used to control the DSP stuff.
So, doing:
- GPL audio codecs and parsers on ARM side
- GPL DSP API on ARM side
- Binary only DSP FW on DSP
should be fine with the GPL, there are binary only FWs for WLAN
cards etc. that somehow can work with the GPL. But linking with
a "closed" DSP control API on the ARM with GPL code I fear will not
work.
Regards,
Nathan True
Björn Stenberg
> Hold on there. Violating the GPL is violating the terms of a contract.
> This is not a crime as far as I know - it is a civil matter that must be
> settled via lawsuit between the offending party and the licenser of the
> code (in this case the author of the GPL'd code).
Incorrect. First, the GPL is a license and not a contract. Second, distributing GPL code in violation of the license amounts to copyright violation. Copyright violation is in the US, since the NET Act of 1997, a federal crime with a maximum penalty of five years in prison and a $250,000 fine.
> It is my belief that the use of proprietary self-contained libraries on
> the ARM side can be argued convincingly in a court of law to not be an
> "extension" of GPL code.
Perhaps it can, perhaps it can't. But going to court to try and sneak around the GPL is not exactly the best way to attract developers and advertise your open source friendly business. And would you really want to bet your business on the outcome of such a court case?
> My apologies to the Open Source idealists out there, but Neuros is a
> business that ultimately needs to make its decisions in favor of profits
I'm sorry, but the fact that Neuros has to make a profit does not trump the fact that they must follow the law. Some of you may think the GPL is only flimsy idealistic hand-waving, but I assure you it is not. Much larger companies than Neuros have gotten into trouble over that mistake.
I have nothing to gain from Neuros' failure, and lots to benefit from its' success. That is why I'm so concerned about what I percieve as a blind spot in the management. This is a business-critical issue, and must be addressed as such.
One way to solve the open/closed mixing issue would be to use the BSD license instead of the GPL for the in-house code. The BSD license allows such mixing. But then you will be restricted in the amount software of available and much will have to be written from scratch instead. (Not to mention the fact that you no longer have any protection from competitors taking your code without giving anything back.)
--
Björn
Nathan True
USC Title 17, Chapter 5, Section 506What is the retail value of free code again?
(a) Criminal Infringement.— Any person who infringes a copyright willfully either—(2) by the reproduction or distribution, including by electronic means, during any 180-day period, of 1 or more copies or phonorecords of 1 or more copyrighted works, which have a total retail value of more than $1,000, shall be punished as provided under section 2319 of title 18, United States Code. For purposes of this subsection, evidence of reproduction or distribution of a copyrighted work, by itself, shall not be sufficient to establish willful infringement.
http://www.law.cornell.edu/uscode/html/uscode18/usc_sec_18_00002319----000-.html
USC Title 18, Part 1, Chapter 113, Section 2319
(b) Any person who commits an offense under section 506 (a)(1) of title 17—(1) shall be imprisoned not more than 5 years, or fined in the amount set forth in this title, or both, if the offense consists of the reproduction or distribution, including by electronic means, during any 180-day period, of at least 10 copies or phonorecords, of 1 or more copyrighted works, which have a total retail value of more than $2,500;(2) shall be imprisoned not more than 10 years, or fined in the amount set forth in this title, or both, if the offense is a second or subsequent offense under paragraph (1); and(3) shall be imprisoned not more than 1 year, or fined in the amount set forth in this title, or both, in any other case.
Seems you have a point there. It appears that section 2319(b)(3) allows for 1 year of imprisonment for violations under $2500. I suppose GPL code would qualify as $0 retail value since it is free.
Nowhere, however, does the NET act say $250,000. Indeed, I'm having trouble finding where monetary fines are defined at all. Would anyone happen to know the location of those definitions?
Also, why aren't we leveling this against companies such as Western Digital which uses Linux in their networked hard drives yet refuse to release source code?
Vladimir Pantelic
> Excellent. Then let us move to the discussion of action, as it appears
> the discussion of license compatibilities has been exhausted.
With the result being?
Nathan True
Kaspar Rothenfußer
threads):
1. Is the usage of closed source codecs a violation
of the GNU GPL?
(and as such different from the usage of binary
WLAN drivers etc on a Linux PC)
2. What are the redistribution policies of the binary
firmware parts and what can be done to replace them?
(A GPL opcode list/interface to the DSP part of
the DM320 and things like that)
BTW, choosing another license but the GPL for Neuros firmware (OS ARM
parts) is not possible since it willl be BASED UPON LINUX and therefore
a derivation in terms of the GPL.
Kaspar Rothenfußer
Michael Gao
> The issues here being that these will all be compiled for ARM,
> rendering useless the DSP unless the ARM-side of the proprietary
> modules can be used to control the DSP stuff.
>
> Chairman Gao, is this the case?
>
Thus yes, some ARM side modules will be used to control it.
Josh Malone
> BTW, choosing another license but the GPL for Neuros firmware (OS ARM
> parts) is not possible since it willl be BASED UPON LINUX and therefore
> a derivation in terms of the GPL.
Not true at all. Although I loath to get into this discussion, I must
point out that simply running a piece of code on Linux does not
subject that code to the GPL. NOBODY disputes this. The "firmware"
(which is really just a Linux application) can be BSD, MPSL, X,
whatever.
--
Joshua Malone www.ubergeeks.com/~jmalone
Power Users Use The Power To Serve www.freebsd.org
Joe Born
Joe
-----Original Message-----
From: Neuros-DM3...@googlegroups.com [mailto:Neuros-DM3...@googlegroups.com] On Behalf Of Björn Stenberg
Sent: Wednesday, March 08, 2006 6:54 AM
To: Neuros-DM3...@googlegroups.com
Subject: Re: source code stat?
Nathan True wrote:
> Hold on there. Violating the GPL is violating the terms of a
> contract. This is not a crime as far as I know - it is a civil matter
> that must be settled via lawsuit between the offending party and the
> licenser of the code (in this case the author of the GPL'd code).
Incorrect. First, the GPL is a license and not a contract. Second, distributing GPL code in violation of the license amounts to copyright violation. Copyright violation is in the US, since the NET Act of 1997, a federal crime with a maximum penalty of five years in prison and a $250,000 fine.
> It is my belief that the use of proprietary self-contained libraries
> on
> the ARM side can be argued convincingly in a court of law to not be an
> "extension" of GPL code.
Perhaps it can, perhaps it can't. But going to court to try and sneak around the GPL is not exactly the best way to attract developers and advertise your open source friendly business. And would you really want to bet your business on the outcome of such a court case?
> My apologies to the Open Source idealists out there, but Neuros is a
> business that ultimately needs to make its decisions in favor of profits
I'm sorry, but the fact that Neuros has to make a profit does not trump the fact that they must follow the law. Some of you may think the GPL is only flimsy idealistic hand-waving, but I assure you it is not. Much larger companies than Neuros have gotten into trouble over that mistake.
I have nothing to gain from Neuros' failure, and lots to benefit from its' success. That is why I'm so concerned about what I percieve as a blind spot in the management. This is a business-critical issue, and must be addressed as such.
One way to solve the open/closed mixing issue would be to use the BSD license instead of the GPL for the in-house code. The BSD license allows such mixing. But then you will be restricted in the amount software of available and much will have to be written from scratch instead. (Not to mention the fact that you no longer have any protection from competitors taking your code without giving anything back.)
--
Björn
Aaron Howard
[snip]
> What is the retail value of free code again?
> I suppose GPL code would qualify as $0 retail value since it is free.
>
Simply responding to these two statements. The "free" part of GPL
code often confuses people. GPL code can be charged for. Most do
not, because you cannot turn around and tell someone else they're not
allowed to redistribute it (for a fee or not). So, the value
proposition on charging actual money for the code itself approaches $0
because the first person you sell it to can post it on his website and
redistribute it free of monetary charge.
That does NOT mean the value of the code is $0. Granted, it would be
potentially difficult to put a dollar figure on it. But the idea is
that code licensed under the GPL is licensed to others for
consideration other than cold hard cash. It is primarily for
returning the favor and contributing your code back to the project.
For instance, it may take me a year to write some piece of software to
do X. That would be worth my salary for a year, perhaps. But, let's
say I wrote three months worth of code that did some subset of X,
that's worth three months of my salary. But if I license it to you
under the GPL, and you spend three months adding additional
functionality, refactoring, fixing bugs, etc. and I spend another
three months also, we've now got nine months worth of work done in
six. We're trading labor, basically. I'm granting you a license to
my code in return for you granting me a license for your code. That's
the payment. There IS a value to it. I agree that in a court of law,
I'd have no idea how to argue what the proper value for any given pice
of GPL code should be...but then, I'm not a lawyer.
For reference, I recommend the following reading:
http://www.groklaw.net/staticpages/index.php?page=20050131065655645
That is GrokLaw's GPL page. It has links to a cajillion references,
including the text of the GPL itself, FAQs, articles about the GPL,
etc. I particularly recomment the article titled "The Sustainable
GPL" which explains the "consideration" received under the GPL a bit.
There are also articles on why the GPL is a license, not a contract.
If you haven't followed GrokLaw, I recommend it. It's mostly about
SCO vs. IBM, but there are tons and tons of useful articles about the
GPL, copyright, patents, etc. that are great for giving non-lawyers
(and lawyers alike) a better understanding of the principles.
-Aaron
--
==
Aaron Howard
arch...@gmail.com
Nathan True
Michael Gao
1. Audio Codec
Plugin framework is designed to load audio codec either separately or
toghether with the video codec. Actually current support for
MP3/AAC/AC3/WMA/ audio is through ARM side audio codec. Replacing them
(WMA?) and adding new ones with OS ARM Audio Codec is easy.
2. Video Codec
It is part of the same framework, theoretically it is as easy as to
replace the audio codec. However, video codec themselves heavily uses
DSP core, the OS codec themselves will take time to come.
/MG
Kaspar Rothenfußer
(which can be under whatever license but devicxe drivers (in- or outside
the linux kernel) and the kernel itself which probably contain DSP code
as well. Those have to be GPL.
Nathan True
Paul M Edwards
>
> I'll have some more definitive answers on the GPL issue and the linking, etc. We do take this issue seriously. I'll respond more shortly.
>
> Joe
I read through the entire thread and did not see one mention of the
GNU Lesser GPL, which may be a viable license to use for this purpose.
--
Paul M Edwards
"Paul the PC Physician"
http://paul.thepcphysician.com/
Sick computer? Call me!
253.332.9872
Joe Born
binaries along with the source. That was one of the big issues that
stopped us from being able to effectively "open" the source on the
original Neuros. If we can't do that, then well, agreed, we're kind of
a joke calling ourselves open source, and we pretty much just need to
focus on getting Rockbox to work on the device. I'm actually going to
start another thread on that subject (Rockbox on dev board).
-----Original Message-----
From: Neuros-DM3...@googlegroups.com
[mailto:Neuros-DM3...@googlegroups.com] On Behalf Of Daniel
Stenberg
Sent: Wednesday, March 08, 2006 5:30 AM
To: Neuros-DM3...@googlegroups.com
Subject: RE: source code stat?
On Tue, 7 Mar 2006, Joe Born wrote:
> There simply are no open source substitutes.
I'm still curious if other parties are also allowed to redistribute
those
binary objects in your SVN repository. The license excerpt didn't
clarify
that.
--
-=- Daniel Stenberg -=- http://daniel.haxx.se -=-
ech`echo xiun|tr nu oc|sed 'sx\([s\x]\)\([\xoi]\)xo un\2\1 is xg'`ol
Joe Born
really can't be used for anything else. No?
Joe
-----Original Message-----
From: Neuros-DM3...@googlegroups.com
[mailto:Neuros-DM3...@googlegroups.com] On Behalf Of Paul M
Edwards
Sent: Wednesday, March 08, 2006 1:44 PM
To: Neuros-DM3...@googlegroups.com
Subject: Re: source code stat?
------------------------------------------------------------
Dragon Wisard
Please visit my website:
http://www.dragonwisard.net/
Joe Born
Can we see a diagram showing the modules that exist and what licenses
they have and how they link?
How does everyone else get a graphic image of what the code looks like
and what modules, files there are and links to what?
Here is my current understanding, all please chime in where you think
I'm missing something:
We have a distribution of Linux, obviously governed by the GPL as Linus
interprets it. We have to rely on the great body of users that have
created these proprietary modules, etc that these are legal. It was my
assumption, perhaps incorrect, that although those modules were not
required to be open source, if they were required to compile, they would
be required to be freely distributed. If not, what is the requirement
for these modules. If nothing else, my understanding is that we will
compile these into a "blob" for lack of a better term and that will be
able to be distributed, so that it can be compiled and you can actually
do something with the code. That was the understanding of our contract
with Ingenient.
We have an application that we are creating from scratch (as I
understand it) that sits on top of Linux so we do have licensing options
there, but it has been my assumption from the start that it will be GPL
for all the reasons discussed in this thread (ability to incorporate
other GPL code, etc).
Then we have this "framework" or API whatever that is. I'm not really
clear how it connects to anything else. I need the diagram here.
Finally we have the binaries that sit on the DSP and we don't touch
those. My understanding is that it's accessed by one of the proprietary
modules, and basically the code on the DSP sits on the DSP and is not
updated or distributed. It's kind of like the PSOC or micro programs
that just reside in the HW and are not linked to other software modules
at all. I need the diagram here too.
For those of you that are concerned, please understand that I'm not
viewing my understanding as a substitute for a complete legal opinion,
but a necessary step towards getting that opinion and putting it in the
appropriate context.
Joe
-----Original Message-----
From: Neuros-DM3...@googlegroups.com
[mailto:Neuros-DM3...@googlegroups.com] On Behalf Of Vladimir
Pantelic
Sent: Wednesday, March 08, 2006 6:38 AM
To: Neuros-DM3...@googlegroups.com
Subject: Re: source code stat?
Nathan True wrote:
> The issues here being that these will all be compiled for ARM,
> rendering useless the DSP unless the ARM-side of the proprietary
> modules can be used to control the DSP stuff.
So, doing:
- GPL audio codecs and parsers on ARM side
- GPL DSP API on ARM side
- Binary only DSP FW on DSP
should be fine with the GPL, there are binary only FWs for WLAN cards
etc. that somehow can work with the GPL. But linking with a "closed" DSP
control API on the ARM with GPL code I fear will not work.
Regards,
>
> Chairman Gao, is this the case?
>
> Vladimir Pantelic wrote:
>>Nathan True wrote:
>>
>>
>>>"extension" of GPL code. As for the DSP-side code, communicating
>>>with a separate CPU is going to be far less of a link than running on
>>>the same CPU and as such will be less of an issue than proprietary
>>>ARM-side code.
>>>
>>
>>Yes, the DSP side stuff could be OK with the GPL
>>
>>
>>>My apologies to the Open Source idealists out there, but Neuros is a
>>>business that ultimately needs to make its decisions in favor of
>>>profits (even if only so its employees and their families get paid).
>>>Thus your alternatives such as "cancelling the project completely"
>>>and "writing open-source codecs for everything before launching the
>>>products" are simply not viable (the latter because it would take too
>>>much development time for a product that may already be losing out on
>>>the bleeding edge, and the former I suppose to be obvious).
>>>
>>
>>Beside the DSP stuff you got audio decoders and file format parsers
>>and there are open source alternatives for almost all of them, like
>>MAD for MP3, liba52 for AC3, faad for AAC, ffmpeg for WMA, AVI, ASF,
>>MP4. So actually you could use a lot of existing open source, no? As
>>you plan to make an open source device, you are not banned from using
>>open source codecs.
>>
>>Regards,
>>
>>
>>
>>
>
>
------------------------------------------------------------
Mail was checked for spam by the Freeware Edition of No Spam Today! The
Freeware Edition is free for personal and non-commercial use. You can
remove this notice by purchasing a full license! To order or to find out
Michael Gao
> Can we see a diagram showing the modules that exist and what licenses
> they have and how they link?
>
joe...@gmail.com
platform, I've done a considerable amount of research.
http://www.rosenlaw.com/oslbook.htm and particuliarly
http://www.rosenlaw.com/Rosen_Ch06.pdf and
http://www.rosenlaw.com/Rosen_Ch12.pdf
Which also led me to
http://en.wikipedia.org/wiki/Mozilla_Public_License
and http://www.gnu.org/philosophy/netscape-npl.html
and http://www.croftsoft.com/library/tutorials/gplmpl/
I'm sure folks have opinions about the above, and I'd be interested in
hearing them...
Daniel Stenberg
> I'm sure folks have opinions about the above, and I'd be interested in
> hearing them...
MPL is deemed not compatible with GPL. That has in itself turned out such a
big issue to Mozilla itself that they dual or triple license theire code these
days (GPL/LGPL/MPL).
Joe Born
such a
>big issue to Mozilla itself that they dual or triple license theire
code these
>days (GPL/LGPL/MPL).
I've noticed that. I don't believe MPL is viable for us for just that
reason. I mainly included that link because I think the debate is
interesting, particularly in combination with Rosen's analysis of the
GPL/LGPL and linking. More on that shortly.
Daniel Stenberg
> particularly in combination with Rosen's analysis of the GPL/LGPL and
> linking.
Yes, Rosen's view on that (linking on what right licenses have on that) is not
the same as the FSF has.
But then as usual, law needs to be tested in court for us to know exactly how
to interpret such things.
Personally I think reading every paragraph literally is the wrong way.
Following the spirit and the intention of the licenses is better and generally
keeps more people (that have written or offers software) happy.
Joe Born
My feeling after considerable research (on both the legal and the
"spirit") is that we should allow the authors (to the extent we can find
them) determine how the code should be used. This is just part of
obeying the unwritten rules of open source. Linking seems to be a gray
area, but even things like forking that are clearly legal, should
avoided as much as possible for just that reason.
Basically, Linux is our software base, and Linus has made his views on
linking known. For applications that we initiate, we will follow those
similar guidelines. When it comes to other applications, Rockbox,
MythTV, etc we'll follow the guidelines set by the authors, or
representatives of the authors. In many cases, this may not have much
legal standing, but given what I've read, I don't really believe that
poses a huge risk for a few reasons:
1. Approval (formally or informally) of what we're doing from
"representatives" of the group means that it's very unlikely we're going
to get sued by them
2. If we are careful with the linking so as not to create "derivative
works" based on the copyright definition, it seems what we're doing is
legal anyway.
Bear in mind that it's not our intention to create a bunch of
proprietary modules, our development will be open source will outside
contributors on the same terms etc. This issue just surrounds getting
started and how to create this framework and stitch together the
proprietary pieces that we were given. Over time hopefully we can find
open source replacements for those.
My next question is, is there a solution that would allow Rockbox to be
implemented on the N3 with the FSF interpretation of linking? I guess
this would *not* be as an application on Linux but rather with some kind
of "bridge" to the DSP for talking to the Audio codecs?
-----Original Message-----
From: Neuros-DM3...@googlegroups.com
[mailto:Neuros-DM3...@googlegroups.com] On Behalf Of Daniel
Stenberg
Sent: Tuesday, March 21, 2006 2:59 PM
To: Neuros-DM3...@googlegroups.com
Subject: RE: source code stat?
------------------------------------------------------------
Daniel Stenberg
> My next question is, is there a solution that would allow Rockbox to be
> implemented on the N3 with the FSF interpretation of linking? I guess this
> would *not* be as an application on Linux but rather with some kind of
> "bridge" to the DSP for talking to the Audio codecs?
Treating and considering the DSP as a sepearate entity that it would "talk to"
using some defined way, where the DSP side would be closed, would be perfectly
legal and fine license wise. I mean, Rockbox already runs on 12-14 targets now
and we don't have source code to any HW it interacts with. I figure we can
consider the DSP part of the chip to be "just another" codec chip.
The problem would be if talking to the DSP would need to be done using a
closed source lib of some kind.
(I should clarify that these are my opinions and views, I'm not speaking for
any group.)
--
Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Joe Born
-----Original Message-----
From: Neuros-DM3...@googlegroups.com
[mailto:Neuros-DM3...@googlegroups.com] On Behalf Of Daniel
Stenberg
Sent: Tuesday, March 21, 2006 3:54 PM
To: Neuros-DM3...@googlegroups.com
Subject: RE: source code stat?
------------------------------------------------------------
Bob Faskos
There will be the need for some "closed lib" in order to comply with the license of the CODEC vendor.
There are 2 cases of such:
1: Loadable modules, in kernel space.
There is the linking gray area there, but lots of people do it. For example, there are divers for video cards that are not available in source code.
Linus has openly declared that he will not go after protected IP in loadable modules, exactly to promote support for hardware that would otherwise not be available in Linux.
2: Parts of user space code that have "closed license" terms, such as file format parsers, etc.
These are libraries that can (must) be linked by an application in order to make them work.
Neuros will have to provide an abstraction layer that allows open source code to use IP provided by these 2 forms of closed license.
Bob
Daniel Stenberg
> 2: Parts of user space code that have "closed license" terms, such as
> file format parsers, etc.
For Rockbox we wouldn't use any closed source file format parsers etc. We'd
use our own set of codecs and meta data parsers that already work fine on
several platforms.
The question now was only if we can make sound with Rockbox without the use of
closed source libs. Or rather how hard it would be, since we can always - as a
last resort - reverse engineer your required libs should there be any, and
hack this the hard way.
> These are libraries that can (must) be linked by an application in order
> to make them work.
Is this true even when we don't want to use your codecs/file parsers?
> Neuros will have to provide an abstraction layer that allows open source
> code to use IP provided by these 2 forms of closed license.
I don't see how you can manage to do this for Rockbox. Rockbox is not Linux.
Vladimir Pantelic
>
> There will be the need for some "closed lib" in order to comply with
> the license of the CODEC vendor.
> There are 2 cases of such:
> 2: Parts of user space code that have "closed license" terms, such as
> file format parsers, etc.
> These are libraries that can (must) be linked by an application in
> order to make them work.
What do you need those for? There is ton's of open source code that can
read/write AVI, ASF, MP3 etc. so why used a closed source lib???
____________________________________________________________________________
This email and any files transmitted with it are confidential and are
intended solely for the use of the individual or entity to which they are
addressed. Access to this e-mail by anyone else is unauthorised. If you are
not the intended recipient, any disclosure, copying, distribution or any
action taken or omitted to be taken in reliance on it, is prohibited. E-mail
messages are not necessarily secure. Archos does not accept responsibility
for any changes made to this message after it was sent.
Steven Robertson
Hash: SHA1
Daniel Stenberg wrote:
> On Tue, 21 Mar 2006, Bob Faskos wrote:
>
>> 2: Parts of user space code that have "closed license" terms, such as
>> file format parsers, etc.
>
> For Rockbox we wouldn't use any closed source file format parsers etc. We'd
> use our own set of codecs and meta data parsers that already work fine on
> several platforms.
In fact, for audio platforms, we may share your code for some things,
like metadata support and a FLAC codec. AFAIK, we will attempt to keep
as much as practical completely open-source (as in: completely on the
ARM), and it's an obvious choice to use your stuff and just send changes
upstream.
(However, Neuros is a business, not an ideology. It seems Neuros has
embraced open source because it's the right thing to do; but if the
closed code has a significant advantage (e.g. in terms of battery life),
then I imagine they'll choose that.)
> The question now was only if we can make sound with Rockbox without the use of
> closed source libs. Or rather how hard it would be, since we can always - as a
> last resort - reverse engineer your required libs should there be any, and
> hack this the hard way.
>
>> These are libraries that can (must) be linked by an application in order
>> to make them work.
>
> Is this true even when we don't want to use your codecs/file parsers?
I'm not absolutely positive, but I believe that hardware resources like
the D/AC can be accessed from the ARM half, meaning open source all the
way is possible. However, features like video decoding will *not* be
available to you, as those require the much more efficient DSP to do.
IANA real developer, so don't take my word for it.
>> Neuros will have to provide an abstraction layer that allows open source
>> code to use IP provided by these 2 forms of closed license.
>
> I don't see how you can manage to do this for Rockbox. Rockbox is not Linux.
>
If you don't plan to support video, and want to use codecs that run on
the ARM half, then I don't believe we'll need to.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEIWlqTN19gvIugIoRAi9zAKCM9EjafcgbW0FjRnQUJDZmRS/bkACbB1pC
s3BzL8zYFaBwm589yhUgkD4=
=oFdp
-----END PGP SIGNATURE-----
Steven Robertson
Hash: SHA1
Vladimir Pantelic wrote:
> What do you need those for? There is ton's of open source code that can
> read/write AVI, ASF, MP3 etc. so why used a closed source lib???
On a 200MHz ARM9 CPU? The DSP completely annihilates the CPU in terms
of encode/decode performance on the DM320. We couldn't support the
quality we do if we chose to go open-source all the way; or at least,
not within a reasonable time frame.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEIWokTN19gvIugIoRAr+bAKCNQTZGwszA3+0HazpJ7Z2LEC82BQCfXqQn
a8LEF7G0K66W2CBFk9OoX3s=
=AKq5
-----END PGP SIGNATURE-----
Vladimir Pantelic
> Vladimir Pantelic wrote:
> >What do you need those for? There is ton's of open source code that can
> >read/write AVI, ASF, MP3 etc. so why used a closed source lib???
>
> On a 200MHz ARM9 CPU? The DSP completely annihilates the CPU in terms
> of encode/decode performance on the DM320. We couldn't support the
> quality we do if we chose to go open-source all the way; or at least,
> not within a reasonable time frame.
actually, sorry.
Anyway, a 200MHz ARM should be happy to decode MP3 and be even a bit bored.
Also, the "closed" audio codecs run on the ARM as well, so at least for
audio open
source is a way to go. The only thing that *needs* to be done on the
DSP is video
codecs, but the DPS we can treat as a separate CPU and live with closed
source.
Everything else can be done open IMHO.
Michael Gao
> Bob, Gao, can you guys answer the "closed source lib" question?
>
For none Linux application, no, I don't see _any_ closed source lib is
required. Back with N1 and N2, we used BIOS and audio Codecs from TI,
which came in the format of libs. But with DM320, we can treat DSP core
as another 'Codec Chip', code to encapsulate DSP core to be a Codec Chip
can be all open source. The question is the time it takes to develop the
encapsulation code.
To encapsulate audio, it will be pretty simple, as it is just a matter
of setting up DMA/McBSP/Interrupts and wiring data between ARM and DSP.
Video will be much harder if practical at all.
/MG
Joe Born
On a 200MHz ARM9 CPU? The DSP completely annihilates the CPU in terms
of encode/decode performance on the DM320. We couldn't support the
quality we do if we chose to go open-source all the way; or at least,
not within a reasonable time frame.
<snip>
I believe there is some confusion here. Rockbox is an audio application
and per the previous discussion does not "allow" linking to proprietary
software, nor require the video DSP code.
The Neuros "platform" however, does use a combination of Linux and
proprietary modules via a multimedia framework, and of course uses the
DSP video code.
So these two approaches are not compatible. The question is is there an
alternate way the Rockbox can get the audio to play outside of our
proprietary framework? They already have the necessary codecs that run
on the ARM...
Vladimir Pantelic
><snip>
>
>On a 200MHz ARM9 CPU? The DSP completely annihilates the CPU in terms
>of encode/decode performance on the DM320. We couldn't support the
>quality we do if we chose to go open-source all the way; or at least,
>not within a reasonable time frame.
>
><snip>
>
>I believe there is some confusion here. Rockbox is an audio application
>and per the previous discussion does not "allow" linking to proprietary
>software, nor require the video DSP code.
>
Yes, but I was referring to the Neuros code which is under the same license,
namely the GPL, as Rockbox - at least what is in the SVN. This code links
to closed source file format parsers and arm side audio codecs for which
open
source replacements could be found. So my question is, why use the
closed stuff
when you want to be open source?
Steven Robertson
Hash: SHA1
> I believe there is some confusion here. Rockbox is an audio application
> and per the previous discussion does not "allow" linking to proprietary
> software, nor require the video DSP code.
>
> The Neuros "platform" however, does use a combination of Linux and
> proprietary modules via a multimedia framework, and of course uses the
> DSP video code.
>
> So these two approaches are not compatible. The question is is there an
> alternate way the Rockbox can get the audio to play outside of our
> proprietary framework? They already have the necessary codecs that run
> on the ARM...
Yup. As listed on the updated dev board spec page:
"A stub program will be created in the DSP to allow ARM code to have
access to the ADC/DAC, allowing completely ARM-based and open-source
applications to be created."
That was taken from Bob Faskos' full spec:
"Since the McBSP registers are only accessible by the DSP side of the
DM320, only DSP programs have the ability to configure this interface.
However, it is possible to create a stub in the DSP code to relay
settings originating from ARM code to the McBSP interface. Once
initialization is complete, it is possible to create memory mappings in
such a way that the McBSP will get outgoing samples and put incoming
samples directly into memory accessible by the ARM."
Meaning that with a little bit of caution, we can produce an audio-only
version of Rockbox or even the Neuros app which can be open-source
top-to-bottom.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEIacRTN19gvIugIoRAgclAJ44thHQP1FausSoqM2rehP5oUs3oACg1wcV
/HUUdCzaShdFAYrtYn0xGqU=
=/f4u
-----END PGP SIGNATURE-----
Daniel Stenberg
> (However, Neuros is a business, not an ideology. It seems Neuros has
> embraced open source because it's the right thing to do; but if the closed
> code has a significant advantage (e.g. in terms of battery life), then I
> imagine they'll choose that.)
If Neuros goes with Rockbox then using closed source codecs is simply not a
choice, be it a business or not.
> If you don't plan to support video, and want to use codecs that run on the
> ARM half, then I don't believe we'll need to.
I'm convinced Rockbox will show video in the future (and it already does on
the Archos Recorder models).
Bob Faskos
Vladimir Pantelic wrote:
Bob Faskos wrote:There will be the need for some "closed lib" in order to comply with the license of the CODEC vendor. There are 2 cases of such: ... 2: Parts of user space code that have "closed license" terms, such as file format parsers, etc. These are libraries that can (must) be linked by an application in order to make them work.What do you need those for? There is ton's of open source code that can read/write AVI, ASF, MP3 etc. so why used a closed source lib???
Bob Faskos
Rockbox is audio-only.
We can easily provide an open source DSP load that pass PCM samples from
the audio codec to the ARM.
No close licensed materials needed.
As a matter of fact, we could even place some fancy equalizer or other
audio processing on the DSP and have it "free of charge" as far as ARM
MIPS are concerned.
The DSP and ARM can share some of the SDRAM address space, so passing
the samples is a piece of cake.
On top of that, it abstracts the DSP from the process, something that
most Open Source people will be happy to see.
And if you want source code and have the tools ... just go ahead and
roll up the sleeves.
In other words, it is possible to have an audio system entirely open.
I am all for that.
Bob
Björn Stenberg
> I believe there is some confusion here. Rockbox is an audio application
> and per the previous discussion does not "allow" linking to proprietary
> software, nor require the video DSP code.
Rockbox will not remain limited to audio. As mentioned before we already play video on Archos models and a lot of people want to play video on other models as well. We just haven't got around to it yet.
As both Daniel and Vladimir noted there is no problem with having proprietary code in the DSP, since it is a separate product not derived from GPL code. Only on the CPU side must we remain 100% open source.
What this means is that we can support anything in Rockbox, if you just provide DSP API documentation and the binary "black box" file that we upload to the DSP.
--
Björn
Vladimir Pantelic
> What this means is that we can support anything in Rockbox, if you just provide DSP API
> documentation and the binary "black box" file that we upload to the DSP.
So, 2 questions to the Neuros guys:
- Would the license given to Neuros from the DSP SW supplier allow that?
- do you have knowledge about the "raw" DSP API or is is hidden inside
the ARM-side closed source objects?
Vladimir Pantelic
>
> Beacuse they are intimately connected with the user code that knows how
> to use the rest of the system.
OK, I understand that, but "intimately connected" sounds like something that
does not go well with the GPL.
I realise now that we talk about 2 things, one being a truly open source
product (maybe using Rockbox) the other is your app that will run on
the 442. This one you have put under the GPL, but I doubt it will work
out this way. I imagine buying the 442 and then asking you for all the
"source" needed to build the app.
Joe Born
-----Original Message-----
From: Neuros-DM3...@googlegroups.com [mailto:Neuros-DM3...@googlegroups.com] On Behalf Of Vladimir Pantelic
Sent: Thursday, March 23, 2006 3:45 AM
To: Neuros-DM3...@googlegroups.com
Subject: Re: source code stat?
Björn Stenberg wrote:
------------------------------------------------------------
Joe Born
Vladimir Pantelic wrote:
>OK, I understand that, but "intimately connected" sounds like something
that does not go well with the GPL.
>I realise now that we talk about 2 things, one being a truly open
source product (maybe using Rockbox) the >other is your app that will
run on the 442. This one you have put under the GPL, but I doubt it will
work out >>this way. I imagine buying the 442 and then asking you for
all the "source" needed to build the app.
Well, as we've established, GPL does not equal GPL. In other words the
fsf interpretation of linking and GPL is not the same as Linus'
interpretation. In the absence of some clarifying case law (which
hopefully is not immediately forthcoming) it seems reasonable to simply
respect the author's wishes on this linking issue. i.e. Rockbox does
not allow linking, then we don't link. However, for Linux and Neuros
initiated code, although Still GPL, linking (as long as that linking is
not a "derivative work") is allowed.
There are currently lots of proprietary modules to Linux that are not
GPL, and as far as I can tell, there's no real evidence that it's in
violation of the GPL. I also would argue that's its only in violation
of the spirit, if it violates the author's wishes (thus our approach
above). It's not correct to argue that it's inconsistent with the
spirit of open source since academic licenses are well recognized and
have no reciprocity provisions at all.
This creates a strange situation where Linux/Neuros GPL is something
like a "universal donor" code, a little like BSD, in that our code can
be used as part of the Rockbox code, but not the other way around.
Hopefully as proprietary code is replaced with open source, this forked
code can be merged...
Anyway, that's my conclusion based on my research. Further discussion
is certainly welcomed.
Joe
ghav...@comcast.net
Yes, I think it would be nice if it were all open source and that I could get in and muck with any part of it, but if that stuff has to be isolated, so be it.
As long as all the code talking to the DSP code is open, I think that's a great start, and working to replace the proprietary stuff running on the DSP with open stuff over time is a way to go.
Greg
andrew fresh
> Well, as we've established, GPL does not equal GPL. In other words the
> fsf interpretation of linking and GPL is not the same as Linus'
> interpretation. In the absence of some clarifying case law (which
> hopefully is not immediately forthcoming) it seems reasonable to simply
> respect the author's wishes on this linking issue. i.e. Rockbox does
> not allow linking, then we don't link. However, for Linux and Neuros
> initiated code, although Still GPL, linking (as long as that linking is
> not a "derivative work") is allowed.
>
> There are currently lots of proprietary modules to Linux that are not
> GPL, and as far as I can tell, there's no real evidence that it's in
> violation of the GPL. I also would argue that's its only in violation
> of the spirit, if it violates the author's wishes (thus our approach
> above). It's not correct to argue that it's inconsistent with the
> spirit of open source since academic licenses are well recognized and
> have no reciprocity provisions at all.
I just ran across this article that seems to say that Linux in general
is running into these same issues.
"Efforts to bring glitzy new graphics to Linux are fueling an old
conflict: Does proprietary software belong in open-source Linux?"
http://news.zdnet.com/2100-3513_22-6061491.html?tag=st.prev
l8rZ,
--
andrew - ICQ# 253198 - JID: afr...@jabber.org
Proud member: http://www.mad-techies.org
BOFH excuse of the day: Internet shut down due to maintenance