Subject: [Roll] Software Licensing and RPL

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Feb 2010 17:48:22 +0100

What are the _software_ licensing schemes (not IPR) which I can expect
from RPL designed at IETF?

Can RPL be implemented in a linux kernel (GPL)?

Can RPL be implemented in a Open Source project?

In the past, when people tried to port the TCP/IP stack from BSD to
linux they realize (after months of work) the BSD licensing would
prevent them, and rewrote it from scratch.

Now that I see the word "BSD" mentioned in the RPL draft (which is new,
not all RFCs do) I am afraid there may be some software licensing problems.

Alex

---

From: Philip Levis <[email-masked]>
Date: Wed, 10 Feb 2010 09:17:29 -0800

> Can RPL be implemented in a linux kernel (GPL)?

Yes.

> Can RPL be implemented in a Open Source project?

Yes.

> prevent them, and rewrote it from scratch.

I don't think this is true. Do you have a reference?

Phil

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Feb 2010 19:17:43 +0100

>> Can RPL be implemented in a linux kernel (GPL)?

The draft says BSD (Berkeley Systems Distrib).  The linux kernel is GPL
(General Public License).  I suppose there may be a contradiction, in
the sense that all that runs in the linux kernel MUST be GPL, otherwise
it's binary (no source available).

What do you mean when you say 'Yes' to the question of linux kernel and RPL?

>> Can RPL be implemented in a Open Source project?

Which Open Source license is compatible with RPL document?

>> In the past, when people tried to port the TCP/IP stack from BSD
>> to linux they realize (after months of work) the BSD licensing
>> would prevent them, and rewrote it from scratch.
>

I am not sure which part you believe untrue?

Sorry, I don't have a reference, just some thoughts not published
anywhere else.

I noticed there are only few TCP/IP stacks in wide use, and are
either the BSD's or the linux's.  And knowing the linux's came much
later after BSD, and after BSD was already integrated in many commercial
systems, one wonders why did they write a stack from scratch for linux?
  I suppose it was because of the licensing.

Alex

---

From: Philip Levis <[email-masked]>
Date: Wed, 10 Feb 2010 11:25:34 -0800

> What do you mean when you say 'Yes' to the question of linux kernel and RPL?

Alex, I don't really want to turn this list into a primer on source licenses. The basic point is that you can take code under a BSD license and release it under a GPL license. The original BSD license remains. While Theo de Raadt has commented on how he finds this personally offensive[1], you can of course do it.

> Which Open Source license is compatible with RPL document?

Please go read about open source licensing and all of the ways in which different licenses can interact. As you might imagine, this information is very available on the Internet. Let's not clog up this list with the basics of a quite mature area of concern which isn't at all ROLL-specific.

> I suppose it was because of the licensing.

So, you don't know, made something up based on your best (clearly uninformed) guess, and then asserted it as truth? That's not a good approach for anyone to take your concerns seriously.

Phil

[1] http://kerneltrap.org/OpenBSD/Stealing_Versus_Sharing_Code

---

From: Joakim Eriksson <[email-masked]>
Date: Wed, 10 Feb 2010 20:25:52 +0100

> What do you mean when you say 'Yes' to the question of linux kernel and 

 From this description http://en.wikipedia.org/wiki/BSD_licenses and
reading the version of the suggested BSD license it seems to be
compatible with GPL so implementing in Linux should not be any problems.
The original BSD license had problems since it imposed some 
"advertisement" in the user interface of the software that used the
BSD licensed software.

> Which Open Source license is compatible with RPL document?

Most. Look at above link. And there is not much code to actually
take from the RPL specification. It would take almost not time at
all to write that code instead of "cut-n-pasing" from the
RPL-specification if the license would be a problem.

>  I suppose it was because of the licensing.

It might have been an original 4-clause BSD license that is not 
compatible with GPL.

Best regards,
-- Joakim Eriksson, SICS

> Alex
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Adam Dunkels <[email-masked]>
Date: Wed, 10 Feb 2010 20:27:28 +0100

> What do you mean when you say 'Yes' to the question of linux kernel and 

