Re: [License-discuss] [Non-DoD Source] Re: [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) 0.4.0

[Engel Nyst]

On Wed, Aug 17, 2016 at 8:32 PM, Richard Fontana
 wrote:
> On Wed, Aug 17, 2016 at 06:17:07PM +, Karan, Cem F CIV USARMY RDECOM ARL 
> (US) wrote:
>>
>> Once again, liability isn't the only issue; there are also copyright issues
>> (for contributors), and IP issues.  If we could solve the problem via a 
>> simple
>> disclaimer of liability, we would.  We need to handle ALL the issues.
>
> Even if you were correct in the assertions you've made about ARL code,
> why is a new license needed for contributors other than ARL?

I'm assuming it's because they (ARL) don't have section 5 otherwise.

ARL OSL can apply to public domain works and have a clause 5 to point
to why contributors' code is under AL2.0.
While arguably unnecessary, I believe I see where they're coming from,
it's not hurting, and it's better in a document that equally gives
from USG all AL2.0-for-public-domain-works including patent grant.

Just my understanding of the needs of the OP.
___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) 0.4.0

[Engel Nyst]

On Tue, Aug 16, 2016 at 9:43 PM, Karan, Cem F CIV USARMY RDECOM ARL
(US)  wrote:
> OK, I see where you're coming from now.  I had to have the ARL Legal team
> explain this to me as well, but the ARL OSL is actually a contract, and the
> contract can apply even if there is no copyright.  We release material to our
> collaborators on a regular basis under contract; we even do this with
> software, even though it is in the public domain.  If they break the contract,
> we can sue them, but we can't sue anyone that they delivered the software to
> (it's in the public domain, so we don't have any copyright protections to sue
> over).  The ARL OSL extends this as a chain; the USG releases the software to
> anyone that wants to download it, but by downloading it, they agree to the
> contract.  That person in turn can hand off the software to another person,
> forming the chain.  However, if the chain is broken, the USG only has the
> right to sue the first person that broke the chain; the others may be able to
> claim that they got the software in good faith.  Since there is no copyright
> involved, and since they didn't break the contract, they are innocent; only
> the person that broke the chain originally is liable (note that I'm not a
> lawyer, and may have gotten some of this wrong; it's just my understanding
> from the ARL Legal team).  This means that to sue, the USG will need to prove
> that the person was the first one in the chain to break the contract.
>
> Copyright is something entirely different from contract law.  Copyright is a
> bundle of rights that an author gets by creating a work.  The license allows a
> user to use the work without getting sued/stopped/etc.  The trick is that
> since copyright attaches to a work AND since you can't
> copy/use/display/perform/etc. a work without permission from the copyright
> holders, you have to be able to point to the license that allows you to use
> the work without being sued.  That means that a copyright holder doesn't need
> to follow a chain, it just needs to demonstrate that it has copyright on the
> work, and that its license is being violated.
>
> The closest analogy I can provide is that contract law is innocent until
> proven guilty, while copyright is guilty until proven innocent.

I understand the intention, and I know it seems tempting to work via contract,
but here's the problem:

https://www.law.cornell.edu/uscode/text/17/301

"On and after January 1, 1978, all legal or equitable rights that are
equivalent to any of
the exclusive rights within the general scope of copyright as
specified by section 106 in
works of authorship that are fixed in a tangible medium of expression
and come within
the subject matter of copyright as specified by sections 102 and 103,
whether created
before or after that date and whether published or unpublished, are
governed exclusively
by this title. Thereafter, no person is entitled to any such right or
equivalent right in any
such work under the common law or statutes of any State."

Some claims of breaches of contract will fall squarely into what this
paragraph says: they
would claim the same thing as the rights under copyright.

In other words: if A tries to make a contract with B, where A says
"you can't reproduce this
work", that obligation lives or dies via copyright alone. (if nothing
else is involved)

From what you say, you intend here exactly that: to recreate the
rights to reproduce,
distribute, or make derivative works, or to put obligations as if you
had them, through
contract. It seems to me that copyright law already says USG can't do that.

You can do a lot of contracts, to be sure; just not those who simulate
copyright.

Caselaw on this exact topic seems a mess. I don't know what would come of this;
without getting into it, here's my suggestion, considering all I
understand from your
intentions:

The interesting thing with your intended license/contract is that
preemption doesn't
matter for malevolent contributors: you can STILL make it so that
contributors will provide
their (presumably copyrightable) work under it, in your projects.
Because only clauses
2 and 4 would be affected by preemption, redrafting the
license/contract so that the rest
stands in all cases should give you the same effect (or close).

Apache license is almost unique in the following respect: there are 2
explicit directions in
which it works.

Direction (1) - from USG/others to the world.

Here you have the problem that if you start without copyright, and the
license tries to usurp
the domain of copyright rights, that can make it all fail. You said it
yourself: the concern is
that it depends on copyright, and thus may all be deemed invalid.
Indeed, I'm just
saying that recreating copyright-like rights via contract where title
17 clearly denied them,
can also be deemed invalid.

Direction (2) - from a "contributor" to USG and the world, via
"intentional submission for
inclusion in the Work" (clause 5).

Re: [License-discuss] [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) 0.4.0

[Engel Nyst]

On Tue, Aug 16, 2016 at 5:12 PM, Karan, Cem F CIV USARMY RDECOM ARL
(US)  wrote:
> OK, but wouldn't those changes mean that the license no longer applies to the
> uncopyrightable portions?  That would mean that downstream users would no
> longer have any protection from being sued, etc., right?

The obligations (a)-(d) would not apply to the uncopyrightable
portions. That's not the whole license/contract, only those particular
obligations that try to put "restrictions" on the rights to reproduce,
prepare derivative works, and distribute them.

For example, (a) says "[you can reproduce this work], provided that
... you give other recipients a copy of this license". In other words,
"you can't reproduce this work if you don't add a copy of this
license". This obligation doesn't apply to a public domain work, I can
reproduce it without.

But I'm not sure what you're worried about, sue for what? These
(a)-(d) obligations have nothing to do with suing users, do they? ARL
OSL has all the other clauses, which apply fine regardless of whether
the underlying Work is copyrighted or not, like disclaimers of
liability and clause 5.


-- 
~ "We like to think of our forums as a Free-Speech Zone. And freedom
works best at the point of a bayonet." (Amazon, Inc.)
___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) 0.4.0

[Engel Nyst]

On Mon, Aug 15, 2016 at 11:59 PM, Karan, Cem F CIV USARMY RDECOM ARL
(US)  wrote:
>> >4. Redistribution. You may reproduce and distribute copies of the
>> >   Work or Derivative Works thereof in any medium, with or without
>> >   modifications, and in Source or Object form, provided that You
>> >   meet the following conditions:
>>
>> I'd suggest to add in clause 4, or in its obligations a)-d), an "if
>> copyright exists" or something similar. If copyright doesn't exist in the
>> Work,
>> can't put enforceable conditions on redistributions.
>
> What wording would you suggest?

"4. Redistribution. You may reproduce and distribute copies of the
  Work or Derivative Works thereof in any medium, with or without
  modifications, and in Source or Object form, provided that for
  Works subject to copyright You meet the following conditions:"
Or,
"4. Redistribution. You may reproduce and distribute copies of the
  Work or Derivative Works thereof in any medium, with or without
  modifications, and in Source or Object form, provided that You
  meet the following conditions for the copyrightable parts of the
  Work or Derivative Works:"
Or,
"4. Redistribution. You may reproduce and distribute copies of the
  Work or Derivative Works thereof in any medium, with or without
  modifications, and in Source or Object form, provided that You
  meet the following conditions:

  (a) You must give any other recipients of the Work or
  Derivative Works a copy of this License, except when the Work
  or Derivative Work is not subject to copyright; and

  (b) You must cause any modified files to carry prominent notices
  stating that You changed the files, excluding those files that
  contained no copyrightable part; and"

In the latter, (c) and (d) seem to already have applicable exclusions.

The first seems cleanest to me.
___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] U.S. Army Research Laboratory Open Source License (ARL OSL) 0.4.0

[Engel Nyst]

On Thu, Jul 28, 2016 at 3:50 PM, Karan, Cem F CIV USARMY RDECOM ARL
(US)  wrote:
>   "License" shall mean the terms and conditions for use, reproduction,
>   and distribution as defined by Sections 1 through 9 of this document.

You may want to update the sections count, they're 10 now.

>4. Redistribution. You may reproduce and distribute copies of the
>   Work or Derivative Works thereof in any medium, with or without
>   modifications, and in Source or Object form, provided that You
>   meet the following conditions:

I'd suggest to add in clause 4, or in its obligations a)-d), an "if
copyright exists" or something similar. If copyright doesn't exist in
the Work, can't put enforceable conditions on redistributions.

Just wondering: you said that Apache License 2.0 doesn't have a
severability clause, and it would have helped your wishes. However you
didn't add one. Why not?

-- 
~ "We like to think of our forums as a Free-Speech Zone. And freedom
works best at the point of a bayonet." (Amazon, Inc.)
___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] open source licenses addressing malicious derivatives

