Searching \ for '[ADD:]The first and initial release 0.1.1 of the V' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=first+initial+release
Search entire site for: 'The first and initial release 0.1.1 of the V'.

Exact match. Not showing close matches.
PICList Thread
'[ADD:]The first and initial release 0.1.1 of the V'
2004\08\06@104317 by Ake Hedman

flavicon
face
The first and initial release of the VSCP (Very Simple Control Protocol) package has been released.

Following the release of the CANAL (CAN Abstraction Package) on July 21 2004 the first development release of the Very Simple Control Protocol and  friends package has been released today.

VSCP protocol, is a very simple and free protocol for SOHO (Small Office/HOme) automation tasks. The protocol is so easy that everyone can grasp the idea behind it in a few minutes. Therefore it's also very easy to construct and use VSCP aware modules and components. Nodes just start up and then serve the control solution reliable without any fuzz.

VSCP  is, as the name imply, a very simple protocol indeed. It is simple because it has been developed for use on low end devices such as microcontrollers.

Even if the protocol is very easy to use it is still very capable and can be used in very demanding control situation.

Except for a very well specified message format the protocol supports global unique identifiers for nodes, a register model to give a flexible interface to node configuration and a model for node functionality. This model is EDA. EDA which stands for Event, Decision, Action tells how work is carried out by a node. A node can be as complex as needed and do very tough work but to the world it should export an interface following EDA. This is

  1.

     *Event.* The node should be capable of reacting to VSCP messages.
     Each message is considered an event. The node itself decide which
     messages it is interested in except for a very small common subset
     of base VSCP protocol functionality messages.

  2.

     *Decision*. The node has a hard defined or user configurable
     *_decision matrix_*. This matrix tells what should be done when a
     certain event is received.

  3.

     *Action*. The action is what a node performs and the outcome of a
     decision.


The package consist of a service/daemon for the WIN32 platform, a test application in MFC/C++, a ActiveX control plus a test application for Visual Basic. A DLL is included for interfacing the server/service.

A relase for Linux will follow in addition to low level stuff for Microchip PIC and Atmel AVR processors.

The code is release under the GPL and the LPGP licens and is thus maed available for additions chamges inspection by the community.

The specification and more information is available at http://www.vscp.org and http://sourceforge.net/project/showfiles.php?group_id=53560

--  ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org


--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\06@143425 by Wouter van Ooijen

face picon face
> A relase for Linux will follow in addition to low level stuff for
> Microchip PIC and Atmel AVR processors.
>
> The code is release under the GPL and the LPGP licens and is
> thus maed
> available for additions chamges inspection by the community.
>
> The specification and more information is available at
> http://www.vscp.org and
> http://sourceforge.net/project/showfiles.php?group_id=53560

Do you realise that code released under GPL or LGPL is almost useless
for commercial embedded use? We had a long discussion about this on the
jallist.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\06@145017 by Alex Harford

face picon face
On Fri, 6 Aug 2004 20:34:22 +0200, Wouter van Ooijen <spam_OUTwouterTakeThisOuTspamvoti.nl> wrote:
> >
> > The code is release under the GPL and the LPGP licens and is
> > thus maed
> > available for additions chamges inspection by the community.
>
> Do you realise that code released under GPL or LGPL is almost useless
> for commercial embedded use? We had a long discussion about this on the
> jallist.

Is this on the Yahoo Groups archive?  I'd like to read the discussion,
but I can't find it in the archives.

Alex

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\06@145430 by Bob Blick

face picon face
> Do you realise that code released under GPL or LGPL is almost useless
> for commercial embedded use? We had a long discussion about this on the
> jallist.
> Wouter van Ooijen

Other than being hard to enforce in embedded products I see no problem,
unless you are someone who doesn't like the spirit of GPL.

Cheerful regards,

Bob

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\06@150845 by Wouter van Ooijen

face picon face
> > Do you realise that code released under GPL or LGPL is
> almost useless
> > for commercial embedded use? We had a long discussion about
> this on the
> > jallist.
> > Wouter van Ooijen
>
> Other than being hard to enforce in embedded products I see
> no problem,
> unless you are someone who doesn't like the spirit of GPL.

GPL requires that you provide the sources of code you link with the
GPL-ed code. LGPL relaxes this to excempt dynamically linked stuff. For
embedded things this means that if you use GPL-ed code (in a product
that you sell or give away) you are obliged to provide the source. In
most cases this is not something you want to do, but even if you want to
do it: imagine a customer buying a valentine card with a uC that plays
some lovely tune. If the uC code contains GPLed code that customer must
get the source to it, and a copy of the GPL/LGPL text.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\06@151507 by Marc Nicholas

flavicon
face
On Fri, 6 Aug 2004, Wouter van Ooijen wrote:

> GPL requires that you provide the sources of code you link with the
> GPL-ed code. LGPL relaxes this to excempt dynamically linked stuff. For
> embedded things this means that if you use GPL-ed code (in a product
> that you sell or give away) you are obliged to provide the source. In
> most cases this is not something you want to do, but even if you want to
> do it: imagine a customer buying a valentine card with a uC that plays
> some lovely tune. If the uC code contains GPLed code that customer must
> get the source to it, and a copy of the GPL/LGPL text.

No. The customer has the right to request the GPL'd code on demand. They
don't have to be given the source. A very good example of this is Linksys.

-marc

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\06@151921 by Ake Hedman

flavicon
face
Wouter,

I have tried to release all parts that can be of any commercial use and where the GPL will be a problem under the LGPL license. In which way is this a problem? With the LPGP you can use the lib or whatever without sharing your proprietary stuff: Would it be better to go for a dual license of some form?

Regards
/Ake

Wouter van Ooijen wrote:

{Quote hidden}

--  ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org


--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\06@152544 by Marc Nicholas

flavicon
face
part 1 2341 bytes content-type:TEXT/PLAIN; charset=ISO-8859-1; format=flowed (decoded quoted-printable)

I personally prefer BSD style licenses, or the new IBM license. :-)

-marc

On Fri, 6 Aug 2004, Ake Hedman wrote:

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2004\08\06@153339 by Ake Hedman

flavicon
face
Wouter ,

In both  CANAL and VSCP and in the upcoming uP code the lower levels are released under the LGPL. So there is no need to for a user app. using this stuff to release its code. The higher level  parts are GPL  just for sharing so if you use code from the upper levels you have to release your own code as well.

If you compile something together and ship it to a customer and it contains GPL code I can't see why you should bother your customer with this fact. For the developer community however there should be a chance to get the source code from you in some open way.  It's that easy....

Regards
/Ake

Wouter van Ooijen wrote:

{Quote hidden}

--  ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org


--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\06@153548 by Ake Hedman

flavicon
face
Why?

BSD take away allot of freedom from the community. IBM license is something I never looked at.

Regards
/Ake

Marc Nicholas wrote:

{Quote hidden}

--  ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\06@154206 by Wouter van Ooijen

face picon face
> With the LPGP you can use the lib or whatever without
> sharing your proprietary stuff: Would it be better to go for a dual
> license of some form?

I had the same idea with the Jal libraries, but after carefull reading
of the LGPL it is a relaxation of the GPL *only* for dynamical-liked use
of LGPL-ed code. For the Jal-libraries I/we are switching to the zlib
license.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\06@154208 by Wouter van Ooijen

face picon face
> No. The customer has the right to request the GPL'd code on
> demand. They
> don't have to be given the source. A very good example of
> this is Linksys.

You are right. Yet the seller must make clear to the buyer of the thing
how he should do this. Still inconvenient, at least.

But the bigger problem is that the seller is required to provide *all*
code of his gadget, not just the GPL-ed part.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\06@154417 by Wouter van Ooijen

face picon face
> In both  CANAL and VSCP and in the upcoming uP code the lower
> levels are
> released under the LGPL. So there is no need to for a user app. using
> this stuff to release its code. The higher level  parts are GPL  just
> for sharing so if you use code from the upper levels you have
> to release
> your own code as well.
>
> If you compile something together and ship it to a customer and it
> contains GPL code I can't see why you should bother your
> customer with
> this fact. For the developer community however there should
> be a chance
> to get the source code from you in some open way.  It's that easy....