There is nothing that prevents an implementation of RPL to adopt any 
software license that the copyright holder may chose. RPL can be 
implemented as non-open source software, as GPL free software, as 
MIT/X11/BSD/Apache/whatever open source software. It is up to the 
copyright holder and not up to the IETF to decide. The RPL draft does 
not appear to contain any code or otherwise copyrightable tables. It 
seems that the Code Components clause has been added only because it is 
in the boiler plate, and not because the draft contains any code that 
needs it.

In any case, a 3-clause BSD-licensed RPL implementation can without 
problems be combined with GPL code. I.e., such an implementation can be 
included in the Linux kernel. A GPL licensed RPL implementation could 
also be included in the Linux kernel. And so forth. It is not up to the 
IETF to decide what licenses the implementations choose to use. The only 
code that the IETF can assert copyright over is code that is part of an 
RFC or other IETF document. In this case, there seems to be nosuch code.

> Sorry, I don't have a reference, just some thoughts not published

I think you may be recalling the problems that existed with the old 
4-clause BSD license. This license was used for the original BSD code, 
and included an "advertising clause" which was deemed to be 
non-compatible with the GPL. This may have prompted people to rewrite 
the TCP/IP stack under the GPL.

This 4th clause has subsequently been removed and the BSD license is now 
compatible with the GPL. You'll find it on the list here: 
http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses

/adam
-- 
Adam Dunkels <[email-masked]> | +46 70 7731614 | http://www.sics.se/~adam/
Book: Interconnecting Smart Objects with IP - http://TheNextInternet.org

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Feb 2010 20:51:55 +0100

Le 10/02/2010 20:27, Adam Dunkels a écrit :
> software license that the copyright holder may chose.

Sorry, but the fact this Internet Draft says it must be "BSD" worries me 
a lot, especially from the GPL standpoint.

> RPL can be
> copyright holder and not up to the IETF to decide.

IETF says: "BSD", in the draft.

Alex

  The RPL draft does

---

From: Adam Dunkels <[email-masked]>
Date: Wed, 10 Feb 2010 20:54:30 +0100

> a lot, especially from the GPL standpoint.

It is not a problem.

/adam

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Feb 2010 20:57:42 +0100

> compatible with GPL so implementing in Linux should not be any problems.

I meant linux kernel.  Is there some BSD code in the linux kernel?

Alex

---

From: Adam Dunkels <[email-masked]>
Date: Wed, 10 Feb 2010 21:08:16 +0100

> I meant linux kernel.  Is there some BSD code in the linux kernel?

Plenty. Here are a few examples, from a quick search:
http://lxr.linux.no/#linux+v2.6.32/include/acpi/actbl.h#L11
http://lxr.linux.no/#linux+v2.6.32/include/acpi/acexcep.h#L11
http://lxr.linux.no/#linux+v2.6.32/scripts/unifdef.c#L4
http://lxr.linux.no/#linux+v2.6.32/drivers/net/bsd_comp.c#L14

/adam

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Feb 2010 21:08:52 +0100

Le 10/02/2010 20:27, Adam Dunkels a écrit :
> [...] It seems that the Code Components clause has been added only
> because it is in the boiler plate, and not because the draft contains
> any code that needs it.

It makes no sense whatsoever for the boilerplate to talk "Code
Components" and there to be no "Code Components".

Let's remove the word "Code Components" because there are no "Code
Components".

Similarly to the reason why we put the Abstract first because it should
be there first.

> It is not up to the IETF to decide what licenses the implementations
> choose to use.

Well, but why does IETF force us to use the word "BSD" in the RPL
document?  Isn't that a license?

> The only code that the IETF can assert copyright over is code that is
> part of an RFC or other IETF document. In this case, there seems to
> be nosuch code.
>
>>>> In the past, when people tried to port the TCP/IP stack from
>>>> BSD to linux they realize (after months of work) the BSD
>>>> licensing would prevent them, and rewrote it from scratch.
>>>
> 4-clause BSD license. This license was used for the original BSD
> code, and included an "advertising clause" which was deemed to be

Also, this was possible because the TCP/IP RFCs did not have such "BSD"
word in them.

It was a great advantage to have two different implementations of
TCP/IP, interoperable.

Were the RFCs to say "BSD" then the GPL'ed stack would have been impossible.