[Engel Nyst]

On Wed, Jun 22, 2016 at 10:40 PM, Christopher Sean Morrison
 wrote:
>
> For #1, I know CDDL has a required notice of authorship of modifications but
> didn’t see anything else at least amongst the popular licenses.

Same for MPL 1.1, but it was removed in MPL 2.0. Somehow similar
clause is in AL 2.0, 4b), though not as broad.
___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Reverse Engineering and Open Source Licenses

[Engel Nyst]

Hello,

One may wonder what is the big deal with this single phrase in LGPL. It
basically states something fairly similar with EU software directive:

http://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32009L0024

Please see art. 6, Decompilation:

 The authorisation of the rightholder shall not be required where
 reproduction of the code and translation of its form within the
 meaning of points (a) and (b) of Article 4(1) are indispensable to
 obtain the information necessary to achieve the interoperability of
 an independently created computer program with other programs, [...]

This decompilation provision is very narrow, but it says in plain
English that there are cases when the user of computer software has the
right to copy the software privately and even decompile it.

I compare with LGPL 2.1: it says that users of the other program have
the right to reproduce/decompile the other program in order to achieve
interoperability with the LGPLed library, including with an
user-modified version of that library.

 you may also combine or link a work that uses the Library with the
 Library to produce a work containing portions of the Library, and
 distribute that work under terms of your choice, provided that the
 terms permit modification of the work for the customer's own use and
 reverse engineering for debugging such modifications.

This is a similar scope with Article 6 (though not identical; nor can
it, since it talks about works based on the work while EU directive
about any interoperability).

The recipient has a right to take actions that fall under reverse
engineering (copying, testing, decompiling the whole thing) for
interoperability. Integration between the library and the other work is
an example of precisely interoperability between the two.

LGPL2.1 provision is very narrow too, for customer's own use and for
debugging why the modified library doesn't work as expected. Not more.


In other words, LGPL2.1 *shouldn't need* to say its little phrase today,
or apparently surprise corporate lawyers/speakers at all, because this
is supposed to be law already in EU: the legal protection of software
contains users' right to decompile under specific narrow circumstances,
no matter what the proprietary license agreement claims.

Since 1991 at least. (The directive precursor of the current one was
from 1991; for comparison, LGPL-2.0 seems to be from 1991 as well [1],
and LGPL-2.1 from 1999.)

Is there some law in Germany, which is contrary to this right?

 As long as we do not have a legal decision

Commentators say that SAS v. World Programming is a pertinent legal
decision, for example:

http://www.bloomberg.com/news/articles/2012-05-02/copyright-can-t-block-software-reverse-engineering-court

(These are EU examples. In US, things are framed a bit differently, i.e.
the right to reverse engineering with the purpose to discover
uncopyrightable elements necessary for interoperability with other
software is under fair use, with circuit-dependent and case-dependent
interpretation.)


[1] https://www.gnu.org/licenses/old-licenses/lgpl-2.0.html

-- 
Oracle corollary to Hanlon's razor:
Never attribute to stupidity what can be adequately explained by malice.
(~ adapted from Adam Borowski)
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] FAQ entry on CLAs

[Engel Nyst]

On 01/18/2015 02:57 PM, Radcliffe, Mark wrote:
 As Allison noted, most OSI approved licenses can be used for inbound
 use, but we do not take a position on that issue in approving
 licenses. [..] Thus, the approval of a license by OSI as meeting the
 criteria of the OSD does not reflect a review of the use of the
 license as inbound but only outbound.

This is deeply concerning. Is OSI's position out of the sudden that it
has approved some licenses which haven't been checked for compliance
with #5, #6 and #7 for any person or entity receiving code?

OSD contains exceptions, entities which the license might prohibit from
incorporating or distributing code under that allegedly open license?

That's plain illogical. It's like, when a developer licenses their work
under an open license, the license wasn't reviewed for conformance
with OSD, thus it might not grant the permissions to anyone receiving
the software. But when you're a mere *LICENSEE* [with CLA] of that
developer, then suddenly your purported license was reviewed for OSD
conformance.
(or if you're accumulating copyright, then your license somehow becomes
reviewed)

That doesn't make any sense. How is the open source license not good?
How doesn't it give permissions set out in OSD? And WHY was it approved
if it doesn't comply?

I don't see in OSD #3 that the license may prohibit modifications and
derivative works or distributing them under the same license, if you're
for example Random J. Developer, writing and licensing your patch, and
not a copyright accumulator of a kind or another.

I don't know how is this under doubt. If, by licensing their code under
an OSI-approved license, developers aren't giving permissions to any
entity, then software developed without CLAs is under doubt. I guess
the next thing is to see how long will OSI continue to use open source
software developed without CLAs. Because, while OSI might think it has
received open source software, if the project you got it from has an
OSI-approved license from copyright holders, it wouldn't matter: the
license itself *may not have given permission* to distribute in the
first place.

It might have been, who knows, one of those 'some' unspecified
OSI-approved licenses that you suggest wouldn't work inbound=outbound.

 Different communities have different approaches

Wanting more licenses is not, and cannot be, about *uncertainty* whether
a license meets the OSD.

Different entities have different reasons for wanting *additional*
stuff. They might WANT to give another license to some or all, now or in
the future, open source or proprietary. Therefore they *choose* to ask
for another license. Or they might have policies for committers to
repositories they host, therefore they might have an agreement for that.
Or they might OFFER to enforce the license in a court of law for more or
all copyrightable material in a work.

Or they might want another license, and instead of being upfront about
it, they attempt to place open source licensing under fear, uncertainty
and doubt.

But that Open Source Definition page out there sets the criteria
according to which the license must conform, for any copyright holders
to grant permissions to any entity receiving code under that license.

Since when is OSI going back on that, and claims now that some
entities might not receive these permissions for some OSI-approved
licenses?

 the Apache Software Foundation uses specific CLAs for its projects

Does ASF use CLAs /because/ AL2.0 is uncertain, it hasn't been checked
whether it gives them the rights to reuse, modify, distribute the code
they'd receive under it, under the conditions of AL2.0?

 FSF has long used an assignment approach

Indeed, for some projects, and for some not. FSF's practice has (like
ASF's) confused people, and both were (ab)used to further confusion.

Regardless, does it follow from here that GPL might not be safe to use
inbound, it might not give the permissions to copy, modify and further
distribute derivative works of the code when an entity is receiving it
under GPL?

This is a non-sequitur, and shocking that OSI thinks it's okay to
popularize it.

(random signature...)

-- 
  Excuse me, Professor Lessig, may I ask you to sign this CLA, so we can
*legally* have your permission to remix and distribute your CC-licensed
works?
  ~ Permission culture, take two.
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] FAQ entry on CLAs

[Engel Nyst]

On 01/20/2015 03:24 PM, Ben Tilly wrote:
 A project using http://opensource.org/licenses/BSD-3-Clause has
 marketing comparing it to Foo's project Bar.  But no prior written
 permission from Foo was obtained for this.  If Foo looks at the
 project, notices a bug, and submits a patch under the same license,
 the project can't apply that patch without violating the license.

I'm not sure I understand correctly. Isn't that intended behavior of the
license? (assuming there was claim of endorsement)

If I reuse code under BSD license, then I have to comply with the license.

(That Foo submitted a patch or I take it myself doesn't seem to make a
difference either.)


-- 
Oracle corollary to Hanlon's razor:
Never attribute to stupidity what can be adequately explained by malice.
(~ adapted from Adam Borowski)
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] FAQ entry on CLAs

[Engel Nyst]

On 01/20/2015 12:50 PM, Allison Randal wrote:
 I wrote up an example of an open source license that has different
 legal effects when used inbound and outbound, but I've deleted it to
  avoid taking this thread down a rabbit hole.

Please do, though. It's worse to practically state that using an OSI
approved license(s) doesn't seem to give the permissions necessary,
within the bounds of the license, for anyone to combine one's project
from different sources and distribute it.

 The key point is that inbound=outbound is a contribution policy, a
 specific use of an open source license within a particular context.
 OSI reviews the text of licenses, it doesn't review contribution
 policies.

The issue here is simply that inbound=outbound must hold, because it's
not a random contribution policy. OSD compliance is why it holds.

-- 
Public works must serve a community. Open source licensing ensures the
Tools are accessible to the world. We have not found any authority for
the proposition that the world is a community within the meaning of
501(c)(3).
  (~US IRS)
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] FAQ entry on CLAs

[Engel Nyst]

On 01/17/2015 01:57 PM, Allison Randal wrote:
 OSI's criteria for open source licenses doesn't include any review of
 whether the *license used inbound* would be respectful of developers'
 rights and desires for the use of their code, encourage healthy
 collaboration in the community of developers, allow for ongoing
 maintenance of an established codebase by an ever-changing group of
 developers, empower groups who want to do active GPL enforcement,
 etc, etc.
[my emphasis]

I see your point. I agree these issues are not part of a review for OSD
compliance.