My comment was on uC code. If I use GPL or LGPL code in my commercial uC
application I am forced to open *all* code of my application (unless the
license is LGPL and my uC support dynamic linking, the latter is not
very practical on a PIC).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\06@155657 by Bob Blick

face picon face
> My comment was on uC code. If I use GPL or LGPL code in my commercial uC
> application I am forced to open *all* code of my application (unless the
> license is LGPL and my uC support dynamic linking, the latter is not
> very practical on a PIC).

If you are doing a commercial project and want to keep your code closed,
why not write the code yourself? After all, you have a step up because
you've seen the code in the GPL project.

So you have the benefit of the free code, at the cost of having to rewrite
it if you want to keep it closed.

Cheerful regards,

Bob

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\06@160940 by Wouter van Ooijen

face picon face
> If you are doing a commercial project and want to keep your
> code closed,
> why not write the code yourself? After all, you have a step up because
> you've seen the code in the GPL project.
>
> So you have the benefit of the free code, at the cost of
> having to rewrite
> it if you want to keep it closed.

This is a valid standpoint if your aim is to maximize free code
availability. But when your aim is to maximize the use of the VSCP it
would be better to allow unmodified use of the provided code without
GPL-consequences.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\06@163637 by Martin Klingensmith

face
flavicon
face
Wouter van Ooijen wrote:
{Quote hidden}

You can link any code you want and you're fine. It's when you modify
code that presents a problem. I can create a closed-license program that
links to stdlib on a Linux machine and I haven't broken any laws.
If you used the actual GPL code in your closed code this is the same as
modifying it. If you had an object file and linked it this is supposedly
different.
You would of course have to provide the GPL with your device, and
provide access to the GPL code, but your object is your object as long
as it is separate.
If you statically link it? Well I have no idea then ;)
--
--
Martin Klingensmith
http://infoarchive.net/
http://nnytech.net/

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\06@165958 by Ake Hedman

flavicon
face
For me a *class* or a *file* implementing some kind of functionality  is the same as a library in the form of a Unix DL or Windows DLL or a compiler dynamic linked library. So I interpret  LGPL so that it is OK to use this code in a propritary application without releasing other code.

/Ake

Wouter van Ooijen wrote:

{Quote hidden}

--  ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org


--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\06@170822 by Ake Hedman

flavicon
face
Bob,

The problem is the opposite. You want others to contribute code to 'your' common project. For this GPL is good. It serves the community very well. Together people construct better code. But sometimes you need to protect code for some reason. Here LGPL serves you right. You can use the code and still protect the parts you want t protect. No need to rewrite the common parts. The community ca still benefit from your efforts by getting a bigger user base.

/Ake

Bob Blick wrote:

{Quote hidden}

--  ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org


--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\06@171029 by Wouter van Ooijen

face picon face
> For me a *class* or a *file* implementing some kind of
> functionality  is
> the same as a library in the form of a Unix DL or Windows DLL or a
> compiler dynamic linked library. So I interpret  LGPL so that
> it is OK
> to use this code in a propritary application without
> releasing other code.

You can of course interpret any text in any way you want, but the LGPL
wording is very precise in its distinction between static and dynamic
linking. And for someone to feel safe to use your code it is the legal
wording that is important, not your stated interpretation of it.

But again, if the aim is to increase the volume of free software GPL (or
sometimes LGPL) is the correct choice, if the aim is to support the use
of VSCP something like zlib, artistic, bds, etc. is more approriate.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\06@171030 by Wouter van Ooijen

face picon face
> If you statically link it? Well I have no idea then ;)

I do: then you have to provide all code. And my comment was on
microcontroller code, where static linking is (nearly always) the only
option.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\06@185338 by William Chops Westfield

face picon face
On Aug 6, 2004, at 2:10 PM, Wouter van Ooijen wrote:

> You can of course interpret any text in any way you want, but the LGPL
> wording is very precise in its distinction between static and dynamic
> linking.

I thought it was the was the GPL with the specific wording about
dynamic linking?  Your problem with JAL was that the libraries aren't
"linked" at all; they're include at source level.  That wasn't forseen
by the G people
at all, and even the LGPL will make source code that include LGPL
SOURCE need to be released in source form as well.

BillW

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\06@191606 by Byron A Jeff

face picon face
On Fri, Aug 06, 2004 at 09:08:12PM +0200, Wouter van Ooijen wrote:
> > > Do you realise that code released under GPL or LGPL is
> > almost useless
> > > for commercial embedded use? We had a long discussion about
> > this on the
> > > jallist.
> > > Wouter van Ooijen
> >
> > Other than being hard to enforce in embedded products I see
> > no problem,
> > unless you are someone who doesn't like the spirit of GPL.
>
> GPL requires that you provide the sources of code you link with the
> GPL-ed code.

That is correct. As an alternative you can provide a written offer for the
code if you wish.

> LGPL relaxes this to excempt dynamically linked stuff.

Actually it's more than that. When using an LGPL library you must provide
a way for the user to update the library. This can simply be a collection
of objects and a linker.

BTW you don't have an obligation to provide a mechanism to update the firmware.
So if you mask ROM program a LGPL library. All you have to do is provide
your objects. It's not your problem that the user has no way to get that
new firmware onto the product.

>For
> embedded things this means that if you use GPL-ed code (in a product
> that you sell or give away) you are obliged to provide the source.

That's right. Which probably makes no sense. OTOH you can simple follow the
letter of the license and be done with it. Ship a CD with the source, or
the objects.

> In
> most cases this is not something you want to do, but even if you want to
> do it: imagine a customer buying a valentine card with a uC that plays
> some lovely tune. If the uC code contains GPLed code that customer must
> get the source to it, and a copy of the GPL/LGPL text.

Well not exactly. The customer must have the right to access the source code
and they must know about that right. You don't have to give it to them and
they don't have to ask for it. But the right to do so and the knowledge of
that right must be presented.

See JAL presents a sticky issue. It has libraries that are LGPL, but the
LGPL source is comingled with the application source to build the firmware.
With LGPL even if you don't change the library code itself, the user has the
right to build a new firmware verson based on an updated library. But because
of the mechanism of building that firmware, they must have the application
source in order to do that. So right now LGPL doesn't buy the developer any
privacy for their source. What would need to happen is for the JAL compiler
to be able to create linkable objects. Then the applications could be
compiled into a linkable object and provided with the source for the libraries.

The funny thing is that the end user probably doesn't care. Also with both
the GPL and LGPL you are only obligated to provide these services only to
those who have received L/GPL stuff from you. So you could have a passworded
website if you wished. However that user has the same distribution rights to
the L/GPL stuff as you do. But! If you use the object/linker route you could
restrict the distribution of your object. So you give them
YourObj+LGPLv1lib.  The user can get new LGPLv2lib and link with your object.
However you can prevent them from redistributing YourObj. I was fuzzy on is
the status of YourObj+LGPLv[12] but I actually spent 2 minutes reading the
license. You have control over YourObj+LGPLv[12] and can restrict its
redistribution. So the bottom line is that you can create an object, and
tell the user under what terms they can use the object. AFAICT that means
the the object can be closed and propritery.

BTW the way to solve the problem with JAL's libraries is simply to license
them as BSD licenses. That's probably what you wanted Wouter: anyone can use
the libraries for any purpose. But the end user does lose some rights in the
transistion. But considering where JAL is right now, it's probably the right
thing to do.

Folks, I know that the GPL and the LGPL seems to be a scheme cooked up by
a mad scientist designed to torment developers, especially embedded ones.
But the real objective is to give downstream users the right to develop
modify, and redistribute free software if they choose to do so. This is
important because much of the time there is some intermediate value add to
the software. Developer A creates something and puts it under a GPL/LGPL
license. Often because he'd like to get help in development. Without the
GPL/LGPL in place, Developer B will come along, take the code infrastructure,
add to it in some meaningful way, and then attempt to curtail the very
rights to others that gave them the ability to create the value add in the
first place. The end user gets stuck on depending on Developer B for updates
because the value add isn't available for them to access. Now while I agree
this would be quite fair if Developer B created the whole system. As the
author that would be his/her right. However to take the generosity of
Developer A and not "pay it forward" as it were is disingenouous at best.

