OpenRecord license

For those of you who are interested in the finer points of
open source 
licensing...

When I started OpenRecord, back in 2005, I started it as a
public domain 
project, using a public domain dedication (PDD) instead of
an open 
source license.  My goal was to distribute the code with no 
restrictions, so that anyone could take all of the code, or
any small 
part of it, and use it for any purpose.  When we became a
project of the 
Dojo Foundation, we agreed to also distribute the code under
the 
Academic Free License (AFL), the standard license used by
all Dojo 
Foundation projects.

Since then, I've been gradually learning more about public
domain 
dedications -- reading FAQs, talking with attorneys, and
corresponding 
with other open source developers.  It's become
increasingly clear that 
using the PDD is problematic.  It's also problematic to try
to use the 
PDD in conjunction with the AFL.  Last week our own attorney
gave me her 
advice on the matter, confirming what I had heard elsewhere.
 If you're 
interested in the gnarly details, let me know, and I can
post a quick 
summary about why the PDD is problematic.

Based on the advice we've gotten, I believe we should stop
running 
OpenRecord as a public domain project, and instead simply
distribute the 
OpenRecord code using the AFL, a conventional open source
license.  We 
might also consider dual-licensing under both the AFL and
the BSD 
License, as the Dojo Toolkit does.  I'm planning to raise
this issue 
over on the dojo-contributors mailing list, where we can
have a vote of 
the dojo committers and (hopefully) get approval for the
change.

If the dojo committers approve of change, then the old code
in our SVN 
repository would continue to be in the public domain (up to
revision N), 
but revision N+1 would be a derivative work that would be
licensed under 
the AFL (and perhaps BSD) but would not be placed in the
public domain.

In addition to placing the OpenRecord source code in the
public domain, 
we've also been placing all the ancillary material in the
public domain: 
the screencasts, the web site, the posts to the mailing
list, etc.  At 
some point we might want to revisit that decision, but the
PDD is not as 
problematic for those uses as it was for the source code, so
for now I 
think it's fine to keep using the PDD for that content.

~ Brian




____________________________________________________________
_______
Copyright rights relinquished. This work is in the Public
Domain.
For details see: htt
p://creativecommons.org/licenses/publicdomain/

openrecord-dev mailing list
openrecord-devlists.berlios.de
https://lists.berlios.de/mailman/listinfo/openrecord-dev

Brian, I would like to learn, why public domain  is
problematic for 
software projects.

I thought up to now, that Python, is published as
"public domain".
But I looked closer 
(http://www.python.org/download/releases/2.4.2/license/
)  and in fact,
python is not distributed as public domain but with a
license, giving 
you most of the
benefits of public domain

    '' GPL-compatible doesn't mean that we're
distributing Python under
    the GPL.  All Python licenses, unlike the GPL, let you
distribute
    a modified version without making your changes open
source.  The
    GPL-compatible licenses make it possible to combine
Python with
    other software that is released under the GPL; the
others don't.''
   
but still is a license which forces you

- to keep the copyright info in it
- to accept the software "as it is"


Publishing software as PD gives you no license at all, but
software 
developers
and publishers need at least be protected from possible
infringements.

Is this the point ?