The relevant aspect here, seems to me, is that OSI's criteria for open
source licenses *include* whether the *license used inbound* is giving
rights to anyone receiving the software, as set out in the OSD.

Anyone includes the project, a legal entity behind the project, the
interest groups around a project, just like it includes individual
users, recipients of the software from the original developer or
project, etc.

OSI criteria do this by OSD #5, #6 and #7.

 A single legal document is perfectly adequate to cover both
 contribution and receiving, and I expect any license OSI has approved
 would be fine used inbound=outbound. But when OSI approves a license
 it is only making a statement that the license meets the outbound
 criteria of the OSD.

 From the above, it follows that when OSI approves a license, it is
making a statement that the license meets the criteria of the OSD,
*whether used inbound or outbound*.

(Therefore, I don't guess it would be fine used inbound=outbound. It is
fine. It *has* to be. Solely from the perspective of the rights set out
in OSD, that is.)


-- 
~ We like to think of our forums as a Free-Speech Zone. And freedom
works best at the point of a bayonet. (Amazon, Inc.)
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] FAQ entry on CLAs

[Engel Nyst]

On 01/16/2015 08:02 PM, Allison Randal wrote:
 The text is out-of-date, and wrong in some places.

 OSI is in the process of a refresh on the whole site, updating or
 removing a lot of old cruft, and this will get swept as part of it.

That's good to hear, thank you.

 If OSI wants to discuss or inform the larger community about CLAs,
 this doesn't seem accurate language for doing so.

 I'm not convinced that OSI needs to explain contributor agreements.
 We do periodically get asked to review contributor agreements, so
 it's important to have some kind of statement making it clear that
 OSI reviews *outbound* open source licenses, and not *inbound*
 agreements. It also doesn't review the use of open source licenses
 as inbound=outbound.

Reviewing doesn't seem to have anything to do with it indeed, but other
than that I'm not sure I understand the difference you feel important
here. An open source license is inbound or outbound depending only
on the position /of the speaker/. There is no absolute direction, it's
relative to the speaker.

Am I looking at some code I wrote, or am I looking at code someone else
wrote. Why is that relevant?

There is probably no way to make a statement like this without taking a
position, and the above does that. It's saying that inbound agreements
are something else than open licenses, fulfill an unspecified need that
open licenses don't. That open licenses are meant to be outbound (to
whom?). That alone contributes to confusion about open source licensing.

One cannot say that open licenses are meant to be outbound without
implying that when you receive them (so inbound from your perspective)
you may need something else. It's synonym with: they weren't meant to be
received, they were only meant to be sent (?). They, well, might
also work when you're at the receiving end, but weren't written for it.

 It also doesn't review the use of open source licenses as
 inbound=outbound.

I honestly don't see how OSI can do otherwise than make a clear
statement that the OSD guarantees all rights one needs to *receive* to
be able to further copy, distribute, modify, include or make derivative
works of, under the conditions of the respective open source license.

Endorsing the distinction between inbound and outbound as if it was
objectively meaningful, and placing open licenses on the outbound side
is, in the best case, like saying: OSI reviews licenses to guarantee
developers that they give the necessary rights to anyone, but it doesn't
review if, as far as the license is concerned, you receive these
rights. That doesn't make any sense to me.


-- 
  Excuse me, Professor Lessig, may I ask you to sign this CLA, so we can
*legally* have your permission to remix and distribute your CC-licensed
works?
  ~ Permission culture, take two.
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] 3-clause BSD and reverse engineering

[Engel Nyst]

On 01/16/2015 07:44 AM, Zluty Sysel wrote:
 Reverse engineering, decompilation, and/or disassembly of software
 provided in binary form under this license is prohibited.

I'm wondering why you want this clause. Is the software in source form
available under BSD or do you intend to make it available under this
license? What purpose would this clause for the binary version solve?


-- 
Public works must serve a community. Open source licensing ensures the
Tools are accessible to the world. We have not found any authority for
the proposition that the world is a community within the meaning of
501(c)(3).
   (~US IRS)
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] FAQ entry on CLAs

[Engel Nyst]

On 01/17/2015 03:00 PM, John Cowan wrote:
 Engel Nyst scripsit:

 There is probably no way to make a statement like this without
 taking a position, and the above does that. It's saying that
 inbound agreements are something else than open licenses,
 fulfill an unspecified need that open licenses don't. That open
 licenses are meant to be outbound (to whom?). That alone
 contributes to confusion about open source licensing.

 While I agree with what you are saying (there is no reason why any
 open source license can't be used as a contributor agreement, and
 some projects actually work that way), there is a fundamental
 difference between the FSF's CLA and the GPL, namely that the CLA is
 not a *public* license. Open source licenses grant things to
 whomever has the source code; a CLA normally grants things (anything
 up to full copyright ownership) only to the party they are addressed
 to.

 We could say that implicit requirement 0 of the OSD is that the
 object of discussion is a public software license.

I would set CAAs a bit aside for the discussion, because they're not
licenses at all. CLAs are licenses.

I agree with this remark. But doesn't it mean, in other words, that a
CLA is a *proprietary* license? It doesn't grant rights to anyone
getting the software, it excludes everyone except a named entity.


-- 
~ We like to think of our forums as a Free-Speech Zone. And freedom
works best at the point of a bayonet. (Amazon, Inc.)
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

[License-discuss] FAQ entry on CLAs

[Engel Nyst]

Hello license-discuss,

OSI FAQ page has an entry on CLAs: What are contributor license
agreements? Are they the same thing with open licenses?.

As a historical note, according to webarchive, the entry has appeared in
June-July 2013, although there is no mention on it on (public) mailing
lists at the time.

The answer to this question contains both expected things, and
unexpected things. Just some quick notes on the answer as written.

It says many open source projects use these agreements. I have to
dispute the implied suggestion that there are more than not.

 Contributor agreements are not open source licenses -- rather, they
 are a way for the contributor to tell the project that it has the
 right to distribute the new contributions under the project's
 existing open source license.

But an open source license does this: by licensing their modifications
under the license of the project, developers tell the project that it
has the right to distribute those modifications under the project's
existing open source license.
The implication here is that there is a necessity of some kind for a
contributor to tell the project through a CLA that it has the right to
distribute under the existing open source license. A necessity that the
open license doesn't fulfill. That is a very unfortunate implication,
and I suggest OSI to remove such language from its official pages.

It continues with
 (Some contributor agreements also allow for the project to
 distribute the contributions under other open source licenses
 too[...]).

This explicative parenthesis seems to imply that most agreements are
inbound-outbound, which is probably not the case with CLAs. (unless here
it was meant DCOs, but that acronym isn't present)

 In a Contributor License Agreement (CLA), the original contributor
 retains copyright ownership of their contributions, but grants the
 project a broad set of rights such that the project can incorporate
 and distribute the contributions as it needs to.

It's unclear to me what is meant by this. Does this mean that the entity
behind the project /wants/ to license under other licenses than the open
source license of the project, or does it suggest that the project
/needs/ CLAs to do its incorporation and distribution of code under the
open source license it has? The ambiguity has the effect of implying the
second and obscuring the first.

 With both CLAs and CAAs, it is of course necessary that 'the
 project' be some kind of legal entity able to enter into
 agreements.

This sounds right, but incomplete. While a loose association might not
be appropriate, an individual can be.

 a for-profit corporation [...] requests contributor agreements in
 order to manage the development community

I don't know what this means. Is it trying to say a for-profit corp
needs to know the identities of developers, or that community
management gets mysteriously easier to do when you have more copyright
rights?

Also, the text links to
http://wiki.civiccommons.org/Contributor_Agreements, which no longer exists.


I'd like to open a discussion about fixing this text.

If OSI wants to discuss or inform the larger community about CLAs, this
doesn't seem accurate language for doing so.

Overall, the text strikes me as false neutrality. It posits CLAs as
something many do, apparently naturally occurring, it contains
implications that they somehow fulfill a need of a project to be able to
incorporate and distribute code under the open license it has (!), it
links only to (inactive) project Harmony and a dead link, it doesn't
contain any warnings about asymmetry and pitfalls associated with them,
it doesn't contain analysis and opposing arguments.

Thank you for sharing your thoughts.

-- 
Oracle corollary to Hanlon's razor:
Never attribute to stupidity what can be adequately explained by malice.
(~ adapted from Adam Borowski)
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Better MIT License ?

[Engel Nyst]

On 06/29/2014 07:39 AM, Joe Kua wrote:


Is this better than the original MIT license ? It has patent grants
which MIT lacks.



At a cursory reading, it looks like I'd expect a first draft of MIT with 
patents to be like. Please note: IANAL, TINLA, not affiliated with OSI.


An issue with simply adding patents in a license like this is that they 
have a different mechanism than copyright. I don't claim I understand 
software patents (they make little sense), only, I will submit to your 
attention a detail: their different coverage. (which doesn't follow 
copyright)


If I take a look at Mozilla Public License 2.0 [1] and Apache License 
2.0 [2], the patents being licensed have a scope delimited to: those 
necessarily infringed by the licensor's own code, or by the combination 
of the licensor's code with the rest of the work as it was when they add 
their code. Not less (not only the code you fully write yourself), not 
more (not the patents you may hold, which will be implemented by some 
fork or future development you don't - you can't - know about today).


If I take a look at a license in development, a rewrite of CC0 with 
patents [3], I find a similar treatment with your new MIT license: it 
includes a patent grant for the Work/Software.


Lets say I register patents P1, P2, P3. I contribute to a work under 
your New-MIT, a piece of code where I implement P1, and another patch 
that finishes an existing set of algorithms implementing P2. Which 
patents have I licensed by my actions?

I think it's clear I have licensed P1, and I haven't licensed P3.
I'm not so sure about P2. I think one can argue I didn't necessarily 
license P2.


If I do the same for a project under MPL 2.0 or Apache 2.0, then by my 
actions I license P1 and P2. Non-ambiguously P2 too.



Is the result above for New-MIT your desired result? Do you agree this 
is the result of the license(s)?



[1] https://www.mozilla.org/MPL/2.0/
[2] https://www.apache.org/licenses/LICENSE-2.0.html
[3] https://github.com/asaunders/public-domain-customized


--
Excuse me, Professor Lessig, may I ask you to sign this CLA, so we can 
*legally* have your permission to distribute your CC-licensed works?

___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] For Approval: Scripting Free Software License, Version 1.3.7.2 (S-FSL v1.3.7.2)