And you'd best believe there are lots and lots of Developer B's out there.
Hence the stringent and somewhat awkward rules in managing L/GPL style
distributions.

I wanted to add 2 cents. It looks closer to two bills.

BAJ

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\06@191816 by Michael Olson

flavicon
face
Well, in the case of the GPL this is the intent and I don't see a real
significant difference between embedded and any other proprietary
software. The LGPL however looses a little of it's intent, so use the
LGPL with static linking exceptions. See SSCILIB for an example of a
project with that license.

One can certainly debate weather most companies would want to use
L/GPLed code in their products but thats really not a new argument or
one thats embedded specific.

Personally, If I were making a commercial product (major speculation
zone considering I've never been anywhere near the creation of a
commercial product) I doubt I'd much care about using LGPL w/Static
exception. As for regular GPL/LGPLed code, thats harder to say, it
depends on how much of my product was based on nifty code.

-- Mike

>My comment was on uC code. If I use GPL or LGPL code in my commercial uC
>application I am forced to open *all* code of my application (unless the
>license is LGPL and my uC support dynamic linking, the latter is not
>very practical on a PIC).
>
>Wouter van Ooijen
>
>

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\06@192022 by Byron A Jeff

face picon face
On Fri, Aug 06, 2004 at 09:33:55PM +0200, Ake Hedman wrote:
> Wouter ,
>
> In both  CANAL and VSCP and in the upcoming uP code the lower levels are
> released under the LGPL. So there is no need to for a user app. using
> this stuff to release its code.

But you must make an object available so that the user can relink if you
distribute an executable/firmware to them.

> The higher level  parts are GPL  just
> for sharing so if you use code from the upper levels you have to release
> your own code as well.
>
> If you compile something together and ship it to a customer and it
> contains GPL code I can't see why you should bother your customer with
> this fact.

Because the GPL requires it. You have to make the offer and the end user
has to know that the offer exists. They don't have to exercise it, but do need
to be aware of their rights.

> For the developer community however there should be a chance
> to get the source code from you in some open way.  It's that easy....

The GPL doesn't make a distinction. Anyone who receives a system with GPL
code in it has the right to access the GPL source. And as Wouter pointed out
if it's GPL then any derivative part of the system must have its source
available.

BAJ

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\06@192230 by Byron A Jeff

face picon face
On Fri, Aug 06, 2004 at 09:44:46PM +0200, Wouter van Ooijen wrote:
> > In both  CANAL and VSCP and in the upcoming uP code the lower
> > levels are
> > released under the LGPL. So there is no need to for a user app. using
> > this stuff to release its code. The higher level  parts are GPL  just
> > for sharing so if you use code from the upper levels you have
> > to release
> > your own code as well.
> >
> > If you compile something together and ship it to a customer and it
> > contains GPL code I can't see why you should bother your
> > customer with
> > this fact. For the developer community however there should
> > be a chance
> > to get the source code from you in some open way.  It's that easy....
>
> My comment was on uC code. If I use GPL or LGPL code in my commercial uC
> application I am forced to open *all* code of my application (unless the
> license is LGPL and my uC support dynamic linking, the latter is not
> very practical on a PIC).

Wouter,

It doesn't have to be dynamic linking for the LGPL. Static linking works too.
As I stated in my first (much longer) response in this thread, the problem is
that if no linking system is available at all, then you'd have to release all
the source because that's the only way the end user can exercise their right
to be able to update the library.

BAJ

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\06@193231 by Byron A Jeff

face picon face
On Fri, Aug 06, 2004 at 12:57:30PM -0700, Bob Blick wrote:
> > My comment was on uC code. If I use GPL or LGPL code in my commercial uC
> > application I am forced to open *all* code of my application (unless the
> > license is LGPL and my uC support dynamic linking, the latter is not
> > very practical on a PIC).
>
> If you are doing a commercial project and want to keep your code closed,
> why not write the code yourself? After all, you have a step up because
> you've seen the code in the GPL project.
>
> So you have the benefit of the free code, at the cost of having to rewrite
> it if you want to keep it closed.

This is the unfortunate storm that occurs at the front of competing
ideologies. On the one hand the free software zealots (BTW I'm not that
far across the line) would like all code to be free and are gently encouraging
you to free your code when binding with existing free code. OTOH you have
the closed source crowd that would like to use the free software in their
closed source projects, essentially encumbering the free code by taking
away rights that were given to them by the free source author.

Your suggestion above is one possible path. The other is that if the free
code is a library, then make it LGPL and allow the two to coexist. Often
the free source side can get a boost from the closed source side because
any changes made to the library proper is under the scope of the GPL and
must be released. So the library can get better, and closed source
developers can use the library in their closed source projects. The end
user gets the chance to take advantage of downstream updates to the library.
Seems like a win all the way around.

BAJ

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\06@200804 by Byron A Jeff

face picon face
On Fri, Aug 06, 2004 at 10:09:00PM +0200, Wouter van Ooijen wrote:
> > If you are doing a commercial project and want to keep your
> > code closed,
> > why not write the code yourself? After all, you have a step up because
> > you've seen the code in the GPL project.
> >
> > So you have the benefit of the free code, at the cost of
> > having to rewrite
> > it if you want to keep it closed.
>
> This is a valid standpoint if your aim is to maximize free code
> availability. But when your aim is to maximize the use of the VSCP it
> would be better to allow unmodified use of the provided code without
> GPL-consequences.

There's another possible route here. The question is what's the consequence
of adding an exception. Here are the competing issues:

1) Closed source application developer who wants to keep the source that they
  write to themselves. But want to use an free library.

2) End users/library developers who want to be able to improve the free
  library and update applications that use that free library.

3) Lack of tools to adequately separate the two conflicting components i.e.
  no linker.

Now frankly folks on each side have something to gain and something to lose.
The closed source developer doesn't have to rewrite/redebug/retest a library
that they need. But can lose the right to keep their source closed. The end
user/library developer gets more library proliferation plus the ability to make
updates/performance enhancements. But could lose the application altogether
due to free distribution guidelines.

So the compromise is to add an exception that states that compiler comingling
of closed source and free library doesn't tag the closed source as free.

Certainly a win for closed source developer. They can use the library and
keep their source closed.

But the end users/library developers give up a right in order to make that
happen.

So the question is what's the compensation? Should the closed source developer
be required to offer a written guarantee to provide the library developer/
end user with comingled application using the free library version of their
choice? Some other avenue?

What about strict licensing on the closed source author's source? Since the
comingling is done by the compiler, the author's source is their source. Why
not just stick a license on it that states that the sole purpose is for
the end user/library developers to update the firmware. Or make them sign
an NDA for it? All of these are possible.

I think that folks don't think that the right for downstream users and
developers to be able to update libraries and firmware is important. But
without these protections in place you get a very slippery slope where
eventually the license applied to free software isn't worth the bits the
file is stored in.

So the question is that if as a developer you get an exception on
distributing your source when using LGPL type libraries, then how are you
going to pay so that the downline users/developers rights are maintained?

BAJ

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\06@231707 by M. Adam Davis

flavicon
face
Ake Hedman wrote:

>
> BSD take away allot of freedom from the community. IBM license is
> something I never looked at.
>
And gives the developer all that freedom.  It's a simple shift over the
line from "Free for the community" to "Free to use however you like"

As a developer I prefer the BSD style license, it simply gives me more
freedom with other code.  When I release code for others to use then I
want others to use it for any purpose - I don't want to tie them down to
the community.  If you make a million off my code and no one can see
your additions or improvements then good for you.  I stand on your
shoulders sometimes, you stand on mine.  I could argue that code is
little more than knowledge, and as far as I can tell when I understand
something that is based on trigonometry I'm not forced to add my
discovery to all the trigonometry books out there.  I can sit on it, but
if I do let it be widely known I can't simply force others to release
their later discoveries based on my knowledge.

It's a simple difference of objectives, that's all.  The GPL is only
'more free' from a certian (narrow) perspective.  The BSD is much more
free in a more general sense.