I share this letter with the "working in
parallel" mailinglist of
minciu sodas (http://www.ms.lt/) and hope you
feel comfortable with that.

--Thomas Kalka


Brian Douglas Skinner wrote:
> For those of you who are interested in the finer points
of open source 
> licensing...
>
> When I started OpenRecord, back in 2005, I started it
as a public domain 
> project, using a public domain dedication (PDD) instead
of an open 
> source license.  My goal was to distribute the code
with no 
> restrictions, so that anyone could take all of the
code, or any small 
> part of it, and use it for any purpose.  When we became
a project of the 
> Dojo Foundation, we agreed to also distribute the code
under the 
> Academic Free License (AFL), the standard license used
by all Dojo 
> Foundation projects.
>
> Since then, I've been gradually learning more about
public domain 
> dedications -- reading FAQs, talking with attorneys,
and corresponding 
> with other open source developers.  It's become
increasingly clear that 
> using the PDD is problematic.  It's also problematic
to try to use the 
> PDD in conjunction with the AFL.  Last week our own
attorney gave me her 
> advice on the matter, confirming what I had heard
elsewhere.  If you're 
> interested in the gnarly details, let me know, and I
can post a quick 
> summary about why the PDD is problematic.
>
> Based on the advice we've gotten, I believe we should
stop running 
> OpenRecord as a public domain project, and instead
simply distribute the 
> OpenRecord code using the AFL, a conventional open
source license.  We 
> might also consider dual-licensing under both the AFL
and the BSD 
> License, as the Dojo Toolkit does.  I'm planning to
raise this issue 
> over on the dojo-contributors mailing list, where we
can have a vote of 
> the dojo committers and (hopefully) get approval for
the change.
>
> If the dojo committers approve of change, then the old
code in our SVN 
> repository would continue to be in the public domain
(up to revision N), 
> but revision N+1 would be a derivative work that would
be licensed under 
> the AFL (and perhaps BSD) but would not be placed in
the public domain.
>
> In addition to placing the OpenRecord source code in
the public domain, 
> we've also been placing all the ancillary material in
the public domain: 
> the screencasts, the web site, the posts to the mailing
list, etc.  At 
> some point we might want to revisit that decision, but
the PDD is not as 
> problematic for those uses as it was for the source
code, so for now I 
> think it's fine to keep using the PDD for that
content.
>
> ~ Brian
>
>
>
>
>
____________________________________________________________
_______
> Copyright rights relinquished. This work is in the
Public Domain.
> For details see: htt
p://creativecommons.org/licenses/publicdomain/
>
> openrecord-dev mailing list
> openrecord-devlists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openrecord-dev

>
>   
____________________________________________________________
_______
Copyright rights relinquished. This work is in the Public
Domain.
For details see: htt
p://creativecommons.org/licenses/publicdomain/

openrecord-dev mailing list
openrecord-devlists.berlios.de
https://lists.berlios.de/mailman/listinfo/openrecord-dev

Brian, I would like to learn, why public domain  is
problematic for 
software projects.

I thought up to now, that Python, is published as
"public domain".
But I looked closer 
(http://www.python.org/download/releases/2.4.2/license/
)  and in fact,
python is not distributed as public domain but with a
license, giving 
you most of the
benefits of public domain

    '' GPL-compatible doesn't mean that we're
distributing Python under
    the GPL.  All Python licenses, unlike the GPL, let you
distribute
    a modified version without making your changes open
source.  The
    GPL-compatible licenses make it possible to combine
Python with
    other software that is released under the GPL; the
others don't.''
   
but still is a license which forces you

- to keep the copyright info in it
- to accept the software "as it is"


Publishing software as PD gives you no license at all, but
software 
developers
and publishers need at least be protected from possible
infringements.

Is this the point ?

I share this letter with the "working in
parallel" mailinglist of
minciu sodas (http://www.ms.lt/) and hope you
feel comfortable with that.

--Thomas Kalka


Brian Douglas Skinner wrote:
> For those of you who are interested in the finer points
of open source 
> licensing...
>
> When I started OpenRecord, back in 2005, I started it
as a public domain 
> project, using a public domain dedication (PDD) instead
of an open 
> source license.  My goal was to distribute the code
with no 
> restrictions, so that anyone could take all of the
code, or any small 
> part of it, and use it for any purpose.  When we became
a project of the 
> Dojo Foundation, we agreed to also distribute the code
under the 
> Academic Free License (AFL), the standard license used
by all Dojo 
> Foundation projects.
>
> Since then, I've been gradually learning more about
public domain 
> dedications -- reading FAQs, talking with attorneys,
and corresponding 
> with other open source developers.  It's become
increasingly clear that 
> using the PDD is problematic.  It's also problematic
to try to use the 
> PDD in conjunction with the AFL.  Last week our own
attorney gave me her 
> advice on the matter, confirming what I had heard
elsewhere.  If you're 
> interested in the gnarly details, let me know, and I
can post a quick 
> summary about why the PDD is problematic.
>
> Based on the advice we've gotten, I believe we should
stop running 
> OpenRecord as a public domain project, and instead
simply distribute the 
> OpenRecord code using the AFL, a conventional open
source license.  We 
> might also consider dual-licensing under both the AFL
and the BSD 
> License, as the Dojo Toolkit does.  I'm planning to
raise this issue 
> over on the dojo-contributors mailing list, where we
can have a vote of 
> the dojo committers and (hopefully) get approval for
the change.
>
> If the dojo committers approve of change, then the old
code in our SVN 
> repository would continue to be in the public domain
(up to revision N), 
> but revision N+1 would be a derivative work that would
be licensed under 
> the AFL (and perhaps BSD) but would not be placed in
the public domain.
>
> In addition to placing the OpenRecord source code in
the public domain, 
> we've also been placing all the ancillary material in
the public domain: 
> the screencasts, the web site, the posts to the mailing
list, etc.  At 
> some point we might want to revisit that decision, but
the PDD is not as 
> problematic for those uses as it was for the source
code, so for now I 
> think it's fine to keep using the PDD for that
content.
>
> ~ Brian
>
>
>
>
>
____________________________________________________________
_______
> Copyright rights relinquished. This work is in the
Public Domain.
> For details see: htt
p://creativecommons.org/licenses/publicdomain/
>
> openrecord-dev mailing list
> openrecord-devlists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openrecord-dev

>
>   
____________________________________________________________
_______
Copyright rights relinquished. This work is in the Public
Domain.
For details see: htt
p://creativecommons.org/licenses/publicdomain/

openrecord-dev mailing list
openrecord-devlists.berlios.de
https://lists.berlios.de/mailman/listinfo/openrecord-dev

What is esactly the difference between a public domain
dedication (PDD)
and an  Academic Free License (AFL)?
Can the AFL be used in commercial software? It is like an
LGPL?
Stornger? Weaker?


On 8/22/06, Brian Douglas Skinner <skinnerdojotoolkit.org> wrote:
> For those of you who are interested in the finer points
of open source
> licensing...
>
> When I started OpenRecord, back in 2005, I started it
as a public domain
> project, using a public domain dedication (PDD) instead
of an open
> source license.  My goal was to distribute the code
with no
-- 
Software Architect
http://www.objectsroot.co
m/
Software is nothing
____________________________________________________________
_______
Copyright rights relinquished. This work is in the Public
Domain.
For details see: htt
p://creativecommons.org/licenses/publicdomain/

openrecord-dev mailing list
openrecord-devlists.berlios.de
https://lists.berlios.de/mailman/listinfo/openrecord-dev

On Tuesday 22 August 2006 12:41 am, Giovanni Giorgi wrote:
> What is esactly the difference between a public domain
dedication
> (PDD) and an  Academic Free License (AFL)?

The AFL is a BSD-like Open Source License which uses
copyright law to 
provide a set of guarantees to users about how they can use
the code 
based on the fact that a license agreement has been offered
and 
accepted.

The Public Domain, OTOH, attempts to divest the original
owner of any 
rights to enforce any agreement whatsoever by disclaiming
any ongoing 
interest in the code.

What the Foundation's lawyers determined is that we can't
both say "if 
you hurt yourself with this software, we can't be
liable" and "we 
divest all interest in the copyrights to this code" at
the same time. 
Since liability disclaimers are a big part of Open Source
software, the 
public domain won't really meet our goals (i.e., we're not
getting paid 
enough to care about whether or not your hurt yourself with
our code).

> Can the AFL be used in commercial software?

Yes. It's explicitly sub-licenseable.

> It is like an LGPL? 

It's more BSD-ish, but includes a weak patent termination
clause. 
Essentially, you retain your right to use us for patent
infringement in 
our software, but if you do, you can no longer use it under
the terms 
of the AFL. You can *try* to screw us over, but we're under
no 
obligation to help you out should you try.

> Stornger? Weaker?

More liberal. Depending on your politics, that could be
viewed as either 
stronger or weaker 

Regards

> On 8/22/06, Brian Douglas Skinner <skinnerdojotoolkit.org> wrote:
> > For those of you who are interested in the finer
points of open
> > source licensing...
> >
> > When I started OpenRecord, back in 2005, I started
it as a public
> > domain project, using a public domain dedication
(PDD) instead of
> > an open source license.  My goal was to distribute
the code with no

-- 
Alex Russell
alexsitepen.com     A99F 8785 F491 D5FD 04D7 ACD9 4158
FFDF 2894 6876
alexdojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78
E242 59C3 9723
____________________________________________________________
_______
Copyright rights relinquished. This work is in the Public
Domain.
For details see: htt
p://creativecommons.org/licenses/publicdomain/

openrecord-dev mailing list
openrecord-devlists.berlios.de
https://lists.berlios.de/mailman/listinfo/openrecord-dev

Giovanni Giorgi wrote:
>> What is esactly the difference between a public
domain 
>> dedication (PDD) and an Academic Free License
(AFL)?

Alex Russell wrote:
> The AFL is a BSD-like Open Source License which uses
copyright 
> law to provide a set of guarantees to users about how
they can 
> use the code based on the fact that a license agreement
has been 
> offered and accepted.
> 
> The Public Domain, OTOH, attempts to divest the
original owner 
> of any rights to enforce any agreement whatsoever by
disclaiming 
> any ongoing interest in the code.

If you're looking for more info, Wikipedia has articles
about the AFL 
and about the public domain:
   ht
tp://en.wikipedia.org/wiki/Academic_Free_License
   http://en.
wikipedia.org/wiki/Public_domain

And the AFL itself is posted here:
   http:/
/www.opensource.org/licenses/afl-3.0.php

The Creative Commons Public Domain Deciation is posted here:
   htt
p://creativecommons.org/licenses/publicdomain/

~ Brian




____________________________________________________________
_______
Copyright rights relinquished. This work is in the Public
Domain.
For details see: htt
p://creativecommons.org/licenses/publicdomain/

openrecord-dev mailing list
openrecord-devlists.berlios.de
https://lists.berlios.de/mailman/listinfo/openrecord-dev

> Brian, I would like to learn, why public domain is
problematic 
> for software projects.

In countries like the United States and India it is possible
to place 
software in the public domain.  In these countries there is
a statutory 
framework for donating software to the public domain. 
However, there 
are a number of problems...

(A) Moral rights problems

In some jurisdictions, including Germany, it is impossible
for an author 
to place a work completely in the public domain.  An author
cannot 
entirely relinquish copyright because the author
automatically retains 
"moral rights."

(B) Liability problems

Placing software in the public domain is risky for the
author because 
the author may retain a "warranty obligation". 
The author may be held 
liable for flaws in the software, or for a user's mis-use
of the 
software.  In the US there is no statutory mechanism for
placing 
software in the public domain without incurring a risk of
liability.  In 
contrast, by using an open source license, the license can
explicitly 
disclaim warranties.

(C) Retraction problems

When an author places a work in the public domain, that may
be 
considered to be a gift, rather than a legal agreement. 
That gift may 
be an "illusory and unenforceable promise" that
could be retracted by 
the author at any time.  Users might refrain from using the
software out 
of fear that the public domain dedication and may someday be
retracted.

(D) OSI certification problems

The Open Source Initiative (OSI) allows you to label your
software as 
"OSI Certified Open Source Software" if the
software is distributed 
using an open source license that has been approved by the
OSI.  The OSI 
has approved about 60 open source licenses, including common
licenses 
like the GPL, LGPL, AFL, BSD, MIT, Apache, Mozilla, etc.

In the 1990s, the OSI explicitly included public domain
software as "OSI 
Certified Open Source Software", but in 2001 the OSI
changed that 
policy, and now public domain software is not approved as
OSI certified. 
  That lack of certification creates practical problems. 
For example, 
every year Google provides millions of dollars of open
source funding 
through their "Summer of Code" program, but
Google will only fund 
projects where the code is released under an OSI approved
license.

(E) Dual-release problems

It is common for open source projects to
"dual-license" their software, 
making the software available under more than one open
source license. 
That allows the user to choose the license that best meets
their needs.

Even though the OSI does not certify public domain software,
it would 
still be possible to get OSI certification if the software
could be 
released using both an OSI certified license and a public
domain 
dedication.  Unfortunately, a dual-release strategy will not
work.  A 
dual-release is considered contradictory, because the author
is 
necessarily asserting copyright rights by using an open
source license, 
while at the same time using a public domain dedication that
asserts 
that no one holds the copyright to the software.

-------------------
Further reading:
[1] http://en.
wikipedia.org/wiki/Public_domain
[2] http://en.wikip
edia.org/wiki/WP:PDWTF
[3] h
ttp://www.zetadev.com/misc/software-public-domain/
[4] http://www.zetadev.com/misc/software-public-dom
ain/responses.html
[5] http://en.w
ikipedia.org/wiki/Moral_rights
[6] http://www.rosenlaw.
com/lj16.htm
[7] http://www.crynwr.com/cgi-bin/ezmlm-cgi?3
:mss:3177:ldaadnjlgdmdomdaofhc




____________________________________________________________
_______
Copyright rights relinquished. This work is in the Public
Domain.
For details see: htt
p://creativecommons.org/licenses/publicdomain/

openrecord-dev mailing list
openrecord-devlists.berlios.de
https://lists.berlios.de/mailman/listinfo/openrecord-dev

> If the Public Domain License may lead to problems, I
think it is 
> better to go for AFL and BSD since the fundamental
objectives of 
> the project will not be changed with the new
agreements.

Yup, I raised the issue on the dojo-contributors mailing
list yesterday, 
and called for a vote:
http://dojotoolkit.org/pipermail/dojo-
contributors/2006-August/003616.html

Voting will close tomorrow.  So far there has been no
objection to the 
proposed change (12 votes in favor, 0 opposed).

 Brian





____________________________________________________________
_______
Copyright rights relinquished. This work is in the Public
Domain.
For details see: htt
p://creativecommons.org/licenses/publicdomain/

openrecord-dev mailing list
openrecord-devlists.berlios.de
https://lists.berlios.de/mailman/listinfo/openrecord-dev

> I raised the issue on the dojo-contributors mailing
list yesterday, 
> and called for a vote:
> http://dojotoolkit.org/pipermail/dojo-
contributors/2006-August/003616.html

Voting has closed, and the measure passed.  The final tally
was 12 in 
favor and 0 against, out of about 38 eligible voters.

 Brian




____________________________________________________________
_______
Copyright rights relinquished. This work is in the Public
Domain.
For details see: htt
p://creativecommons.org/licenses/publicdomain/

openrecord-dev mailing list
openrecord-devlists.berlios.de
https://lists.berlios.de/mailman/listinfo/openrecord-dev