[Engel Nyst]

Elmar,

Your new version continues to ignore obvious issues raised on this
mailing list, with direct impact on its OSD compliance. Frankly, it
comes across as rude too.
I will take a little more time to pass roughly again through it, but I
doubt I'll do anything more, and please see suggestions below.

On 12/01/2013 10:24 PM, Elmar Stellnberger wrote:

No patches that could be shipped use to exist for automatic
derivation processes like f.i. the compilation of sources.

Unclear, and grammatically incorrect.


By applying automatic derivations you consent that you will provide
all makefiles or any other additional input which is required for the
derivation process to the original authors under the same licensing
and same terms as patches.

I seem to recognize here GPL's all the source code needed to generate,
install, and (for an executable work) run the object code and to modify
the work, including scripts to control those activities. However, it's
very unclear, derivation process is undefined, the requirement is to
the original authors but the same licensing is S-FSL which is
somewhat contradictory. I suggest fully rewriting this or just use GPL.


We suggest you to ship binaries and sources in different packages.

Not a licensing term. I suggest to drop this.


3. Modifications applied to this program may not affect the name,
original version, copyright, license or any reference given to the
authors such as their email addresses or their web presence and/or
page in any part of the program or any files attached to the program
apart from updates to these references made by the respective authors
themselves.

This can be read as simply attribution, or as badgeware. If your goal
here is that derivatives must display, in their UI, YOUR logos and
names, then it fails OSD #3 indirectly, because it attempts to stifle
competition.
I suggest rewriting with standard (known) wording for attribution, or
use a license that offers it already.


You as a distributor need to let your contributors add their names,
their email and modifications with date to the changelog. You may use
the upstream changelog if present or your own one as long as it stays
accessible upstreams.

This is mostly useless. Many open source projects don't use a manual
changelog, but that's because the log of the vcs shows all names and
contributions with a simple command. It's simple and less prone to
misses and human errors.


Any derived work must carry the name of the distributor, vendor or
the product in its name (or a unique shorthand for it) directly
preceded by the original unchanged final upstream name of the
software and its version at the beginning.


This is very unclear. Derived work is undefined, and this naming rule
is in contradiction with section 6. I can guess what you're actually
trying to achieve, but it's a very poor idea to include such development
policy in a license. The result is unreadable and contradictory at best,
and probably rejectable by the target Linux distributions to which your
license dictates how to name packages.


For automatic derivations a tag concerning the derivation process or
 its output like f.i. the machine architecture would be appropriate.

See above. I think Linux distributions know how to do their packaging.


You must not charge for the programs under S-FSL themselves but you
may require a reasonable charge for the physical reproduction of the
 data.

This probably fails OSD #1.

If you read carefully Artistic license (even 1.0), you'll see that it
explicitly adds that fees for support, fees for aggregate distributions,
and others, are allowed. Even so, Artistic 1.0 barely passes this
criterion (IMHO). But any less doesn't pass.


As far as you are not a public distributor you are obliged to send a
 copy of your patches to the original authors referred to herein as
the authors of the first version of the program as being listed in
the changelog or program header whenever you publish or exchange your
patches with other people. If you have some work in progress you are
obliged to send out bundled patches once at least every month.

This fails OSD. See previous emails as to why. I suggest to give it up.
People contribute if they want to, not because they're forced by a
license. Your only results here will be a) people won't bother with your
projects at all; b) the license is NOT Open Source.


This is to assert the availability and recognition of patches at
least by the original authors or branch maintainers; a condition
which must be held even if you agree not to actively 'send' or
'forward' your patches.

'Send' and 'forward' undefined and unclear.


For bundled patches you do not need to ship intermediate patches or
dead end patches provided that the final derived work can be restored
by applying all distributed patches to the original in an order
indicated by the patch providers. Something is considered a dead end
patch if it leads to a broken program, the result is not usable and
you do not 

Re: [License-discuss] dual licensing and the Open Source Definition

[Engel Nyst]

On 12/17/2013 09:34 PM, zgil...@culturestrings.org wrote:

On 12/14/2013 02:21 PM, Engel Nyst wrote:

It's quite common place today; I say weird not because it's
uncommon (it's not) but for several other reasons, among which one
 similar to yours if I understand you correctly: this particular
dual licensing doesn't seem to serve the goals intended by the
license (not by OSI). Whether you consider these goals focused to
assure software freedom/openness or to promote alternative business
models.



Indeed, the purpose of my question was to find out whether a single
license could guarantee that the source remains available in all
scenarios, and also ensure that using the library would be free for
all end-users, yet entail a (one-time) charge for vendors of
commercial/proprietary software. I think there are several advantages
(both practical and technical) to using a single license over
multiple licenses, but at the same time consider such advantages to
be secondary to offering at least one license that is OSI-approved.



Please note, this is not what I said. I don't support trying to use GPL
with proprietary licenses for particular uses, one-time or not.
Businesses could and should be built without relying on (additional or
not) licenses that go back to copyright restrictions.

If one's goal is to make money by something else than donations (as you
were writing), my suggestion would be to look into ways that aren't
donations, nor relying on copyright restrictions. I gave a couple of
quick examples.


Thank you for making so many excellent points.  The model based on a
transitive grace period is very interesting, even though it still
requires dual-licensing for full compatibility with other open
source projects and libraries.  One way or the other, then, it might
have to be a dual-licensing model that offers the GPL in conjunction
with the license of choice...



I'd make two more notes here. First, the two dual licensing real-world
facts, the model you were initially referring to, and the dual licensing
in the example of transitive grace period, are, IMO, entirely unrelated,
as far as reasons/intents of dual-licensing are concerned.

The transitive grace period license seems (to me) a viable licensing
framework for who wants to make software proprietary for a while (12
months, for the first licensee/second licensor). It seemed relevant to
your intent to ask for a fee via copyright. However, this license, as
opposed to proprietary (licensing fee for business use), is *not*
proprietary itself, or not in my reading.

Concerning its OSI approval, you may find a lot of discussion on it
(example [1]) in the archives of this mailing list. IIRC, there have
been a lot more concerns on proliferation, practicality and
understandability on how the license works, than problems on OSD
compliance. Please check them out if you wish, though. I haven't re-read
some emails on TGPPL possibly for years, my memory may be faulty.

Dual-licensing with GPL is here for compatibility with GPL. I'd add that
there are other open source copyleft projects (and licenses) that
dual license or allow relicensing to GPL, to ensure compatibility. Most
permissive licenses/projects don't need it, but copyleft
licenses/projects need it if they want this compatibility. That happens
because GPL scope is maximum, and copyleft is usually defined as
licensed under the same license (so there's a conflict between such
copylefts).


A second note I'd make: whether this particular licensing attempt is
interesting to you or not, please note a distinctive feature it has,
opposed to dual licensing models for business: all paths result
eventually in open source software available, and with all source,
including for downstreams. Maybe in 12 months (if the licensee chooses
TGPPL and the grace period), maybe immediately.


[1] http://ur1.ca/g7w2v

--

~ Excuse me, Professor Lessig, but may I ask you to sign this CLA, so 
that we have legally your permission to distribute your CC-licensed words?

___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] dual licensing and the Open Source Definition

[Engel Nyst]

Hello,

On 12/12/2013 11:46 PM, zgil...@culturestrings.org wrote:

As per the Open Source Definition, commercial use of Open Source
software must be permitted, yet the license shall not require a
royalty or other fee for such sale.

One interesting side-effect of the above is that software can be
released under a strong copyleft license, for instance the GPL, and
yet be accompanied by the option to buy one's way out of the
license, thereby releasing the buyer from any and all obligation to
make the modified source available to the public.