The GPL could easily be argued to be more open than the BSD, but
certianly not more free in general.

Keep in mind that most modern operating systems got their TCP/IP stack
from the Berkely distribution with a BSD license.  The internet may well
not be today what it is if it weren't for the fact that companies could
include TCP/IP for free without having to divulge any of their other
associated code.  The internet wouldn't have been nearly as
interoperable if everyone made their own stack (each getting the bright
idea to 'fix' or 'enhance' it).  Plugging the 'standard' in was easy,
and since everyone had the same quirks they all worked together without
issue.  Companies, especially at the time, would have balked at a GPL or
even LGPL style license.  They either wouldn't have included it, or
worse made a half complete version that sort of worked with their own
systems.

A modern example would be Ogg Vorbis.  I believe they have a BSD license
primarily so companies can integrate the standard with minimum of fuss.
All the hits Linksys and other companies are taking because they used
GPL code and didn't release the modifications in a timely manner are
making them consider carefully whether the 'community' is worth the trouble.

Please don't take this the wrong way - the GPL is not any better or
worse a license than the BSD, or any license for that matter.  I could
see myself releasing under the GPL for specific projects or purposes,
but in general I lean towards more free/less open than more open/less
free.  I don't think that in the long run it really matters.

Plus RMS just rubs me the wrong way.  ;-)

-Adam

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\07@002817 by Byron A Jeff

face picon face
On Fri, Aug 06, 2004 at 09:42:02PM +0200, Wouter van Ooijen wrote:
> > With the LPGP you can use the lib or whatever without
> > sharing your proprietary stuff: Would it be better to go for a dual
> > license of some form?
>
> I had the same idea with the Jal libraries, but after carefull reading
> of the LGPL it is a relaxation of the GPL *only* for dynamical-liked use
> of LGPL-ed code. For the Jal-libraries I/we are switching to the zlib
> license.

Wouter,

I hate sounding like a broken record (scratched CD? ;-). But I think that
it's important in this discussion to separate the right the LGPL imparts and
the mechanism by which that right is invoked. First the right:

The receiver of a work that contains an LGPL library has the right to update
the LGPL library against the work.

In short if you distribute yourcode+lgpllib, then the receiver of that has the
right to rebuild and use yourcode+newlgpllib. Let's call it the rebuild right.

Nothing is attributed to yourcode (or to the combo of yourcode+eitherlgpllib)
other than the above right to rebuild with newer library versions. You don't
have to release source to yourcode unless it interfere's with the abovelisted
right.

And that's what affects the JAL libraries. Now let's talk about mechanisms
for combining yourcode+lgpllib. The simplest and most obvious is dynamic
linking. Since only the runtime is linked, the user can simply update the
library and the next time yourcode is run it's automagically linked to
the new library. Done deal.

Next is static linking. While this creates a permanent yourcode+lgplglib
the two components (the yourcode object and the lgpl library) are separate
enough that you can simply provide the user with a yourcode object and they
can relink to a newlgpllib whenever they are ready.

Now here's the problem with JAL's libraries. Neither of those two mechanisms
are available. The only way to build yourcode+lgpllib is to compile the
source code for each together. So it's the mechanism that creates the
situation where the source of yourcode has to be available, coupled the right
that the user has to recombine the code.

It's a problem. But it's not as black and white as "a relaxation of the GPL
*only* for dynamic[al]-linked use of LGPL-ed code."

For clarity I would phrase the problem as follows: The LGPL grants the end
user the right to rebuild systems utilizing LGPL code. Because the only
mechanism available under JAL libraries is source recompilation, this right
can only be fulfilled by the release of the source code (of yourcode) to the
user.

Nothing's changed but it clarifies the problem.

Switching licenses is a prudent course of action. And of course you know that
I trust you to do the right thing. Unfortunately there will be developers
that will take your licensing generosity and exploit it. The LGPL also has a
second provision to protect the freeness of the code itself. Note in all of
the above examples that yourcode and lgpllib have been pretty much
separated.  However in the instance where the developer of yourcode needs to
add or change something in lgpllib to create
yourcode+newlgplupdatedforyourcode then the GPL effect kicks in for the
library. While there's still no encumbrance for yourcode (other than the
original rebuild right granted to downline users) the modified library is
subject to the GPL and the source for the changes must be distributed along
with the new combo. So the downline user can get both the ability to rebuild
and be able to use the updated library just like the original in both this
application with yourcode and with any other application the user so chooses.

Now by switching to a license with less restrictions developers can now
take code that was given freely to them, modify and possibly improve it,
and have no obligation whatsoever to share the results.

As much as some folks complain about L/GPL restrictions, it's really designed
to be fair: What is free remains free, what rights are given to you must
be transferred downline, and what's yours is yours as long as you didn't
utilize free software to get it.

But by switching to the zlib license (artistic and BSD are similar) developers
get the opportunity to retain any rights and code given to them, and no
obligation at all to share any of their contributions to their users downline
or others in the developer community. Not the stuff they generate themselves
(remember what's yours is yours) but the modification of the code that was
freely given to you.

In the free software pantheon there is a shift between the rights of what
I've been calling downline users and developers and modifying distributing
developers. Each license from the GPL to strict closed source grants rights
to one side or the other, and restricts rights for one side or the other.

Here's the list:

Most Free granting most rights to downline users/developers
----
GPL
LGPL
X
Zlib,BSDL, Artistic
Vendor community source licenses such as Netscape, Sun, Apple, and Microsoft
Closed source
Patents
----
Least free granting most rights to author/developers

Now the LGPL doesn't work in the JAL case. I agree. However I think there
needs to be something in spot X in the list. Zlib and friends takes away both
the rebuild right and the propagation of library source modifications right.
LGPL grants both of those rights. The license in X should drop (or modify)
the rebuild right but keep the propagation of library source modification
to the downline intact.

I'm not sure it exists. I just hope that JAL developers using the zlib library
will honor the sprit in which the code is licensed. Because the code is being
relicensed in order to work around a code combination mechanism that currently
doesn't have a fix. The LGPL is actually the right license overall, but it's
conditions cannot be easily met.

BAJ

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body

2004\08\07@004307 by Byron A Jeff

face picon face
On Fri, Aug 06, 2004 at 11:10:08PM +0200, Wouter van Ooijen wrote:
> > If you statically link it? Well I have no idea then ;)
>
> I do: then you have to provide all code.

Not true. Read my even longer post on the subject further along in this
thread.

>  And my comment was on
> microcontroller code, where static linking is (nearly always) the only
> option.

Now that's true. And possibly not even then.

BAJ

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body

2004\08\07@004515 by Wouter van Ooijen

face picon face
> Zlib and friends takes away both
> the rebuild right and the propagation of library source
> modifications right.
> LGPL grants both of those rights. The license in X should
> drop (or modify)
> the rebuild right but keep the propagation of library source
> modification
> to the downline intact.

IMHO the rebuild-right is not relevant for embedded stuff, or better
rephrase: for an embedded library to be usefull the (commercial) user of
the library must not be bothered by it. Making a modified library public
is not enforceable (nobody but the commercial user knows it exists), so
I see no reason to claim it. The only thing I want to claim is that if a
modified *source* is made available, it will be as free as the original.


Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body

2004\08\07@005136 by Byron A Jeff

face picon face
On Fri, Aug 06, 2004 at 04:35:50PM -0400, Martin Klingensmith wrote:
{Quote hidden}

Not exactly. I have a very long post on rebuild rights a bit further down
in this thread.

> It's when you modify code that presents a problem.

More specifically when you modify the code of a LGPL library, those
modifications are subject to GPL licensing.

> I can create a closed-license program that
> links to stdlib on a Linux machine and I haven't broken any laws.

That's mechanism, not rights. Also if it's a static linking process you do
have some futher obligations. Again check out my rebuild rights post.

> If you used the actual GPL code in your closed code this is the same as
> modifying it.

Yes.

> If you had an object file and linked it this is supposedly
> different.

Not for the GPL, though there is some gray area there. And you still need to
honor the rebuild right if the library is LGPL'ed.

> You would of course have to provide the GPL with your device, and
> provide access to the GPL code, but your object is your object as long
> as it is separate.