> This 4th clause has subsequently been removed and the BSD license is
>  now compatible with the GPL. You'll find it on the list here:

LKe't s not use https redirections, it's very difficult.

That same URL you post as indication says it's risky to recommend the
use of the "BSD license" and the X11 should be referred to instead.

I don't care about them.

I want no license in this document RPL.  If there should be one, then
let the implementer (yes, the implementer) write it.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Feb 2010 21:09:04 +0100

Le 10/02/2010 20:25, Philip Levis a écrit :
[blah]
> The basic point is that you can take code under a BSD license
> and release it under a GPL license. The original BSD license remains.

I think it's impossible to take BSD code and turn it into GPL code.

Let me say that I have my strong reasons to not want that "BSD" word in 
this draft.  Or otherwise make it experimental.

Alex

> While Theo de Raadt has commented on how he finds this personally
> offensive[1], you can of course do it.
>
>>
> Please go read about open source licensing and all of the ways in which
> different licenses can interact. As you might imagine, this information
> is very available on the Internet. Let's not clog up this list with the
> basics of a quite mature area of concern which isn't at all ROLL-specific.
>
>>
> So, you don't know, made something up based on your best (clearly
> uninformed) guess, and then asserted it as truth? That's not a good
> approach for anyone to take your concerns seriously.
>
> Phil
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Feb 2010 21:16:07 +0100

Le 10/02/2010 20:25, Philip Levis a écrit :
[...]
> Please go read about open source licensing and all of the ways in
> which different licenses can interact. As you might imagine, this
> information is very available on the Internet. Let's not clog up this
> list with the basics of a quite mature area of concern which isn't at
> all ROLL-specific.

WEll thanks for the redirection, I just went to the IPR WG and made some
questions about this.  I'll stop clogging this list about this.

[...]
> approach for anyone to take your concerns seriously.

Philip, I once wrote an open source license.

I don't want the word "BSD" in this RPL document.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Feb 2010 21:20:27 +0100

> http://lxr.linux.no/#linux+v2.6.32/drivers/net/bsd_comp.c#L14

Ah I see what you mean.

For example Intel may ask linux community to include their license in
the kernel.

I don't want IETF to ask the linux community to include the "BSD"
license, whatever version of BSD that may be.

If IETF has to ask anybody implementing RFCs to include some license
then let it be GPL and not some BSD derivative.