I'm not sure there's causality between the two. Commercial use must be
permitted (not denied, as in non-commercial use), and, there are other
business models than those based on copyright restrictions (fee per copy).

Commercial services around the software, customizations at user's place,
are a few other possibilities. They are alternatives to 
fee-per-copy-otherwise-restricted traditional models.

This is a major point, in my opinion, that should be understood.

However, indeed this isn't happening in the scenarios you're referring
to: proprietary-GPL dual licensing or open core business models are a
weird case that has emerged in practice. It's quite common place today;
I say weird not because it's uncommon (it's not) but for several other
reasons, among which one similar to yours if I understand you correctly:
this particular dual licensing doesn't seem to serve the goals intended
by the license (not by OSI). Whether you consider these goals focused to
assure software freedom/openness or to promote alternative business models.


1) to what extent does the GPL meet the OSI promise regarding the
source of Open Source Software remaining open? After all, if vendors
can take GPL'ed software and buy their way out of the license so that
binaries, with or without changes, can be distributed without
restriction and without a corresponding source, then something is
probably not working the way it was originally intended.


It's an interesting perspective you seem to have, that GPL may be at
fault on this point. I'm not sure I disagree, depends what exactly you 
mean and where you're looking for improvements; but again, it has 
nothing to do (AFAICT) with OSD/OSI. Rather, I can see why among all 
licenses, GPL and AGPL are favorites in this game.


Copyright system is such that a license like GPL, which requires a
strong leveling of the playing field for contributors (nobody can use
copyright to restrict works/derivatives), is exposed /more/ in a sense
to copyright privilege when a single owner adds up for themselves
separate rights from all contributors. When one can what no one else can
(as opposed here to permissive licenses, where everyone can restrict
derivatives), that one has more power.

That's a philosophical matter, though, and it doesn't mean at all that
the GPL by itself doesn't work to keep software open. GPL and many other 
licenses make the software open source.



Then again, it seems to me that the possibility to regulate one-time
charges for commercial use from _within_ a license should be much
preferred over a de facto option to bypass the license altogether.


See above on business models. (and please see below for another option)

On 12/13/2013 10:02 PM, zgil...@culturestrings.org wrote:

The framework in which I am interested would allow a distinction
between derivative work in general, and changes to a specific library
in particular.  In other words, I'm looking for a license that would
guarantee source availability of all patches that were applied to an
open source library, but not necessarily of the code that uses the
interfaces which that library exports.


This goal (and only it) sounds like you may want to take a look at MPL
or LGPL. With MPL it's simple, files that contain code of the original 
work are covered by copyleft. Outside files (even within a fork of

the library/framework, though, note), are not bound to any condition.
Depending how you interpret derivative works (in copyright law, and add
the intention of LGPL licensors), LGPL copyleft seems to cover the
library/framework, but not the software using its API. The actual scope
is disputed though.
Also, there are others with approximately this scope.

On 12/13/2013 09:46 PM, zgil...@culturestrings.org wrote:

Here, too, my issue is with the idea that an effective open source
license needs to be upgraded in order for software to become
profitable for its copyright holder, or convenient for the vendors
of commercial software that would like to use it. I am also not sure
that a license that allows the modified source of a library to no
longer be available is an upgrade to begin with, but that is of
course subject to interpretation.



I sympathize with the sentiment. In any case, I don't think another 
license that is proprietary is an improvement.



2) Consider the case of an individual entrepreneur who created a
software library, and who would like to require vendors of
commercial 

[License-discuss] History of approved and not approved licenses

[Engel Nyst]

Hello license-discuss,

Last week there was a need for a history of rejected licenses. That 
relates (to me) with Luis' previous calls for data on the approved licenses.


I'm interested in open licensing, and I want to have a better and more 
systematic view for myself on the licenses attempted in the past, and on 
the issues brought out by people on these mailing lists, so I took this 
opportunity to work on it.


I added in the OSI wiki data that may be of interest. The focus of this 
work is on links to existing content from public archives, that is, to 
data as it is publicly available, keeping low the level of information 
drawn from this data.


Please take a look at the new pages and sections.

*Not approved licenses list*:
http://wiki.opensource.org/archived_not_approved_licenses

Please note that these are not rejected licenses. The list includes 
almost any licenses (I read) that haven't been approved, but submitted 
and/or discussed on license-review and/or license-discuss before that.


Withdrawn, sent back for some reason, submitted and apparently missed, 
or not submitted at all (only asked about).


Some licenses have short notes. These are sketches, with or without a 
summary on the license text. Example of such summary: based on MIT 
template with added Sleepycat copyleft condition.


These notes were intended as minimal descriptive-only notes (no 
judgments), contained and undisputed in the discussions linked to. In 
the measure possible, that is, and as work-in-progress. The reader would 
[have to] check the link(s) to the discussion(s) for anything substantial.

Please, take a look and review them as you see fit.

There are no summaries of the discussion threads, and no official 
positions. I was thinking these can be added/replaced at a second pass, 
from the license committee reports for example? I didn't do that, though.



*Approved and superseded*:
http://wiki.opensource.org/license_comment_sweep

Added approval threads.
Added section for superseded licenses, intended for issues solved in 
next revisions in particular.
Added section with several pre-2005 license committee reports (I don't 
seem to find pre-2005 board minutes on the site).
Added a few questions to Luis Has Not Yet Reviewed section (with 
apologies to Luis! it was a temporary place for lack of a better idea, 
those should probably be deleted now...)



*OSD resources*:
http://wiki.opensource.org/osd_interpretation

These are links to discussion threads, split in two sections.

First section are links to OSD direct questions/proposals. I added links 
to public emails that start a new thread targeting directly the subject 
(i.e. Why this or that in the OSD?). I did not try to manage all 
content in the archives. Instead, the data is almost only those emails 
that start a discussion about the OSD. Of course, due to the method 
there is no representative sampling in this section. They're a low 
number of links to content, common or uncommon, interesting or not, just 
the same, up to your judgment.


The second section is for commonalities between OSI-approved licenses. 
It has links to proposed criteria for classifying licenses, in view of 
gathering data/specification for license tools.



All links are to public web archives, mostly 2000-2005 and 2011-2013 I 
believe, with some lower coverage for 2006-2009 at most... if I remember 
correctly. Most board minutes (license committee reports) are not 
covered, and not cross-checked.


Please, check them out and use them as you consider fit. Thoughts, 
changes, feedback, removals, tomatoes, are all welcome...



--
~enyst

Excuse me, Professor Lessig, but may I ask you to sign this CLA, so 
that we have legally your permission to publish your CC-licensed words?

  ~ Permission Culture, take two.
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] History of approved and not approved licenses

[Engel Nyst]

On 11/24/2013 09:12 PM, John Cowan wrote:

Engel Nyst scripsit:

Please note that these are not rejected licenses.


This is a very important point that should be made explicitly on the
page.  My objections to listing rejected licenses do not apply to a list
such as this, which talks about licenses that have not been approved
for a variety of reasons, of which official rejection must surely be the
rarest.



Fixed.

--
~enyst

Excuse me, Professor Lessig, but may I ask you to sign this CLA, so 
that we have legally your permission to distribute your CC-licensed words?

  ~ Permission Culture, take two.
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

[License-discuss] Issue on licenses pages

[Engel Nyst]

Hello license-discuss,

It seems that OSL 1.1, 2.0, and AFL 1.0, 1.1, 1.2, 2.1 are not 
accessible at http://opensource.org/licenses/[SPDX name]. As far as I 
know/find, they have been approved.


A number of discussions on OSI mailing lists archives reference their 
approval.


They are also not listed in superseded category.

Is the text intended to no longer be accessible?
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Beginner question on CCSA and derivative work

[Engel Nyst]

On 11/18/2013 04:24 PM, Nick Yeates wrote:

My question is, if I am incorporating it into a work that is considerable 
larger, do I need to license the entire piece of work as CCSA?
The parts from U of Oxford will be, say, 3% of the complete content (derivative 
work???). Really, most of the content is new/mine.



If it is a derivative, yes. As a CC-BY-SA licensor, I expect the 
derivative works to be available to recipients with similar rights as 
CC-BY-SA gave you. It's not a matter of size. Though, there's too little 
information to know if your work is indeed a derivative work (in CC 
parlance, an adaptation), or a collection, or other cases such as fair 
use of the material for specific purposes.


For example, works known as sequels or fan fiction don't necessarily 
contain even 1% of verbatim copied material, but they are based on the 
original work, use its characters, are set in its world, refer to its 
events. They are remixes, many consider them derivative works.


If the original work is under copyright restrictions (the default 
copyright law), then these works are infringing, and their authors at 
best tolerated. If the original work is under CC-BY-SA, then works 
building on it are free to develop. They just should keep offering the 
same rights to their readers as the original gave them: CC-BY-SA or similar.


IMHO, your best course of action is to ask the author of the work. Note 
that ShareAlike licenses allow commercial use.

___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Another crayon license

[Engel Nyst]

Hello Gregor,

