Re: FYI: Savannah forces new projects to use GFDL for documentation
Sune Vuorela <[EMAIL PROTECTED]> writes: > On 2006-02-09, Matthew Palmer <[EMAIL PROTECTED]> wrote: >> What really got me saying "whoa!" though is the blog post linked from the >> ticket comments -- the fourth paragraph seems to say that Savannah changed >> it's policy because Debian doesn't think the GFDL is DFSG-free. Worrying, >> if true. > > The blog entry is now gone. Any one got a copy ? The policy statement in the FAQ seems to have changed: >For documentation, we are currently clarifying exactly what licenses we >accept. Of course, we accept our GNU Free Documentation License (and >compatibles), even if it is not compatible with the GNU GPL. Interesting. cheers, Rich. -- rich walker | Shadow Robot Company | [EMAIL PROTECTED] technical director 251 Liverpool Road | need a Hand? London N1 1LX | +UK 20 7700 2487 www.shadow.org.uk/products/newhand.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FYI: Savannah forces new projects to use GFDL for documentation
Felix Kühling <[EMAIL PROTECTED]> writes: > Hi, > > I was trying to get my project DRIconf hosted at Savannah (Non-GNU) and > found out that as of recently Savannah requires all new projects to > license their documentation under the GFDL, which we all know, Debian > considers non-free. Dual-licensing under GFDL and GPL is apparently > still ok. See also > http://savannah.gnu.org/task/?func=detailitem&item_id=5214. Odd. The hosting policies at http://savannah.gnu.org/faq/?group_id=5802&question=Project_-_How_to_get_it_approved_quickly.txt say: # GNU GPL-compatible license: your license should be listed as # compatible at # http://www.gnu.org/licenses/license-list.html. Alternatively you can # use the GNU Free Documentation License for technical # documentation. You can also use the Affero GPL. cheers, Rich. -- rich walker | Shadow Robot Company | [EMAIL PROTECTED] technical director 251 Liverpool Road | need a Hand? London N1 1LX | +UK 20 7700 2487 www.shadow.org.uk/products/newhand.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPL v3 Draft
Michael Poole <[EMAIL PROTECTED]> writes: > Alexander Terekhov writes: > >> Yeah. So legal mandates like, for example, >> >> http://www.courts.state.va.us/text/scv/amendments/rule_71_75_SC.html >> >> >> When the communication is in writing, the disclaimer shall be in bold >> type face and uppercase letters in a font size that is at least as large >> as the largest text used >> > > You fail at reading comprehension. Try reading the rest of rule 7.2. For those reading along at home, rule 7.2 applies to *advertisements placed by lawyers*, rather than, say, warranty disclaimers in contracts. cheers, Rich. -- rich walker | Shadow Robot Company | [EMAIL PROTECTED] technical director 251 Liverpool Road | need a Hand? London N1 1LX | +UK 20 7700 2487 www.shadow.org.uk/products/newhand.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
Alexander Terekhov <[EMAIL PROTECTED]> writes: > On 9/16/05, Rich Walker <[EMAIL PROTECTED]> wrote: >> Alexander Terekhov <[EMAIL PROTECTED]> writes: >> >> > On 9/14/05, Andrew Suffield <[EMAIL PROTECTED]> wrote: >> > [...] >> >> As an anarchist I >> > >> > You're brainwashed GNUtian. >> >> Wow. > > Anarchists are anti-copyright and against fake free software. You *are* aware that anarchism isn't a monolithic block, aren't you. > > http://timtyler.org/fake_free_software/ An interesting restatement of the BSD vs GPL argument. Of course, it relies on an unstated definition of the word "Free". > At least when it comes to [L]GPL, GNUtians are quite pro-copyright... > nevermind that they confuse engineering dependencies with copyright > infringement, don't grok first sale, and happen to believe in Moglens > "pure copyright license, not a contract" lunacy. I always thought that the GPL was an interesting hack using the methods of copyright and contract law to create a public commons that hopefully could be kept inviolate. Which, funnily enough, is a very anarchist thing to do (look at housing co-operatives for another example). cheers, Rich. -- rich walker | Shadow Robot Company | [EMAIL PROTECTED] technical director 251 Liverpool Road | need a Hand? London N1 1LX | +UK 20 7700 2487 www.shadow.org.uk/products/newhand.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
Alexander Terekhov <[EMAIL PROTECTED]> writes: > On 9/14/05, Andrew Suffield <[EMAIL PROTECTED]> wrote: > [...] >> As an anarchist I > > You're brainwashed GNUtian. Wow. I think that's the *least relevant* rejoinder I've ever seen. cheers, Rich. -- rich walker | Shadow Robot Company | [EMAIL PROTECTED] technical director 251 Liverpool Road | need a Hand? London N1 1LX | +UK 20 7700 2487 www.shadow.org.uk/products/newhand.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: EUPL draft
trade register in which the Licensor is entered and his registration number, the different technical steps to follow to conclude the Licence, prior to the Distribution and/or the Communication of the Work, where the Licence contract will be accessible, the languages which can be used for the conclusion of the Licence. The Licence terms provided to the Licensee must be made available in a way that allows him to store and reproduce them. 12. Termination of the Licence The Licence and the rights granted hereunder will terminate automatically upon any breach by the Licensee of the terms of the Licence. Such a termination will not terminate the licences of any person who has received the Work from the Licensee under the Licence, provided such persons remain in full compliance with the Licence. 13. Miscellaneous Without prejudice of article 9 above, the Licence represents the complete agreement between the Parties as to the Work licensed hereunder. If any provision of the Licence is invalid or unenforceable under applicable law, this will not affect the validity or enforceability of the Licence as a whole. Such provision will be construed and/or reformed so as necessary to make it valid and enforceable. 14. Jurisdiction Any litigation resulting from the interpretation of this license, arising between the European Commission, as a Licensor, and any Licensee, will be subject to the jurisdiction of the European Court of Justice, as laid down in article 238 of the Treaty establishing the European Community. Any litigation arising between parties other than the European Commission, and resulting from the interpretation of this license, will be subject to the exclusive jurisdiction of the competent court: · where the Licensor resides or conducts its primary business, if Licensor resides or conducts its primary business inside the European Union; · where the Licensee resides or conducts its primary business if Licensor resides or conducts its primary business outside the European Union; page 5 of 6 © European Community 2005 EUPL v.01-EN · where the Licensor resides or conducts its primary business, if both the Licensor and the Licensee reside or conduct their primary business outside the European Union. 15. Applicable Law This License shall be governed by the law of the European Union country where the Licensor resides or has his registered office. This License shall be governed by the Belgian Law if a litigation arises between the European Commission, as a Licensor, and any Licensee. This License shall also be governed by the Belgian Law if the Licensor has no residence or registered office inside a European Union country. © European Community 2005 page 6 of 6 -- rich walker | Shadow Robot Company | [EMAIL PROTECTED] technical director 251 Liverpool Road | need a Hand? London N1 1LX | +UK 20 7700 2487 www.shadow.org.uk/products/newhand.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On the definition of source
"Michael K. Edwards" <[EMAIL PROTECTED]> writes: [snip] > If you're going to accept programs for inclusion in main that are > written and maintained by people with an agenda -- which includes but > is not limited to corporate backers who profit from the sale of tied > produces and services -- you have to recognize that not everything > about their design goals and inner wokings is fully disclosed. The > classic example is DES; the S-boxes were designed to be resistant to > differential cryptanalysis, which was unknown in the public literature > at the time (see > http://en.wikipedia.org/wiki/Differential_cryptanalysis ). Commercial > users just had to take the NSA's (i. e., MITRE's) word for it that > S-box tweaking was motivated by a desire to strengthen DES rather than > to Trojan it. I think you mean: The story that is circulated now about the tweaking of the S-box is that it was to make DES more resistant to differential cryptanalysis, which was unknown at the time. Once you allow systems to exist with poor disclosure of the construction process of their internals, you have opened up a back door wide enough to drive a thousand exploits through. If you are aware that the providers of the system have an agenda, then it actually makes sense to work *harder* on the "full disclosure of all components necessary to reconstruct" angle than you would otherwise. (Yes, I *am* in the business of producing stuff that you can only reproduce part of from the design data.) cheers, Rich. -- rich walker | Shadow Robot Company | [EMAIL PROTECTED] technical director 251 Liverpool Road | need a Hand? London N1 1LX | +UK 20 7700 2487 www.shadow.org.uk/products/newhand.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MP3 decoder packaged with XMMS
Jack Moffitt <[EMAIL PROTECTED]> writes: [snip, chop, trim] > > Before we released Ogg Vorbis beta 1, we did indeed hire a patent > specializing attorney to go over the MP3 suite of patents. He only > thought it necessary to issue a formal opinion on a single one of these > patents. We were advised by him, and other attorney's, that the > specifics of this opinion could not be divulged publically. Since that > time (around 2000,2001 I believe), I believe several companies have also > had lawyers look over this issue. Thanks for this very informative statement. Two questions spring to mind, one MP3-technical and one patent-technical: 1. which patent was the one worth issuing an opinion on? 2. why was the opinion not to be divulged publically? Clearly, the specific patent is a matter of interest for those developing in this area so they can effectively get advice. The other question is "what kind of useful advice cannot be propagated, and why?"... cheers, Rich. -- rich walker | Shadow Robot Company | [EMAIL PROTECTED] technical director 251 Liverpool Road | need a Hand? London N1 1LX | +UK 20 7700 2487 www.shadow.org.uk/products/newhand.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#317359: kde: ..3'rd "Help"->"About $KDE-app" tab calls the GPL "License Agreement", ie; a contract.
"Sean Kellogg" <[EMAIL PROTECTED]> writes: > "If individual A is authorized to distribute software, and individual B > initiates an action that results in a copy being made of that software from > A's distribution server, has B violated the original author's 106(1) rights? > Or, as I believe Glenn is suggesting (and may be right... question is > really interesting) does the grant to distribute authorize B to give others > the right to copy in the process of distribution?" Given that Debian is a global distribution, perhaps your question should reference something other than local law? I checked '"106(1)" rights' on Google, and it appears to be a US legal concept. As far as the other 6.1 billion of us go, what is our position? cheers, Rich. -- rich walker | Shadow Robot Company | [EMAIL PROTECTED] technical director 251 Liverpool Road | need a Hand? London N1 1LX | +UK 20 7700 2487 www.shadow.org.uk/products/newhand.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Adrian Bunk <[EMAIL PROTECTED]> writes: > On Fri, Apr 08, 2005 at 07:42:51PM +0200, Josselin Mouette wrote: >> Le vendredi 08 avril 2005 à 19:34 +0200, Adrian Bunk a écrit : >> GFDL documentation will still be available in the non-free archive. > > Assuming you have an online connection and a friend told you how to > manually edit your /etc/apt/sources.list for non-free. You *do* know that current versions of the installer ask you if you want non-free, don't you? > But where's the documentation if you don't have an online connection but > only the dozen binary CDs of Debian? Clearly, since the judgement is "it can't be legally distributed as part of a package of Debian CD's", it isn't on a package of Debian CD's. cheers, Rich. -- rich walker | Shadow Robot Company | [EMAIL PROTECTED] technical director 251 Liverpool Road | need a Hand? London N1 1LX | +UK 20 7700 2487 www.shadow.org.uk/products/newhand.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#296369: ITP: spin -- Powerfull model checking and software verification tool
Eike Dehling <[EMAIL PROTECTED]> writes: [snip] > As stated on their website: > > > " Spin is distributed in source form to encourage research in formal > verification, and to help a > support friendly and open exchange of algorithms, ideas, and tools. The > software itself has a > copyright from Lucent Technologies and Bell Laboratories, and is distributed > for research and > educational purposes only (i.e., no guarantee of any kind is implied by the > distribution of the > code, and all rights are reserved by the copyright holder). For this general > use of Spin, no license > is required. > > Commercial application of the Spin software is also allowed, but requires the > acceptance of a basic > license. Refer to the Spin Public license for details. " *Bzzzt* . Check the case of Madey vs. Duke University. If the business of your organisation includes raising money to do research, then your use is probably commercial use. cheers, Rich. -- rich walker | Shadow Robot Company | [EMAIL PROTECTED] technical director 251 Liverpool Road | need a Hand? London N1 1LX | +UK 20 7700 2487 www.shadow.org.uk/products/newhand.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Copyright Question
Brian Thomas Sniffen <[EMAIL PROTECTED]> writes:
> Josh Triplett <[EMAIL PROTECTED]> writes:
>>
>> That seems a bit harsh; I think sarge would be quite usable for this
>> purpose, as long as you avoid GFDLed bits. Is there anything GFDLed in
>> Debian that isn't in /usr/share/{doc,info,man} ?
>
> Gosh, nobody really knows. This is part of why it's annoying to have
> non-free non-program software in Debian.
Which reminds me: why can't I do
apt-cache search GFDL
and get a license?
Shouldn't the license be part of the dpkg -s output?
At present, anyone wanting to select packages based on their license
status has "DFSG-free"/"DFSG-non-free" as the selection criteria.
This seems limiting.
It might be nice, for example in an embedded system, to install packages
that were under "OSS" licenses, excluding "GFDL".
Would it make sense to add a License: field to the status information
available to dpkg?
cheers, Rich.
--
rich walker | Shadow Robot Company | [EMAIL PROTECTED]
technical director 251 Liverpool Road |
need a Hand? London N1 1LX | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml
Re: Hardware license
Walter Landry <[EMAIL PROTECTED]> wrote: > Thomas Uwe Gruettmueller <[EMAIL PROTECTED]> wrote: > > On Monday 02 December 2002 21:04, Walter Landry wrote: > > > Rich Walker <[EMAIL PROTECTED]> wrote: > > > > http://www.opencores.org/OIPC/OHGPL.shtml. > > > > > > The OpenIPCore license is a more of a copyleft, so you'll > > > probably be happier with it. Looking through the license, it > > > looks mostly ok. > > > > There are some points about it that strike me. Maybe I'm > > completely wrong about it... > > > > 1. This license is only a draft. Is it a good idea to use it > > already? Future versions could be incompatible with it. It seems to have been through a discussion period. I am happy when it has been through this one, as long as my IP guy is happy with it. > > 2. Is this license GPL compatible? In the future, digital > > devices will propably use the GPLed F-CPU, so this might be > > a big problem, then. > > I don't think that it is GPL compatible. I need this to be clarified, as it's a fundamental point. If a piece of hardware is placed under an OHGPL license, and someone wants to use a piece of GPL'd hardware or software, how are the licenses incompatible? For example: can't cut-and-paste design chunks from one to the other can't connect outputs of one to inputs of the other can't drive OHGPL hardware from GPL code > > > 3. AFAIK, the copyleft in the GPL is not strong enough to > > prevent that a chip that has been built from a GPLed design > > is bought by a non-licensee, and resold, soldered into a > > non-free circuit. This is like creating a non-free artwork > > out of Debian CDs, but far more severe. I am not sure if > > there is a possible strategy about this at all, and what the > > OHGPL is doing about this. > > It is basically impossible to do what you want. Actually, it's silly to. This would be like (for example) BlueTie forbidding system vendors from providing a purchased boxed set of BlueTie GNU/Linux Deluxe with a built system. Kind of defeats the point of making the boxed set in the first place. The thing you want to prevent is them shipping the system without letting the customer know that it's using BlueTie v 145.22.woody or whatever. Both licenses do this, but the OHGPL is a little more appropriate to generating things-that-are-physical. > When you sell a > person a physical thing, they automatically gain certain rights. They > are free to do modify the thing however they want and then resell it. > This is part of the basic consumer guarantees that you get when you > buy something (at least in 49 states in the US). > > > 4. I can't find the phrase that allows distribution of a > > modified version. > > Oops. You're right. You can fix this by changing paragraph 2 from > > 2. You may copy, distribute and/or implement ... > > to > > 2. You may copy, modify, distribute and/or implement ... okay. > > > 5. Paragraph 3, which forbids selling but allows a fee OTOH, > > seems to be against the wording of DFSG 1. Is there a > > license that has been classified DFSG-free which uses a > > similar wording? > > This is fine. There are other licenses that don't allow selling the > software per se. The DFSG only requires the ability to sell it as > part of an aggregate software distribution. It does make it GPL > incompatible, though. I thought DFSG-1 was to prevent the "You must pay us $0.01 if you sell a copy of this"; Certainly, I think, 3 is compatible with DFSG-1. > > Regards, > Walter Landry > [EMAIL PROTECTED] > > > >
Hardware license (status)
> We've been putting together some robot-related software and hardware. We > want to release this with a DFSG-compliant license set. For the > software, GPL, no problems. For the hardware we propose to include .pcb > files for pcb, .sch files for gschem, and .asm files for the PIC > firmware. What licenses are appropriate for hardware releases? After interesting discussion on and off debian-legal, I'm now down to a choice of one hardware license for everything except the firmware which will be GPL'd. The hardware license is probably the OHGPL <http://www.opencores.org/OIPC/OHGPL.html> with clause 2 modified to read You may copy, modify, distribute, and/or ... The outstanding problem (AFAICT) is the suggestion that hardware under the OHGPL might not be compatible with GPL-d hardware or software. I've cc'd this to the opencores people in case they have any thoughts; otherwise, does anyone *disagree* that this is DFGS-compliant? cheers, Rich. -- rich walker | technical person | Shadow Robot Company | [EMAIL PROTECTED] front-of-tshirt space to let 251 Liverpool Road | London N1 1LX | +UK 20 7700 2487
Re: Hardware license
> Envelope-to: [EMAIL PROTECTED] > Date: Mon, 02 Dec 2002 12:04:34 -0800 (PST) > Cc: debian-legal@lists.debian.org > From: Walter Landry <[EMAIL PROTECTED]> > X-UIDL: 1038859920.21444.elm.eurobell.net > X-RCPT: shadowrp > X-Spam-Status: No, hits=-0.5 required=5.0 > tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_05_08 > version=2.43 > X-Spam-Level: > > Rich Walker <[EMAIL PROTECTED]> wrote: > > Walter Landry <[EMAIL PROTECTED]> writes: > > > > [snip] > > > > > > Umm; the .sch and .pcb files are not really source code; they are more > > > > like .pdf files. Also, I'm using a GPL rather than BSD license for the > > > > traditional philosophical reasons: this is an addition to the commons, > > > > rather than a gift to the public domain. > > > > > > If the .sch and .pcb files are not the preferred form for making > > > modifications, then what is? > > > > The .sch file is only the preferred form for making modifications when > > loaded into an application, which presents a rendering of it. You would > > *not* edit the .sch file; you would use gschem to work on it. So it's > > equivalent to, say, a gimp save-file. The .pcb file is similar. > > Well, whatever it is that you use to make modifications is what you > should distribute. That is what most people will want anyway. And, hardware being hardware, you certainly need the .sch, and you probably need the .pcb and the bill of materials and the PIC firmware and ... Which is what we were planning to put in the package anyway; it's just a question of getting the license right. > It sounds like you need additional programs in order to make the final > device. If you like, you can add a special exemption that says that > distributing those programs is not required in order to distribute the > final device (non-source derived work). This is analogous to the > operating system exception already in the GPL. You would need it > because most systems don't come with all of the tools needed to make > hardware. Okay; I see what you're saying. Since (almost) all the tools necessary are available in debian/testing or as free-Beer downloads from hardware vendors I don't see their distribution as being much of an issue, and I'm trying to use an off-the-shelf license rather than a modified one... Thanks, though. cheers, Rich. -- rich walker | technical person | Shadow Robot Company | [EMAIL PROTECTED] front-of-tshirt space to let 251 Liverpool Road | London N1 1LX | +UK 20 7700 2487
Re: Hardware license
> Rich Walker <[EMAIL PROTECTED]> wrote: > > Terry Hancock <[EMAIL PROTECTED]> writes: > > > The LART license is probably required reading on this subject ;-) > > > > > > http://www.lart.tudelft.nl/LICENSE > > This is pretty much the same as the BSD license. You suggested that > you wanted to copyleft your work, so it may not work for you. It is > certainly DFSG-free. Okay; thanks. That's also the precise philosophical point I was hoping someone else would illuminate. > > http://www.opencores.org/OIPC/OHGPL.shtml. > > > > Are these both compliant licenses? > > The OpenIPCore license is a more of a copyleft, so you'll probably be > happier with it. Looking through the license, it looks mostly ok. > The only thing that caught my eye is section 5 > > 5. Any modification of this hardware design or any derivative work > from it should be documented by providing list of changes, > reasons behind the changes and the date of change. > > Requiring people to list the _reasons_ for a change is somewhere > closer to the edge of DFSG-free than I'd like. It might be fine with > it, but it'd be better to just change it to > > 5. Any modification of this hardware design or any derivative work > from it should be documented by providing a list and the date of > the change. For a hardware design, I can see that providing this documentation is more necessary than for a software design. diff doesn't work that well on most sorts of hardware documentation. I'll raise this with the OpenIPCore people and see why they did it this way. cheers, Rich Walker. -- rich walker | technical person | Shadow Robot Company | [EMAIL PROTECTED] front-of-tshirt space to let 251 Liverpool Road | London N1 1LX | +UK 20 7700 2487
Re: Hardware license
Terry Hancock <[EMAIL PROTECTED]> writes: > On Tuesday 26 November 2002 01:59 pm, Rich Walker wrote: > > We've been putting together some robot-related software and hardware. We > > want to release this with a DFSG-compliant license set. For the > > software, GPL, no problems. For the hardware we propose to include .pcb > > files for pcb, .sch files for gschem, and .asm files for the PIC > > firmware. What licenses are appropriate for hardware releases? > > The LART license is probably required reading on this subject ;-) > > http://www.lart.tudelft.nl/LICENSE Yes; I'm currently looking at that and the OpenIPCore license. http://www.opencores.org/OIPC/OHGPL.shtml. Are these both compliant licenses? > and you'll probably want to look at the site in general > > http://www.lart.tudelft.nl/ > > for other information about an apparently successful open > hardware project. cheers for that, Rich Walker. -- rich walker | technical person | Shadow Robot Company | [EMAIL PROTECTED] front-of-tshirt space to let 251 Liverpool Road | London N1 1LX | +UK 20 7700 2487
Re: Hardware license
Walter Landry <[EMAIL PROTECTED]> writes: [snip] > > Umm; the .sch and .pcb files are not really source code; they are more > > like .pdf files. Also, I'm using a GPL rather than BSD license for the > > traditional philosophical reasons: this is an addition to the commons, > > rather than a gift to the public domain. > > If the .sch and .pcb files are not the preferred form for making > modifications, then what is? The .sch file is only the preferred form for making modifications when loaded into an application, which presents a rendering of it. You would *not* edit the .sch file; you would use gschem to work on it. So it's equivalent to, say, a gimp save-file. The .pcb file is similar. > Could you distribute that? In that > case, you could use a slightly modified GPL, where you replace "object > code" with "non-source derivative works". > > Regards, > Walter Landry > [EMAIL PROTECTED] > > -- rich walker | technical person | Shadow Robot Company | [EMAIL PROTECTED] front-of-tshirt space to let 251 Liverpool Road | London N1 1LX | +UK 20 7700 2487
Re: Hardware license
> Rich Walker <[EMAIL PROTECTED]> writes: > > > We've been putting together some robot-related software and hardware. We > > want to release this with a DFSG-compliant license set. For the > > software, GPL, no problems. For the hardware we propose to include .pcb > > files for pcb, .sch files for gschem, and .asm files for the PIC > > firmware. What licenses are appropriate for hardware releases? > > If it's got source code of some sort, then it would seem to me that > the GPL is just fine. Alternatively, you could just use a BSD-style > license. Umm; the .sch and .pcb files are not really source code; they are more like .pdf files. Also, I'm using a GPL rather than BSD license for the traditional philosophical reasons: this is an addition to the commons, rather than a gift to the public domain. cheers, Rich. -- rich walker | technical person | Shadow Robot Company | [EMAIL PROTECTED] front-of-tshirt space to let 251 Liverpool Road | London N1 1LX | +UK 20 7700 2487
Hardware license
Hi, We've been putting together some robot-related software and hardware. We want to release this with a DFSG-compliant license set. For the software, GPL, no problems. For the hardware we propose to include .pcb files for pcb, .sch files for gschem, and .asm files for the PIC firmware. What licenses are appropriate for hardware releases? cheers, Rich. -- rich walker | technical person | Shadow Robot Company | [EMAIL PROTECTED] front-of-tshirt space to let 251 Liverpool Road | London N1 1LX | +UK 20 7700 2487