I am wondering why am I spending time on this anyways... :-(

Alex

---

From: Nicolas Tsiftes <[email-masked]>
Date: Wed, 10 Feb 2010 21:31:40 +0100

> I am wondering why am I spending time on this anyways... :-(

Hello Alex,

First, if there would have been any code in the draft, which there isn't 
by the way, the implementor is free to neglect it and write own code. 
Second, if the license would've been GPL instead of BSD, and the 
implementor for some unknown reason would'vee been forced to include 
this nonexistent code in the implementation, the license would've made 
it impossible to include in BSD kernels. On the other hand, the 
nonexistent BSD-licensed code would be possible to include in both 
BSD-licensed and closed-source kernels (which the BSD license allows.)

Nicolas

---

From: Owen Kirby <[email-masked]>
Date: Wed, 10 Feb 2010 12:34:50 -0800

Alex,

As I understand the BSD license and how it is involved with the RPL 
specification, we're not imposing any license on any implementation of 
the RPL specification. The copyright license applies to the text of the 
RPL document which may contain (pseudo)code or MIB structures, and only 
comes into effect if you copy that text from the specification. An 
implementation of RPL is not considered a copy of the specification, and 
can fall under any license the software author chooses, be it BSD, GPL 
or something entirely proprietary.

Even so, If we allow the proposition that the copyright license for the 
RPL specification gets carried over to any implementations of that spec, 
then a modified BSD license is an excellent choice, since it is not a 
copyleft license and can be integrated with almost any other license 
(including the GPL). The GPL would be an extremely bad choice for RPL, 
since the copyleft provisions would effectively prohibit implementing 
RPL in anything other than the Linux network stack. In particular, you 
couldn't add RPL to the BSD stack.

As an additional question, why do we need a license anyways? Is there 
any danger in making these code and MIB components public domain?

Thanks,
Owen

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Feb 2010 21:41:38 +0100

Le 10/02/2010 21:31, Nicolas Tsiftes a écrit :
>> For example Intel may ask linux community to include their license
>>  in the kernel.
>>
>> If IETF has to ask anybody implementing RFCs to include some
>> license then let it be GPL and not some BSD derivative.
>>
> First, if there would have been any code in the draft,

There is a table in the IANA section which will soon contain values.
There are certainly some names which will be used in the macro definitions.

The "Code Components" as per IETF definition may include these.

Now, what is "Code"?  If you wish we can discuss it too.

> which there isn't by the way, the implementor is free to neglect it
> and write own code.

I think that if I use a value from the RPL IANA table and some macro 
from the text then I no longer write own code, but reuse from the draft. 
  Which is normal.

What I don't want is to have that BSD tag on the values from the IANA 
table.  Or, Code Components seem to.

>  this nonexistent code in the implementation, the license would've
> made it impossible to include in BSD kernels.

A-ha!  Even worse!  So if this draft said "GPL" the the BSD community
wouldn't be happy at all.  So why should the GPL community be happy when
this draft says "BSD"?

> On the other hand, the nonexistent BSD-licensed code would be
> possible to include in both BSD-licensed and closed-source kernels
> (which the BSD license allows.)

Non-existent code?  Why does the preamble say "Code Components extracted
from this draft"?

This makes no sense, please remove "Code Components" from the preamble
and the BSD word too.

Please remove all that's not necessary and that can cause confusion.

Alex

---

From: John E Drake <[email-masked]>
Date: Wed, 10 Feb 2010 12:53:59 -0800

It sounds as though this is much ado about nothing

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alexandru Petrescu
> Sent: Wednesday, February 10, 2010 12:42 PM
> To: Nicolas Tsiftes
> Cc: [email-masked]
> Subject: Re: [Roll] Software Licensing and RPL
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Feb 2010 21:57:09 +0100

Le 10/02/2010 21:34, Owen Kirby a écrit :
> specification, we're not imposing any license on any implementation
> of the RPL specification. The copyright license applies to the text
> of the

Copyright applying to text is ok.  But BSD applies to code, not
to text ("provided AS-IS" - who cares about text being "AS-IS"?).

Why talking BSD if there's no code?  It would be sufficient to
talk only Copyright.

> RPL document which may contain (pseudo)code or MIB structures, and
> only comes into effect if you copy that text from the specification.

What if I use a value from the table, and a name as a macro?  Does that
BSD license apply?  I am tempted to say yes because IETF Trust seems to
say so in its description of "Code Components" - it says more than just
MIB - tables and values too.

BEsides, not even the MIBs - I don't want MIBs tagged BSD.

Ah if only I knew this BSD default preamble... I wouldn't have
contributed to so many discussions, time spent for nothing, really.

> An implementation of RPL is not considered a copy of the
> specification, and can fall under any license the software author
> chooses, be it BSD, GPL or something entirely proprietary.

I won't blindly submit example code to this draft knowing it will be
automatically tagged BSD.  No thanks.

And as an implementer having implemented some RFCs I often said thanks
when I found C code in that RFC.

But this document with that "BSD" on it and without code, this draft
won't have many thanks from GPL implementers.  And they won't submit GPL 
code either.

> Even so, If we allow the proposition that the copyright license for
> the RPL specification gets carried over to any implementations of
> that spec, then a modified BSD license is an excellent choice, since
> it is not a copyleft license and can be integrated with almost any
> other license (including the GPL). The GPL would be an extremely bad
> choice for RPL, since the copyleft provisions would effectively
> prohibit implementing RPL in anything other than the Linux network
> stack. In particular, you couldn't add RPL to the BSD stack.

Well, if it is so (GPL code couldn't make it into BSD kernel) then don't
tag the draft "GPL" either.  Don't tag it anything, just like before,
let the implementer choose the license.

> As an additional question, why do we need a license anyways? Is
> there any danger in making these code and MIB components public
> domain?

I agree in this sense.  Don't tag _any_ software license on the Internet
Draft RPL.  If there is a license to be tagged then make it GPL.

Alex

> Thanks, Owen
>> _______________________________________________ Roll mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Feb 2010 22:12:28 +0100

> It sounds as though this is much ado about nothing

WEll ok, I can stop posting in this WG as well.

(after having seen so many times complains about licensing _after_ the
fact - as if people did not know before that the preamble part
(boilerplate) is there to mean something).

Alex

>
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
>> Sent: Wednesday, February 10, 2010 12:42 PM To: Nicolas Tsiftes
>> Cc: [email-masked] Subject: Re: [Roll] Software Licensing and RPL
>>
>>>> For example Intel may ask linux community to include their
>>>> license in the kernel.
>>>>
>>>> I don't want IETF to ask the linux community to include the
>>>> "BSD" license, whatever version of BSD that may be.
>>>>
>> There is a table in the IANA section which will soon contain
>> values. There are certainly some names which will be used in the
>> macro definitions.
>>
>>> which there isn't by the way, the implementor is free to neglect
>>> it and write own code.
>>
>> I think that if I use a value from the RPL IANA table and some
>> macro from the text then I no longer write own code, but reuse
>> from the draft. Which is normal.
>>
>> What I don't want is to have that BSD tag on the values from the
>> IANA table.  Or, Code Components seem to.
>>
>>>  implementor for some unknown reason would'vee been forced to
>>> include this nonexistent code in the implementation, the license
>>> would've made it impossible to include in BSD kernels.
>>
>> A-ha!  Even worse!  So if this draft said "GPL" the the BSD
>> community wouldn't be happy at all.  So why should the GPL
>> community be happy when this draft says "BSD"?
>>
>>> possible to include in both BSD-licensed and closed-source
>>> kernels (which the BSD license allows.)
>>
>> Non-existent code?  Why does the preamble say "Code Components
>> extracted from this draft"?
>>
>> This makes no sense, please remove "Code Components" from the
>> preamble and the BSD word too.
>>
>> Alex _______________________________________________ Roll mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/roll
>

---

From: Jon Smirl <[email-masked]>
Date: Wed, 10 Feb 2010 22:08:44 -0500

> I think it's impossible to take BSD code and turn it into GPL code.

The GPL license is a super set of BSD.  Plenty of BSD code has been
incorporated into the Linux kernel. I work on the Linux kernel and
combining BSD and GPL code has been discussed in great detail. All of
the kernel mode setting and direct rendering code is BSD licensed.

Open source lawyers have written an explicit procedure for integrating
BSD code into GPL software. I can find the document if needed.  The
key danger is taking patches made to the GPL code base back into the
BSD code base, you don't want to inadvertently turn the BSD code into
GPL code. An explicit step of also contributing the patch to the BSD
code base is needed.

Royalty bearing patents are completely incompatible with the GPL. The
GPL requires the developer to redistribute code without royalty and
for copying costs only. Nobody bothers with the copying cost so the
code is effectively free. If RPL needs a patent royalty it will never
go into the Linux kernel. To work around this companies like IBM grant
royalty free patent licenses for use in GPL'd software. Putting a
royalty requirement on the protocol will pretty much ensure that the
Linux kernel people will build an alternative solution that is GPL
compatible.

Since virtually every home router in existence runs Linux, I'd hope
that RPL can be added to the kernel so that it can easily be
incorporated into these routers.  Add $10 of 802.15.4 hardware and all
of these routers can talk to smart meters, dimmers, thermostats, etc.

>
> Let me say that I have my strong reasons to not want that "BSD" word in this
> draft.  Or otherwise make it experimental.
>
> Alex
>

-- 
Jon Smirl
[email-masked]

---

From: Geoff Mulligan <[email-masked]>
Date: Wed, 10 Feb 2010 23:40:04 -0700

Adam,
  So this is an interesting, how does someone writing open source code
notify the the users of that code that the software is encumbered with
patents, so that people that take the code understand that they are
using software that comes with a license.

	geoff

---

From: Adam Dunkels <[email-masked]>
Date: Thu, 11 Feb 2010 08:41:14 +0100

Hi Geoff,

(Disclaimer: I am not a lawyer)

> using software that comes with a license.

First, patents and copyrights are *completely* separate issues and 
should not be confused with each other. So if I may interpret your 
question as two questions, one regarding patents and one regarding 
copyright:

(1) how do you let people know that your system (open source or closed 
source, it doesn't matter) is covered by patents?

and

(2) how do you let people know that your code is open source and can be 
distributed and modified under a copyright license?

One way to solve (1) is to include a list of patents that covers the 
software. You see this sometimes (e.g. vmware: 
http://www.vmware.com/download/patents.html). It is not an obligation to 
inform anyone of such patents, however. Most, if not all, software 
systems today are covered by many patents from different parties. The 
open source Linux kernel is covered by patents from IBM, Apple, 
Microsoft, etc. The closed source Windows kernel is also covered by 
patents, as is the Mac OS X kernel. Call me a cynic, but software 
patents seem to have very little to do with technology or innovation.

The normal way to solve (2) is simply to tell people that your software 
is open source and may be redistributed under a specific license. 
Without such a license, the software may not be redistributed - 
redistribution is always forbidden in by law, unless explicitly allowed 
by a copyright license.

/adam

---

From: JP Vasseur <[email-masked]>
Date: Thu, 11 Feb 2010 09:36:30 +0100

Interesting discussion as pointing out by Adam, these are separate  
issues so if I may let's move the licensing discussing to the  
appropriate WG.

On Feb 11, 2010, at 8:41 AM, Adam Dunkels wrote:

> (1) how do you let people know that your system (open source or  
> closed source, it doesn't matter) is covered by patents?
>
> and
>
> (2) how do you let people know that your code is open source and can  
> be distributed and modified under a copyright license?
>
> software. You see this sometimes (e.g. vmware: http://www.vmware.com/download/patents.html) 
> . It is not an obligation to inform anyone of such patents, however.  
> Most, if not all, software systems today are covered by many patents  
> from different parties. The open source Linux kernel is covered by  
> patents from IBM, Apple, Microsoft, etc. The closed source Windows  
> kernel is also covered by patents, as is the Mac OS X kernel. Call  
> me a cynic, but software patents seem to have very little to do with  
> technology or innovation.
>
> The normal way to solve (2) is simply to tell people that your  
> software is open source and may be redistributed under a specific  
> license. Without such a license, the software may not be  
> redistributed - redistribution is always forbidden in by law, unless  
> explicitly allowed by a copyright license.
>
> /adam
> --

---

From: Jon Smirl <[email-masked]>
Date: Thu, 11 Feb 2010 08:26:52 -0500

On Thu, Feb 11, 2010 at 3:36 AM, JP Vasseur <[email-masked]> wrote:
> Interesting discussion as pointing out by Adam, these are separate issues so
> if I may let's move the licensing discussing to the appropriate WG.

The issue of incorporating royalty bearing patents into the RPL
standard is a highly relevant one. Royalties prevent incorporation of
RPL into the Linux kernel and will probably result in the creation of
an alternative, unencumbered protocol.

Is Cisco willing to provide a royalty free license for their patents
when RPL is implemented in GPL licensed code? Will other people with
IP claims provide a GPL compatible license?

This is the same issue Mozilla is currently facing with H.264. Mozilla
is GPL licensed, H.264 requires royalties. Mozilla can't include
H.264. So far this has resulted in the Google acquiring ON2. We're
still waiting for Google to announce a royalty free alternative to
H.264 as a result of the ON2 acquisition. YouTube will be converted to
this new codec and Mozilla will be able to incorporate it. H.264 will
lose the Internet.

>> First, patents and copyrights are *completely* separate issues and should
>> not be confused with each other. So if I may interpret your question as two
>> questions, one regarding patents and one regarding copyright:
>>
>> inform anyone of such patents, however. Most, if not all, software systems
>> today are covered by many patents from different parties. The open source
>> Linux kernel is covered by patents from IBM, Apple, Microsoft, etc. The
>> closed source Windows kernel is also covered by patents, as is the Mac OS X
>> kernel. Call me a cynic, but software patents seem to have very little to do
>> with technology or innovation.
>>
>> The normal way to solve (2) is simply to tell people that your software is
>> open source and may be redistributed under a specific license. Without such
>> a license, the software may not be redistributed - redistribution is always
>> forbidden in by law, unless explicitly allowed by a copyright license.
>>
>> /adam
>> --

-- 
Jon Smirl
[email-masked]