The following are answers and comments on and around the license and its 
goal.


On 11/10/2013 05:53 PM, Gregor Pintar wrote:

Is relicense meaningful in law?



Relicense is not a term of art in copyright, as far I know (I trust 
someone can correct me if it is). In actions and discussions around 
copyright licensing, it's used in more relevant different ways, in 
particular it can refer to sublicensing or to the copyright holder 
granting another license.


Its lack of definition in the text can make the clause invalid, and the 
license may/will be rejected by communities that care about accurate or 
familiar licensing. The license should preferably talk about rights in 
copyright (and patents) field.


You could use sublicense, or use a paraphrase (MIT does).

It's still like what you intend, an ultra-permissive license. But it's a 
license, not a waiving of copyright of sorts.



Such an ultra-permissive license (or an equivalent existing one, there 
are others than WTFPL) is a possible approach to your goals.


Another approach is CC0, PD dedication with fallback license, and 
perhaps with patent grant.
It has been pointed out during CC0 review for OSI approval (it's 
withdrawn) that it specifically reserves patent rights. No other open 
source license gives copyright rights and explicitly reserves all patent 
rights in the same time (read: the right to demand royalties or sue for 
patents on that code). Saying nothing about patents in a license still 
allows to rely in good faith on implicit assumptions, but saying it 
reserves them is different.
I want to live in a world where no one ever has to worry and hesitate 
because of software patents, but that's not this world today. Anyway, 
there is work out there to fix CC0 adding to it a waiver of patents 
rights.[1] Personally, I'd recommend to use it.


Another approach is a permissive license with author attribution 
condition, because they're popular and expected, IMO, though I 
understand it's not what you want.



Hmm, it's less explicit, but it's still longer than zlib's.
Wouldn't to the utmost extent, any kind, any way and any issue
do the trick?



You're right, there are minimal clauses. I don't know what works better 
here. I'm not a lawyer, and I didn't research issues surrounding 
implicit warranties or their risks. As noted before, I think you're 
better off to just adopt an existing one.


 Do you think it would be better without Copyright (C) (with just
 name)?


Better, as in clearly meant to allow removal? Well, no, I don't think 
so. Some would keep the license and at least main authorship notices 
regardless. Only, since this is what you wish, let it be a choice simply 
by not including a condition to keep them.


If you want to guide interpretation as an implicit public domain 
dedication more than that, you can add text to clarify that you'd make 
it public domain if you could do it simply. But please keep the added 
text outside the license. (i.e in the name of the license, or readme of 
a project, or write an introduction clearly marked as not part of the 
license text.)



[1] https://github.com/asaunders/public-domain-customized
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

[License-discuss] FAQ suggestion

[Engel Nyst]

Hello license-discuss,

I would propose an additional paragraph to the FAQ, for the question
What is free software and is it the same as open source?