Not for GPL. I see there is a lot of confusion here. I think that's why
folks get so frustrated with this. If it required dynamic linking to a GPL
library to operate, it must ne GPL code. If it's an LGPL library, then
just the object is OK. The murky area is if the object works with either a
GPL library and a non-GPL licensed one too. Then there can be no claim that
the object is a derviative of the GPL library, and so isn't subject to the
license even if it is then linked to the GPL library.

> If you statically link it? Well I have no idea then ;)

If you statically link to GPL, it's GPL and you have to release the code.
If you statically link the LGPL, then the use has rebuild rights and you have
to give them the ability to rebuild. This may be either in object or source
form.

BAJ

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

2004\08\07@005137 by Byron A Jeff

face picon face
On Sat, Aug 07, 2004 at 12:43:07AM -0400, Byron A Jeff wrote:
> On Fri, Aug 06, 2004 at 11:10:08PM +0200, Wouter van Ooijen wrote:
> > > If you statically link it? Well I have no idea then ;)
> >
> > I do: then you have to provide all code.
>
> Not true. Read my even longer post on the subject further along in this
> thread.
>
> >  And my comment was on
> > microcontroller code, where static linking is (nearly always) the only
> > option.
>
> Now that's true. And possibly not even then.

Better clarify that. Static linking for microcontrollers may not even then
be available.

BAJ

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

2004\08\07@011354 by Wouter van Ooijen

face picon face
OK BAJ, I re-read the LGPL one more time :)

So I backtrack my objections to LGPL-ed embedded libraries to the fact
that you can not use such a library to create a realy closed
pay-per-chip product.

Note that as author of a library that is exactly what you might want to
prevent, it that case (L)GPL is a perfect license for your library. But
when you want to promote a concept like a communication protocol I still
hold that a more premissive license will promote the concept better (at
the cost of making the downstream product less free).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body

2004\08\07@013056 by Byron A Jeff

face picon face
On Sat, Aug 07, 2004 at 06:45:35AM +0200, Wouter van Ooijen wrote:
> > Zlib and friends takes away both
> > the rebuild right and the propagation of library source
> > modifications right.
> > LGPL grants both of those rights. The license in X should
> > drop (or modify)
> > the rebuild right but keep the propagation of library source
> > modification
> > to the downline intact.

Wouter,

what time is it there? Here in Atlanta it's 1AM. It must be very very
early morning for you, yes?

>
> IMHO the rebuild-right is not relevant for embedded stuff, or better
> rephrase: for an embedded library to be usefull the (commercial) user of
> the library must not be bothered by it.

I'm pretty much in agreement with that. Note that license X proposes to
drop the rebuild right.

> Making a modified library public
> is not enforceable (nobody but the commercial user knows it exists),
> so I see no reason to claim it.

Don't be so sure about that... There have already been instances with
Linksys and KiSS technologies where GPL code has been reported to be
found in embedded devices.

But mechanism aside what about the right? If you write a library and make
it freely available, then I come along and improve it a bit, then why
shouldn't I share that good fortune with you and other developers? This
is the philosophical question at the core of the difference between the L/GPL
and other free licenses.

> The only thing I want to claim is that if a
> modified *source* is made available, it will be as free as the original.

But we all no that with no compulsion to produce a modified source, very
few will.

For me it's about balance. Here in the US in stores there are "Give a penny,
take a penny." trays next to the cash register where if you are a penny or 3
short you can take a few and if you get some change with pennies you can drop
them in for others to use. It's an honor system and it works fairly well
because many folks hate pennies. However the L/GPL rquires you to give
when you take and use.

I wish the honor system worked. But I see posts is the gnu.discuss.misc
newsgroup everyday about developers who want to incorporate free software
into their stuff without giving back ANYTHING! Eventually you run out of
pennies, and everyone looses, including the developers who lose their stream
of free software.

There is a need for this X license above for embedded libraries. It needs to
say "take the library. Use it. Embed it. However if you change it, then you
have to give the changes back so that others can benefit."

Simple and fair. Which is all that I'm looking for personally.

BAJ

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body

2004\08\07@015704 by Byron A Jeff

face picon face
On Sat, Aug 07, 2004 at 07:14:02AM +0200, Wouter van Ooijen wrote:
> OK BAJ, I re-read the LGPL one more time :)

It's a sticky one. I've found that when reading stuff from the FSF it's
best to figure out what rights they are trying to protect.

> So I backtrack my objections to LGPL-ed embedded libraries to the fact
> that you can not use such a library to create a realy closed
> pay-per-chip product.

Why not? The rebuild right is annoying. Let's set it aside for now under
the guise of even if you can build new firmware, there's no way to get it
into the product.

So what's left? If you use LGPL libraries unmodified, then the combo of
yourcode+lgpllib firmware is yours to do what you wish. You can charge pay
per chip.  You can restrict distribution. You can relicense it. Folks can't
copy it.  Presuming that yourcode is closed source and your own clean code,
then the only right a user has is to sell the product. Nothing more. Nothing
less.

The LGPL is very very careful to separate the library source and binary from
the yourcode source and binary. As long as you use the library unmodified
you can treat the result as proprietary code (exempting the rebuild right
of course).


>
> Note that as author of a library that is exactly what you might want to
> prevent,

Well the LGPL isn't the right way to do it. That's the big difference between
the LGPL and the GPL. If you want to "force" source code release of yourcode
and allow for unlimited redistribution, then make the library a GPL library.

> it that case (L)GPL is a perfect license for your library.

Nope. GPL is perfect for that. The LGPL expressly recinds the encumbrance
of code that uses the library right. If you just use an LGPL library then
you have no restrictions other than the rebuild right.

> But
> when you want to promote a concept like a communication protocol I still
> hold that a more premissive license will promote the concept better (at
> the cost of making the downstream product less free).

Actually for the protocol itself isn't really relavent one way or the other.
However if a reference code implementation accompanied it, then the license
would be important. Truthfully a more restrictive license may actually be
more helpful:

1) It would guarantee consistency of implementations.
2) It could facilitate central coordination of reference library code.

But think in general for embedded systems, an Embedded GPL which the LGPL
with section 6 (rebuild right) dropped is appropriate. In short:

1) yourcode+egpllib is yours to do what you want.
2) Changes to egpllib must be distributed if the modified lib is distributed
  in any form.

That's equitable. Folks can use the library as they see fit, but any changes
get filtered back to the development community.

Again I agree that the rebuild right is a bit overbearing in an embedded
environment.

BAJ

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body

2004\08\07@024136 by Byron A Jeff

face picon face
On Sat, Aug 07, 2004 at 01:57:23AM -0400, Byron A Jeff wrote:
> On Sat, Aug 07, 2004 at 07:14:02AM +0200, Wouter van Ooijen wrote:
> > OK BAJ, I re-read the LGPL one more time :)
>
> > So I backtrack my objections to LGPL-ed embedded libraries to the fact
> > that you can not use such a library to create a realy closed
> > pay-per-chip product.
>
> Why not? The rebuild right is annoying. Let's set it aside for now under
> the guise of even if you can build new firmware, there's no way to get it
> into the product.
>
> So what's left? If you use LGPL libraries unmodified, then the combo of
> yourcode+lgpllib firmware is yours to do what you wish. You can charge pay
> per chip.  You can restrict distribution. You can relicense it. Folks can't
> copy it.  Presuming that yourcode is closed source and your own clean code,
> then the only right a user has is to sell the product. Nothing more. Nothing
> less.

Clarify. The user can resell the hardware you sold to them...

BAJ

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body

2004\08\07@025837 by Ake Hedman

flavicon
face
I Get your point. I will have a look at the alternatives. Thank you!

/Ake

Wouter van Ooijen wrote:

{Quote hidden}

--  ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org


--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservEraseMEspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

2004\08\07@094105 by D. Jay Newman

flavicon
face
> Clarify. The user can resell the hardware you sold to them...
>
> BAJ

Despite the shrink-wrap agreements, you can also resell the software
if you do it legally (get rid of your copies).

One of the basic rights that a buyer has is that he can resell his
property.
--
D. Jay Newman           ! DCX - it takes off and lands base down,
RemoveMEjayspamTakeThisOuTsprucegrove.com     !       as God and Robert Heinlein intended.
http://enerd.ws/robots/ !

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservEraseMEspam.....mitvma.mit.edu with SET PICList DIGEST in the body

2004\08\07@141417 by Wouter van Ooijen

face picon face
> Again I agree that the rebuild right is a bit overbearing in
> an embedded environment.

I would say that it makes the (L)GPL totally inappropriate.

I have thought about making a small modification to the LGPL, but that
is not allowed because the LGPL text itself is (c). That of course makes
sense, it would ve very annoying if you got a piece of code with what
seems to be an LGPL license but it turns out to be subtly different.

Another approach would be to add a statement to the comment in the code
that refers to the LGPL. This fails because (for the jal-ethernet
project) SourceForge was to be used, which requires a recognised free
license.

So I ended up with zlib, which is OK except that it does not force
modifications to be made public.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspammitvma.mit.edu with SET PICList DIGEST in the body

2004\08\07@141418 by Wouter van Ooijen

face picon face
> what time is it there? Here in Atlanta it's 1AM. It must be very very
> early morning for you, yes?

IIRC it was actuallyt very late in the evening.

> I'm pretty much in agreement with that. Note that license X
> proposes to drop the rebuild right.

I have not seen that licence yet, so I did not consider it.

> But mechanism aside what about the right? If you write a
> library and make
> it freely available, then I come along and improve it a bit, then why
> shouldn't I share that good fortune with you and other
> developers? This
> is the philosophical question at the core of the difference
> between the L/GPL
> and other free licenses.

As I argued, (L)GPL enforces somewhat more than just that.

> But we all no that with no compulsion to produce a modified
> source, very few will.

Fine with me. I just don't want to face a fee for a modified version of
my own library :)

In fact the file section of the jallist is full of condtributed code,
but often without a clear license statement. And alas, without any
structure :(

> For me it's about balance.

For me it is all about purpose.

The Jal compiler itself is GPL for various reasons, one is that I wanted
to give something back for being able to use the great free GCC compiler
on almost any platform.

The Jal libraries were LGPL because that seemd to fit my ideas (free for
all to use, but if you distributed a modified source it keeps teh same
license), but I was wrong about that, hence a switch to zlib license.

The Wisp628 source is scrictly (c), except for
- use on hardware that I sell
- use in preprogrammed chips that I sell
- use in your own DIY hardware
This is because I want to make money from this design, yet I don't want
to leave out the hobbyists that would probably never buy from me in the
first place because they don't have the money (and have enough time to
build their own hardware). And of course the source is avialable for
reading, which makes it easy for me to answer progarmming questions
(just look in wisp628.jal, it is all there dude!), and occasionally
someone will point out a bug (often with the solution).

The PC software for Wisp628 is totally free (artistic license? I don't
remember where I got it from) because it makes no sense to restrict it
more than that. The interface is also available, which has simulated
some people to make alternative software for Wisp628. This can only have
simulated the use and sale of the Wisp628.

So for each use I pick the license that suits me best. This is just like
any other engineering descision: balance the pro's and con's and decide.

> There is a need for this X license above for embedded
> libraries. It needs to
> say "take the library. Use it. Embed it. However if you
> change it, then you
> have to give the changes back so that others can benefit."
> Simple and fair. Which is all that I'm looking for personally.

If this license existed I would have used it instead of zlib, but I
found none.

A related license question: what would be an appropriate compareable
license for a hardware design?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservEraseMEspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body

2004\08\07@151757 by Bob Axtell

face picon face
D. Jay Newman wrote:

>>Clarify. The user can resell the hardware you sold to them...
>>
>>BAJ
>>
>>
>
>Despite the shrink-wrap agreements, you can also resell the software
>if you do it legally (get rid of your copies).
>
>One of the basic rights that a buyer has is that he can resell his
>property.
>--
>
>
>
Actually, you can in theory, but in practice, you can't. One time I
purchased a well-known CAD product. I then discovered that there was a
competitor at 1/2 price that had a better product. I then went back to
the first one to get my money back, as it really wasn't used at all (and
it had a dongle). Not only would they NOT take it back for obvious
reasons, they (1) would NOT pass on the product support to a second
purchaser should I resell it, and (2) they would NOT recognize the
repurchaser as being the legal owner of the product. That $2000 mistake
made me realize that negotiations in writing are required BEFORE buying
expensive software.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspam_OUTspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body

2004\08\07@152418 by D. Jay Newman

flavicon
face
> D. Jay Newman wrote:

> >Despite the shrink-wrap agreements, you can also resell the software
> >if you do it legally (get rid of your copies).
> >
> >One of the basic rights that a buyer has is that he can resell his
> >property.

> Actually, you can in theory, but in practice, you can't. One time I
> purchased a well-known CAD product. I then discovered that there was a
> competitor at 1/2 price that had a better product. I then went back to
> the first one to get my money back, as it really wasn't used at all (and
> it had a dongle). Not only would they NOT take it back for obvious

That is their right.

> reasons, they (1) would NOT pass on the product support to a second
> purchaser should I resell it, and (2) they would NOT recognize the

Again, that is their right. Tech support is separate.

> repurchaser as being the legal owner of the product. That $2000 mistake

Now that is a problem. In the US they don't have that right unless
they rather specifically licensed the product to you instead of sold
it.

However, some courts have overturned such agreements.

On the other hand, if you don't have the money to fight it, it doesn't
matter what the law says.

> made me realize that negotiations in writing are required BEFORE buying
> expensive software.

Ayup.
--
D. Jay Newman           ! DCX - it takes off and lands base down,
RemoveMEjayTakeThisOuTspamspamsprucegrove.com     !       as God and Robert Heinlein intended.
http://enerd.ws/robots/ !

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspamspamspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body

2004\08\08@011306 by techy fellow

picon face
Hate to say this. It is very common for people in Asia first try out the warez (not sure whether this is the correct spelling) version. Once they find the software suits them, they then buy the original so as to get proper support. Surprisingly, crackers can even by-pass dongle checks by mean of simple patch(es) !!

Sometimes, it is the software company that drives people to use pirated copy. For eg., I tried to be nice by using original software. In one case, I bought an original copy of the ROBOLAP version 2.52 from Lego. I asked the salesperson where can I register my copy (ie on-line registration) but all I got was a 'no' answer. I then ask how can I be assured I will get proper supports from Lego, for eg., patches, minor upgrades, etc. The answer is again, "you are on your own". That is, if Lego were to come out with any upgrades no matter how small (eg., version 2.53) and if I want it, I will have to buy the whole software again at full cost. I was so surprise because Lego is not a small company but their "high and mighty" attitude, pissed me off. I fully understood if the next version is a major upgrade, for eg. version 3.0 then, I will have to purchase the whole thing. In fact, most of the software companies give steep discount for purchasing their latest version if you own their
previous version. This is to encourage you to buy original from them again (translates to, more profits for them). One thing for sure, if I want to any ROBOLAP version after 2.52, I know where to get it but it will not be from Lego. Er.. this is just my personal opinion. I am sure many people will disagree with me on this one. Everyone entitles to their own opinions, right !?

Yet another case is, consumer complained they are willing to buy originals but the price of originals is very high. The resellers of original software argued they are 'bleeding' because of pirates. Therefore, they have no choice but to charge a higher price. Granted. The govt then managed to clamp down on software piracy but, the price in fact, has gone up even higher than before. Consumers then realised the 'pirates' do have a positive role to play afterall in the resell market. That is, they act as 'competitors'. No more pirates = no more competitors. Resellers rules.....

Sorry for complaining. Everytime I heard software companies after-sales services sucks, I will want to share my unpleasant experiences.


"D. Jay Newman" <RemoveMEjayKILLspamspamSPRUCEGROVE.COM> wrote:
{Quote hidden}

That is their right.

> reasons, they (1) would NOT pass on the product support to a second
> purchaser should I resell it, and (2) they would NOT recognize the

Again, that is their right. Tech support is separate.

> repurchaser as being the legal owner of the product. That $2000 mistake

Now that is a problem. In the US they don't have that right unless
they rather specifically licensed the product to you instead of sold
it.

However, some courts have overturned such agreements.

On the other hand, if you don't have the money to fight it, it doesn't
matter what the law says.

> made me realize that negotiations in writing are required BEFORE buying
> expensive software.

Ayup.
--
D. Jay Newman ! DCX - it takes off and lands base down,
jaySTOPspamspamspam_OUTsprucegrove.com ! as God and Robert Heinlein intended.
http://enerd.ws/robots/ !

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservSTOPspamspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body


---------------------------------
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestspamBeGonespammitvma.mit.edu

2004\08\09@035355 by Ake Hedman

flavicon
face
Wouter ,

is this http://www.gzip.org/zlib/zlib_license.html  the zlib license you referred to earlier?

Regards
/Ake

Wouter van Ooijen wrote:

{Quote hidden}

--  ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org


--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\08\09@040927 by Wouter van Ooijen

face picon face
> is this http://www.gzip.org/zlib/zlib_license.html  the zlib
> license you referred to earlier?

Yes.

What I wanted was
- general things like a warranty disclaimer
- free for all use, but
- a distributed *source* must keep the same license

What I would have liked but did not find was
- when a modified non-source distribution is made (in my case: an
executable) the source modifications must be made public under the same
license

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\08\09@043420 by Ake Hedman

flavicon
face
Wouter,

for uP code of VSCP and CANAL the disclaimer is what I am after. After all I want to promote a protocol. Not to sell software. I am interested in selling hardware modules based on the work but if others do this as well it is still a good thing for my company.

The GPL/LGPL combination works OK for the Windows and Linux stuff and I think I achieve what I am after by using them.

Thanks everyone for pulling me in the right direction.

Regards
/Ake

Wouter van Ooijen wrote:

{Quote hidden}

--  ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org


--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\08\09@091157 by Byron A Jeff

face picon face
On Sat, Aug 07, 2004 at 08:14:59PM +0200, Wouter van Ooijen wrote:
> > Again I agree that the rebuild right is a bit overbearing in
> > an embedded environment.
>
> I would say that it makes the (L)GPL totally inappropriate.

No disagreement on that. But It can still be a starting point of the discussion
of what (if any) rights are available.

> I have thought about making a small modification to the LGPL, but that
> is not allowed because the LGPL text itself is (c). That of course makes
> sense, it would ve very annoying if you got a piece of code with what
> seems to be an LGPL license but it turns out to be subtly different.

Agreed. However I think that the addition (or clarification) of any exceptions
is certainly possible.

In fact I've found a perfect example. The Fast Light Toolkit License Agreement.

Find it here:

http://www.fltk.org/COPYING.php

It does precisely what my hypothetical License X does, and does it by
specifying exceptions to the LGPL. The two specific exception sections of
relevance are:

----------------------------------------

3. Static linking of applications and widgets to the FLTK library does not
constitute a derivative work and does not require the author to provide
source code for the application or widget, use the shared FLTK libraries, or
link their applications or widgets against a user-supplied version of FLTK.

If you link the application or widget to a modified version of FLTK, then the
changes to FLTK must be provided under the terms of the LGPL in sections 1,
2, and 4.

4. You do not have to provide a copy of the FLTK license with programs that
are linked to the FLTK library, nor do you have to identify the FLTK license
in your program or documentation as required by section 6 of the LGPL.

However, programs must still identify their use of FLTK. The following
example statement can be included in user documentation to satisfy this
requirement:

[program/widget] is based in part on the work of the FLTK project
(http://www.fltk.org).

----------------------------------------

These exceptions really accomplish everything we really want to do:

1) Unlimited use of the unmodified library with no rebuild requirement. I admit
  it's still missing the compiler comingling exception.

2) Modifications to the library itself must be distributed.

3) Lessened requirements on the reporting of the usage of the license, which
  is somewhat debatable IMHO.

You may be right that designing a new license may be the right way to do it.
But as with all licenses it needs to be explicit as to the expectations, which
of the three above we pretty much agree on.

>
> Another approach would be to add a statement to the comment in the code
> that refers to the LGPL. This fails because (for the jal-ethernet
> project) SourceForge was to be used, which requires a recognised free
> license.

I can't see how an LGPL with exceptions that makes the license closer to
the zlib and BSD license wouldn't be acceptable.

After going through this for nearly a week, I just cannot believe that there
isn't a license written to meet our perceived requirements. We should call
it the YourCode Embedded License:

1) YourCode is your code. Do what you want with it.
2) OurCode is OurCode. Use it with YourCode as you like. However if you change
  OurCode the community would like to get access to the changes.
3) Tell downstream users and developers about this license and the rights that
  they get with it.

I mean how hard can that be? Does such a license exist?

>
> So I ended up with zlib, which is OK except that it does not force
> modifications to be made public.

Right. We're all on the same page. It's sad that there isn't a license to fit
this need.

BAJ

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\08\09@091432 by Byron A Jeff

face picon face
On Mon, Aug 09, 2004 at 10:10:15AM +0200, Wouter van Ooijen wrote:
> > is this http://www.gzip.org/zlib/zlib_license.html  the zlib
> > license you referred to earlier?
>
> Yes.
>
> What I wanted was
> - general things like a warranty disclaimer
> - free for all use, but
> - a distributed *source* must keep the same license
>
> What I would have liked but did not find was
> - when a modified non-source distribution is made (in my case: an
> executable)

or product with embedded firmware?

> the source modifications...

to the code under this hypothetical license. Not your code that you combine
with it...

> must be made public under the same license

by public you mean distributed or an offer of distribution right?

I agree wholeheartedly. That's the license we need.

BAJ

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\08\09@092055 by Byron A Jeff

face picon face
On Mon, Aug 09, 2004 at 10:33:20AM +0200, Ake Hedman wrote:
> Wouter,
>
> for uP code of VSCP and CANAL the disclaimer is what I am after.

Check out the Fast Light Tool Kit License. It's the LGPL with such as
disclaimer:

http://www.fltk.org

You may want to forther modify to allow for source combining not creating
a derivative executable as long as the licensed source code is unmodified.
I think that's fair. Brief example:

You write a reference protocol module for the PIC. In order to use your
code I #include it instead of linking (Sorry Olin, it's just an example! ;-)
If I don't change your source, then my code shouldn't be subject to the
license even if I include your source to create my work. However if I make
changes to YOUR source in order to get it to work, then I should have to
publish (or make the offer to distribute) those changes.

> After
> all I want to promote a protocol. Not to sell software. I am interested
> in selling hardware modules based on the work but if others do this as
> well it is still a good thing for my company.

Right. The basic idea around L/GPL type licenses is that everyone shares
the common source, and all changes to it are made public. I generally find
that's fair.

>
> The GPL/LGPL combination works OK for the Windows and Linux stuff and I
> think I achieve what I am after by using them.

At that level. Because with dynamic linking you get that automagically.

>
> Thanks everyone for pulling me in the right direction.

No problem.

BAJ

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\08\09@093927 by Byron A Jeff

face picon face
On Sat, Aug 07, 2004 at 08:14:59PM +0200, Wouter van Ooijen wrote:
> > what time is it there? Here in Atlanta it's 1AM. It must be very very
> > early morning for you, yes?
>
> IIRC it was actuallyt very late in the evening.
>
> > I'm pretty much in agreement with that. Note that license X
> > proposes to drop the rebuild right.
>
> I have not seen that licence yet, so I did not consider it.

It's a hypothetical license. Sadly there doesn't seem to be an example that
exists. The Fast Light Toolkit License makes a good attempt of trying to
define it:

http://www.fltk.org/COPYING.php

It would still need to be tweaked because it still leaves the source
comingling issue.

The more I look at it, it seems it may be better to build up a less restrictive
license, like zlib, instead of trying to tear down a more restrictive license.

It seems that zlib + one more paragraph may accomplish the task.

{Quote hidden}

Not really. I set the rebuild right aside a while ago. The LGPL minus rebuild
is very close to where I think we need to be. Without rebuild the LGPL
becomes (LGPLNR for short):

1) You must distribute the license with the work.
2) You must make available changes to source under this license.

I don't think there's more than that. I may make more explicit that any code
that uses the LGPL code unmodified isn't subject to the license, along with
only the changes to the LGPLNR source having to be made available.

>
> > But we all no that with no compulsion to produce a modified
> > source, very few will.
>
> Fine with me. I just don't want to face a fee for a modified version of
> my own library :)

I find it worse when improvements to my stuff isn't available for me to
incorporate into my projects. I guess that's why I'm fighting so hard to retain
that right from the LGPL, which zlib and BSD just dropped.

>
> In fact the file section of the jallist is full of condtributed code,
> but often without a clear license statement. And alas, without any
> structure :(

Wouter,

I think we've gone around this issue enough. I propose that we hash out the
JAL Embedded License and get it on the OSI docket. There's a clear need for
it. Plus it'll give a license hook for these contributors to hang their code
onto.

Do you think that Jean-loup and Mark might be willing for us to start with
the zlib text. Maybe we can ask them.

I almost hate to ask the question, but are there any lawyers out there?

BAJ

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\08\09@100007 by Ake Hedman

flavicon
face
>It seems that zlib + one more paragraph may accomplish the task.

OK, lets define the "Firmware License 1.0". We are enough people on the list to make such a license attractive for others and we on the list are already working together sharing tips, code and such so it can have immediate use. Many of us have commercial projects going on and want  protection for these. Many have hobby projects and don't want to get riped off. It would be perfect if the code we share carry a well known license most of us can accept.

For me the zip license terms are OK. What paragraphs should be added to make it suitable for you Wouter,  Byron and all other interested.

Regards
/Ake


Byron A Jeff wrote:

{Quote hidden}

--  ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org


--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\08\09@105540 by Wouter van Ooijen

face picon face
> For me the zip license terms are OK. What paragraphs should
> be added to
> make it suitable for you Wouter,  Byron and all other interested.

- zlib is suitable for me, although not perfect
- I much prefer a 'recognised' free license to a tweaked one

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\08\09@105541 by Wouter van Ooijen

face picon face
> Check out the Fast Light Tool Kit License. It's the LGPL with such as
> disclaimer:
> http://www.fltk.org

IMHO this is (potentially) a bad construct, as the added part and the
(L)GPL itself might conflict. Untill a suitably educated lawyer has
studied it for a week or two I would not trust it.

For instance: as I read it the LGPL allows re-distribution of the
library or a derivate of it under LGPL (without the additional prefix!)
or even GPL. I would want such redistribution under the original license
(with prefix) only. This was the second reson I did not choose such a
construct for the Jal libraries. (The first one is that an existing
(recognised) license is to be preferred.)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\08\09@140424 by Byron A Jeff

face picon face
On Mon, Aug 09, 2004 at 04:56:23PM +0200, Wouter van Ooijen wrote:
> > For me the zip license terms are OK. What paragraphs should
> > be added to
> > make it suitable for you Wouter,  Byron and all other interested.
>
> - zlib is suitable for me, although not perfect

The imperfections are what this new license would address.

> - I much prefer a 'recognised' free license to a tweaked one

OSI accepts new licenses. Acceptance by OSI which sourceforge uses as their
benchmark should qualify as recognized.

Finally there's a real need here. Most licenses seem to be geared towards
big systems where code/address space separation is easy to do. We have a
consensus on several issues.

1) We all agree that big systems licenses don't necessarily work in the
embedded world.

2) We also all agree that changes to free software should also be free.

3) We also agree that combinations of free and non-free software shouldn't
taint the non-free software.

4) I think we agree that users should know their rights in respect to free
software.

5) We definitely agree that a license that covers all of these issues doesn't
exist.

There's a void. We should fill it.

BAJ

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\08\09@141919 by Josh Koffman

face picon face
I'm game to help out, act as editor, etc. Why don't we start more of a
formal list of what we want in the licence?

I hope this doesn't turn into one of those lost PICList causes though.

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

On Mon, 9 Aug 2004 14:05:09 -0400, Byron A Jeff <@spam@byron@spam@spamspam_OUTcc.gatech.edu> wrote:
{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\08\09@142750 by Wouter van Ooijen

face picon face
> OSI accepts new licenses. Acceptance by OSI which sourceforge
> uses as their benchmark should qualify as recognized.

Did you check what is required in the recognition process? I don't deny
that I would like to see an OSI-accepted license that suits my needs
perfectly, but I am not going to put that much work/money into it!

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\08\09@143411 by Ake Hedman

flavicon
face
>1) We all agree that big systems licenses don't necessarily work in the embedded world.
I think there is consensus on this already after the previous discussion.

>2) We also all agree that changes to free software should also be free.
Yes, absolutly.

>3) We also agree that combinations of free and non-free software shouldn't taint the non-free software.The points including the  >disclaimer in the zip license
Yes!

> 4) I think we agree that users should know their rights in respect to free software.
Unsure what you are after here....

>5) We definitely agree that a license that covers all of these issues doesn't exist.
I think we found that out also.


>OSI accepts new licenses....
How does the work flow look like to get a license accepted by OSI?


Regards
/Ake



--  ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\08\09@143825 by Ake Hedman

flavicon
face
The best is if someone (Josh, Byron...) write something we can use as a starting point. Take the zip license add Byrons points and we mangle it down together. This can work if we don't dig ourselves down to deep and keep it as simple as possible (in a legal sense).

/Ake

Josh Koffman wrote:

{Quote hidden}

--  ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org


--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\08\09@152358 by Josh Koffman

face picon face
Sounds reasonable. I'm at work at the moment, but if someone can point
me to the text of the licence, I can try to make changes, deletions,
and additions if people are interested. However, as others have asked,
any idea what it takes to get a licence approved?

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

On Mon, 9 Aug 2004 20:39:17 +0200, Ake Hedman <.....akhespam_OUTspameurosource.se> wrote:
> The best is if someone (Josh, Byron...) write something we can use as a
> starting point. Take the zip license add Byrons points and we mangle it
> down together. This can work if we don't dig ourselves down to deep and
> keep it as simple as possible (in a legal sense).

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\08\09@152819 by Wouter van Ooijen

face picon face
> However, as others have asked,
> any idea what it takes to get a licence approved?

check http://www.opensource.org/docs/certification_mark.php#approval

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\08\09@155541 by Byron A Jeff

face picon face
On Mon, Aug 09, 2004 at 08:28:11PM +0200, Wouter van Ooijen wrote:
> > OSI accepts new licenses. Acceptance by OSI which sourceforge
> > uses as their benchmark should qualify as recognized.
>
> Did you check what is required in the recognition process? I don't deny
> that I would like to see an OSI-accepted license that suits my needs
> perfectly, but I am not going to put that much work/money into it!

I did. It seemed to boil down to.

1) Write the license.

2) Have a lawyer write a point by point justfication. Hence my question of
  "are there any lawyers here on the list." I have a old friend of mine
  who's a PhD Computer Scientist and a Patent Attorney. I can ask him if he
  might be willing to read it over.

4) Submit the whole mess to OSI for review and eventual approval.

Also we may be getting ahead of the game. There may in fact be a license that
meets our needs. But trying to figure out the legalese is a bit tough.

I'll happily ask on gnu.discuss.misc if there's a license that meets the need
that is already OSI approved, then we can call it a day.

There's also a OSI license mailing list. If anyone knows the ins and outs of
Open Source Licensing, that would be the place.

BAJ

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\08\09@161036 by Josh Koffman

face picon face
Well Byron, if you're willing to ask, I say go for it. I don't think I
have the time to monitor another mailing list (usenet group) :)

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

On Mon, 9 Aug 2004 15:54:51 -0400, Byron A Jeff <TakeThisOuTbyron.....spamTakeThisOuTcc.gatech.edu> wrote:
> I'll happily ask on gnu.discuss.misc if there's a license that meets the need
> that is already OSI approved, then we can call it a day.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\08\09@171851 by Ake Hedman

flavicon
face
Josh Koffman wrote:

{Quote hidden}

Yes, that would be great.

/Ake

--  ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org


--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

More... (looser matching)
- Last day of these posts
- In 2004 , 2005 only
- Today
- New search...