The text currently says:
 One of the tactical concerns most often cited by adopters of the term
 open source was the ambiguity of the English word free, which can
 refer either to freedom or to mere monetary price; this ambiguity was
 also given by the OSI founders as a reason to prefer the new term
 (see What Does `free' Mean, Anyway?, and similar language on the
 marketing for hackers page, both from the original 1998 web site).

At this point in the text, I'd suggest to insert a little explanation on 
the ambiguity in the use of the term of open source as well. Quick draft...


 On the other hand, the term open applied to the source is sometimes
 used in the sense of merely provided or visible, but the open
 source definition sets the criteria for open source to software
 licenses that guarantee a set of perpetual and irrevocable
 rights to every recipient.

The text should then probably skip furthermore, and continue...

 The FSF uses a shorter, four-point definition of software freedom
 when evaluating licenses, while the OSI uses a longer, ten-point
 definition. The two definitions lead to the same result in practice,
 but use superficially different language to get there.

I hope it will help with a number of misunderstandings.
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Another crayon license

[Engel Nyst]

Hello license-discuss,

On 11/08/2013 10:26 PM, Gregor Pintar wrote:

What do you think about this crayon license?


It reads to me like an ultra-permissive license, almost a public domain 
dedication in the form of a license. Personally, I find it an 
interesting license.



It has a copyright notice, but it does not require keeping it. This is 
unexpected (for me); I'm not sure why it asserts copyright. It also 
states it allows to relicence.


Is it really intended to allow a full replacement/removal of license 
text and removal of copyright notice? It will have that effect...


No-Warranty. The statement is much simpler than for MIT, BSD, ISC, 
Unlicense, CC0, CC-BY. Personally, I'd suggest not crayon-ing that 
paragraph. I'd think you don't want it to fail.



Just my two cents. And two more... If I met it in the wild, I would 
treat this license like a MIT license for software, and similar for 
content. The text reads okay to me, and it seems more permissive than 
MIT/ISC. But I'm not sure it was indeed intended ultra-permissive (the 
licensor might have assumed the (c) notice has to stay!). Regardless, 
I'd treat it anyway like MIT...

___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] license information improvement project - now with a mockup!

[Engel Nyst]

On 11/06/2013 09:31 PM, Luis Villa wrote:

On Wed, Nov 6, 2013 at 10:50 AM, Richard Fontana font...@sharpeleven.orgwrote:

Maybe a link to the license steward's FAQ, if any (perhaps with some
appropriate disclaimer that the OSI does not necessarily endorse
anything in such FAQs)? This will only be relevant to a few licenses but
some of them are among the more widely used ones.



Excellent point; added to the mockup.

This somehow tipped it over the edge as too information-rich for me, so I
tried out another mockup, posted here for your comments:

http://wiki.opensource.org/license_improvement_sample_alternate



Oh, the alternate sample looks much cleaner to me. Sub-sections and 
simple lists make it readable and it's helpfully organized.


I'm wondering though about the intended links to home and FAQ pages. I'm 
not sure the license homepage is different than what counts as FAQ, it 
seems they are different only for MPL and GPL. A license homepage is 
already rare, and sometimes it's precisely meant as FAQ.


If the license steward doesn't have a dedicated license page (other than 
the text), like EPL, the closest to a license homepage would be the 
legal page I assume...[1] However, it only has other Eclipse information 
and not about the license. I'm not sure it helps.
I provisionally set EPL FAQ as homepage. I must misunderstand the 
intention of the homepage placeholder, in my attempt to take MPL's as 
example. MPL has a rich home. :)



[1] http://www.eclipse.org/legal/

___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Unlicense CC0 and patents

[Engel Nyst]

On 08/23/2013 03:40 PM, Clark C. Evans wrote:

I know the Copyright Commons didn't want to publish an alternative,
since
it would dilute their message.   However, perhaps someone could strike
the words or patent, give it a fancy name, and submit it here?


I've just seen this is happening: 
https://github.com/asaunders/public-domain-customized
Custom Dedication: Open Source is a modified CC0 that addresses the 
patent rights issue. (there are more differences than just strike or 
patent)
It's amazing and very valuable that authors with legal background are 
interested to draft open source licenses in the open, as difficult as it 
has to be for them.

___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Open Source Eventually License Development

[Engel Nyst]

On 08/21/2013 07:27 PM, zooko wrote:

I think I already have this with the Tahoe-LAFS codebase, because of the way
that it is dual-licensed under TGPPL v1+ or GPLv2+ at your option. It satifsies
(i), because B can use a1 under the TGPPL. It satisfies (ii), because B can use
a1 under the GPL. It satisfies (iii), because the TGPPL does not allow B to
keep b1 proprietary-for-a-limited-time and then license b1 under GPL to C.

The only (?) downside to this scheme is the possibility of a licence-fork:
someone could take a1 (e.g. the current version of Tahoe-LAFS) under either GPL
or TGPPL and release a dervied work (b1) under GPL-only, or under TGPPL-only,
and then downstream users from them would not have the dual-licence option.


I don't see how is this only a possibility, I think it's a certitude of 
a license-fork: B *has* to license under TGPPL-only, if they want 
proprietary-for-a-limited-time option. If, during the 1st year, B would 
dual-license b1, then C (and A) who receive b1 could want it under GPL. 
B doesn't want that, and can't say I have the right under GPL to make 
you wait an year.

So downstream from B only receives b1 under TGPPL.
(excluding if B has licensing rights to additionally re-add GPL after 
one year, but I feel that's entirely different)


Am I missing something?
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Open source license chooser choosealicense.com launched.

[Engel Nyst]

Hello license-discuss,

On 08/18/2013 04:38 AM, Richard Fontana wrote:

Independent of this point, I'm concerned about inaccurate statements
made on the choosealicense.com site (one that we talked about was the
assertion that GPLv3 restricts use in hardware that forbids software
alterations).


Please allow me to ask the impossible question: how would you write the 
summary of GPLv3 vs GPLv2 in 8-16 words?

___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

[License-discuss] Text version issue on licenses pages

[Engel Nyst]

Hello license-discuss,

In the process of testing a license database tool [1], we noticed that OSI
site serves the few licenses with plaintext versions available, as text/html.
Please see:
http://opensource.org/licenses/cddl1.txt
http://opensource.org/licenses/cpl1.0.txt
http://opensource.org/licenses/eclipse-1.0.txt

There are very few of them and it is very useful for license documentation,
authoring/packaging and analysis tools, to have canonical plaintext versions.
I suppose that the expected result of these links would be simply serving
text/plain.

Thank you for considering it!

[1] https://licensedb.org/
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] what would de-listing of licenses look like?

[Engel Nyst]

On 3/7/13, Luis Villa l...@tieguy.org wrote:
 On Wed, Mar 6, 2013 at 11:48 AM, Richard Fontana
 font...@sharpeleven.org wrote:
 The Frameworx license is one of those OSI-approved licenses that I
 believe was approved in haste. If OSI had such a procedure, I would
 recommend that the Frameworx license be reviewed for de-listing.

 Any recommendations on what such a process would look like, Richard?
 I'm not super-enthused about the idea, but don't want to rule out
 anything without at least some discussion.


Thank you for taking it into account.
I've put together very roughly a wiki page for a draft proposal of how the
process could, perhaps, look like. The reason is that an actual
prototype of what is being discussed might help a constructive
discussion and give a better view of what is being proposed.
http://wiki.opensource.org/license_delist_proposal

I apologize if that is an unsuitable action. Please feel free to remove it
in that case.


On 3/7/13, Richard Fontana font...@sharpeleven.org wrote:

 In my view, Bruce's justification 2 is the only justification: the
 license does not comply with the OSD and was accepted in error.

 I don't believe it is practical for the OSI to assess Bruce's
 justification 1. As for Bruce's justification 3, I think the OSI does
 enough here in its efforts to classify already-approved licenses.

 I certainly agree with Bruce that de-listing cannot be for political
 reasons. The rationale must be somehow grounded in the OSD, much like
 approval of licenses.

 I think you need to have a committee review a proposal to de-list, with
 arguments from the submitter regarding the problems in the license,

 I agree with that.


I've intended the draft mostly on the basis of existing approval process,
and the discussion here, but it surely contains many inappropriate and
rough points. Please, shut it down or change it, as you see fit.
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] FAQ entry for slight variations in licenses?

[Engel Nyst]

On 3/7/13, Luis Villa l...@tieguy.org wrote:
 A comment on the ISC license page (found by Engel- thanks!) points out
 that there is more than one variation of the ISC license. This is a
 common issue for the older permissive licenses, unfortunately.

 Driven by this question, I think we might want a FAQ entry that
 answers the following question:

 Q: I know about a variant of an approved license that differs from
 the approved license by only one or two words. Is the variant also an
 approved license?

 A: Something along the lines of: Many older licenses have a variety
 of minor variations in the language. Unfortunately, it is not possible
 for OSI to review every variation, so we cannot say if a given
 variation is approved.

 Unfortunately, this is a bit of a non-answer, but I'm not seeing a
 good way to address it. Perhaps someone here can give a more
 useful/constructive answer that I'm not seeing right now?


I wonder if it needs to be only FAQ (generic answer), or there is
a way to explicitly point out the really minor known variations in
use...

Allow me to ask a different question:
Is there anything of significance that OSI knows of, at this time,
which would make the variation break OSD in some way, or
otherwise would probably not be approved?

If the answer 'no', and the variation is in real, successful use,
then perhaps it is worth to say just that.

For example (not necessarily the best example), on the license
page, a note:
there is a variation in use, this [diff]. While it is not considered the
canonical version approved by OSI, and we do not recommend its
use for new projects, there were no significant reasons brought to
light in community discussions for which this variation would break
the OSD, or otherwise known serious flaws.

It is not approved, but then, no variation is even considered for review
as far as I think I have seen on this mailing list and OSI policies for
non-proliferation or related reasons? (please correct me if wrong).

That doesn't mean that they're all alike...

 Unfortunately, it is not possible for OSI to review every variation,
 so we cannot say if a given variation is approved.

From not every, it does not follow logically not any. I don't doubt
the premise is true, but the second does not follow from it alone.
But perhaps there is no need to go all the way, for minor differences
and existing use...: it is not approved, but sometimes it is discussed
and no reasons are raised, which would probably make it rejected.
(apart from reasons unrelated to its FOSS appropriate status)
With all other disclaimers needed... but if it's true, perhaps there is a
way to say it.

Just an idea... Probably not too well-thought.
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Questions about the Frameworx license.

[Engel Nyst]

On 3/7/13, Luis Villa l...@tieguy.org wrote:
 On Wed, Mar 6, 2013 at 11:30 AM, Karl Fogel kfo...@red-bean.com wrote:
 I'm posting this on behalf of Alex Siegal, who is CC'd, because he's
 having trouble posting to our list (the posts disappear, never even end
 up in the moderation queue -- we'll take it up separately with the
 infrastructure crew).  Alex writes:

I would like to use the Frameworx license.  What, if any, modifications
am I permitted to make and still be distributing source code pursuant
to the approved Open Source Frameworx license?  For example, can I
change The Frameworx Company to the name of my company?  Also, there
are typo's and incorrect cross references in the license.  Am I
permitted to modify those so they are correct?

 Hi, Alex-

 As a general point, we would recommend using other, better drafted
 licenses as the best way to avoid this problem. That having been said,
 I hope the discussion will focus on a good-faith attempt to answer
 your question.

 I don't think we've ever had formal policies on any of these
 questions, but I welcome correction/clarification from those with
 older historical memories.

 Fixing typos and incorrect cross references has always been done in
 various ways, so I don't think that's objectionable, and in fact, I
 wouldn't object to updating the version on the website (assuming the
 changes are truly not substantive).

 The other changes... I'm really not sure. Others want to weigh in?


I would add for your attention, on OSI site, Frameworx license is included
in the category: non-reusable licenses. According to the explanations
from the proliferation report[1], non-reusable licenses are specific to their
authors and cannot be reused by others. Many, but not all, of these
licenses fall into the category of vanity licenses.

As a further note, mailing lists archives show concerns raised on the
clauses 1d) and 3b) [2] (and other emails around that time).

Please consider the notes above simply the results of a public search
(this is what they are). I am not affiliated with OSI, nor a lawyer, nor
anything else that would construe the above other than it is: pointers
to existing information, in the hope they are useful.


[1] http://opensource.org/proliferation-report
[2] 
http://projects.opensource.org/pipermail/license-discuss/2011-December/83.html
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] call for volunteers: getting rid of comments on OSI licenses

[Engel Nyst]

On 3/5/13, Luis Villa l...@tieguy.org wrote:

 So: we'd like to nuke all the comments.

 But we'd like to do that with a bit of discrimination. Specifically,
 we'd like to review the comments before deletion, to see if any of
 them should be in the FAQ.


Thank you for the call! I think it can only help, and the site will be better
for it.


On 3/6/13, Karl Fogel kfo...@red-bean.com wrote:

 Folks: remember you'll need to get an authorized account to edit.  Luis
 should be able to create those (and Luis, if you can't, let me know and
 we'll fix that).


Please do note: if you mean the wiki, I have been able to edit the wiki page,
with a newly created wiki account. Unless it has been manually approved
without me requesting it, then this doesn't sound like intended behavior?
Sorry if I misunderstand.



On a different note. While the comments system has not been ideal, I
think the point itself to allow and encourage people to ask questions, or
point out issues with the licenses, is still worth consideration... perhaps
by encouragement to use this mailing list, instead?

I'd suggest to replace the former Log in to enter a comment section
with a line like:
If you have questions, please see the linkFAQ page, or check the
license-discuss mailing list archive.

Just a suggestion. It's only one line. :)
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

[License-discuss] OSI site: broken links

[Engel Nyst]

Hello license-discuss,

Checking a couple of pages, I note some broken links:
On the superceeded or retired licenses page, the link to RPL
1.1. is broken. It seems the license text is at RPL1.0 canonical
link[1].

On the education page[2], several links are broken. From 2009,
* How to leverage open source for the digital recovery
* Building successful open source communities
* Users as Contributors

There are probably more on this page.

You might want to be aware of these. A site check and cleanup
seems a good idea. :)

[1] http://opensource.org/licenses/rpl1.0
[2] http://opensource.org/osi-open-source-education
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] [FAQ] Is some PHP program Open Source?

[Engel Nyst]

On 1/7/13, Ben Reser b...@reser.org wrote:
 On Mon, Jan 7, 2013 at 8:59 AM, Karl Fogel kfo...@red-bean.com wrote:
 What I meant was a specific rewording.  In other words, I'm inviting you
 to do the work you're inviting me to do :-).

 I'll do it, it's a good point.

Thank you for taking it into consideration, and I apologize for the
slow follow-up.

In case it helps in any way, I'd suggest:

You can see the PHP source code, so it's Open Source, right?
No. The code of applications written in languages like PHP or
JavaScript is visible, but that alone doesn't mean anything yet: it
always depends on the license under which the code is distributed.
Only if the code is licensed under an approved Open Source license,
it's Open Source. The licenses in the list maintained by OSI are
reviewed before approval, to make sure that everyone receiving the
code has the perpetual right to use, modify, share and reshare the
code freely, as well as other criteria as listed in the Open Source
Definition. It's those criteria that define Open Source, not access to
the source code alone.
If the code is not under one of the approved licenses, then please do
not call it Open Source.

Thank you!
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

[License-discuss] [FAQ] Is some PHP program Open Source?

[Engel Nyst]

Hello license-discuss,

On 11/29/12, Karl Fogel kfo...@red-bean.com wrote:
 Ben Reser b...@reser.org writes:
On Wed, Nov 28, 2012 at 10:45 AM, Karl Fogel kfo...@red-bean.com wrote:
 Any comments welcome.  If I hear a lot of +1s, then I'll edit the FAQ
 page accordingly.  If this gets a lot of comments, then we'll just see
 where the thread goes.  Here are my proposed top-level categories:

+1

   * Is SOME PHP PROGRAM Open Source simply because it's written in
 PHP?

Some reason why this is PHP and not:

* Is SOME PROGRAM Open Source simply because it's written in SOME
OPEN SOURCE LICENSED LANGUAGE?

 I assume because we got that question more about PHP than about anything
 else.  While I wasn't here when that question was written, I can confirm
 that this trend continues -- when I hear this particular question, it's
 usually about PHP (and not Python, Perl, or ${LANGUAGE_OF_THE_WEEK}).

 -K

About every time I have seen this question, its meaning has been:
Is this PHP program Open Source simply because the source of a PHP
program is *available*, therefore 'open' source?
The source code of the application is provided, therefore open. (in
proprietary licensed applications)
The reason of many people's confusion on PHP applications has not been
the language implementation license at all, but the fact that it's an
interpreted language.

Other experiences may be different. I am, however, submitting this
issue for your attention. I have been surprised that the answer on the
FAQ page assumes[1] that the confusion around PHP applications being
Open Source has anything to do with the license of the language
implementation.

[1] http://opensource.org/faq#language-vs-license
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Differences between GPL and LGPL

[Engel Nyst]

Hello license-discuss,

Lawrence,

Thank you very much for the discussion on the actual differences
between GPL and LGPL in practice! Your clarifications on common
misunderstandings on GPL/LGPL would be extremely welcome for me, and
IMHO they are needed.

Please do consider that apart the groups hinted at, companies which
'force disclosure' of source code and companies which 'choose GPL over
LGPL to force disclosure', there are Open Source projects and
developers which might be interested in the questions. I know I am.

Unfortunately I'm sure that between a common (mis)understanding of
GPL/LGPL and correct use of the legal terms here, there is a mismatch,
which makes it difficult to express what one wants to say without
risking to use the terms inappropriately.

I will take the chance to do so nevertheless.

 You keep referring to the enormous cost of litigation and you encourage
 companies to err on the conservative side of this GPL/LGPL issue. You
 should also consider the potential cost to a plaintiff for falsely accusing
 a defendant of copyright infringement, even outside of court. I would also
 like you to weigh the frustrated expectations of licensors who choose
 between the GPL and LGPL on mistaken grounds, expecting certain behavior by
 their licensees that they won't be able to force even in a court fight.

If I use an LGPL software in my application, without modifying its
code in any way, it's probably safe to say I can license my code in
any way. Including what is declared as GPL-incompatible licenses for
the rest of the code.

If I use GPL software in my application, then almost no matter what
does my application do, if it's on a single computer (classical
scenario), then the whole will have to be at least relicensable as
GPL. (at least relicensable, if I don't have to even relicense it
myself). That's either possible and wanted, or it's not: my project
may have GPL-incompatible pieces, it may be driven by a copyleft
policy under a license which FSF declares GPL-incompatible, or it may
be permissive and want to remain that way.

I don't even get to the question: do I intend to create a 'derivative
work under US copyright law': I have an answer cut out for me before
even getting there. This answer comes from the perception of GPL
intentions, at least, and for sure perception of FSF's explanations.

Strangely, this way I can relate to Bruce's expression to err on the
conservative side. This has nothing to do with business and
proprietary licensing, and only with my perception of what can
possibly be done when combining FOSS licenses.

Apart from this, it's however true that it has always been my
perception that derivative work is indeed redefined by GPL in
practice at least, if not explicitly...

 FOSS is no longer a small-business enterprise where a random copyright owner
 can threaten licensees to force the disclosure of proprietary code and
 expect to win simply because of community pressure. (At the very least, you
 shouldn't expect open source lawyers like me to respond to that form of
 community pressure on a list like this!)

Alternative perspective, if I may: I don't want an Open Source project
I contribute to, to break the expectations and intentions of another
Open Source project which uses GPL. Not for 'fear of litigation'. But
I guarantee to a community that the code is Open Source and safe to
use, modify, and share, as they receive it, under the terms of the
respective license(s), and does not break anyone's rights, nor did
independently written code become GPL without explicit relicensing and
appropriate community discussion.


Luis,

I apologize for the off-topic. Better understanding of GPL/LGPL has,
to me, more to do with license compatibility, though, than flamewars,
even if some of the issues are very prone to the latter. I understand
if people feel differently, though, and I apologize if this message is
an unfortunate part of it.
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Published revised opensource.org/licenses page

[Engel Nyst]

Hello license-discuss,

Thank you for the work and patience on this. IMHO the new page looks
more useful than it used to be.

Cosmetic point: two of the licenses have explicit version, while the
others don't. Is this intended?

A little off, another cosmetic point: I cannot find Mozilla Public
License 1.1 linked anywhere, except the page with MPL 1.0 text. Am I
missing it, or is this intended? Even if it is superceded by 2.0, I
would have expected it listed. It's barely superceded, after all, and
I suppose projects may use it.

Sorry if I'm missing existing discussions on these trivial points, the
subject has many threads...

On 1/2/13, Luis Villa l...@tieguy.org wrote:
 Hi, license-discuss:

 Based on the discussions we've had here over the second half of 2012,
 I've published a revised version of opensource.org/licenses this
 morning.

 A few minor tweaks were made to the last draft based on comments here;
 the biggest being a reference to the FAQ and inclusion of several
 questions from the FAQ. I've also included a reference to the
 proliferation report so that it is more clear how the list of
 popular, etc. was arrived at, and strengthened the language around
 the links to the complete lists so that it is more clear that those
 licenses are also approved and usable.

 The page is still a work in progress, in two ways:

 1) Cosmetically: suggestions on grammar, layout, or uncontroversial
 content (e.g., adding links to other FAQ questions; otherwise beefing
 up the content) are still very welcome, either in this thread or by
 personal email.

 2) Substantively: as has been pointed out and discussed at length, the
 current categories could stand revision, probably including more
 objective criteria. PLEASE do not use this thread to discuss that
 issue. If you have specific, concrete, suggestions, please start new
 threads, or respond to my older thread on objective criteria.

 Luis
 ___
 License-discuss mailing list
 License-discuss@opensource.org
 http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] objective criteria for license evaluation

[Engel Nyst]

Hello license-discuss,

As a software developer, interested to raise awareness on open
licensing, build a community of an Open Source project, and educate
myself and all involved people to understand and choose their open
licenses, I very much welcome this discussion. I admit I have been
looking for slightly more guidance on OSI pages, over the last couple
of years, than it is available currently. Please don't take that as
criticism, or not otherwise intended than simply a need for pointers.

If I may share a few thoughts from this user-side experience. I think
that OSI pages could greatly help if they contain hints or assistance
in particular for:

On 12/10/12, Lawrence Rosen lro...@rosenlaw.com wrote:
 Regarding the classification of licenses, I think it is most important to
 categorize licenses in the same business-related terminology that relates
 to
 business models. So you need to identify which licenses ignore or have
 antiquated provisions regarding patents, and why that might matter; which
 licenses require reciprocity; whether that reciprocity includes use by
 third
 parties over a network or whether it is a strong or weak reciprocity;

I quote this for the reciprocity criterion first and foremost. I think
it's essential, including but not limited to, for developers looking
for a license, and for developers and community to understand open
licenses, their effects, their goals. For an educational purpose.

My own (poor) attempt at it has been the simplified and easy to
understand approach (IMHO):
permissive licenses (require no reciprocity; BSD, MIT, Apache) - weak
copyleft (MPL; with LGPL more towards the next 'step') - strong
copyleft (GPL) - strong copyleft extended (AGPL).

Additionally, I think OSL is worth a place; again for informative or
educational purpose IMHO.

 which licenses are definitely incompatible with each other for derivative
 work purposes;

This is another important question, one needs to know or inform
themselves easily on definite incompatibilities. As expected,
personally I have addressed it by researching the licenses, license
stewards statements, and projects statements where needed. IMHO a
matrix or listings of at least some license incompatibilities would be
very useful.


Other criteria discussed in this thread could also be useful, for
sure. However, at least these above (including patents position, with
a simple explanation if it's possible, for the many unaware of
potential issues), are in my experience very much needed. They shape
the landscape of Open Source licenses and categorization by them would
greatly help to understand at least the basics of this landscape.
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss