Re: [License-discuss] patent rights and the OSD

[Ben Tilly]

I used weasel words, "..does impact distribution of software.."  By which I
meant that the act of distributing software CAN trigger patent law.  Not
that it always does.

Arguments can be made both ways on this.  Giving away software for free can
be argued to fall under, "Whoever actively induces infringement of a patent
shall be liable as an infringer."  But, as you said, free speech is
involved here.

That said, downloading compiled code in the US from a Canadian ftp site is
an activity that OSD #1 says should be allowed, but my understanding of US
patent law clearly says that this is forbidden.  And that's enough for
patent law to cross into territory that the OSD cares about.

(I'm still not a lawyer, etc.)

On Tue, Mar 7, 2017 at 5:52 PM, Lawrence Rosen  wrote:

> Ben Tilly wrote:
>
> > According to the statute as shown at https://www.law.cornell.
> edu/uscode/text/35/271, patent law covers selling and importing.  Which
> by my reading means that it does impact distribution of software, even if
> you do not run it.
>
>
>
> I don't read the law quite that way. Certainly selling or importing a
> product that contains patented software for its intended use would be
> infringing. But merely importing or distributing source code that is
> licensed under CC0 does not infringe. I'd call it free speech.
>
>
>
> Other opinions?
>
>
>
> /Larry
>
>
>
>
>
> *From:* Ben Tilly [mailto:bti...@gmail.com]
> *Sent:* Tuesday, March 7, 2017 4:27 PM
> *To:* Lawrence Rosen ; License Discuss <
> license-discuss@opensource.org>
> *Subject:* Re: [License-discuss] patent rights and the OSD
>
>
>
> *[] *
>
> IANALTINLA and all that.
>
>
>
> On Tue, Mar 7, 2017 at 3:57 PM, Lawrence Rosen 
> wrote:
>
> Christopher Sean Morrison wrote:
>
> > Software patents are terrible in part because they pertain to the
> source code itself, thus affecting the distribution terms on that code.
>
>
>
> Patents don't pertain to source code or to code distribution, at least not
> in legal terms of direct patent infringement. Patent rights pertain to the
> "use" of the software, not its written description.
>
>
>
> Patents are already described as publicly as open source code (see
> USPTO.gov), but one is under patent law and the other under copyright law.
> This openness of publication under patent law is on purpose, although with
> the flood of software patents and their obscure language, this publication
> openness is not very helpful to creators of copyrighted software. But this
> doesn't affect source code or its distribution, certainly not literally in
> the many jurisdictions where the patents are ineffective, nor in the U.S.
>
>
>
> Where this discussion can go awry is when we interpret the OSD too broadly
> with respect to patents. The OSD can be clarified or amended, but at its
> birth nobody fully understood software patents. After reading the CC letter
> to the White House (https://github.com/WhiteHouse/source-code-policy/
> issues/149), I can agree it is a complicated problem.
>
>
>
> /Larry
>
>
>
>
>
> *From:* License-discuss [mailto:license-discuss-boun...@opensource.org] *On
> Behalf Of *Christopher Sean Morrison
> *Sent:* Tuesday, March 7, 2017 3:10 PM
> *To:* license-discuss@opensource.org
> *Cc:* License Discuss 
> *Subject:* Re: [License-discuss] patent rights and the OSD
>
>
>
>
>
>
> On Mar 07, 2017, at 04:45 PM, Ben Tilly  wrote:
>
> When we talk about whether a software license is OSD compliant, we are
> only addressing the question of whether this license restricts software
> under copyright law in a way that violates the OSD.
>
>
>
> I hear you, but I don't see where the OSD says that.  It does not mention
> copyright law.  The OSD annotated or otherwise doesn't even mention the
> word 'copy'.  It (specifically?) says "the distribution terms".
>
>
>
> While I certainly can understand the perspective that there are other
> laws, regulations, and factors, not all of them affect distribution terms
> of the software -- they are restrictions on me, my assets, my situation,
> not the software.  Software patents are terrible in part because they
> pertain to the source code itself, thus affecting the distribution terms on
> that code.
>
>
>
> In a way, it's convenient that the OSD does not specifically call out
> copyright and speaks generically.  It's a testament of forethought (or
> luck) of the original authors.
>
>
>
> Cheers!
>
> Sean
>
>
>
>
>
>
> ___
> License-discuss mailing list
> License-discuss@opensource.org
> https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
>
>
>
___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] patent rights and the OSD

[Ben Tilly]

According to the statute as shown at
https://www.law.cornell.edu/uscode/text/35/271, patent law covers selling
and importing.  Which by my reading means that it does impact distribution
of software, even if you do not run it.

IANALTINLA and all that.

On Tue, Mar 7, 2017 at 3:57 PM, Lawrence Rosen  wrote:

> Christopher Sean Morrison wrote:
>
> > Software patents are terrible in part because they pertain to the
> source code itself, thus affecting the distribution terms on that code.
>
>
>
> Patents don't pertain to source code or to code distribution, at least not
> in legal terms of direct patent infringement. Patent rights pertain to the
> "use" of the software, not its written description.
>
>
>
> Patents are already described as publicly as open source code (see
> USPTO.gov), but one is under patent law and the other under copyright law.
> This openness of publication under patent law is on purpose, although with
> the flood of software patents and their obscure language, this publication
> openness is not very helpful to creators of copyrighted software. But this
> doesn't affect source code or its distribution, certainly not literally in
> the many jurisdictions where the patents are ineffective, nor in the U.S.
>
>
>
> Where this discussion can go awry is when we interpret the OSD too broadly
> with respect to patents. The OSD can be clarified or amended, but at its
> birth nobody fully understood software patents. After reading the CC letter
> to the White House (https://github.com/WhiteHouse/source-code-policy/
> issues/149), I can agree it is a complicated problem.
>
>
>
> /Larry
>
>
>
>
>
> *From:* License-discuss [mailto:license-discuss-boun...@opensource.org] *On
> Behalf Of *Christopher Sean Morrison
> *Sent:* Tuesday, March 7, 2017 3:10 PM
> *To:* license-discuss@opensource.org
> *Cc:* License Discuss 
> *Subject:* Re: [License-discuss] patent rights and the OSD
>
>
>
>
>
>
> On Mar 07, 2017, at 04:45 PM, Ben Tilly  wrote:
>
> When we talk about whether a software license is OSD compliant, we are
> only addressing the question of whether this license restricts software
> under copyright law in a way that violates the OSD.
>
>
>
> I hear you, but I don't see where the OSD says that.  It does not mention
> copyright law.  The OSD annotated or otherwise doesn't even mention the
> word 'copy'.  It (specifically?) says "the distribution terms".
>
>
>
> While I certainly can understand the perspective that there are other
> laws, regulations, and factors, not all of them affect distribution terms
> of the software -- they are restrictions on me, my assets, my situation,
> not the software.  Software patents are terrible in part because they
> pertain to the source code itself, thus affecting the distribution terms on
> that code.
>
>
>
> In a way, it's convenient that the OSD does not specifically call out
> copyright and speaks generically.  It's a testament of forethought (or
> luck) of the original authors.
>
>
>
> Cheers!
>
> Sean
>
>
>
>
>
> ___
> License-discuss mailing list
> License-discuss@opensource.org
> https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
>
>
___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] patent rights and the OSD

[Ben Tilly]

My legal rights to software on the computer in front of me may be
restricted by many things.  A short and incomplete list includes copyright
law, patents, contracts, who owns the computer and my employment status.
Any and all of these can impact whether I actually enjoy the freedoms that
the OSD describes.  I may be unaware of or misinformed about any or all
these potential encumbrances.

When we talk about whether a software license is OSD compliant, we are only
addressing the question of whether this license restricts software under
copyright law in a way that violates the OSD.  In principle it is generally
impossible to decide whether I *actually* have the rights described by the
OSD to the software in front of me.

(I am not a lawyer and this is not legal advice.)

On Mon, Mar 6, 2017 at 3:41 PM, Christopher Sean Morrison 
wrote:

>
> In light of the recent CC0 discussion, I’m refreshing my mind on what
> rights are provided under patent law, each of the OSD criteria, and any
> connections between them.
>
> From my reading, a patent gives the holder the right to exclude others
> from (a) making, (b) using, (c) selling, or (d) importing/exporting their
> invention.  The OSD clauses refer to “the distribution terms” in rather
> license- and copyright-agnostic terms, so here’s my basic layman analysis:
>
> 1) Exclusion (a) seems not problematic for the OSD as it precludes others
> outside of licensing.
> 2) Certainly a problem in the broad sense, but exclusion (b) seems not
> problematic with the OSD.
> 3) Exclusion (c) seems to fail OSD clause #1 (Free Redistribution) and
> possibly #7 (Distribution of license).
> 4) Exclusion (d) similarly fails #1 and #7.
>
> So what?  In terms of OSD compliance, there appears to be several issues
> if a patent exists and one does not grant/hold a royalty-free patent
> license.  If I have a software patent and license that software under CC0,
> for example, without any other distribution terms in place, it’s my reading
> that this would technically be distribution terms that violate OSD #1 and
> #7.
>
> This creates an interesting situation where “the distribution terms” of
> some software will depend on whether the distributor holds a patent, not
> necessarily on the language of their license.  There are, of course, ample
> examples of licenses that convey conforming patent rights, both implicit
> and explicitly.
>
> Does anyone disagree that holding a patent and not granting a patent
> license violates the OSD, perhaps as an out-of-band perspective?  Should
> the OSD only be measured against a copyright standard, as originally
> drafted?  Does OSI need to clarify “all bets are off” if there’ s a patent
> or consider them as part of the distribution terms equally?  What are other
> people’s thoughts on this?
>
> Cheers!
> Sean
>
> ___
> License-discuss mailing list
> License-discuss@opensource.org
> https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
>
___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Views on React licensing?

[Ben Tilly]

Item 1 of the OSD says, "The license shall not restrict any party from
selling or giving away the software as a component of an aggregate software
distribution containing programs from several different sources. The
license shall not require a royalty or other fee for such sale."

Red Hat's trademark license fails this provision as badly as you could want.

The issue is the same as the one that arose for Debian (whose free software
guidelines are the inspiration for the OSD) with regards to Mozilla
trademarks.  See
https://en.wikipedia.org/wiki/Mozilla_software_rebranded_by_Debian for what
happened next.

On Tue, Dec 6, 2016 at 3:40 PM, Tzeng, Nigel H. 
wrote:

> So Larry and Ben, is RHEL is not open source because you cannot
> redistribute RHEL without a trademark license from RedHat?
>
> If an explicit patent grant is a requirement for open source should an
> explicit trademark grant also be required?  Does CPAL provide an implicit
> permission to use trademark given the attribution requirement?
>
> From: License-discuss  on behalf
> of Ben Tilly 
> Reply-To: License Discuss 
> Date: Tuesday, December 6, 2016 at 6:04 PM
> To: License Discuss 
> Cc: "henrik.i...@avoinelama.fi" 
> Subject: Re: [License-discuss] Views on React licensing?
>
> Looking at the open source definition, it should be able apply to any
> license of any kind.
>
> The argument is that the patent grant is not open source because the
> inability to continue using the software after suing Facebook for patent
> infringement is a "price".  However you are unable to use the software
> before receiving it, so you do not wind up worse off from having received
> it.  Therefore there is no real price to receiving it.
>
> After having received the program, there is clearly a price to violating
> the license.  But the same is true for any license.  For example look at
> the GPL v3.  If you distribute a GPL v3 program without appropriate
> copyright notices as required by clause 4, then your license can be
> terminated under clause 10, and you will lose the right to continue running
> the software as granted under clause 2.  This is an apparent "price" of the
> exact same form.
>
> Either this patent grant is open source, or no license can qualify.
>
> On Tue, Dec 6, 2016 at 1:00 PM, Tzeng, Nigel H. 
> wrote:
>
>> On 12/6/16, 3:33 PM, "henrik.i...@gmail.com on behalf of Henrik Ingo"
>>  wrote:
>>
>>
>> >The question isn't about patents or copyrights. The point is that taking
>> >an OSI approved license and making additions to it by adding a separate
>> >file with additional terms and conditions, results in a combination which
>> >as a whole is not OSI approved open source license. It is no different
>> >from taking the BSD license and making additions to it within the same
>> >file.
>>
>> In what way is the BSD copyright license impacted by an external patent
>> grant license?
>>
>> How is this different than combining a BSD copyright license and an
>> external trademark license agreement?
>>
>> IMHO it has everything to do with whether patents are in or out of scope
>> for OSI license approval for copyright licenses.
>>
>> >I categorize patent grants with wide reaching termination clauses as
>> >commons-friendly. Like I said, my only regret is that there aren¹t
>> >licenses being used that would be even more wide reaching than this one.
>>
>> That¹s fine as long as there are open source licenses with far more narrow
>> grants or no grants whatsoever like CC0.
>>
>> CC0->ECL v2->Apache->React should all be fine from a OSI license approval
>> perspective.
>>
>> ___
>> License-discuss mailing list
>> License-discuss@opensource.org
>> https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
>>
>
>
> ___
> License-discuss mailing list
> License-discuss@opensource.org
> https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
>
>
___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Views on React licensing?

[Ben Tilly]

Looking at the open source definition, it should be able apply to any
license of any kind.

The argument is that the patent grant is not open source because the
inability to continue using the software after suing Facebook for patent
infringement is a "price".  However you are unable to use the software
before receiving it, so you do not wind up worse off from having received
it.  Therefore there is no real price to receiving it.

After having received the program, there is clearly a price to violating
the license.  But the same is true for any license.  For example look at
the GPL v3.  If you distribute a GPL v3 program without appropriate
copyright notices as required by clause 4, then your license can be
terminated under clause 10, and you will lose the right to continue running
the software as granted under clause 2.  This is an apparent "price" of the
exact same form.

Either this patent grant is open source, or no license can qualify.

On Tue, Dec 6, 2016 at 1:00 PM, Tzeng, Nigel H. 
wrote:

> On 12/6/16, 3:33 PM, "henrik.i...@gmail.com on behalf of Henrik Ingo"
>  wrote:
>
>
> >The question isn't about patents or copyrights. The point is that taking
> >an OSI approved license and making additions to it by adding a separate
> >file with additional terms and conditions, results in a combination which
> >as a whole is not OSI approved open source license. It is no different
> >from taking the BSD license and making additions to it within the same
> >file.
>
> In what way is the BSD copyright license impacted by an external patent
> grant license?
>
> How is this different than combining a BSD copyright license and an
> external trademark license agreement?
>
> IMHO it has everything to do with whether patents are in or out of scope
> for OSI license approval for copyright licenses.
>
> >I categorize patent grants with wide reaching termination clauses as
> >commons-friendly. Like I said, my only regret is that there aren¹t
> >licenses being used that would be even more wide reaching than this one.
>
> That¹s fine as long as there are open source licenses with far more narrow
> grants or no grants whatsoever like CC0.
>
> CC0->ECL v2->Apache->React should all be fine from a OSI license approval
> perspective.
>
> ___
> License-discuss mailing list
> License-discuss@opensource.org
> https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
>
___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Using opensource in a company not in the software business

[Ben Tilly]

If you host the software on a server and they hit that API, this does not
count as distribution.  But there are licenses, such as the AGPL, that will
still cause you problems there.

The exact definition of when linking creates a derivative work has not to
my non-lawyerly knowledge been litigated.  Many lawyers think that the GPL
FAQ is overly optimistic about how much power the license will have if
litigated.  On the other hand staying within its suggestions greatly limits
the odds of problems down the road.

In general each open source license aims to allay some fear that the author
of the software had.  Some, like the MIT and Apache licenses, protect the
authors and otherwise make it easy to use the code as you see fit.  Others,
like the GPL, avoid having someone build something cool on your software
while refusing to let you see/build on that.

It is likely easiest for you to start with
https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses#FOSS_licenses,
decide where your comfort level is, and try to only use software on one
side of that.  That's a lot easier than staying careful about exactly how
you use each piece of software.

Alternately you can decide that you are not in the software business after
all, give away all distributed software with source, and charge for access
to a service that you maintain.  (And avoid the AGPL!)

On Tue, Nov 29, 2016 at 12:27 AM, FREJAVILLE Etienne <
etienne.frejavi...@coface.com> wrote:

> Hello,
>
>
>
> Thank you for the answers. It seems that we are concerned even though we
> don't sell the software provided to the customer.
>
> Apparently, the fact that the customer uses the software from the outside
> of the company counts as a 'distribution'.
>
>
>
> I may submit that topic to our lawyers, but before I have more precise
> questions related, concerning particular uses of licences, to be sure I
> understand them correctly.
>
> And I agree not to trust 'as is' answers from a mailing list, but it's a
> good start!
>
>
>
> It seems that Apache, BSD, MIT... licences do not cause particular
> problems in our context (and in general).
>
>
>
> Concerning GPL, I have found in the GPL's FAQ that:
>
>
>
> "The community expects that all code linked to GPL code will be licensed
> under the GPL, even if the link is made at runtime using a shared library"
>
>
>
> Does it means that in that case we should release publicly under the GPL
> licence any of our source code that use the open source libraries ?
>
> If true, does indirect usages are also concerned ? Libraries that call
> libraries that call open source libraries will also have to be licenced
> under the GPL licence ?
>
>
>
> Concerning LGPL, knowing that the user cannot modify our code as it's
> proprietary, I understand that using Java libraries for example is not
> possible as he must be able to
>
> (§ 4 of the LGPL V3 : ) "...  recombine or relink the Application with a
> modified version of the Linked Version to produce a modified Combined Work".
>
>
>
> But using Opensource javascript LGPL library without providing source code
> should be possible if I understand well.
>
> Indeed, if the code using the opensource uses it as a reference to a
> library on a distant domain, the user can get the benefits of the latest
> version of the library used by our code if he wants.
>
>
>
> E.g , if displaydate.js is an open source library released under the LPGP
> licence, in our code:
>
>
>
> 
>
> 
>
>
>
> would be an incorrect usage, whereas:
>
>
>
> http://www.yahoo.com/displaydate.js"</a>;>
>
> 
>
>
>
> would be a correct usage.
>
>
>
> Is it correct ?
>
>
>
> Thank you.
>
>
>
> Cordialement, Best regards.
>
>
>
> Etienne
>
>
>
>
>
> *De :* License-discuss [mailto:license-discuss-boun...@opensource.org] *De
> la part de* Radcliffe, Mark
> *Envoyé :* lundi 28 novembre 2016 22:55
> *À :* license-discuss@opensource.org
> *Cc :* c...@theiet.org
> *Objet :* Re: [License-discuss] Using opensource in a company not in the
> software business
>
>
>
> I agree with Ben.  Lawyers with open source experience will dramatically
> decrease your costs.  You should also consider consulting Heather Meeker’s
> book: https://www.amazon.com/Open-Source-Business-Practical-
> Licensing/dp/1511617772/ref=sr_1_1?ie=UTF8&qid=1480369990&
> sr=8-1&keywords=open+source+for+business+meeker
>
>
>
> *From:* License-discuss [mailto:license-discuss-boun...@opensource.org
> ] *On Behalf Of *Ben Tilly
> *Sent:* Monday, November 28, 2016 11:44 AM
> *To:* L

Re: [License-discuss] Using opensource in a company not in the software business

[Ben Tilly]

Nigel's list is biased towards paranoia.  Paranoia is a healthy default
 But it is OK, for example, to ship useful standalone GPL tools to
customers in a zip file that happens to also contain proprietary code of
yours that does not use those tools.

As always, if in doubt you should consult a lawyer and the license.  And
don't rely on opinions from a mailing list.

One final note, I would recommend that it may be worth your while to find a
lawyer with open source experience, and not just familiarity with
intellectual property.  Open source licenses are somewhat unusual, and
there are common misunderstandings around, for instance, how the GPL works
that a general lawyer is likely to spend time working through the first
time.  (Is this a contract?  Does it apply if it is not a contract?)  While
lawyers are generally happy to research things on your dime, this is not
always an efficient use of your money...

On Mon, Nov 28, 2016 at 9:29 AM, Tzeng, Nigel H. 
wrote:

> Cindy advice is best but the quick and dirty answer for you given the two
> things you stated:
>
>- We do not modify or enhance the open source code of the used
>libraries.
>- At last, our code must be kept as proprietary and we don’t consider
>providing the source code using the opens source libraries.
>
> Good:  Apache, BSD, MIT and other permissively licensed open source code.
>
> Maybe Good:  LGPL, MPL and weak copyleft licensed open source code.
>
> Not Good:  GPL and any strong copyleft licensed open source code.
>
> Review your code base and anything that used GPL source code in an
> Android/iOS app or Windows/MacOS/Linux program is an issue.  On your
> internal server if you used any AGPL code it may be an issue.
>
> Your normal lawyer should be able to find you an IP lawyer but you might
> as well start going over your code base.
>
> Regards,
>
> Nigel
>
> From: License-discuss  on behalf
> of Cinly Ooi 
> Reply-To: "c...@theiet.org" , License Discuss <
> license-discuss@opensource.org>
> Date: Monday, November 28, 2016 at 7:51 AM
> To: License Discuss 
> Subject: Re: [License-discuss] Using opensource in a company not in the
> software business
>
> You _are_ in the software business.
>
> The correct person to evaluate your case is your lawyer.
>
> As Woolley said, regardless of which the license of the software you
> choose uses, you still have responsibility under open source license, and
> your customers have expectations as provided for by the license.
>
> It is the same whether it is open source license or close source license
>
> Your lawyer will look at each license you need to use and apply it to see
> whether it meets your business objective.
>
> Another good place to start is to see is there any local people who can
> talk you through it for the price of a coffee. However, your lawyer has the
> final say.
>
>
> Best Regards,
> Cinly
>
> *
> “There should not be an over-emphasis on what computers tell you, because
> they only tell you what you tell them to tell you,” -- Joe Sutter, Boeing
> 747 Chief Engineer.
>
> On 28 November 2016 at 10:23, FREJAVILLE Etienne <
> etienne.frejavi...@coface.com> wrote:
>
>> Hello,
>>
>>
>>
>> I'm sorry for asking a question that has probably been answered in the
>> past, but I couldn't find a clear and precise answer on the subject on your
>> website or any web resource.
>>
>>
>>
>> We are a private company and we wonder how to deal with developments
>> using open source.
>>
>>
>>
>> First of all we are not a software company, and therefore we just provide
>> software applications to our customers, so that they can use our
>> services/buy our products.
>>
>>
>>
>> We develop with code that may use opensource, both:
>>
>>
>>
>> - 1. Pure internal software
>>
>> - 2. Software for our customers provided as Web applications (that
>> obviously interacts with a part of our internal software).
>>
>> - 3. Software for our customers provided as mobile applications
>> (IOS&Android apps) that interacts with a part of our internal software.
>>
>>
>>
>> The usage we make of opensource, is either use the opensource products as
>> standalone products (e.g Maven, Kados..), or use them ‘as is’ as libraries
>> (most java or javascript) (e.g POI, jQuery...).
>>
>> We do not modify or enhance the open source code of the used libraries.
>>
>> At last, our code must be kept as proprietary and we don’t consider
>> providing the source code using the opens source libraries.
>>
>>
>>
>> I have read quite a few pages on the opensource.org website, the FAQ and
>> other external papers, but it seems that the licences discussions and
>> restrictions, concern most of the time the usage of the open source in
>> commercial products, or concern the distribution of open sources
>> modifications.
>>
>>
>>
>> First of all, I would like to know if a software provided to our
>> customers in our case, is considered in the open source terminology as a
>> 'customer product'.
>>
>> Second, I would like to understand

Re: [License-discuss] Is OSI still alive?

[Ben Tilly]

Define alive.  This mailing list works...

On Mon, Nov 28, 2016 at 10:01 AM, Tzeng, Nigel H. 
wrote:

> Just curious as I get crickets in license-review.
>
> I guess it must still be alive as I got asked for a donation…but an update
> on NOSA v2 and UCL would be nice.
>
> ___
> License-discuss mailing list
> License-discuss@opensource.org
> https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
>
>
___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Proposal: Apache Third Party License Policy

[Ben Tilly]

You will never cover all legitimate fears that organizations might
have for a variety of reasons that seem good to them.

For example you'd think that the BSD license would be entirely
unobjectionable.  But Facebook released a lot of code under BSD with a
patent license that many objected to.  (They eventually adjusted
course on that patent license, though there is still objectionable
stuff in there.  See
http://www.infoworld.com/article/2908879/open-source-software/facebook-gives-in-on-patent-grant.html
for a quick summary.)

The more easily that you want people to be able to accept what you
produce, the harder you have to be careful about what you consume.

On Wed, May 27, 2015 at 11:17 AM, Lawrence Rosen  wrote:
> Nigel, your answer echoes many others:
>
>
>
>> If I have to start checking every Apache package for GPL code I’ll have to
>
>> strongly recommend that we approach all Apache packages with caution.
>
>
>
> If we amended the proposal to leave out the GPL licenses, would that calm
> your concerns?
>
>
>
> I'd really hate to do that at Apache for that set of generous FOSS licenses,
> but fear is fear Apache didn't cause this fear of "infection" and Apache
> can't cure it. There is a group of attorneys that is drafting an appropriate
> "exception" that would allow at least some GPL software to be aggregated
> with Apache software.
>
>
>
> But are ALL other OSI-approved licenses OK with you?
>
>
>
> /Larry
>
>
>
>
>
> From: Tzeng, Nigel H. [mailto:nigel.tz...@jhuapl.edu]
> Sent: Wednesday, May 27, 2015 9:42 AM
> To: memb...@apache.org; lro...@rosenlaw.com; 'License Discuss'
> Subject: Re: [License-discuss] Proposal: Apache Third Party License Policy
>
>
>
> Thanks, without the context it was somewhat harder to follow on
> license-discuss.
>
>
>
> Consider this a vote in the negative as a non-member user of Apache
> software. If I have to start checking every Apache package for GPL code I’ll
> have to strongly recommend that we approach all Apache packages with
> caution.
>
>
>
> Becoming a “universal acceptor” significantly impacts your ability to be a
> “universal donor”.  I have no desire to accidentally be the cause of any
> organization I work for becoming the test case for what is an aggregation vs
> what is a derivative.  If Apache was willing to indemnify downstream
> users…yah, I didn’t think so.
>
>
>
> Nice try though.
>
>
>
> From: "lro...@rosenlaw.com" 
> Reply-To: "memb...@apache.org" , "lro...@rosenlaw.com"
> , License Discuss 
> Date: Tuesday, May 26, 2015 at 10:16 PM
> To: License Discuss 
> Subject: [License-discuss] Proposal: Apache Third Party License Policy
>
>
>
> [This has been a hellishly long thread on private Apache lists before the
> board cut off discussion on revised policies. Below was the short start of
> it I submitted over two weeks ago. Apache board members don't want to revise
> current policy. Many Apache members don't want it. Still, it is a serious
> proposal to bring some more freedom and cooperation to open source. Please
> treat this as a political document for license-discuss@. /Larry]
>
>
>
> …
>
>
> ___
> 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] Proposal: Apache Third Party License Policy

[Ben Tilly]

To be fair, the responses that I have seen involving Apache involved
independent analyses that came to the same conclusion that I did, and
did not reference my comment.  Furthermore my email there bounced
(which is why I just took them off the CC list), so they probably did
not see it.

Now on to the OSD.  The OSD was unfortunately not written by a lawyer,
and can be parsed ambiguously in many ways.  So you often have to go
back to intent to figure out which way it should be parsed.

My understanding is that the original version of item #1 is that third
parties are not restricted from giving away or selling the software
without paying royalties or any fee.  The awkward wording around
aggregation was added so that
http://opensource.org/licenses/artistic-license-1.0 could be declared
open source despite section 5 which only allowed it to be sold as part
of an aggregation.  Furthermore there is no question that Bruce Perens
was aware of section 2 of http://www.gnu.org/licenses/gpl-2.0.html and
intended the GPL v2 to be open source.

Given that, here is how I read, "The license shall not restrict any
party from selling or giving away the software as a component of an
aggregate software distribution containing programs from several
different sources. The license shall not require a royalty or other
fee for such sale."

I read it as saying that when you distribute, you are free to charge
or not as you wish, and you owe no royalty or fee regardless of what
you choose.  However there is a distinction between "AN aggregate" and
"ANY aggregate".  Some aggregates are not allowed to be distributed.
Another similar hair to split is that the manner in which it is sold
can matter.  For example it is OK to sell it in a box, but is not
necessarily OK to put the name of the author of the software on said
box.  (A number of open source licenses have advertising
restrictions.)

That said, I completely agree that it is possible to parse that
section in a way that the *GPL v* family of licenses will fail.  But
this is not the only way in with the OSD fails to be a legal document.

On Thu, May 21, 2015 at 8:51 AM, Lawrence Rosen  wrote:
> Ben Tilly quoted OSD #1 [Free Redistribution]
> "The license shall not restrict any party from selling or giving away the 
> software as a component of an aggregate software distribution containing 
> programs from several different sources. The license shall not require a 
> royalty or other fee for such sale."
>
> He then added this: "But not all aggregations are created equal." And now 
> some at Apache are treating Ben Tilly's added statement as important for 
> analysis of aggregations containing FOSS software.
>
> How do "unequal aggregations" affect OSD #1?
>
> I'm expressly NOT speaking of derivative works.! I used the word 
> "aggregation" on purpose.
>
> /Larry
>
>
> -Original Message-
> From: Ben Tilly [mailto:bti...@gmail.com]
> Sent: Wednesday, May 20, 2015 2:07 PM
> To: Lawrence Rosen; License Discuss
> Cc: Legal Discuss; European Legal Network
> Subject: Re: [License-discuss] Proposal: Apache Third Party License Policy
>
> The first item in the Open Source Definition seems to address this.
>
> 1. Free Redistribution
>
> The license shall not restrict any party from selling or giving away the 
> software as a component of an aggregate software distribution containing 
> programs from several different sources. The license shall not require a 
> royalty or other fee for such sale.
>
> Therefore you would think that all open source software should be OK to 
> distribute in an aggregation.
>
> But not all aggregations are created equal.  Licenses in the GPL family 
> distinguish between things that have simply been aggregated together, versus 
> things that are meant to be used as part of a combined work.  Therefore if 
> you, for instance, shipped an Apache 1.1 licensed program from one source 
> together with a GPLed library from another source that the program won't run 
> without, then you're in violation of the GPL.
>
> So if you're aggregating open source programs that do different things and do 
> not rely on each other, then open source software licenses should be fine.  
> But there are some potential gotchas.
>
> On Wed, May 20, 2015 at 1:40 PM, Lawrence Rosen  wrote:
>> Apache Legal JIRA-218 asked:
>>>> My question is about whether "Eclipse Public License -v 1.0"
>>>> is compatible with our Apache License 2.0.
>>>> I couldn't find an answer on https://www.apache.org/legal/resolved.html.
>>
>> Larry Rosen suggested:
>>> The obvious answer we could state in a short FAQ: "Of course. All
>>> FOSS licenses are compatible for aggregations.

Re: [License-discuss] Proposal: Apache Third Party License Policy

[Ben Tilly]

The first item in the Open Source Definition seems to address this.

1. Free Redistribution

The license shall not restrict any party from selling or giving away
the software as a component of an aggregate software distribution
containing programs from several different sources. The license shall
not require a royalty or other fee for such sale.

Therefore you would think that all open source software should be OK
to distribute in an aggregation.

But not all aggregations are created equal.  Licenses in the GPL
family distinguish between things that have simply been aggregated
together, versus things that are meant to be used as part of a
combined work.  Therefore if you, for instance, shipped an Apache 1.1
licensed program from one source together with a GPLed library from
another source that the program won't run without, then you're in
violation of the GPL.

So if you're aggregating open source programs that do different things
and do not rely on each other, then open source software licenses
should be fine.  But there are some potential gotchas.

On Wed, May 20, 2015 at 1:40 PM, Lawrence Rosen  wrote:
> Apache Legal JIRA-218 asked:
>>> My question is about whether "Eclipse Public License -v 1.0"
>>> is compatible with our Apache License 2.0.
>>> I couldn't find an answer on https://www.apache.org/legal/resolved.html.
>
> Larry Rosen suggested:
>> The obvious answer we could state in a short FAQ: "Of course. All FOSS 
>> licenses
>> are compatible for aggregations.”
>
> Ralph Goers then responded:
>> The fundamental problem here is that it seems that most of the rest of us
>> disagree completely with this statement. I know I do. Yes, I am not an 
>> attorney,
>> but I don’t need to be to express that the many conversations I have had
>> with attorneys for the companies I have worked for and that their (possibly
>> incorrect) opinions are the reason why we would prefer to be overly 
>> conservative.
>
> Thank you Ralph!
>
> That is EXACTLY the reason why we moved this conversation to 
> legal-disc...@apache.org, which is a public email list that anyone can read 
> and copy. I'm now also copying license-discuss@opensource.org and the 
> European Legal Network .  I'm hoping for responses 
> from attorneys. I'm fully prepared to ride my horse into the sunset if other 
> attorneys tell me I'm inventing copyright law.
>
> I will lend my horses to others to ride into the sunset if (PLEASE!) 
> attorneys say something supportive.
>
> /Larry
>
>
> -Original Message-
> From: Ralph Goers [mailto:ralph.go...@dslextreme.com]
> Sent: Wednesday, May 20, 2015 1:18 PM
> To: Legal Discuss; Lawrence Rosen
> Subject: Re: Proposal: Apache Third Party License Policy
> 
>
>
> ___
> 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] Strong and weak copyleft

[Ben Tilly]

I believe that the legal key is distribution of the licensed code, not
linking to it.

The LGPL defines a "Combined Work" and has requirements on what is
required when you distribute a combined work together.  The intent is
clearly that if you distribute the combined work together and DO NOT
meet those conditions, then you had no permission to distribute the
LGPLed code.  And this has force because while the proprietary half of
a combined work is not a derived work, you still need permission to
distribute some else's copyrighted code and that permission was
contingent on what you did with your application.

The GPL defines a covered work to be, "either the unmodified Program
or a work based on the Program."  Later in the license a distinction
is drawn between that and "mere aggregation".  The intent is that
distributing your program + the covered GPLed code it depends on
creates a work and you need GPL permission to have distributed the
covered GPLed code.  (Whether a judge will agree with this
interpretation is another question, but I'm pretty sure that the
license drafters intended a judge to understand it this way.)

With that said, the LGPL gives a lot of license flexibility for your
part of the combined work but says you must allow reverse engineering.
Which by default is allowed in many places, but is something that many
proprietary licenses take away.  By contrast the GPL offers no real
alternative but to license the code you own under the GPL.  Therefore
LGPLed code keeps itself copylefted but does not encourage developers
to GPL their own code.  While GPLed code pushes people who want to use
that code to have to GPL the code that they wrote.

On Tue, Apr 7, 2015 at 10:23 AM, Lawrence Rosen  wrote:
> Patrice-Emmanuel Schmitz referred me to this thought-provoking link:
>
>
>
> https://joinup.ec.europa.eu/community/eupl/news/meaning-%E2%80%9Ccopyleft%E2%80%9D-eupl
>
>
>
> Can anyone here precisely identify the language in the GPL licenses that
> makes it "strong" rather than "weak" copyleft? And can anyone here identify
> anything in copyright law or cases that allow this distinction in the
> meaning of "derivative work"?
>
>
>
> /Larry
>
>
>
>
> ___
> 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] Shortest copyleft licence

[Ben Tilly]

What does copyleft mean?

The purpose of a copyleft provision in my mind is to make it so that
changes get contributed back.  While it is clear that the Sleepycat
license attempts to do so, it does not stop source being available for
a nominal fee under an additional copyright license chosen by the
contributor.  If that license happens to be the GPL, well OK.  But
Sleepycat can't use that code without changing their license.  If that
license happens to be something preventing further modification and
redistribution, then you've lost the whole point of copyleft.

Nailing down copyleft and making it actually work is surprisingly
tricky.  That is one reason why careful copyleft licenses are so
verbose.

On Mon, Mar 30, 2015 at 7:24 AM,   wrote:
> Maxthon Chan scripsit:
>
>> Is it favorable to add a copy left clause into 2BSDL to make it copyleft?
>> "You must provide the source code, in its human-preferred format, with
>> this work or any derivatives of this work you created when
>> redistributing."
>
> That's pretty much what the Sleepycat license does.  Here's a very lightly
> edited version of its additional clause:
>
> Redistributions in any form must be accompanied by information
> on how to obtain complete source code for the licensed software
> and any accompanying software that uses the licensed software.
> The source code must either be included in the distribution
> or be available for no more than the cost of distribution
> plus a nominal fee, and must be freely redistributable under
> reasonable conditions. For an executable file, complete source
> code means the source code for all modules it contains.
> It does not include source code for modules or files that
> typically accompany the major components of the operating
> system on which the executable file runs.
>
> The restrictions pretty much match those of the GPL2.
> The Sleepycat license itself is redundant and non-templatized,
> so it can't be reused directly.  If someone felt like
> proposing something like 2-clause BSD + the above, I for one would
> welcome it.  Unlike the GPL, this does not create a new and
> distinct software commons.
>
> --
> John Cowan  http://www.ccil.org/~cowanco...@ccil.org
> Police in many lands are now complaining that local arrestees are insisting
> on having their Miranda rights read to them, just like perps in American TV
> cop shows.  When it's explained to them that they are in a different country,
> where those rights do not exist, they become outraged.  --Neal Stephenson
>
>
> ___
> 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] Software, licenses, and patents

[Ben Tilly]

If the facts are what I guessed, then the Alice v. CLS Bank decision
last year would make that point.  But the United States Court of
Appeals for the Federal Circuit has a history of creatively
interpreting Supreme Court decisions to expand what is patentable.  So
it is not certain that the pendulum will not swing back before anyone
tests this particular patent.

Furthermore we don't have all of the facts.  It may be that the patent
describes a creative way to apply known mathematical techniques in a
clever way to a problem that had long been poorly solved in a very
different way.  In that case, a court could decide that the fact that
the mathematical techniques happened to have been known by people in
another field is not a bar to patentability in this one.  (See
http://en.wikipedia.org/wiki/Inventive_step_and_non-obviousness#Graham_factors
for the relevant test.)

On Thu, Mar 12, 2015 at 4:59 PM, ChanMaxthon  wrote:
> Just wondering, since decades if not centuries ago a prior art already stood 
> there, why would the patent still be relevant in the first place? If the 
> hostile IP cockroach is biting you can show the court those prior art, either 
> proving that their patents have nothing to do with your code, or just shoot 
> their patents down completely.
>
> No lawyer, just trying to give my two cents.
>
> Sent from my iPhone
>
>> On Mar 13, 2015, at 06:49, Ben Tilly  wrote:
>>
>> I think I can unconfuse you. :-)
>>
>> The developer knows of an applicable patent, but believes the
>> following set of statements to be true.
>>
>> 1. The new software does not infringe.
>>
>> 2. The patent holder might believe otherwise.
>>
>> 3. Said patent may have been granted on the basis of work the
>> developer did many years ago.
>>
>> 4. The algorithms used have at least 3 decades of prior art behind
>> them.  Just not decades of prior art in software.
>>
>> My further impression is that there is considerable history between
>> the developer and the patent holder.  Likely there is some bad blood.
>> The developer is unhappy that the patent exists, and thinks it
>> shouldn't.
>>
>> If my impression is correct, the developer is an interested party in
>> an ongoing conflict.  Therefore the developer's opinion on
>> infringement is biased and is therefore not to be trusted.  I
>> therefore suggest that the developer should discuss the situation with
>> a neutral lawyer, and follow that lawyer's advice.
>>
>> (None of us like being accused of incorrectly evaluating the
>> situation.  But having recently been through a divorce, I'm painfully
>> aware of how my judgement of certain situations was different during
>> the conflict than it is now...)
>>
>>> On Thu, Mar 12, 2015 at 2:48 PM, Lawrence Rosen  wrote:
>>> Jonathon,
>>>
>>> This double-negative in your email leaves me confused: "This isn't a case 
>>> of where the developer is unaware of possible patents."
>>>
>>> In many situations, such as in Apache and W3C, a contributor has an 
>>> obligation to the community to disclose what he or she knows. Secrets serve 
>>> nobody. Disclose what you know. No negatives.
>>>
>>> AS-IS and NO WARRANTY with respect to patents would then be appropriate.
>>>
>>> /Larry
>>>
>>>
>>> -Original Message-
>>> From: jonathon [mailto:jonathon.bl...@gmail.com]
>>> Sent: Thursday, March 12, 2015 1:53 PM
>>> To: license-discuss@opensource.org
>>> Subject: [License-discuss] Software, licenses, and patents
>>>
>>> All:
>>>
>>> Need some help.
>>>
>>> Software was privately created.
>>> Developer wants to release under the GNU GPL 3.0.
>>> If you want to change the license, for your comments, do so.
>>>
>>> Issue:
>>> Developer is using systems, methods, and techniques that were described in 
>>> the literature more than three decades ago (in some instances 400 years 
>>> ago), except instead of using pen and paper, they are using software.
>>>
>>> As best as can be determined, there are no patent issues with any libraries 
>>> that are used.
>>>
>>> As best as can be determined, there are no copyright/license issues with 
>>> any of the libraries that are used.
>>>
>>> Developer is not going to be responsible for claims of patent infringement 
>>> by users.
>>>
>>> Developer is not going to cover any court costs incurred by users, because 
>>> of patent related litigati

Re: [License-discuss] Software, licenses, and patents

[Ben Tilly]

I think I can unconfuse you. :-)

The developer knows of an applicable patent, but believes the
following set of statements to be true.

1. The new software does not infringe.

2. The patent holder might believe otherwise.

3. Said patent may have been granted on the basis of work the
developer did many years ago.

4. The algorithms used have at least 3 decades of prior art behind
them.  Just not decades of prior art in software.

My further impression is that there is considerable history between
the developer and the patent holder.  Likely there is some bad blood.
The developer is unhappy that the patent exists, and thinks it
shouldn't.

If my impression is correct, the developer is an interested party in
an ongoing conflict.  Therefore the developer's opinion on
infringement is biased and is therefore not to be trusted.  I
therefore suggest that the developer should discuss the situation with
a neutral lawyer, and follow that lawyer's advice.

(None of us like being accused of incorrectly evaluating the
situation.  But having recently been through a divorce, I'm painfully
aware of how my judgement of certain situations was different during
the conflict than it is now...)

On Thu, Mar 12, 2015 at 2:48 PM, Lawrence Rosen  wrote:
> Jonathon,
>
> This double-negative in your email leaves me confused: "This isn't a case of 
> where the developer is unaware of possible patents."
>
> In many situations, such as in Apache and W3C, a contributor has an 
> obligation to the community to disclose what he or she knows. Secrets serve 
> nobody. Disclose what you know. No negatives.
>
> AS-IS and NO WARRANTY with respect to patents would then be appropriate.
>
> /Larry
>
>
> -Original Message-
> From: jonathon [mailto:jonathon.bl...@gmail.com]
> Sent: Thursday, March 12, 2015 1:53 PM
> To: license-discuss@opensource.org
> Subject: [License-discuss] Software, licenses, and patents
>
> All:
>
> Need some help.
>
> Software was privately created.
> Developer wants to release under the GNU GPL 3.0.
> If you want to change the license, for your comments, do so.
>
> Issue:
> Developer is using systems, methods, and techniques that were described in 
> the literature more than three decades ago (in some instances 400 years ago), 
> except instead of using pen and paper, they are using software.
>
> As best as can be determined, there are no patent issues with any libraries 
> that are used.
>
> As best as can be determined, there are no copyright/license issues with any 
> of the libraries that are used.
>
> Developer is not going to be responsible for claims of patent infringement by 
> users.
>
> Developer is not going to cover any court costs incurred by users, because of 
> patent related litigation, or threats of such litigation.
>
> Developer is emphatically not going to pay for the right to utilize any 
> patents within the software.
>
> Content created by the developer years before the patents were applied for, 
> might have been the source of any patents that were granted.
>
>
> Question:
> Should developer make any notation about possible patents that the software 
> _might_ infringe upon?
>
> This isn't a case of where the developer is unaware of possible patents.
> Nor is it a case of where the developer holds any patents.
>
>
> jonathon
>
>
> ___
> 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] [FTF-Legal] Reverse Engineering and Open Source Licenses

[Ben Tilly]

I will respond inline this time because the conversation got complicated.

On Mon, Mar 9, 2015 at 9:18 AM, Reincke, Karsten  wrote:
> Many thanks for your detailed description. Indeed, I am sorry that we are 
> reciprocally frustrated with us.
> But I do not want to give up. Let me first summarize – what we both accept 
> (even if I until did not talk
> about it):
>
> The LGPL-v2 has been invented for strategic reasons. No doubt. This directly 
> follows from the
> preamble. Licensing a library under the LGPL-v2 shall aim “[…] to encourage 
> the widest possible use
> of a certain library, so that it becomes a de-facto standard”. Or the “[…] 
> permission to use a particular
> library in non-free programs enables a greater number of people to use a 
> large body of free software.”
> But “although the Lesser General Public License is Less protective of the 
> users' freedom, it does
> ensure that the user of a program that is linked with the Library has the 
> freedom and the wherewithal
> to run that program using a modified version of the Library”.
> That’s the base for the spirit, that in [many|all] cases reverse engineering 
> of the work using the library
> must be allowed.

Exactly.

> We are divided over configuring the parameter [many|all]. You say: The 
> LGPL-v2 say ‘all’; I say, the
> license text say ‘many’. More exactly: I say in case of separately 
> distributing a dynamic linkable
> application [which is not linked], the LGPL-v2 license text (sic!) does not 
> require to permit reverse
> engineering. You have vetoed.

We have different understandings of where the disagreement is.

Your paper indicates that dynamic linking gets you out of trouble.  I
am saying that if you distribute
both library and application together, dynamic linking does not get
you out of trouble.

I have not said all.  Specifically, I have pointed out that it is
permissible to distribute a dynamic linkable
application if at no point do you distribute the library.  However I
claim that distributing said application
and library together triggers the copyright license provisions.  Your
paper said that it doesn't.  Do you
agree with me that it doesn't in that case?

As for separate distribution, I don't consider that guaranteed wrong.
I think it is a grey area.  If you
distribute the application, and the library happens to be in an
archive that you maintain a mirror of,
I think you should be OK.  If you've got a script that downloads and
installs both in 2 separate http
requests, I don't see that the technicality should make it any
different than distributing together.  In
between there are a million shades of grey.  And I don't know where
the line should be.

> You are arguing for you position by correctly quoting a passage of the 
> preamble and then you
> refer to the FAQ and finally you conclude “The drafters explained, both in 
> the license and in their
> FAQ, that they intended to cover dynamic linking”. With all due respect, I 
> cannot follow this way of
> concluding, based on two reasons:

Really?  Section 6 says "combine or link" and the preamble defines a
"combined work".  From this
you refuse to conclude that a combined work that uses dynamic linking
is subject to the provisions
of section 6?

What more would it take for you to conclude that?

> 1) You are quoting the preamble together with its hint that the “ General 
> Public License therefore
> permits such linking only if the entire combination fits its criteria of 
> freedom”. But you cannot
> conclude from this requirement of the GPL to maintain the freedom to the 
> intended meaning, that
> the LGPL-v2 requires to permit reverse engineering. The text you quoted 
> explicitly says, that the
> “Lesser General Public License permits more lax criteria for linking other 
> code with the library.”

The "more lax criteria" is that you do not have to GPL your code.  It
is not that dynamic linking is OK.

Your argument here is of the form, "They meant to be permissive, so
they must be willing to let me
have that cookie as well!"  But in fact the preamble defines a
combined work.  And section 6 on
reverse engineering says "combine or link".  The only reasonable way
to read that is to believe
that creating a combined work by using dynamic linking is meant to
trigger the reverse engineering
permission.

> You argumentation ignores that the LGPL-v2 explicitly speaks of a work 
> containing portions of the
> library (§6) and that it additionally states, that up to specific sizes of 
> portions “the use of the object
> file [containing these portions] is unrestricted [sic!!!], regardless of 
> whether it is legally a derivative
> work[sic!!!]” (§5).

I believe that the explicit section reflected the drafter's
understanding of what was legal.  But they
wanted it explicit so as not to accidentally discourage allowed usage.

> 2) But additionally, so you are arguing, the “[…] the drafters explained, 
> both in the license and in
> their FAQ, that they intended to cover dyn

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

[Ben Tilly]

use free software 
> compliantly. Let me explain, how your obstruction comes into being:
>
> You delivered a summary classified as “the intended interpretation of the 
> drafters”:
>
>>  If you distribute
>>  code that dynamically links to an LGPL library that is already
>>  present, you have not created a Combined Work.  On the other hand if
>>  you distribute the library you will dynamically link to with your
>>  code, you *have* created a Combined Work.  There is a grey area where
>>  you distribute both, but not at the same time.
>
> The meaning(sic!) of this summary perfectly fits the conclusion of my – as 
> you named it - “[…] try to reason […] out from the first principles”:
>
> Following a strict analyses of the (LGPL-v2) licenses text itself, 
> particularly of its §6, one gets a simple logical based rule:
>
> 'If you compliantly distribute a work containing portions of the 
> Library, then you have to allow reverse engineering.'
>
> Applying Modus Ponens onto this rule, from the fact, that you distribute a 
> work containing portions of the Library compliantly, it directly and 
> imperatively follows, that you have to allow reverse engineering. Applying 
> Modus Tollens onto this rule, from the fact, that you do not allow reverse 
> engineering, directly and imperatively follows, that you do not compliantly 
> distribute the work containing portions of the Library.
>
> The only open question for applying this rule in praxis is, what a work shall 
> be, that contains portions of the Library. Fortunately, §5 of LGPL v2 
> delivers clear limits up to which sizes "the object file" of a "work using 
> the library " which contains portions of the library "[...] is unrestricted, 
> regardless of whether it is legally a derivative work".
>
> So, the result of my – as you named it - “try to reason […] out from the 
> first principles” is very similar to your summary: as long as you distribute 
> an object file of the work using the library which contains less elements 
> than the defined limits you are not obliged to allow reverse engineering, in 
> all other cases you are. (For details an sub problems and conditions please 
> see my complete text).
>
> Why do I only say ‘very similar’ instead of ‘equal’. The problem with your 
> summary is this: you do not talk about the license text! Your term “combined 
> work” DOES NOT OCOUR in §6 of LGPL-v2. And this §6 is the only part of the 
> license trying to regulate a necessary permission of reverse engineering. 
> Unfortunately, you also do not link (derive) you paraphrase to (from) the 
> license text. But without using the license text itself or strictly derived 
> paraphrases of the license text, you are talking about your personal opinion. 
> Or about the opinion of a group. This might be important. You might be 
> important. But, we want the users of free software to respect the complete 
> licenses, not the opinions of others concerning these licenses. So, for 
> acting compliantly, there is one central rule: The license text first!!!
>
> Thus, I cannot take your summary and implement a mandatory rule into our 
> company by pointing out “Oh, in the community, there is the famous and well 
> respected Mr. Ben Tilly who says, that if we do not distribute a combined 
> work, than we need not to allow reverse engineering”. Everyone will directly 
> ask me “Nice to hear from Mr. Tilly. But, please show me the corresponding 
> line in the license text itself. Or deliver me at least a step by step 
> analysis which derives this Tilly rule”. You see? There is a gap. The LGPL 
> does not talk about combined works in the context of reverse engineering, 
> neither directly, nor indirectly. Thus your summary does not help, to 
> convince others, even if I fully agree with its' content.
>
> Therefore, your answer is impeding my personal task and – as far as I can see 
> - the wish of FSF to encourage and enable people and companies to use free 
> software compliantly. Although our intended result is the same, you tries to 
> discredit my complex analysis. This analysis is so complex, because it indeed 
> starts by the first principles: the licenses text itself. But speaking about 
> that issue with founding the statements on the license text itself, does not 
> help.
>
> What could you have done instead of this? For example, you could simply have 
> answered:
>
> “Oh my god! What a large document!! More than 20 pages for explaining 
> one sentence!!! But indeed, this document delivers the missing link between 
> the license text itself and the well known more generically formulated 
> position of the FSF. And it delivers this link by reasoning the issue out

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

[Ben Tilly]

Actually there is an excellent reason why distribution is key here.

The LGPL is a copyright license.  Its reasoning is based on the idea
that if you do something otherwise forbidden by copyright, then you're
forced to either follow the license, or be sued for copyright
violation.  But this only works if you do something otherwise
forbidden by copyright.  Receiving a copy of a library is not
forbidden.  Current US precedent says that an API is not covered by
copyright, and therefore programming to the API is allowed.  (There is
a lawsuit between Oracle and Google that potentially could change
this.)  And precedent exists saying that the virtual copy in RAM from
dynamic linking is allowed.  But distribution is covered by copyright
law.

Therefore if you are writing and distributing an application which is
meant to be dynamically linked to an LGPL library, the *only* thing
you typically do which requires copyright permission is to distribute
the library.  No matter what the library author may think of your
actions, until you distribute the library, you do not require
permission.  But once you have, then we're into the question of
whether your actions fell within the permission granted by the license
or not.  And if you and the author of the library cannot reach
agreement, then the disagreement will need to be settled by a court.
Which could rule either way.

So if you want to be cautious, here is what you do.  Do not distribute
*GPL software unless you intend to comply with the author's
understanding of their license.  Which frequently will match the FSF's
understanding.  And they've written a FAQ explaining what that is.  So
play it safe according to that FAQ, and you should be fine.

This is all, of course, according to my understanding of US law.  I
have no idea how different the situation may be in other countries.
And I still am not a lawyer. :-)

On Thu, Mar 5, 2015 at 1:09 AM, Wiedemann, Claus-Peter
 wrote:
>> -Ursprüngliche Nachricht-
>> Von: Ben Tilly [mailto:bti...@gmail.com]
>> Gesendet: Donnerstag, 5. März 2015 03:51
>> An: License Discuss
>> Cc: ftf-le...@fsfeurope.org; karen.copenha...@gmail.com;
>> arm...@tjaldur.nl; Wiedemann, Claus-Peter; Schwegler, Robert
>> Betreff: Re: [License-discuss] Reverse Engineering and Open Source Licenses
>>
> [...]
>>
>> The intended interpretation of the drafters is made clear at
>> https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic.  They
>> distinguish by how the software is distributed.  If you distribute code that
>> dynamically links to an LGPL library that is already present, you have not
>> created a Combined Work.  On the other hand if you distribute the library
>> you will dynamically link to with your code, you *have* created a Combined
>> Work.  There is a grey area where you distribute both, but not at the same
>> time.  My suspicion is that they would at that point distinguish based on
>> whether or not you intend to link them.
>
> I don't think it makes a difference wrt to the "Combined Work" aspect. The 
> fact  that a "Combined Work" or better a "work that uses the Library" is 
> created is independent from the  specific way of distribution. It does not 
> matter if you distribute the library together with the program, or not. If 
> the program needs it to run, it is a "work that uses the Library". Some 
> people think they can "evade" the LGPL obligations for the program (e.g. 
> permit reverse engineering) by not distributing the library. I don't think 
> that works. The reason why the FAQ makes a distinction here is simple. If the 
> library is already present on the user's computer, then one can assume that 
> the user is already in possession of the corresponding source code (which 
> must have been provided earlier together the library).  In this case there is 
> no obligation to provide the source code again. In LGPL V2.1, this is made 
> explicit in section 6e)
> e) Verify that the user has already received a copy of these materials or 
> that you have already sent this user a copy.
>
> Best regards
> Claus-Peter (not a lawyer, either)
>
> 
>  BearingPoint GmbH
> Geschäftsführer: Marcel Nickler (Vorsitzender), Hans-Werner Wurzel (stellv. 
> Vorsitzender), Kiumars Hamidian, Matthias Loebich, Kai Wächter, Dr. Robert 
> Wagner
> Vorsitzender des Aufsichtsrats: Beat Leimbacher
> Sitz: Frankfurt am Main
> Registergericht: Amtsgericht Frankfurt am Main HRB 55490
>
>
> The information in this email is confidential and may be legally privileged. 
> If you are not the intended recipient of this message, any review, 
> disclosure, copying, distribution, re

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

[Ben Tilly]

Sorry, but this is a ridiculously heavyweight way of thinking about
things.  The problem with thinking in a heavyweight fashion is that it
is easy to lose track of what is going on, and hard for anyone else to
wade through it and point out the error.  However I'll try.

On page 6 you are arguing for a specific interpretation based on your
claim that an alternate one would not achieve the aims of the drafters
of the LGPL.  But you set up a false dichotomy.  There are other
possible interpretations that you have not considered.  And rather
than trying to reason it out from first principles, it is better to
just ask the source.

The intended interpretation of the drafters is made clear at
https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic.  They
distinguish by how the software is distributed.  If you distribute
code that dynamically links to an LGPL library that is already
present, you have not created a Combined Work.  On the other hand if
you distribute the library you will dynamically link to with your
code, you *have* created a Combined Work.  There is a grey area where
you distribute both, but not at the same time.  My suspicion is that
they would at that point distinguish based on whether or not you
intend to link them.

Before you argue against this interpretation, I remind you that your
argument on page 6 rests on the expertise of the drafters of the
license.  In your words, "We know that the inventors of the GNU
licenses and GNU software are very sophisticated experts."  But if you
accept them as experts, you are in no position to argue about what
they say about how their own license is supposed to be interpreted.

For the record, I am not a lawyer.  This is not legal advice.  And in
common law countries, until a legal precedent is set, there is no way
to tell whether the courts will interpret the license in the way that
the drafters hope they will.

On Wed, Mar 4, 2015 at 7:16 AM, Reincke, Karsten  wrote:
> Dear Colleagues;
>
>
>
> In the past I was involved in some full discussions concerning the issue
> ‘reverse engineering and open source licenses’. Although personally
> esteeming and inspiring, such discussions sometimes became a bit explosive:
> If – at least – the LGPL-v2 indeed requires to allow the reverse engineering
> of those programs which use LGPL-v2 licensed components, then companies are
> not able to protect these ‘private’ programs against revealing the embedded
> business relevant secrets, even if they do not distribute the corresponding
> source code. And – as far as I know – at least some companies have therefore
> forbidden to link essential programs against the LGPL-v2.
>
>
>
> I have taken the view that this ‘rule of reverse engineering’ cannot be
> applied  in case of distributing dynamically linkable programs. By arguing
> that way,  I caused astonishment and dissents. But often, I was also asked
> to note down my argumentation, because some of my partners wanted to review
> it in detail.  They had the hope to get a solution for conflict of using
> open source software compliantly and protecting their business relevant
> software.
>
>
>
> During the last two month, I had the pleasure to fulfill this request by
> writing the corresponding article. Now, I am indeed sure that all important
> open source licenses including the LGPL-v2 allow reverse engineering only in
> case of distributing statically linked programs. Moreover: I am definitely
> sure, that none of these open source licenses requires to allow reverse
> engineering in case of distributing dynamically linkable programs and that
> particularly even the LGPL-v2 does not require reverse engineering in case
> of distributing dynamically linkable programs.
>
>
>
> Unfortunately, the deduction of this position had to become more complex
> than initially thought. But fortunately, it could preserve a
> straight-forward argumentation: After having started with a linguistic
> disambiguation and transposing the license statements into a logical
> formula, it derives the results by using logic ways of inferring a
> conclusion. And this method is applied for the LGPL-v2, for the LGPL-v3, and
> for the other most important open source licenses. Hence, for now, I – for
> myself - am indeed sure, that my argumentation is valid and mandatory.
>
>
>
> But subjective certainty is not enough. As long as we do not have a legal
> decision, the best way to become sure is to invoke a discussion (and a
> consensus) by publishing the results. For that purpose, we decided, not only
> to insert the analysis into the OSLiC, but to distribute that chapter also
> as an autonomous article
> (http://opensource.telekom.net/oslic/en/planning/results.html ). Thus, it is
> also licensed under the der CC-BY-SA-3.0. So, feel free to use it, to modify
> it, and/or to share it. The sources of the pdf are part of the OSLiC
> repository (https://github.com/dtag-dbu/oslic/ ).
>
>
>
> We, Deutsche Telekom AG and I, Karsten Reincke, are indeed hopin

Re: [License-discuss] FAQ entry on CLAs

[Ben Tilly]

On Tue, Jan 20, 2015 at 12:09 PM,   wrote:
> Allison Randal scripsit:
>
>> If you want specific examples, I'd say GPL and Apache both work fine
>> with inbound=outbound. GPL takes a position close to compelling
>> inbound=outbound. Apache 2.0 was specifically designed with
>> inbound=outbound in mind, you can see fingerprints of it all over the
>> text.
>
> I cannot imagine any open source license (other than un-templated ones with
> hard-coded licensors) that *cannot* work as an inbound license.  Does
> anyone have counterexamples?

Here is a simple example.

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 totally support campaigning for inbound=outbound and DCO,
>
> What does DCO mean in this context?
>
> --
> John Cowan  http://www.ccil.org/~cowanco...@ccil.org
> Mr. Henry James writes fiction as if it were a painful duty.  --Oscar Wilde
>
>
> ___
> 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] Fwd: [Osi] [General enquiries] Type of License and Keylock

[Ben Tilly]

Giorgio clearly is confusing "open source" and "non-commercial".  The point
of open source is that when you get it, you are free to use pretty much
however you want.  Including commercially.  So any "personal use only"
software is not open source.

See http://opensource.org/osd-annotated for details.


On Thu, Jul 10, 2014 at 2:32 PM, Patrick Masson 
wrote:

>  I'm not sure if anyone got back to Giorgio on this. I am sure he would
> appreciate this group's thoughts.
>
> Thanks,
> Patrick
>
>
>  Original Message   Subject: [Osi] [General enquiries]
> Type of License and Keylock  Date: Tue, 27 May 2014 19:35:13 + (UTC)  
> From:
> gior...@sommaruga.org  To: o...@opensource.org
>
> Giorgio Sommaruga (gior...@sommaruga.org) sent a message using the contact
> form at http://opensource.org/contact.
>
> My team is developing a project in business area.
> The software is developed in two segment.
> A first segment is a basic version of software with an Open Source license,
> but we don't want to allow to modify the code and then resell it. We want to
> allow changes only for personal use.
> And second segment is based over the basic version but with other proprietary
> code, for example for more other functions or add-ons.
> We want to enable our partners to modify the software and sell it, but only
> with our authorization and acquiring the rights of the changes.
>
> Furthermore we would like to combine the software with a hardware protection,
> at least for the "business" but if possible also for the "Open" segment.
> This, at least to keep track of who is using the software.
> As an alternative for the Open segment, we would like to force the user to
> register the software in order to receive an activation code.
>
> Is this possible in the context of OSI licenses and which one?
>
> Thanks in advance.
> Sincerely
> Giorgio Sommaruga
>
> Report as 
> inappropriate:http://opensource.org/mollom/report/mollom_content/140527e8b62565508a
>
> ___
> Osi mailing 
> listOsi@opensource.orghttp://projects.opensource.org/cgi-bin/mailman/listinfo/osi
>
>
>
>
> ___
> 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] You need to pay to access AGPL3 scripts?

[Ben Tilly]

The downside of the GPL for networked programs is that someone can
receive the program, modify it to strip references to you out of the
output, improve it, and then host a competitor.  There is no legal
issue as long as they don't redistribute.

The AGPL is supposed to avoid this issue.  Because now they have to
acknowledge you, adn let you see their improvements.

On Wed, Jun 11, 2014 at 1:55 PM, David Woolley
 wrote:
> On 10/06/14 22:26, Kuno Woudt wrote:
>
>> I assume FullContentRSS has the copyright on their own software, and can
>> license it as they want.  Including selling it to you under AGPLv3,
>> while not offering a download themselves for their users.
>
>
> I find it difficult to work out why someone would use the AGPL unless there
> was an upstream AGPL constraint or the wanted the software to be free of
> charge to users of their service.
>
> The only thought I had was that it was to put competitors at a disadvantage,
> as they would have to provide free source, but that doesn't really hold
> water.
>
> As far as I can see, for someone who didn't want to maximise availability of
> the code and wasn't under an AGPL constraint from upstream it would be
> better to use the plain GPL.
>
>
> ___
> 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] FAQ entry (and potential website page?) on "why standard licenses"?

[Ben Tilly]

Apparently so.  Because if you agree with the goals of the GPL, you
should probably be using GPL v3+ rather than GPL v2+.

On Mon, Apr 28, 2014 at 1:57 PM, Richard Fontana
 wrote:
> On Mon, 28 Apr 2014 13:31:06 -0700
> Ben Tilly  wrote:
>
>> Suggested solution, can we use the word "common" instead of
>> "standard"?  And our definition of common should be something
>> relatively objective, like the top X licenses in use on github, minus
>> licenses (like the GPL v2) whose authors are pushing to replace with a
>> different license.
>
> You'd exclude the most commonly-used FLOSS license from "common"?
>
>  - RF
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] FAQ entry (and potential website page?) on "why standard licenses"?

[Ben Tilly]

On Mon, Apr 28, 2014 at 9:55 AM, Lawrence Rosen  wrote:
> John, once again you state the obvious to support an invalid argument:
>> By the same token, the GPL is a standard open-source license and the
>> Motosoto Open Source License is not, though both are equally OSI certified.
>
> Do you expect anyone to argue that the GPL isn't the most widely used
> and popular open source license (although its author might quarrel with
> the phrase "open source" much as I do to the word "standard")? I'm also
> comfortable with the suggestion that the Motosoto license is an irrelevancy
> in the software industry. If your FAQ wants to say that, do so.

Suggested solution, can we use the word "common" instead of
"standard"?  And our definition of common should be something
relatively objective, like the top X licenses in use on github, minus
licenses (like the GPL v2) whose authors are pushing to replace with a
different license.

The problem is simple.  Larry has a vested interest because he is the
author of several licenses, and makes money in helping clients find
the license that best meets their needs.

Most other people in this conversation don't particularly care whether
the license best meets the needs of the person writing software - as
software consumers they want to have a small number of licenses to
understand and deal with.  Hence there is a desire to call some of
them "standard licenses".  But when you throw the word "standard" out
there, you give the implicit notion that there is a "standard" by
which things were judged.  And standards processes are always going to
be very, very political because, by definition, they are attempting to
select approved winners and the disapproved losers will always try
(generally loudly) to influence the selection process.

However we have no standards process, no standards body, and shouldn't
be triggering that reaction lightly.

But it seems to me that "common" pushes developers in a desirable
direction, but does so subtly enough to leave Larry room for what he
does, and without triggering the "OMG, we're not following a
standard!" reaction where it is not warranted.
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] A simple, no-requirements license.

[Ben Tilly]

Why don't you feel that http://opensource.org/licenses/MIT meets this need?

On Tue, Apr 22, 2014 at 11:54 AM, Buck Golemon  wrote:
> Apologies for the previous message.
> I fat-fingered the send button before finishing my revision.
>
> ---
> There's a gap that CC0 and the Unlicense have attempted to fill, which is
> still not covered by any OSI approved license.
> Are any of you willing (and able) to attempt to fill this gap?
>
> I believe the first step would be to agree on a (short!) list of minimum
> requirements.
>
> My own requirements:
>
> 1) The license should be understandable by myself and my fellow engineers.
>* This requires brevity.
> 2) The license should have the absolute minimum of compatibility issues with
> other OSI licenses.
>* The licensee would ideally have no requirements placed on them by the
> license.
> 3) Assure both the licensee and licensor against litigation by the other (to
> the extent possible, of course).
>
> It's entirely possible that 2) and 3) cannot both be accomplished by a
> single license, but that's what I'm here to find out.
>
>
>
> I'm trying to follow up on the suggested course of action in these posts:
>  *
> http://projects.opensource.org/pipermail/license-review/2012-February/000243.html
>  *
> http://projects.opensource.org/pipermail/license-review/2012-January/47.html
>
> ___
> 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] [Osi] [General enquiries] Dual License for CC0

[Ben Tilly]

My non-lawyer mind understands it as follows.

If the PD declaration holds, then you're right.  But there can be a
legal question as to whether the PD declaration has legal force.  But
if it does hold, THEN you can use MIT.  So you're covered either way.

This seems to me to be strictly better than a straight PD declaration
which might or might not have force depending on legal jurisdiction
and legal theories that I don't know the ins and outs of.

On Tue, Apr 1, 2014 at 1:44 PM, Wilson, Andrew  wrote:
> odie5...@gmail.com writes:
>
>> Hi. I see questions about CC0 and public domain dedication pop up all
>> the time on message boards. In the FAQ, it goes through why these
>> licenses are not currently OSI approved. I was wondering if you could
>> amend the FAQ to put forth the option that developers can dual license
>> their work as e.g. both CC0 and MIT. It seems a lot of people don't
>> know about this option, and it makes for a good middle ground for
>> those that want public domain, but also want to be sure they're
>> covered by OSI's approval system.
>
> Not clear to my non-lawyer mind how these licenses could coexist, at least in 
> a legal system like the US
> where PD is recognized.  If the CC0 PD declaration is valid, how can the 
> original copyright holder
> then grant an MIT license to copyrights he/she no longer controls?
>
> In a legal system where PD is not recognized, e.g. Europe, then the effective 
> portion of CC0 is presumably not
> the PD declaration but the permissive license.  As other posters have noted, 
> that permissive license
> is not perceptibly different in effect from MIT.
>
> Andy Wilson
> Intel open source technology center
>
> ___
> 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] Illumina Open Source License

[Ben Tilly]

Put me in the nothing close to being OSI camp.

It discriminates against anyone other than Illumina, Inc who would
like to use it in gene sequencing software.  I would therefore fail it
under item 5.  A major intent of open source software is exactly that
you not discriminate in this way.

But I'm a private citizen and my interpretation is only my
interpretation.  If you're specifically interested in Debian, then go
to https://www.debian.org/legal/ and get on their mailing lists to get
their opinions.  Because that is the only one that matters.

On Wed, Mar 12, 2014 at 9:00 AM, Albert Vilella  wrote:
> Hi,
>
> I have been trying to wrap my head around the following license, and
> discussed the contents of it with colleagues. There seems to be two
> markedly opposed opinions around the license. This is, people that
> think it's OSI-compliant, and people that think it's nothing close to
> being OSI-compliant:
>
> http://github.com/sequencing/isaac_aligner/blob/master/General_Illumina_Open_Source_License_Template_1_Final.pdf?raw=true
>
> Although I don't have anything against the license itself, I am
> personally curious to see how it does when reviewed in this mailing
> list. Specifically, I would like to see if there are any impediments
> for software under this license to be packaged for Debian.
>
> Thanks in advance,
>
> Albert.
>
> Disclaimer: these thoughts and opinions are my own, and not that of my 
> employer.
> ___
> 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] dual licensing and the Open Source Definition

[Ben Tilly]

Your fundamental confusion is that you don't understand how dual
licensing works.

A license gives you a set of terms under which you are allowed to do
something that you would not be allowed to do without the license.
Dual licensing is the situation where you have a potential choice of
licenses.

All cases where you can "buy out" of a GPL license are dual licensing
situations.  The company owns the copyright to the license, and gives
you a choice of an open source license for free, or a commercial
license for money.  There is nothing in the GPL saying that you can do
this, and there is nothing you could put in the GPL saying that you
could not do this either.  The GPL is popular for this purpose because
it is both well-understood, and inconvenient for many commercial
purposes.  (So there is incentive to "purchase the upgrade" to a
commercial license.)

With that cleared up, here are the answers to your questions.

1) The GPL is perfectly fine under the OSD.

2) No license with the kind of conditions that you want would qualify
as open source.

On Thu, Dec 12, 2013 at 1:46 PM,   wrote:
> Greetings,
>
> 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.  For a possible real-life example please see the
> cygwin project, and specifically the clause concerning the project license
> (found under "Cygwin License Contract" at
> http://www.redhat.com/services/custom/cygwin/, and mentioned here for
> illustration purposes only).
>
> In light of the above, and given the guarantee of the Open Source Definition
> with respect to source availability and fields of endeavor, a couple of
> questions arise:
>
> 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.
>
> 2) Consider the case of an individual entrepreneur who created a software
> library, and who would like to require vendors of commercial products that
> _depend_ on that library to pay a _one-time fee_, but otherwise be permitted
> to use the library or distribute it in any way they see fit without
> additional charges, and provided that the original source code, along with
> all changes that were applied to it, remain available to the public.  Would
> that author be able to release his/her library under an OSI-approved
> license?  Having gone through the various licenses on the site, I was unable
> to identify a single license that adequately meets this scenario.
>
> I believe that (2) could be of interest to independent developers who either
> prefer not to, or are unable to rely on voluntary donations for the
> continuing development of their projects.  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.  Ultimately, then, the purpose of this post is to
> discuss, and hopefully find out, whether a license can be written with the
> above scenario in mind, and yet remain in compliance with the Open Source
> Definition.
>
> Looking forward to your thoughts,
> z. gilboa
>
>
> ___
> 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] Dual-Licensing (GPLv2 and Artistic License 2.0)

[Ben Tilly]

The idea of dual licensing is that the copyright owner has offered you
a choice of license terms.  Pick the one you like better.

Just make sure to follow those terms and you're fine.

(And yes, the Artistic License does let you sell binaries without source.)

On Tue, Oct 29, 2013 at 1:18 AM, Nico Diekhaus  wrote:
> Hello,
>
>
>
> I can’t find any details about dual-licensing, that helps me. I have a
> question about a source code I found and want to use for my program.
> The souce code is licensed with the GPLv2 and the Artistic License 2.0. Can
> I use the code for my program (and sell the program) without posting my
> source code on the internet?
> If it is just licensed without GPL I would say yes. Because I found the
> following in the Artistic License:
>
>
>
> „(6) You may Distribute a Modified Version in Compiled form without the
> Source, provided that you comply with Section 4 with respect to the Source
> of the Modified Version.”
>
> “(4) You may Distribute your Modified Version as Source (either gratis or
> for a Distributor Fee, and with or without a Compiled form of the Modified
> Version) provided that you clearly document how it differs from the Standard
> Version, including, but not limited to, documenting any non-standard
> features, executables, or modules, and provided that you do at least ONE of
> the following:
>
> (a) make the Modified Version available to the Copyright Holder of the
> Standard Version, under the Original License, so that the Copyright Holder
> may include your modifications in the Standard Version.
> (b) ensure that installation of your Modified Version does not prevent the
> user installing or running the Standard Version. In addition, the Modified
> Version must bear a name that is different from the name of the Standard
> Version.
> (c) allow anyone who receives a copy of the Modified Version to make the
> Source form of the Modified Version available to others under
> (i) the Original License or
> (ii) a license that permits the licensee to freely copy, modify and
> redistribute the Modified Version using the same licensing terms that apply
> to the copy that the licensee received, and requires that the Source form of
> the Modified Version, and of any works derived from it, be made freely
> available in that license fees are prohibited but Distributor Fees are
> allowed.
> Distribution of Compiled Forms of the Standard Version or Modified Versions
> without the Source”
>
>
> So did I understand this right? Can I use the code of that program if I ...
> ... 1. "clearly document how it differs from the Standard Version"
> ... 2. "(b) ensure that installation of your Modified Version does not
> prevent the user installing or running the Standard Version. In addition,
> the Modified Version must bear a name that is different from the name of the
> Standard Version."
> I hope I made my point clear and someone can help me.
> Thank you very much!
> Greetings,
> Nico Diekhaus
>
> ___
> 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] Rejected license list [was Re: TrueCrypt license (not OSI-approved; seeking history, context).]

[Ben Tilly]

We don't have proprietary rights.  But a "name and shame" list would
dissuade people from diluting the term.  And there is no shortage of
organizations who would like to dilute it.


On Mon, Oct 14, 2013 at 5:09 PM, John Cowan  wrote:

> Luis Villa scripsit:
>
> > Slightly more broad than that: a list of licenses that we have rejected,
> > including the rationales for rejection. Your list would presumably be a
> > subset, as some licenses might have been submitted and rejected without a
> > later, false claim to being open source.
>
> I think publishing such a list would be a supremely bad idea.  Our
> business is to approve licenses, not to disapprove them.  If someone is
> using the term "open source" for a non-certified license, we should
> privately try to persuade them to stop doing so, and (if feasible)
> get their license certified or change licenses.  If they are using
> the term in bad faith, as shown by earlier attempts, we should ignore
> them -- we don't have proprietary rights in the term, after all.
>
> --
> There is / One art  John Cowan 
> No more / No less   http://www.ccil.org/~cowan
> To do / All things
> With art- / Lessness --Piet Hein
> ___
> 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] Open source license chooser choosealicense.com launched.

[Ben Tilly]

The GPLv3 is a rewritten GPLv2 which is less US specific, and addresses
additional copyleft weaknesses.


On Mon, Aug 19, 2013 at 10:48 AM, Engel Nyst  wrote:

> 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 mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] License compatibility - reg

[Ben Tilly]

On Wed, Jun 26, 2013 at 11:14 PM, Rick Moen  wrote:
> Quoting Ben Tilly (bti...@gmail.com):
>
>> According to my recollection, she was definitely of the opinion that
>> her statements about whether the license should be enforceable at all
>> helped sway the judge to the position that it should be.
>
> I'm pretty sure you have changed the subject.

That may be.  I jumped in at a point where it looked to me that you
were saying that the views of drafters (and by extension maintainers)
is irrelevant, with an example of how it could prove relevant.

But reading the upthread discussion in detail that I had not before
jumping in, I can't come up with any realy examples where the views of
drafters actually proved relevant to the facts of any case.
Furthermore while I can constructed strained threads of hypotheticals
in which it could potentially be argued to matter, they bear great
resemblance to the chain of events leading from a flap of a
butterfly's wings to a storm halfway around the world some months
later.

> If your assertion is merely that judges may consult various parties
> including licence drafters about various things in a case about
> copyright owner X's software licensing -- leaving aside the awkward
> point (for you) that Ms. Randal was not a licence drafter in this or to
> my knowledge any other case -- then, OK, sure.  Almost tautologically
> true, actually.

Not just "may consult" but "may be approached by".  And yes,
tautologically true.

> Problem:  This was simply not, to the best of my recollection, what was
> being talked about upthread.
>
> Rather, it was some vaguely described situation where one Mr.
> Satyanarayana was said to be 'combining in some way' codebases under
> various licences one of which was GPLv3 from FSF, to which Matthew and
> then you, if I understood correctly, asserted that someone wishing to
> determine what obligaions matter (including, say, judges) should "listen
> to' FSF.

Ah.

There is actually good reason to pay attention to the FSF on this
issue.  They know their own license, have done their own analysis of
precedent, have put forth a position that they think could be argued
for, and there are a lot of people who give their words weight.  So
staying within the bounds that the FSF sets will lessen the likelihood
that someone will ever think they have something to sue you over, and
lessens the likelihood that if someone does sue you, they will find a
potentially successful argument which you failed to notice in advance.

Furthermore if the FSF is a copyright holder to code that you're using
(they do have copyrights on quite a bit of it), what they have
publicly said is a particularly good predictor of what will keep them
from getting annoyed at you.

None of which matters if you get to litigation.  But a lot of what
lawyers do is reduce the possibility of future disputes.  Not
challenging the FSF guidelines would be a safe way to do that.  Even
if you are morally certain that you would, in fact, win on a
particular point.

> To which I said, when copyright violation gets litigated, judges consult
> competent and relevant evidence about what licensors' terms were,
> starting with the written licence text and (if necessary to resolve
> ambiguity) other competent and relevant indicators about what licensors
> intended, such as their other writings, statements, and actions.

The threat of litigation is, of course, important to the enforcement
of copyrights.  However it is rare for open source software to be
enforced through actual lawsuits.

> FSF is not in the general case useful in that regard.  Hence my point.
>
> How you got from there to the Jacobsen case and Alison Randal, notable
> Perl persona but not licensor, I am not sure I know but pretty sure I
> don't really need to know.
>
> The rest of this seems to be a complete waste of time.  If you disagree,
> feel welcome to carry on without me.
>
> ___
> 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] License compatibility - reg

[Ben Tilly]

On Wed, Jun 26, 2013 at 10:49 PM, Rick Moen  wrote:
> Quoting Ben Tilly (bti...@gmail.com):
>
>> For example I point to the efforts of Allison Randal of The Perl
>> Foundation in the case Jacobsen v. Katzer in litigation regarding the
>> Artistic License.
>
> And, just another little point.  You _are_ aware that Randal, despite
> her many accomplishments, was not drafter of that licence, right?
> Assuming you knew that, then what are you going on about, Ben?

If you look back to my first email in this thread where I started off
with the phrase, "...where someone who in some way represents the
drafter..."

I was thinking about Allison, who in her position on The Perl
Foundation and as drafter of a much improved version of the Artistic
license does indeed represent Larry Wall's interests in this matter.
Doubly so since the initial precedent could have had serious
implications for Perl.

> And if hypothetically Alison Randal rather than Larry Wall _had_ been
> drafter of that disasterously awful licence -- and I'm rather glad for
> her sake that she wasn't -- why would the judge consider her a competent
> witness to testify about what was on Robert Jacobsen's and the other
> JRML coders' minds when they released Java code under AL 1.0?  Are they
> all golf buddies?  In the same Masonic lodge?  Group therapy?

What have I have said that could possibly support the impression that
I thought that the judge considered her a witness to Robert Jacobsen's
state of mind???

If you truly think that I was saying that, please re-read until you
understand that I was not.  After that we can discuss the merits of my
actual position.

(Note that Robert Jacobsen's state of mind was never a relevant
question.  His lawyers followed the standard FSF argument that
Katzer's violation of the license left him with no permission to do
things that he did which require permission under copyright law, and
therefore left him open to liability for copyright infringement.  As
http://jmri.sourceforge.net/k/docket/158.pdf demonstrates, this theory
did not initially fare well.)

> You see where I'm going with that, I hope.  You know, that whole
> 'competent and relevant' thing.  If not, I'd _truly_ better give this up.
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] License compatibility - reg

[Ben Tilly]

On Wed, Jun 26, 2013 at 9:35 PM, Rick Moen  wrote:
> Quoting Ben Tilly (bti...@gmail.com):
>
>> This may be true, but there are many cases where someone who in some
>> way represents the drafter of a boilerplate legal vehicle filed an
>> amicus brief that was given due weight by a judge.
>
> On what question, though?  That matters, nei?
>
> Upthread, Matthew states his view (and I'm trying in good faith here to
> paraphrase; my apologies in advance if I err) that it's reasonable to
> consider the licence drafter's views on the question of what the
> licensor agreed to and subject to what conditions.

I would state that in a weaker form.  I would state that the license
drafter's views may prove to be not entirely irrelevant.  Both because
the license drafter's public proclamations may be introduced as a
pertinent fact in establishing what the likely intent and
understanding of the agreement was, and because the license drafter
may attempt to persuade the court of their views.

If you flip what I said, you could reasonably infer that the fact that
the license drafter thinks X usually will be irrelevant.  I would
emphatically agree with this.

>> The drafter does this because it is in their interest to get
>> precedents saying that the legal vehicle actually means what they
>> intended it to mean.  The judge can think this matters because it
>> sheds light on what the participants may have thought they were
>> agreeing to.
>
> Like Matthew, you assert that this happens (you say 'may'), but you
> cannot point to it occurring.  (See below.)  According to my
> understanding of the basics in this area, it would be improbable
> because, as mentioned, the drafter is just not (in the general case) a
> party to the legal action in any way -- nor evan a qualified expert
> witness on the question under discussion (what the licensor intended).

In the general case no.  As to whether I can point to a relevant
example, I still believe that I did.  (See below.)

> Because the drafter couldn't possibly be.  You see.  Or maybe not.  I've
> mentioned this datum a few times because, it seems to me, it should be
> dispositive.  Maybe I'm hallucinating; maybe you and Matthew are.  I'm
> glad to agree to disagree.  {hint}
>
>> For example I point to the efforts of Allison Randal of The Perl
>> Foundation in the case Jacobsen v. Katzer in litigation regarding the
>> Artistic License.
>
> I talked to Ms. Randal (very briefly) about that case at the time.  My
> impression was that the judge did not consult her on the nature of what
> Jacobsen had decreed in his licensing, but rather on other matters
> entirely.

I talked to her (also briefly) about that case both at that time and
later.  According to my recollection, she was definitely of the
opinion that her statements about whether the license should be
enforceable at all helped sway the judge to the position that it
should be.

Remember, the critical legal issue was not whether Katzer had done
things that they license said he shouldn't.  He clearly had and nobody
disputed that.  It was whether the existence of such a broad public
license precluded any possible right to sue under copyright law.  The
initial decision by the Hon. Jeffrey White was that the license did
preclude that, and without a case in copyright or any legally
enforceable contract, there was nothing for Jacobsen to sue over.

Thus my point, again.  The fact that Allison Randal strongly held the
beliefs that she did about the enforceability of the license caused
her to work hard to find legal arguments that may, in fact, have
swayed a judge.  If so, then the fact that she held those beliefs is
not entirely irrelevant to the decision that got handed down.  Though
clearly relevance would be through a tenuous chain of causation.

>> In the example that I pointed to, the judges (multiple, this was an
>> appeals court) came to the decision that Allison Randal supported,
>> using lines of reasoning that she also supported.
>
> Um, that's a heck of a handwave.  You have just talked all around the
> actual point of contention:  Was Randal consulted to help the judge
> determine the nature and purport of Jacobsen's licensing conditions?
> No, she was not.

That's not the point of contention.  The point of contention is
whether Randal's beliefs were entirely irrelevant to the outcome of
the case.

We are in violent agreement that she was not directly consulted.  That
her beliefs were not a material fact in the case.  That the actual
arguments through which she acted on her beliefs derived none of their
force from the fact that they were her beliefs.  And so on and so
forth.

But the point of contention remains.  I claim that when the drafter of
a license becomes aware of

Re: [License-discuss] License compatibility - reg

[Ben Tilly]

On Wed, Jun 26, 2013 at 4:46 PM, Rick Moen  wrote:
> Quoting Matthew Flaschen (matthew.flasc...@gatech.edu):
>
>> Possibly, if the court decides the license is ambiguous.  They might
>> look to the preamble, as well as the licensor's statements (as you said,
>> the licensor is often not the license drafter).
>>
>> But I think it's reasonable to think they may consider the license
>> drafter's statements as well.
>
> You may think that's reasonable, but in my years of study of business
> law[1], I cannot recall any case where the drafter of a boilerplate
> legal vehicle was consulted by any judge, in a situation where the intent
> of a party to some legal action is at issue, and the drafter was not a
> party.  Business contracts would be a prime example.  The judge looks to
> the text.  If the text is somehow murky, he/she looks to other guidance
> apparent in what the parties have written, said, and done elsewhere.

This may be true, but there are many cases where someone who in some
way represents the drafter of a boilerplate legal vehicle filed an
amicus brief that was given due weight by a judge.  The drafter does
this because it is in their interest to get precedents saying that the
legal vehicle actually means what they intended it to mean.  The judge
can think this matters because it sheds light on what the participants
may have thought they were agreeing to.

For example I point to the efforts of Allison Randal of The Perl
Foundation in the case Jacobsen v. Katzer in litigation regarding the
Artistic License.

[...]
>> If you're not certain how the license will be interpreted in court, I
>> think it's conservative (safer) not to do things the license drafter
>> interprets as forbidden.
>
> Same logic error in my view, sorry.  The drafter is not a party to the
> issue in any way.
>
> But I'm glad to agree to disagree, pending the arrival of relevant
> caselaw that I firmly predict will occur exactly never because nobody is
> going to litigate based on such a, ahem, speculative theory of law.  (My
> view, etc.)

In the example that I pointed to, the judges (multiple, this was an
appeals court) came to the decision that Allison Randal supported,
using lines of reasoning that she also supported.  Did her support
cause the judges' to give those arguments extra weight?  It cannot be
proven one way or another.  But it is not impossible that it could
have.

> [1] No, I'm certainly not a lawyer.  I studied for and passed the
> Certified Public Accountant exam, for which one must study and master a
> fair amount of business law.  I'm not claiing expertise; just a more
> seasoned than average amateur and one who tends to avoid many of the
> more common errors.

I have significantly less legal training than you do.  Please feed my
comments through your knowledge and prior beliefs, then only give them
weight according to the degree to which they make sense to you.  And
before taking any action based on the conclusions that you come to,
feed that understanding through a competent lawyer.

Should that process lead you to to a conclusion that later proves
inadvisable, feel free to sue the lawyer.  That is, after all, what
you paid them for.
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] OSI license issue: Artistic license

[Ben Tilly]

There was a time when the Artistic license v1.0 was in use in many
projects in many forms.  For example at one point Ruby was under a
version, many CPAN modules are (or were) under it, many ports of those
modules to other languages, etc.  Making it worse, people who are
inclined to use the Artistic license are generally not deeply
concerned about legal matters, and so tend to display a lack of care
about the exact text.  A phenomena that you noticed the effects of.

In fact the only US court case which I am personally aware of to test
the enforceability of an open source license featured a variant the
Artistic license v1.0.  (Not sure of the exact text, the project is
now under the GPL v2.)

However it is not a popular license for new software.  (Justifiably
not, there are much better licenses available.)

On Thu, Jun 6, 2013 at 1:01 PM, Jilayne Lovejoy
 wrote:
> Hello OSI!
>
> We have identified a few outstanding license list reconciliation issues
> previously and one of those came up again in the form of a request to add
> the Perl Artistic license to the SPDX License List.  I thought it might be
> helpful to review that issue again, separately, in the hopes we can come up
> with some kind of resolution.
>
> By way of reminder, here is a summary of the situation:
>
> The OSI site has explanation regarding two variations of the Artistic
> License v1.0; that is, whether clause 8 is included or not.  We have already
> all agreed that this mandates having two separate entries on the SPDX
> License List – one for each variation.
>
> The trouble is that the OSI also states that when clause 8 is included, it
> is called the Artistic (Perl) license and refers to the Perl site (see:
> http://opensource.org/licenses/Artistic-1.0).  However, the license text
> found on the Perl site (http://dev.perl.org/licenses/artistic.html) and that
> found on the OSI site are significantly different (notwithstanding clause
> 8).  A comparison document is attached here.
>
> Currently, the SPDX License List includes only the Artistic License 1.0
> (Artistic-1.0) (see: http://spdx.org/licenses/Artistic-1.0) which is the OSI
> version (with no clause 8).
>
> In a previous thread, the last comment on this issue by OSI was to ask
> whether the OSI variation occurs "in the wild."  If not, then it was
> suggested to change the OSI site to match the Perl site text.
>
> (my two cents on this is that it may be hard to say what has been found "in
> the wild," as it would be easy to conflate "Artistic LIcense 1.0" without
> realizing the OSI and Perl sites display distinct variations.  The only way
> to determine the difference would require a much closer look.  I would
> hazard to guess that these variations have been confused for each other "in
> the wild."  But I can't back that up in one direction or another at this
> time.)
>
> Some insight from a license-savyy person associated with Perl who could
> help?
>
> Proposed solutions:
>
> #1
> SPDX LIcense List adds two new licenses, as follows:
> - Artistic License 1.0 w/clause 8  |  Artistic-1.0-cl8
> - Artistic License 1.0 (Perl)  |  Artistic-1.0-Perl
>
> OSI can then choose(now, later, whenever) to update or change their listing
> (or not) as it so desires and just update the SPDX short-name identifier
> accordingly; keeping everything in order, in terms of naming and references.
>
> #2
> OSI decides how these variations should be represented, updates its site and
> then SPDX will follow suit to be consistent.
>
> #3
> ?? Another idea?
>
>
> Please let us know what you think.
>
> Cheers,
>
> Jilayne Lovejoy
> SPDX Legal Team |  Co-lead
> OpenLogic, Inc.  |  Corporate Counsel
> jlove...@openlogic.com
>
>
>
>
> ___
> 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] Is Web application including GPL libraries covered under GPL?

[Ben Tilly]

On Wed, May 15, 2013 at 6:02 PM, John Cowan  wrote:
> MURAKAMI, Keiko scripsit:
>
>> Our application are made by Java, so these are not tightly linked GPL
>> libraries, because GPL libraries are located in another directory,
>> are referred or dynamic liked at live time.
>
> It is disputed whether that matters or not.  I tend to think not.
>
>> And we never deliver the application to users, we run the web
>> application on our side servers, all users just use our web service.
>
> In that case, the GPL's requirement to distribute source definitely
> does not apply, because you are not distributing anything.

Definitely?

If the web page contains copyrighted text in its source that is from
the library, then an argument can be made that you have distributed
something.  Namely a web page with a mixture of your copyrighted
works, or someone else's.  Whether this matters in any specific case
depends on all sorts of things that I'm not (as a non-lawyer)
qualified to opine on.
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Copyright Free Software Foundation, but license not GPL

[Ben Tilly]

On Fri, Apr 5, 2013 at 3:14 PM, Robin Winning  wrote:
> Hi All,
> I am a contracts manager at software company, and in addition to doing
> contracts, I now find myself reviewing the licenses associated with the open
> source packages my company has acquired. I have become quite familiar with
> the GPL/LGPL/AGPL suite of licenses, as well as the other, permissive
> licenses: MIT, BSD, etc. Here's my question: quite frequently, the
> programmer makes the Free Software Foundation the copyright holder, but then
> attaches a license that is not in the GPL family. Is that a valid
> combination?
>
> In the case of "ncurses," I was able to research and determine that when
> they assigned their copyright to the Free Software Foundation, the FSF gave
> ncurses a special carve-out allowing them to use a permissive license.
> However, all the rest of the open source packages I have come across that
> assert "Copyright Free Software Foundation" but are accompanied by non-GPL
> licenses do not seem to have that sort of special arrangement.
>
> Maybe I'm overthinking this, but it seems contradictory to me, and I don't
> know how to characterize the license in terms of permissive or restrictive.
>
> Thank you,
> Robin

I would suggest that you contact the FSF with the question, and a
specific list of developers, projects, and licenses.  The FSF is
pretty good about keeping records of actual copyright assignments to
them, and can verify which of those they own copyright to, and what
license(s) they are under.  If the copyright has been properly
assigned to the FSF, it is under whatever license the FSF says, no
matter what the developer thinks.

In most of these cases the developer probably has just borrowed a
copyright statement from someone else and has not assigned copyright.
At that point, how far deep in the rabbit hole do you want to go?  The
programmer almost certainly wrote the software in question, and there
is a good chance that the programmer is the copyright holder.  In that
case their license goes, no matter who they think owns that copyright.
 However depending on the location that the programmer lives, the
details of their employment contract, etc, there is a real possibility
that the work is a work for hire and is technically owned by a company
that likely has no idea that said software exists, or that they have a
legal claim to it.  This situation is surprisingly common, and almost
never causes anyone problems.  If it does cause problems, I've never
heard of anything happening to anyone other than the unlucky
programmer beyond being told that the copyright is not what you
thought it was, could you please stop using it.  In the bizarre case
where someone wanted to pursue it farther, you've got a pretty solid
defense for past infringements because you were going on your
reasonable belief about the license based on what you were told.

I have been told in the past that the FSF is very aware of this
potential can of worms, and that is why they keep careful records to
make sure that they actually own the copyrights that they think they
own.

IANAL and TINLA.
___
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?

[Ben Tilly]

One can reasonably hope that seeing the desired legal reasoning
clearly spelled out in the license would lead the judge towards the
decision that we want.  But when I (admittedly as a non-lawyer) read
that section of that decision, there is nothing that I see that would
have prevented that judge from reaching that conclusion with those
presented facts if the license in question was the much more carefully
drafted GPL v2.

BTW thank you for having been part of the effort to ensure that open
source licenses actually can be enforced in US courts under copyright
law.  It is a critical precedent, and I'm very glad that it was set in
the right direction.

On Thu, Mar 7, 2013 at 11:57 AM, Bruce Perens  wrote:
> Ben,
>
> Yes, my testimony was to establish the economic interest in attribution of
> Open Source software. However, it's going too far to say that the license
> terms were not a problem. The judge's finding starting at "Plaintiff's Claim
> Sounds in Contract, Not Copyright" is that the Artistic License 1.0 text is
> self-invalidating. It's not so clear that a better drafted license would
> have reduced us to basing the appeal on the economic value of attribution
> alone.
>
> Thanks
>
> Bruce
>
> Ben Tilly  wrote:
>>
>> I do not believe that you are fairly describing the cause of what
>> happened.  At issue was not the drafting of the license, it was the
>> fact that it was the first time that the legal idea of "follow the
>> license or we sue for copyright" had ever been tested in a US court
>> for software that had been given away to the world on generous terms.
>>
>> The judge's ruling was based on the fact that software was given away,
>> for free, with no expectation of a reward.  Therefore there was no
>> loss in its being appropriated by a third party.  The fact that the
>> software was available to everyone on generous terms meant that there
>> was no cause under copyright law.  The judge ruled that the license
>> could be viewed as a contract, but of course the basic elements of a
>> valid contract were missing and so you couldn't sue under that either.
>> If
>> the hobbyist had used the GPL as a license, the same facts would
>> have existed, and the judge could easily have ruled the same way.  In
>> fact the reason why the case was so important is exactly because the
>> precedent undermined the enforceability of all open source licenses
>> where no contract existed.
>>
>> For verification, the judge's ruling and reasoning are available at
>> http://jmri.sourceforge.net/k/docket/158.pdf.
>>
>> On Wed, Mar 6, 2013 at 10:09 PM, Bruce Perens  wrote:
>>>
>>> The license isn't really "standing up" when you have to file a writ of
>>> certiorari after a judge throws his hands up at the license text and
>>> pronounces it to be tantamount to a dedication to the public domain. That
>>> was no easy appeal to win, and the Open S
>>>  ource
>>> developer was seriously
>>> damaged by the cost and the 5-year process. It cost me a good deal of
>>> time
>>> and work too.
>>>
>>> A license that stands up would, I hope, require much less time to dispute
>>> and would be parsed as intended by the court.
>>>
>>> So, what the Artistic License 1.0 made much more difficult for the poor
>>> Open
>>> Source developer is exactly what I'd like to fix. And yet the Artistic
>>> 1.0
>>> is not the one I thought of first upon seeing this discussion in
>>> progress.
>>> We have much worse.
>>>
>>> Thanks
>>>
>>> Bruce
>>>
>>>
>>> John Cowan  wrote:
>>>
>>>> Bruce Perens scripsit:
>>>>
>>>>> 1. They are ambiguous or likely to perform in court in unexpected
>>>>> ways,
>>>>>   should
>>>>> they ever be litigated. And thus they are harmful to
>>>>> their users. De-listing is a prompt to the organization that
>>>>> originally created the license to replace it with an accepted
>>>>> license or to submit a new version with greater legal competence in
>>>>> its construction. These would be the "crayon" licenses, mostly,
>>>>> those written without legal counsel.
>>>>
>>>>
>>>>
>>>> And yet the Artistic License 1.0, which is riddled with ambiguities and
>>>> a prototypical crayon license, is one of the few that has been tested
>>>> in court -- and stood up.
>>>
&g

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

[Ben Tilly]

I do not believe that you are fairly describing the cause of what
happened.  At issue was not the drafting of the license, it was the
fact that it was the first time that the legal idea of "follow the
license or we sue for copyright" had ever been tested in a US court
for software that had been given away to the world on generous terms.

The judge's ruling was based on the fact that software was given away,
for free, with no expectation of a reward.  Therefore there was no
loss in its being appropriated by a third party.  The fact that the
software was available to everyone on generous terms meant that there
was no cause under copyright law.  The judge ruled that the license
could be viewed as a contract, but of course the basic elements of a
valid contract were missing and so you couldn't sue under that either.

If the hobbyist had used the GPL as a license, the same facts would
have existed, and the judge could easily have ruled the same way.  In
fact the reason why the case was so important is exactly because the
precedent undermined the enforceability of all open source licenses
where no contract existed.

For verification, the judge's ruling and reasoning are available at
http://jmri.sourceforge.net/k/docket/158.pdf.

On Wed, Mar 6, 2013 at 10:09 PM, Bruce Perens  wrote:
> The license isn't really "standing up" when you have to file a writ of
> certiorari after a judge throws his hands up at the license text and
> pronounces it to be tantamount to a dedication to the public domain. That
> was no easy appeal to win, and the Open Source developer was seriously
> damaged by the cost and the 5-year process. It cost me a good deal of time
> and work too.
>
> A license that stands up would, I hope, require much less time to dispute
> and would be parsed as intended by the court.
>
> So, what the Artistic License 1.0 made much more difficult for the poor Open
> Source developer is exactly what I'd like to fix. And yet the Artistic 1.0
> is not the one I thought of first upon seeing this discussion in progress.
> We have much worse.
>
> Thanks
>
> Bruce
>
>
> John Cowan  wrote:
>>
>> Bruce Perens scripsit:
>>
>>> 1. They are ambiguous or likely to perform in court in unexpected
>>> ways, should they ever be litigated. And thus they are harmful to
>>> their users. De-listing is a prompt to the organization that
>>> originally created the license to replace it with an accepted
>>> license or to submit a new version with greater legal competence in
>>> its construction. These would be the "crayon" licenses, mostly,
>>> those written without legal counsel.
>>
>>
>> And yet the Artistic License 1.0, which is riddled with ambiguities and
>> a prototypical crayon license, is one of the few that has been tested
>> in court -- and stood up.
>
>
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>
> ___
> 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] Permissive but anti-patent license

[Ben Tilly]

I am not a lawyer, this is not legal advice, etc.  But I am under the
impression that in the USA there is precedent saying that incidental
copies that are necessary for use in a temporary medium (eg RAM) are
not considered fixed and are therefore allowed under copyright law.
If so, then any attempt in a copyright license to require acceptance
to make those copies will fail because your permission was not, in
fact, needed.

On Mon, Dec 24, 2012 at 8:46 AM, Bruce Perens  wrote:
> Incidental copying is always necessary for use. You can make the license
> work that way.
>
>
> On 12/24/2012 05:03 AM, David Woolley wrote:
>>
>> My understanding is that US copyright law doesn't restrict use of software
>> (UK law does).  If that is correct, you will need to form a contract at the
>> time of supply of the software, that imposes this constraint.
>>
>
>
> ___
> 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] Creating GPL code

[Ben Tilly]

As copyright holder you can license your stuff however you want and
give yourself whatever permissions you want.

But if you want it to be useful to others, you have to make sure that
they receive everything that they need to take the GPLed project and
run with it.  So, for instance, if you've just cut and pasted code
here and there, they don't need to know where it came from.  But if
you include some other library of yours unchanged, that library should
be distributable by them under the GPL.

On Tue, Oct 9, 2012 at 10:40 AM, Ryan
 wrote:
> Hello All,
>
> I have a question I'm unable to confirm the answer to and was hoping someone
> on this list could kindly lend me their expertise in answering it.  I'm a
> freeware software coder and publish simple tools for anyone to download.
> Recently I've been working on a larger project and because of its size I
> would like to license it under the GPL for others to freely build upon it as
> they see fit.  From what I understand of the GPL if you use GPL code in a
> separate project that separate project must be licensed under GPL too.  Now
> what I've done is sort of the opposite and borrowed code from freeware tools
> I've written not licensed under GPL and want to use the borrowed code in a
> GPL project.  My question is as the copyright holder of the code do I have
> to release all my other projects for which I borrowed/reused code from under
> the GPL?
>
> Thanks,
> Ryan
>
> ___
> 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] License Stewards

[Ben Tilly]

On Thu, Oct 4, 2012 at 5:35 PM, Rick Moen  wrote:
> Quoting Ben Tilly (bti...@gmail.com):
>
>> This makes me wonder whether clever license terms would be patentable
>> under US law.
>
> So, Ben:  What did you determine when you measured that notion against,
> say...
>
> https://en.wikipedia.org/wiki/Patentable_subject_matter#United_States
>
> ?

There is logic, and then there is the trend of the United States Court
of Appeals for the Federal Circuit setting precedents making virtually
anything and everything patentable subject matter.

Your phrase "a software licence consists solely of functional
elements" just triggered cynicism on my part that the CAFC could take
that idea as a basis to try and expand patents.  Yet again.
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] License Stewards

[Ben Tilly]

On Thu, Oct 4, 2012 at 4:04 PM, Rick Moen  wrote:
> Quoting Grahame Grieve (grah...@healthintersections.com.au):
>
>> well, ok, but on what grounds would copyright not apply?
>
> I believe Larry was asserting his view that a software licence consists
> solely of functional elements, and no expressive (artistic) elements (or
> not enough that a judge would recognise copyright eligibility).
>
> That's a fundamental concept in USA copyright law; I have no idea  how
> many other jurisdictions have it.

Hmmm.

This makes me wonder whether clever license terms would be patentable
under US law.
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] plain text license versions?

[Ben Tilly]

On Fri, Sep 7, 2012 at 10:37 AM, Ben Reser  wrote:
> On Thu, Sep 6, 2012 at 11:12 PM, Rick Moen  wrote:
[...]
>>> For that matter is it not also a violation of the technology neutral
>>> clause of the open source definition?
>>
>> No.  Read it.
>
> I did.  If you only provide a URL to read the license I can't fathom
> how you're going to argue that doesn't violate that clause of the
> definition.
>
> Which says:
> "No provision of the license may be predicated on any individual
> technology or style of interface."

The location of the license text is not a provision of the license.
Some licenses, for instance the GPL, actually say that you have to
distribute the license along with the work.  Others leave the matter
silent.  Either way the license is an open source license.

You may argue that software with an uninterpretable license is not
really open.  This is not a problem.  Open source does not mean
copyleft.  A lot of open source licenses allow people to incorporate
the software in proprietary products, and you don't even have to be
told it is there.

> You can't even read the license without using a several specific
> technologies.  If it's not a common license like the GPL you may have
> no way of knowing what the license said.  It may not be in a book.
> The URL may have disappeared.  Making the software in essence All
> Rights Reserved as far as anyone is concerned since they may no longer
> have a clue what the license said.
[...]

This is all true, and entirely irrelevant to the point that you wish to argue.

> All of these scenarios are easily overcome by just including the
> license with the software.  The licenses are not very large and I
> don't see the problem with needing to include them.

I have heard people who have distributed embedded software with GPLed
components disagree with this.  Adding the GPL inside of a device that
nobody can interact with the inside of is pretty useless, and is
frustrating when they are often left fighting for every byte.  Given
the number of devices with embedded computers, this is not exactly a
small use case.
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Can copyrights be abandoned to the public domain?

[Ben Tilly]

On Fri, Aug 17, 2012 at 9:12 AM, Lawrence Rosen  wrote:
> Russ Nelson asked:
>> Larry, have you ever been driving over a bridge that collapsed?
>
> Not that I can recall. :-) Out of fear of that very result, though, I
> support increased infrastructure spending by our government.
>
> But I don't stress out every time I drive over a bridge or when I use open
> source software that is owned by an individual who wants to reserve her
> moral rights. Indeed, I respect moral rights in the ways that I license and
> use open source software and I advise respectful attribution whenever
> appropriate. Does the protection of moral rights require anything onerous of
> you?

Let's see.  Linus Torvalds is Finnish and began Linux in Finland.  As
Henrik pointed out, Finnish law has the concept of moral rights, and
one of those rights is the right of integrity, which can allow the
copyright holder to restrict the use of his copyrighted material in
ways that infringe on his honor.  In particular you can say that you
can't use that work for pornography.  Oleksandr pointed us to
http://www.wipo.int/treaties/en/ip/berne/trtdocs_wo001.html#P123_20726
which says that this moral right can be enforced even in countries
which do not have moral rights in their copyright law.

I am not a lawyer.  I know even less about international law.  My
knowledge of this topic is, in fact, pretty much half an hour with
Google following up references in this discussion.  But it looks to me
like Linus might have the ability to sue a US pornography company that
is using Linux to stream their porn based on his moral right rising
from Finnish copyright law.  If so, then that would run directly
counter to OSD #6.

I trust that Linus never would do so.  But if he and many other
European contributers to open source projects actually *could* do
that, that's not exactly a small detail.  (Particularly if you were
loving using open source to distribute your loving.)
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

[License-discuss] Can copyrights be abandoned to the public domain?

[Ben Tilly]

Based on http://www.linuxjournal.com/article/6225 and similar
articles, I'd long believed that a declaration that you were
abandoning copyright was a meaningless farce.

Then by accident today I ran across http://cr.yp.to/publicdomain.html
which claims the opposite, and cites actual court decisions as
evidence.

Is D. J. Bernstein out of his depth here, or does he have a valid point?
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] proposal to revise and slightly reorganize the OSI licensing pages

[Ben Tilly]

On Mon, Jun 11, 2012 at 8:21 PM, Rick Moen  wrote:
> Quoting Ben Tilly (bti...@gmail.com):
[...]
>> If the license dissuades people that you would like to have using your
>> software, it is also defective.
>>
>> Licenses have multiple potential failure modes.  Not all of which
>> happen in a court room.  There is value in standardized licenses.
>> There is value in simple licenses.  Sometimes this value outweighs the
>> value of having said *exactly* what you want said.
>
> Indeed.
>
> Death and taxes hereby incorporated by reference.
>
> Suggestion:  What the world really needs is a book listing all ways
> to go wrong with licensing.  Might be your calling, Ben.

I think that high on the list should be, "Accepting advice from people
who are unqualified to give it."  Which disqualifies me pretty
soundly.

I'll go back to Perl, math and A/B testing.  I know those pretty well.
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] proposal to revise and slightly reorganize the OSI licensing pages

[Ben Tilly]

On Mon, Jun 11, 2012 at 7:11 PM, Rick Moen  wrote:
> Quoting Ben Tilly (bti...@gmail.com):
[...]
>> If a license does what I want 90% of the time quite well, and fails
>> 10% of the time, is it better or worse than a license that does
>> something you find merely OK 100% of the time?
>
> Mu.  The premise is defective.

Really?

> If the licence doesn't grant the rights you wish granted, then it is
> defective 100% of the time.

If the license dissuades people that you would like to have using your
software, it is also defective.  Legalese that says exactly what you
want said is excess verbiage in your license that will cause some
people to ignore your software because they don't want to deal with
analyzing the license.

Licenses have multiple potential failure modes.  Not all of which
happen in a court room.  There is value in standardized licenses.
There is value in simple licenses.  Sometimes this value outweighs the
value of having said *exactly* what you want said.

> Failing to grant the rights you wish to grant might be evidenced by,
> e.g., 10% of the recipients behaving in ways you intended to disallow,
> but your chosen terms allowed this, and yet you are surprised.

"Don't like" and "intend to disallow" are not equivalent.
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] proposal to revise and slightly reorganize the OSI licensing pages

[Ben Tilly]

On Mon, Jun 11, 2012 at 3:20 PM, Rick Moen  wrote:
> Quoting Tzeng, Nigel H. (nigel.tz...@jhuapl.edu):
>
>> Again, whatever your self identification is, your comment and statement
>> are those espoused by one of those camps over the years.
>
> No, they most certainly are not.  Kindly do not confuse me with some
> bunch of ideologue wankers.
>
>> What was the value of this observation?
>
> That differently licenced derivatives in compliance with your
> requirements are seen as OK if proprietary and hence shut off from
> sharing under the same terms, but not OK if copyleft and hence shut off
> from sharing under the same terms -- which seems to me a prime example of
> failing to grasp _either_ of the two basic facts about copyright law and
> software I mentioned to Ben Tilly:  (1) People can and do perform pretty
> much whatever screwball actions they wish to perform with their own
> property.  (2) You should take care to understand all of the
> implications of any licence you use, because somebody else definitely
> may, and you'll look really silly acting surprised.

Seeing these repeated references to my name is getting annoying.  You
made a comment about some BSD people.  I offered an explanation of one
mindset that leads to that situation.  You came back with an argument
that the mindset is wrong.  Since I don't possess that mindset, and I
have no interest in an argument, I didn't bother to respond.

You like to take people to task who have assumed that you take one
position or another which you don't.  Please stop assuming that you
enlightened me when you did not, and stop associating me with a
position that I do not hold.

> Permitting any derivatives satisfying 2-clause, 3-clause, or 4-clause
> obligations means permitting _any_ derivatives satisfying 2-clause,
> 3-clause, or 4-clause obligations.  If licensor didn't intend that,
> then licensor shouldn't have chosen the licence.

People decide that particular licenses are right for themselves for
all sorts of reasons.  Often those reasons turn out to be mistaken,
and then people tend to get upset.

Many people who choose permissive licenses have a view that says that
when you don't try to order people around with contracts, goodwill
tends to get repaid down the road.  That is, in addition to the
explicit legal contract, they act as if there was an implicit social
contract between them in the world; if they are generous then enough
people will be generous back that things tend to work out.  Most of
the time this belief works.  (That is why people continue to have
beliefs like this.)  Occasionally they are spectacularly wrong.

That is, rather than trying to minimize harm when things go wrong,
they try to maximize the benefit of things going right.  If this is
your goal, complicated legalese is unlikely to be appealing.

Unhappiness can then arise when people who have released under a
permissive license hoping to see reciprocal generosity down the road
see their work improved and the improvements offered under a copyleft
license.  Legally nothing wrong has happened.  Socially nothing wrong
has been done in the world view of the person who made the
improvements.  But in the eyes of the person who originally released
the software, you have failed to be generous back to them, and you
have created a barrier to future generosity from people down the road
who use the improved version.  (Proprietary software creates less of a
barrier because there is a single entity that may come to see
generosity as being in their enlightened self-interest.)

Again I am not describing this to say that I hold this view, or that
you should agree with it.  Quite the contrary.  I am merely offering
it for anyone who wants to understand what may be going through the
head of a person who gets upset about something like this.

> _Unlike_ ideologue wankers, I have no wish to urge any particular
> licensing on anyone, and regard with particular distaste those who do.
> (In the general case, it involves someone else's property and is not
> really my concern at all.)  As I very clearly stated upthread, I regard
> licences as legal instruments to implement the licensor's intentions.
> The intentions should logically dictate owner's licensing strategy: the
> only real tragedy is when people fail to understand their chosen
> licensing's natural and obvious consequences.

If a license does what I want 90% of the time quite well, and fails
10% of the time, is it better or worse than a license that does
something you find merely OK 100% of the time?  You'll have no end of
examples in that failing 10%, but on the whole there are some people
who will still prefer that license, even though it can and does go
wrong quite frequently.

Again, not my point of view.  But if someone has that point of view,
it may make sense for them

Re: [License-discuss] proposal to revise and slightly reorganize the OSI licensing pages

[Ben Tilly]

On Thu, Jun 7, 2012 at 8:33 PM, Rick Moen  wrote:
> Quoting John Cowan (co...@mercury.ccil.org):
[...]
> My surmise is that the thing being referred to as '{sublicensing|relicensing}
> of BSD works' is in fact stating the licensing for a derivative.
>
> A certain number of the BSD regulars remain deeply unhappy when those
> works state copyleft requirements, even though they're perfectly happy
> when derivatives of the same BSD works have proprietary licenses.  Go
> figure.

This makes sense to me.

It seems to me that many people who license code under permissive
licenses do so in the knowledge that there are pressures to push
changes upstream.  If upstream is permissive, there is therefore a
chance of code being re-released under a permissive license later.
Which means that you might be able to pull those changes into a
proprietary project of your own that uses that code.  Apache comes to
mind as an example of a project that in its early days benefitted from
proprietary changes that were later released under a permissive
license.

Sure, most proprietary changes won't be re-released.  But if even a
fraction of them are, that is development effort that you got for
free.  Many are happy for there to be free riders if they are
confident that a certain number of people won't be free riders.

However if someone downstream re-releases under a copyleft license,
there is essentially no chance of changes downstream of that ever
being re-released under a permissive license that can be reintegrated
back into the original project.
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] GPL and proprietary WebAPIs

[Ben Tilly]

The real question is not what the GPLv3 does or does not allow, it is
what copyright does or does not allow.  If a work is derived under
copyright law from a GPLed piece of work, then it must be GPLed.  If a
work is *not* derived under copyright law from a GPLed piece of work,
the GPL is going to have trouble restricting it.  If you write any
other copyright license, you'll run into the same issue.

That said, this is all very vague.  There isn't a lot of case law
about what is and isn't a derived work in software.  There is a lot of
folklore and opinions.  However until an actual judge makes an actual
decision, nobody really knows what will happen.  And different
countries have different copyright laws and precedents.  What flies in
the USA may not fly in Germany, and vice versa.

Note, I am not a lawyer, and this is not legal advice.  I highly
recommend not taking any concrete action that potentially skirts the
GPL until after you engage a real lawyer.  Even then I'd recommend
caution.  The legal basis of the GPL has held up in several countries,
so the only real question is whether it applies to you.

On Fri, Dec 23, 2011 at 9:20 AM, Clark C. Evans  wrote:
> Rick,
>
> My question is rather straight-forward.  Does the GPLv3
> permit the distribution of derived works that require
> an independent and non-free work for its operation [1].
> I was under the impression that the Corresponding Source
> ("all the source code needed to... run the object code")
> and 5c ("the whole of the work, and all its parts,
> regardless of how they are packaged") would effectively
> prevent this sort of distribution.  However, this seems
> not to be the case.
>
> If so, and this seems to be the consensus I'm hearing,
> then I think the GPLv3 is ineffective; more of a nuance
> than effectively protecting the free commons.  Since,
> if I wish to distribute an extension of GPL'd work,
> all I have to do is factor out the critical parts of
> the my work and make them available as an independent
> and proprietary web service.
>
>
>
> On Fri, Dec 23, 2011, at 03:52 AM, Rick Moen wrote:
>> I doubt very much that the recent queries here qualify as
>> that variety of public service.
>
> You are being unnecessarily argumentative.  I'm
> trying to find an appropriate licensing strategy
> for our company, and I'm expressly trying to prevent
> and understand the sort of shims that seem to be
> standard industry practice.  If our work can't be
> protected from these "creative circumventions" by
> the GPL, then we probably won't use this license.
>
> It's my position that if you wish to create a derived
> work that incorporates proprietary functionality,
> you should also provide an equivalent implementation
> under a compatible license.  The style of linking
> and the question if the combined work is also derived
> from the proprietary work are largely irrelevant in
> my estimation.  Yet, these two considerations keep
> emerging as if they are limitations of the GPL.
>
> Part of this problem is legal, but the other part
> is what the community accepts as being acceptable
> and that depends upon the public opinion of legal
> and technical professionals on this list.
>
> Best,
>
> Clark
>
> [1] For purposes of this question, you can consider the
> dependency to be declared as part of the derived work,
> but resolved at runtime via sockets or WebAPI; also
> assume that the derived work is *not* a modification
> or transformation of the independent, non-free work.
> ___
> 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] Greetings, Earthlings! Need quotes for article

[Ben Tilly]

On Tue, Dec 20, 2011 at 2:48 PM, John Cowan  wrote:
> Richard Fontana scripsit:
>
>> The OSI should have some sort of process for delisting
>> formerly-approved licenses for reasons of failing to actually meet the
>> Open Source Definition (or some future replacement of it). That is to
>> say, the OSI should be willing to admit that it made a mistake, much
>> as a court (while it might ordinarily apply the policy of stare
>> decisis) will in certain cases overrule its prior decisions. Clearly
>> for policy reasons such actions should be exceptional rather than
>> common, and perhaps should be limited to certain licenses that were
>> approved during a particular period in the OSI's existence (I would
>> guess 2000-2005?).
>
> Fine in principle, but do you actually have examples of such licenses that
> contravene the OSD?  (About future revisions, of course, nothing can be said.)

At the time it was approved, there was debate about whether section 14
of http://www.opensource.org/licenses/CPAL-1.0 contradicted section 10
of the OSD.  The approved draft is much better than the original,
however that section is still debatable.
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: two new licenses approved

[Ben Tilly]

"Ben Tilly" <[EMAIL PROTECTED]> wrote:
>
>Russell Nelson <[EMAIL PROTECTED]> wrote:
>>
>>We approved two new licenses.  http://opensource.org/licenses/ The
>>Sleepycat license is BSD with a required source disclosure term, and
>>the Nethask license is a GPL precursor.  Both are obviously open
>>source with no controversial terms whatsoever, but we needed them on
>>the approved list because some people wanted to certify software using
>>those licenses.
>
>Actually Sleepycat's license does have one term that caused
>discussion here in the past, and approving it clarifies one
>question.
[...]

Oops, used to have.

It appears that the license I am used to reading is not quite
the one that you approved.  Too bad.  I always thought that
the old one was an interesting compromise...

Cheers,
Ben
_
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: two new licenses approved

[Ben Tilly]

Russell Nelson <[EMAIL PROTECTED]> wrote:
>
>We approved two new licenses.  http://opensource.org/licenses/ The
>Sleepycat license is BSD with a required source disclosure term, and
>the Nethask license is a GPL precursor.  Both are obviously open
>source with no controversial terms whatsoever, but we needed them on
>the approved list because some people wanted to certify software using
>those licenses.

Actually Sleepycat's license does have one term that caused
discussion here in the past, and approving it clarifies one
question.

Sleepycat's license has been drafted based on the premise
that they have retained the ability to relicense, and with
a requirement that there be a copyright notice that retains
intact notice of the fact that they offer support for, and
can relicense, the component they contributed.

>From the point of view of someone dealing in free software,
this term seems harmless.  However it gives them an edge in
their consultanting business, and it gives them advertising
for commercial companies that want to use their code.  The
second is particularly relevant since it gives a way for a
small company to pursue a "halfway open" business model.
You are giving away open source software, but hope to get a
closed-source revenue stream from it.

(This model was discussed in the context of creating an
open-source library for incorporating AI into games.)

Cheers,
Ben
_
Get your FREE download of MSN Explorer at http://explorer.msn.com

RE: Subscription/Service Fees - OSD Intent

[Ben Tilly]

"Smith, Devin" <[EMAIL PROTECTED]> wrote:
>
>Lou Grinzo wrote:
>
> > I've contended for a long time that the primary problem with open/free
> > licenses is that they're not specific enough.
>
>My experience (as a lawyer) with open/free licenses is that many of them 
>are
>not properly drafted.  The GNU GPL is particularly difficult to interpret,
>probably because it was written by a non-lawyer.  The resulting legal
>uncertainty makes it very difficult for me to give sound advice to my
>clients, and makes licensing rights in or out under the GNU GPL very risky.

The GNU GPL also is a very novel structure.  IANAL, but I
have seen plenty of lawyers agree that it is a copyright
statement that offers a contract.  Should you proceed to
distribute you have accepted the contract and are bound
to it under contract law, *NOT* copyright law.  Or at
least that is how the license is intended to work.

In the absence of court decisions, it is hard to say that
this would work.  But that is the intended mechanism.

>Statements of intent are fine as separate commentary but only muddy the
>waters when included in documents that are meant to be legally binding.
>
>With regard to specificity, sometimes more is better but sometimes it's not
>needed and can be harmful.  Statutory and case law frequently fill in the
>"gaps" left in agreements and there's no need to elaborate.  For instance,
>if a license grants the licensee the right to create derivative works of 
>the
>licensed software, the law provides that the licensee owns the derivative
>works created by the licensee (but not the underlying work on which the
>derivative work is based).  So there's no need to add a provision that
>"licensee owns the derivative work and may distribute it . . ."  In fact,
>adding a poorly drafted provision on the issue is even worse than staying
>silent.

This comment is only true when the intended audience is
a group of lawyers.  Consider well that the majority of
people who read the GPL and try to understand it are not
(in my experience) lawyers.

>Finally, Randy Kramer is absolutely correct that "it is sometimes 
>considered
>an advantage to never change the language of a law or agreement but allow
>the interpretation of the language to evolve."  The best example of this
>that I can think of is insurance policies.  The wording of the policies --
>which is pretty standard from insurance company to insurance company -- is
>archaic and confusing to someone not familiar with insurance law.  But the
>wording has been the subject of decades of court decisions (e.g.
>"advertising injury" includes claims of trademark infringement) and the
>meaning of most policies is now pretty much fixed.  Insurance companies are
>loath to insert new language into policies lest the new wording be
>interpreted in a way that they did not intend.  (There is, I believe, a lot
>of litigation brewing over the Y2K exclusions that insurance companies
>hastily issued before 1/1/00.)

The best known example among politically aware programmers
is probably the US Constitution.

>In the case of Open Source licenses, however, this stuff is too new for
>there to be any value in simply sticking with bad language.  I did a search
>of Lexis recently and could not find a single case interpreting the GNU GPL
>or the Mozilla GL.

There is none for the GNU GPL.  The resulting uncertainty
is often branded as a weakness.  But IMHO it should be
viewed as a strength.  Plenty of companies who were not
particularly friendly to the GPL have been challenged for
GPL violations.  *NOT ONE* (after full review by their
lawyers) thought that their odds of winning a case against
it was good enough to take it to court.

In my books that is pretty reassuring. :-)

Cheers,
Ben
_
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: Transfer of Copyright

[Ben Tilly]

Jimmy Wales <[EMAIL PROTECTED]> wrote:
>
>It would be delightful if people could post sample documents for
>the transfer of copyright.
>
>Someone asked something about transfer of copyright to for-profit
>companies.  The idea is that some authors may be wary of transferring
>their rights to a for-profit company, even though the software has been
>released under GPL.

Particularly with what was just pointed out that you can
only complain if you still own copyright.

>At Nupedia (free encyclopedia using GNU FDL), we are hoping to deal
>with that issue by setting up a non profit foundation, the sole job
>of which is to own and defend the copyrights, i.e. to enforce the
>license.

If your product is GPLed, is there any reason to not use
the FSF for this?  Though if you do that, it would be
polite to donate to them something to defray any extra
expenses...

Cheers,
Ben
_
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: Converting/Splitting Code - Open to Closed

[Ben Tilly]

Eric Jacobs <[EMAIL PROTECTED]> wrote:
>Brian DeSpain <[EMAIL PROTECTED]>
>
> >
> > Yes - but the previous versions licensed under the GPL remain GPLd and
> > development can continue on the code.
>
>Can you explain why this is the case?
>
> > > In reality, the code would most likely *fork,* leaving one strand open
> > > and the other proprietary.
> >
> > That's exactly what would happen and that's why the GPL is there in the
> > first place. The copyright owner retains copyright, therefore can make
> > changes. You cannot retroactively change licenses under the GPL. People
> > retain their original rights under the GPL.
>
>How can licensees retain their rights against the copyright owner's
>will? Is there something in the GPL that requires this?

IANAL, but read the GPL, section 5, very closely.

Looks to me like it is a copyright statement that serves
as an offer of a contract.  Whether this will stand up
is, last I heard, not yet completely sure.  But under
this design, for the copyright owners to retroactively
withdraw the GPL would put them in violation of their
offered contract.

But there are some caveats though.  If the GPLed code
should fall under multiple copyrights, patents, or other
restrictions, it may be impossible to meet all terms and
distribute.  In that case you cannot always continue to
develop and distribute code, even though the primary
author put it under the GPL.

As I said before, IANAL, and this is my personal reading
only.

Cheers,
Ben
_
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: Use of GPL without any intention to enforce

[Ben Tilly]

"Carter Bullard" <[EMAIL PROTECTED]> wrote:
>
>
>Gentle people,
>
>IANAL.
>
>Is there any advantage to releasing software under GPL if you
>have no intention of ever enforcing the license?

People know what the GPL is, and you can borrow
from other GPLed projects.

>GPL projects seem to require some form of licensing in order
>for connected software to be compatible, which I interpret
>to mean connectable, bundle able, redistributable.  Since most
>projects are collections of packages, many of which are GPL'd,
>it seems that licensing under a GPL like license would be a
>reasonable thing, regardless of your interest in copyleft or
>not, even when you have no intention of ever enforcing a license
>of any kind.

The GPL is designed to encourage that.

>Would it be reasonable to make the claim that there is no
>intention to enforce a license in the license itself?

IANAL, but the way I have usually seen this done is that
someone will release code with a copyright saying that, "My
code is under (generous license X) however it contains
(FileA, FileB) which are under different licenses."  Here
the generous license X would be something like a dual GPL
with something else, or a BSD.

Now the whole package is available under the GPL, but you
have made it utterly clear that you will not enforce the
GPL, and you have also made it clear how much of the
package may be used without fear of encountering problems
from the GPL.

Of course saying, "This is GPLed" and leaving it at that
is a lot easier.  Indeed tracking copyrights in this way
seems to be an intermediary step where you initially used
GPLed libraries because they are convenient but plan to
someday release the whole thing under a different license.

Cheers,
Ben
_
Get your FREE download of MSN Explorer at http://explorer.msn.com

RE: Germany

[Ben Tilly]

Dave  J Woolley <[EMAIL PROTECTED]> wrote:
>
> > From:   Alexander Eichler [SMTP:[EMAIL PROTECTED]]
> >
> > in US, it needs copyright law to act like it does. Conclusion is, that 
>GPL
> > is only a possibility to give the right to use to somebody else. 
>Copyright
> > beneath this still exists. So GPL is a license agreement. As any other
>   [DJW:]
>   GPL is founded on copyright.  In fact, I've heard that
>   the FSF will insist that copyright ownership is made
>   very clear before accepting something under the Gnu
>   banner.

If you are not the copyright owner you have no possibility
of assigning any copyright statement to software, nor do
you have the right to grant the various permissions that
the GPL is meant to guarantee.

This does not prevent the GPL from simultaneously being a
contract between the copyright holder and the would-be
modifier or distributer.

[...]

Cheers,
Ben
_
Get your FREE download of MSN Explorer at http://explorer.msn.com

RE: [Fwd: Germany]

[Ben Tilly]

"Ravicher, Daniel B." <[EMAIL PROTECTED]> wrote:
>
> > -Original Message-
> > From: David Johnson [mailto:[EMAIL PROTECTED]]
> > Sent: Saturday, January 27, 2001 3:20 PM
> > To: Angelo Schneider; [EMAIL PROTECTED]
> > Subject: Re: [Fwd: Germany]
> >
> >
> > On Saturday 27 January 2001 07:48 am, Angelo Schneider wrote:
> >
> >>  AND sure we have more than one leg to stand on. The same is true in 
>the
> >>  united states. Of course you have implied warranties. Or do you think
> >>  you can say: "Here is software, I have written it. Pay me some dollars
> >>  and you may use it. But I OWN it, still. Nope, I'm not liable if it
> >>  hurts your computer :-)"
> >
> > It is my own private opinion, and IANAL, that all commercial software
>should
> > have the basic warranty of fitness of merchantibility. Even commercial
>Open
> > Source Software should be warrantied. If the seller wishes to absolve
>himself
> > of all warranty and liability, this should be made explicitly clear to 
>the
>
> > buyer at the time of purchase.
>
>A few thoughts from someone who has passed the Bar for the wonderful state
>of NY.  First, there is no, nor can there ever be any, meaningful
>distinction between commerical and non-commerical software.  It's all
>involved in commerce, just at different points of the stream (far upstream
>is education and research and far downstream is product purchased by end
>users).  [...]

I mainly agree except for noting that open source
software may show up at the end-user level (see
Mozilla) and commercial software may show up well
upstream (Matlab comes to mind).

However that notwithstanding, I think a useful
distinction might be drawn between traditional
proprietary software and open source software.
Conceptually if you are the only one who can audit
the source, then it really is your responsibility
to validate that the software does something
reasonable and you should be liable if it is not
appropriate for what you try to sell it as.

>And, you are right, default rule is that sales of goods (software probably
>included) do come with warranties.  And your intuition is also right, that
>they are always disclaimed or absolved explicitly at the time of purchase.
>This used to mean simply telling the purchasor in writing that they are
>getting no warranties with the softaware, but because some judge thought
>this wasn't "explicit enough", now this language has to be in ALL CAPS.  
>[To
>which my response is, if people aren't going to read the warranty 
>disclaimer
>which is part of every single license agreement such that we have to make 
>it
>ALL CAPS, what does that say about the importance of the other parts of the
>license agreement?  Can we assume that since the rest of the license isn't
>in ALL CAPS the purchasor won't read it?  This means, eventually, the 
>entire
>license will have to be in ALL CAPS and thus we're back to the starting
>point with the warranty disclaimer not being explicit enough.]

If I put a grenade inside a bowling ball, and sell it to
you, should I be liable?  Even if I handed you a license
agreement that absolved me of all claims that it was
suitable for any purpose?

What about if it is a car with a marked tendancy to
explode?  A fault I knew about, and could have fixed for
$1/car?

You know, implicit warranties exist for a reason.

>Second point, software companies should be able to sell whatever they want
>for what ever price they want and with or without any warranties they want.
>IF I want to sell BS Office without any warranty and you want to sell MS
>Office with warranties, then let us compete in the market.  If consumers
>want warranties, they'll pay a premium for your product and I'll lose
>business.  If they don't then you'll lose profit by providing warranties 
>for
>product you have to sell at the same price I do.  In reality, the 
>difference
>in price between our products will be approximately the market's valuation
>of those extra warranties that you provide (assuming the Office program you
>and I sell are exactly alike).  When courts come in and regulate the
>marketplace and tell consumers what they are not allowed to buy, it only
>causes societal waste by preventing goods from moving to their highest
>valued user.  This societal waste raises costs for everyone involved.

This assumes symmetric information.  In the real world,
*PARTICULARLY* in the real world with a proprietary design
and tests that the vendor has access to and nobody else
does, this assumption is seriously broken.

To provide a real example, your *EXACT* argument was
repeated with regards to sanitation after the proof by
John Snow based on the epidemic of 1848-1849 that cholera
was carried in water and could be prevented by proper
attention to good sewage and clean water supplies.  We
can point to the very day that this argument became
unacceptable in England.  That day was December 14, 1861
and the event was the death of Prince Albert from typhoid.

In every industrialized country t

Re: Germany

[Ben Tilly]

IANAL and all that...

"Alexander Eichler" <[EMAIL PROTECTED]> wrote:
>
>Hi all,
>
>Following the IPL discussion started by intraDAT we have received quite
>some requests for information concerning legal problems with GPL in
>Germany.
>
>Under German law there are a couple of problems with Open Source Licensing,
>e.g. it is impossible under German law to have no liability for Open Source
>Software. On the other hand, GPL says that there is no liability.

Sections 11 and 12 say "to the extent permitted by
applicable law".  So the GPL does not strictly say
that, though it tries to.

>I learned that this is a problem in some states in US too.

I would hope that anyone trying to collect on such
would have serious trouble doing so.  Strange things
happen (particularly when lawyers get involved) but I
can hope.

>In Germany lawyers discuss if it is possible under copyright law to leave
>all rights to use to the public domain. GPL is not quite clear in this.
>Literature here in Germany says that GPL is founded on copyright law (same
>in US, it needs copyright law to act like it does. Conclusion is, that GPL
>is only a possibility to give the right to use to somebody else. Copyright
>beneath this still exists. So GPL is a license agreement. As any other
>agreement it can be terminated! New forms of usage of the software are not
>covered by GPL, so there might be a different license agreement for that.

My understanding (see section 5 in particular) is that
the GPL is intended to be a copyright statement that
also serves as an offer of a license.  If you proceed
to do anything which copyright law says you need
permission you either are in violation of copyright or
you agreed to the license.  (It would be assumed that
you read and agreed to the license.)

This is a novel structure in US law, and I believe it
is unclear how well it would work in court.  See:

http://www.linuxplanet.com/linuxplanet/reports/2000/1/

>In US it is said that there is no way to prevent people of distributing
>derivative works. There is a discussion whether GPL is an agreement, a
>release or a waiver. If it is a release or a waiver then the contents would
>be, that the licensor will not sue for copyright infringment. Both
>principles will not construe any contractual relationship between the
>parties. On the other hand GPL might be an agreement with the same content
>but with contractual relationship and with respective possibilitys.
>
>In Germany there is no way to do so. We do not have the principles release
>or waiver in case of copyright as far as this means that a right is given
>up. In case of the right of use it is highly discussed if such waiver is
>possible, the majority seems to deny this.
>
>So the only possible way to bring the software to the market under German
>law is to have a contractual relationship between the licensor and the user
>(unimportant in which way the software is used).

I don't see the difference you are alluding to here.
*IF* the GPL works as the design clearly intends, it
would fit what you seem to be describing.  It is a
copyright statement that grants no permissions or
waivers.  However within that copyright there is an
offer of a contract.  Accept that contract and you are
then in a position to do numerous things - BUT your
right to do them depends on your keeping your end of
the contract.

>As I understand it is possible under US and it is possible under German law
>to have the clause in the GPL, that derived works have to be licensed under
>GPL.

It is not possible to create a derived work without
permission from the copyright holder.  That permission
is offered in the GPL only if (see section 5) you agree
that derived works must be licensed under the GPL.

Again all of the grants of permissions in the GPL are
contingent upon your accepting its restrictions...

>If the author of the derived work does not give that together with GPL 
>away,
>then GPL is automatically terminated and copyright law is in act without 
>any
>modification. This should be the same in US.

That is my understanding of the intention.

Again, I am not a lawyer, the GPL has not been (to my
knowledge) tested in court, and I have not (not that I
would have) heard of any other copyright licenses which
try to blend copyright with a contract in this way.
Whether or not the license will work as designed is, I
believe, still open to question.

But the intent appears to be that the GPL should be
enforced as a contract, not a copyright.

Cheers,
Ben

PS Section 5 for those who don't know what I am getting
at is:

  5. You are not required to accept this License, since you have not
signed it.  However, nothing else grants you permission to modify or
distribute the Program or its derivative works.  These actions are
prohibited by law if you do not accept this License.  Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions 

Re: Document formats (was: To the keepers of the holy grail of Open Source)

[Ben Tilly]

Rick Moen <[EMAIL PROTECTED]> wrote:
>
>begin Ben Tilly quotation:
>
>[TeX:]
>
> > OK, so it is not open source.  And before anyone points me at standard
> > GPLed packages for TeX, allow me to point out that Knuth's software is
> > under a license that does not permit modifications.  IANAL, but AFAICS
> > if you incorporate work which you are not allowed to modify into GPLed
> > software, then you have no right to permit modifications as required
> > by section 2 of the GPL, and under section 7 you are then not allowed
> > to distribute the GPLed work as a whole.
>
>LaTex is "based on" Knuth's work in the sense that it implements the TeX
>design, but my understanding is that it is not a derivative work in a
>copyright sense, but rather was written separately by Leslie Lamport,
>and is now maintained by the LaTeX3 Project
>(http://www.latex-project.org/latex3.html).

My understanding is that it is built on top of TeX using
facilities built into TeX explicitly to allow more
complex standards to be built on top of TeX without any
changes to TeX itself.  (Which could then be frozen.)

>I could be mistaken, but am basing my comments on a quick search
>of the online FAQs and other documentation.  (I haven't examined the
>copyright notices on LaTeX's source packages.)

See http://www.latex-project.org/guides/ltx3info/node2.html
for confirmation.  See also
http://www.latex-project.org/guides/ltx3info/node4.html for
evidence that there is at present no plan to remove the
dependency upon TeX.

Cheers,
Ben
_
Get your FREE download of MSN Explorer at http://explorer.msn.com

RE: IPL as a burden

[Ben Tilly]

"Lawrence E. Rosen" <[EMAIL PROTECTED]> wrote:
>
> > OSI Certified Open Source applies to _licenses_, not _software_.
>
>Actually, no, the certification mark is applied to *software* that is
>distributed under approved *licenses*.  Certification marks cannot be
>applied to licenses, because licenses aren't "goods" distributed in
>commerce.

Then I think your position on Berkeley DB, shipped by
Sleepycat Software, would do wonders in clearing this
up.  To my eyes they are open source and they claim
to be open source.  The product is widely used and
their license seems straightforward and simple.

It boils down to saying that you are free to use this
software, with or without modificaiton, in any software
for which source is available.  You may not remove
their copyright notice.  Said notice includes contact
information in case you want to negotiate a different
license or purchase support for Berkeley DB.

The license is at http://www.sleepycat.com/license.net.

Cheers,
Ben
_
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: To the keepers of the holy grail of Open Source

[Ben Tilly]

Bryan George <[EMAIL PROTECTED]> wrote:
>
>David Johnson wrote:
> >
> > On Monday 22 January 2001 09:35 am, Bryan George wrote:
> >
> > > > Okay, I'm writing it down: "Audience = inflexible Unix bigots =>
> > > document = brain dead ASCII text".  Got it, thanks!
> >
> > Sigh...
> >
> > I don't have MS Office, and I am not about to pay for it. This has 
>nothing to
> > do with bigotry, but everything to do with my money, my harddrive space,
> > etc... And when it comes to a choice between rebooting the system to run 
>your
> > document's native OS, or shelling out yet more money to get VMWare, I'll 
>just
> > abstain.
>
>I'm just busting your chops a little, really... :)  You don't have to
>convince me of the need for a low-cost, accessible, open way to pass
>docs around - I just got a little tweaked with the "Real men use ASCII"
>crud. %b

I didn't say that real men use ASCII.  Merely that with
some audiences you have to if you want to be heard.

> > There are alternatives so use them. If the presentation you are sending 
>is
> > comprised solely of verbal content, then ASCII is sufficient. If you 
>need
> > some small amount of text formatting, try HTML. And if you need to 
>control
> > the document's appearance exactly, try PDF.
>
>I was going to suggest that - presumably anyone with pockets for Office
>can pick up a copy of Acrobat as well, and the reader's free and
>multi-platform.

Why not pick up TeX?  The output looks about as good as
you will get, it can be presented as PDF, the source is
human-readable and small, and bit-rot is zero.

Oh, and both software for reading and creating is free.

OK, so it is not open source.  And before anyone points
me at standard GPLed packages for TeX, allow me to point
out that Knuth's software is under a license that does
not permit modifications.  IANAL, but AFAICS if you
incorporate work which you are not allowed to modify
into GPLed software, then you have no right to permit
modifications as required by section 2 of the GPL, and
under section 7 you are then not allowed to distribute
the GPLed work as a whole.

Not that Knuth is likely to complain unless someone
tries to modify it in some way.  (Like Slackware made the
mistake of doing a while ago...)

Cheers,
Ben
_
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: To the keepers of the holy grail of Open Source

[Ben Tilly]

Bryan George <[EMAIL PROTECTED]> wrote:
>
>News flash: A _lot_ of technical people are using Word docs and
>PowerPoint presentations these days - Linux/VMWare is my weapon of
>choice, but there are others.

News flash: Doing so is still a good way to guarantee
that a lot of other technical people will drop your
document in the circular bin sight unseen.  Who is
your audience and what is the document for?

Cheers,
Ben
_
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: OpenDivX license

[Ben Tilly]

[EMAIL PROTECTED] wrote:
>
>on Thu, Jan 18, 2001 at 09:51:40PM -0800, Brian Behlendorf 
>([EMAIL PROTECTED]) wrote:
[...]
>A philosophical point first:  I believe that attempting standards
>enforcement through copyright licensing is fundamentally broken.  We've
>seen this tried several times, with the Artistic (control over "Perl"
>name), and SCSL licenses, the results tending to be that the license
>doesn't work as intended or doesn't meet the OSD.  Wrong tool for the
>task.

Donald Knuth enforced a standard through copyright with
TeX.  I think it worked well, even if the result is not
open source.

>I'd argue that tying allowed modification to specific compatibility
>standards is a violation of:
>
>   - Condition 3, Derived Works:  Is the original license bound to the
> same terms, or could the authors modify the code to be incompatible
> with the MPEG-4 standard.  This might be a stretch, but I'd argue it
> hard.
>
>   - Condition 6, Discrimination against fields of endeavor:  This is IMO
> far more clear cut.  Restricting application of the license to code
> meeting specific compatibility requirements is imposing a
> restriction that a work *not* adhering to this standard is not
> permitted.  The discrimination is against any field of endeavor
> which isn't directly focused on MPEG-4.
>
What do you think about permitting any change you want, but
requiring changes that break a given standard to state that
fact whenever and wherever they display notifications that
it is derived from __X__ that it does not actually meet
standard __Y__?

This could be useful for reference implementations.  There
might be absolutely no problem with borrowing code from the
implementation and using anywhere.  However it is important
to require that if it is used in something not compatible
with the standard that there be no possibility of creating
confusion with the standard.

Cheers,
Ben
_
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: To the keepers of the holy grail of Open Source

[Ben Tilly]

Jorg Janke <[EMAIL PROTECTED]> wrote:
>
>I would like to raise three issues:
>a) License issues
>b) Compiere license
>b) Open Source Trademark
>
>a) General License issues
>---
>- I am a bit frustrated about the process; I had to submit our suggestion
>three times before receiving the first feedback.

It would help if you sent mails as regular ASCII rather
than formatted HTML.

This is a question of knowing your audience.  HTML can
be made to look nice, which means that it will go over
well with suits.  However it suffers from bit-rot,
displays differently on different platforms, is more
complex for standard text tools to process, etc.
Therefore technical types tend to see HTML email in
the same category as Word and Powerpoint attachments -
a sign that the sender is not technical and does not
have a clue about how the technical community works.

So say it in ASCII.  It may not look as pretty to you,
but it will go over a lot better with us.

>- If you only want to deal with the Fortune 1000 - please say so.

Actually the Open Source community has a lot of people
who are very distrustful of the standard Fortune 1000.

>- The current "ready to use" licenses available are inconsistent and there
>is no guideline when to use what

They are not consistent with each other because they are
trying to address incompatible goals.  What guidelines
would you like?  Any guidelines are opinions based on
current goals, ideology, and position.

>- If you want to take the Open Source License seriously, but don't want to
>deal with the "little guys", I suggest you come up with some templates - or
>do something like eTrust
>http://www.etrust.com/webpublishers/pub_resourceguide.html

Actually the continuing proliferation of licenses is
generally agreed to be undesirable.  People seem to
want to create licenses that protect themselves in
some way.  But if you take code licensed under two
different licenses designed that way, you usually are
unable to borrow.  That reduces the ability to use
opened code, or to easily add interesting functionality
to it.

My strong advice would be to carefully consider what it
is you wish to accomplish and use an existing license.

>- I don't think that people would mind the alternative: use one of the
>following templates or pay a fee for us looking at the license - assuming
>that there are templates available and some guideline for non-lawyers when
>to use which.

Templates for stamping out licenses by the dozen would be
a very bad development.  But it would be good if the
"common knowledge" about what licenses are good for what
were gathered in one place rather than having to be
discovered through experience.

>b) Compiere License (www.compiere.org/license.txt or
>www.compiere.org/license.html)
>--
>- The feedback/critique I received was valid, but my reply unanswered.
>- Could you please tell me if I should just forget about it, come back
>later,  ?

Make your license straight ASCII.

Also I would suggest reading

  http://www.gnu.org/philosophy/bsd.html

and then thinking about your license carefully.  You
are basically trying to trade software for branding.
Unfortunately this is a model that quickly becomes
prohibitive when you share code.  As a result even if
you get the official OSI label, you will find
relatively few people are willing to use your code,
and you will be on your own for deciding what code you
can use.

If you use an existing license then at the least people
will be able to give you advice on what code-bases you
are able to freely borrow from without having to study
your license closely.

>c) Open Source Trademark
>
>- As you know, the 'characteristics' of Open Source projects are very
>different.  Recently, there are quite a few companies using the Open Source
>as marketing tool (in addition to the failed commercial projects)

The failed commercial projects are not as failed as you
think.  Relative to the stock bubble silliness they have
come down.  Relative to the estimates that an intelligent
person could have come up with based on the literature at
the time?  They are doing quite well for companies with
their real size and history.

Many other companies moved to an open source model when
it probably was not the greatest fit because of the
bubble.  Many of them are in serious trouble.  OTOH the
same is true through the entire .com sector.

>- I think, you guys need to come up with some guidelines on 'ethical' Open
>Source projects. I realize that there is a fine line ... and Tim O'Reilly
>would not support an Open Book Source project similar to the original
>Napster.

I believe that OSD was intended as such a guideline.  And
Tim O'Reilly is open to experiments, and indeed has tried
some open source books.  Whether or not to do that is up
to the author.  More than one example exists where a
project did the O'Reilly book and also turned the
technical work in

Re: OSI compliance requiring software to be "free beer"?

[Ben Tilly]

Several points.

1) You are seriously misrepresenting what was said.
2) It has been made very clear to you that you will not get
   approval.
3) In all likelyhood you are charging someone money for the
   time spent wasting our bandwidth.  This is the most
   likely explanation for your continued idiotic obstinance.
   At this point you are wasting money and generating bad
   feelings towards Intradat.  You should stop and consider
   whether continuing to damage your client's interests is
   wise.

Regards,
Ben

Manfred Schmid <[EMAIL PROTECTED]> wrote:
>
>Dear Board Members:
>
>I follow up on the discussions on [EMAIL PROTECTED]
>concerning our IPL / Developer Program Model.
>
>We know, that up to now Open Source Software has been free both in the
>meaning of "free speech" and "free beer". We want to introduce a model
>that guarantees free speech but takes the free beer aspect away.
>
>Under certain conditions, IPL requires you to pay the prices according
>to our price list, if you want to use IPLed software.
>
>Within the discussion it turned out, that most participants argued, Open
>Source Software has to be free in the sense of "free beer", i.e.
>requiring the user to pay license fees will be a no-go for OSI approval.
>
>We have not found any such restriction being officially published.
>
>We do not want to change the definition of Open Source, nor do we want
>to correct GPL etc. For us, Open Source covers a continuum defined by
>freedom, competition and the availability, changeability and
>distribution of Source Code.
>
>We think, Open Source as a term should cover all the already OSI
>approved licenses (free source) as well as IPL like models.
>
>I hereby request an official Board statement: Does OSI approval of
>licenses require the software to be free in the sense of "free beer"?
>
>Manfred Schmid
>
>--
>
>-
>intraDAT AG
>Wilhelm-Leuschner-Strasse 7 u. 9-11
>D - 60329 Frankfurt a. M., Germany
>Tel.: +49-(0)69-25629-0
>Fax:  +49-(0)69-25629-256
>http://www.intradat.com
>-

_
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: Open Source *Game* Programming?

[Ben Tilly]

Ken Arromdee <[EMAIL PROTECTED]>
>To: Ben Tilly <[EMAIL PROTECTED]>
>CC: [EMAIL PROTECTED], [EMAIL PROTECTED]
>Subject: Re: Open Source *Game* Programming?
>Date: Wed, 17 Jan 2001 13:26:04 -0800 (PST)
>
>On Wed, 17 Jan 2001, Ben Tilly wrote:
> > IANAL but I think the general reaction would be that the
> > graphics are part of the overall work and said game company
> > would then be obliged to also give away the graphics,
> > which you would then have access to.
>
>Doom and Quake have been released as GPL.  Graphics and data files have 
>not.
>By this reasoning, anyone except the creators of Doom or Quake could not
>distribute those programs at all, since the graphics are necessary to use
>the program and they are not open source.

I am quoting from section 3:

: The source code for a work means the preferred form of the work for
: making modifications to it.  For an executable work, complete source
: code means all the source code for all modules it contains, plus any
: associated interface definition files, plus the scripts used to
: control compilation and installation of the executable.[...]

Do graphics and data files count as "interface definition
files"?  I really don't know.

In any case I would consider it a hole in the GPL if things
like essential parts of the user interface (ie graphics)
did not need to be made available while the work as a whole
was GPLed.

Cheers,
Ben
_
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: Free Software Licensing Strategy -- Some guidelines

[Ben Tilly]

Tom Hull <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
> >
[...]
> > 1. Understand the standard licensing models
> > ---
>
><...>
>
> > The Artistic License is notable for its use with the Perl programming
> > language, however, it's a somewhat eclectic and ambiguous document.
>
>My take is that the Artistic License is mostly an argument with GPL over
>what constitutes a derived work: in particular, it disclaims embedding
>(like the Guile license) and command extensions (regardless of how they
>are implemented), and it does so in ways that are very specific to Perl.
>(That is, one has to rewrite the license to apply it to anything else.)
[...]

My understanding is that the Artistic License is a feel-good
document which is legal Swiss cheese.  It certainly does not
achieve its stated aim, is probably not legally enforcable,
if it were it would be trivial to subvert, and there are
multiple versions out there.  (Having had the wording of the
version in Perl modified several times without getting the
explicit permission of all copyright holders makes its status
somewhat...nebulous.)

I don't think that it should be generally used.

IANAL and this is not legal advice.

Cheers,
Ben
_
Get your FREE download of MSN Explorer at http://explorer.msn.com

RE: IPL as a burden

[Ben Tilly]

"Carter Bullard" <[EMAIL PROTECTED]> wrote:
>
>Gentle people,
>I'm not a laywer so if I'm missing something, please fill in.

IANAL as well.

> > From: Gregor Hoffleit [mailto:[EMAIL PROTECTED]]
> >
> > Well, the GPL says this:
> >
> > "Activities other than copying, distribution and
> > modification are not
> > covered by this License; they are outside its scope."
>
>Appears that the GPL does not grant any rights
>relating to executing the Program based on this clause.

That appears correct.

> > "The act of running the Program is not restricted, and
> > the output from the Program is covered only if its contents
> > constitute a work based on the Program (independent of
> > having been made by running the Program). Whether that is
> > true depends on what the Program does."
>
>The act of executing the Program is not restricted, but it
>also doesn't appear to be granted by the GPL, as it is out
>of scope of the GPL.  Even when the output of the Program
>is "covered", there is no text describing what rights would
>be granted to the user of the output.  Although there may be
>an implication that the GPL may allow the user to "copy,
>distribute and modify" the Program output, that doesn't
>implicitly grant any rights to the use of the output.
>
That is correct.  If I use a GPLed compiler, and the
output does not qualify under copyright law as a work
based on the compiler, then the binary which results
need not be GPLed.

The GPL is based on having copyright.  If the author of
the GPLed software does not have copyright on the final
product of the work, then how can they put a copyright
license on it?

> > and
> >
> >   "6. Each time you redistribute the Program (or any work based on the
> > Program), the recipient automatically receives a license from the
> > original licensor to copy, distribute or modify the Program subject to
> > these terms and conditions.  You may not impose any further
> > restrictions on the recipients' exercise of the rights granted herein.
> > You are not responsible for enforcing compliance by third parties to
> > this License."
> >
> >
>
>Because the recipients' rights granted by the GPL do not apply to
>executing the Program, restrictions on executing the Program would
>not impose any further restrictions on any rights granted by the
>GPL.
>
My understanding is that the copy of the software that you
get is yours.  Your use of your software is covered in
copyright law under "fair use".  This is not equivalent to
a standard commercial license where you do not own the
bits sitting inside of your computer, but have merely
licensed the right to use them.

Whether the latter should be legally valid has been a
subject of some debate.  The industry dearly wants it to be
so, and is currently trying to get UCITA passed, which
would codify it in laws.  Consumer advocates are of the
opinion that not only should it not be so, but that it is
high time for some lemon laws.

Open source software does not stand to benefit from UCITA,
but could stand to lose from lemon laws.  All factors
considered, it is likely that open source software would
receive some loophole in any lemon laws that were passed.
>
>Carter
>
>Carter Bullard
>QoSient, LLC
>300 E. 56th Street, Suite 18K
>New York, New York  10022
>
>[EMAIL PROTECTED]
>Phone +1 212 813-9426
>Fax   +1 212 813-9426
>
People who put their addresses in email always astound me.
You never know what nut might be just a few blocks away. *

Cheers,
Ben

* Me for instance!  (No joke.)
_
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: Open Source *Game* Programming?

[Ben Tilly]

Henningsen <[EMAIL PROTECTED]> wrote:
>
>I would like some advice on what to do in my situation. I am developing
>artificial intelligence modules for computer games, and model games to
>demonstrate and test them. I would like to do that in an open source
>environment, and would like my code to be used widely in other open source
>games. However, the only chance I have of ever seeing my creations in a
>first class game is if they are picked up by a commercial publisher who 
>then
>will have to pay about a million dollars largely for graphics to get the
>game up to AAA standards. If I publish under the GPL (as I have done) or 
>any
>of the other open source licenses I have seen and understood, a publisher
>could simply take my work, add modifications to my code (to which I would
>have access, since they would have to be open source also), add his
>copyrighted graphics (to which I would >>not<< get access to use in my own
>versions of the game, because graphics that goes with code is not covered 
>in
>open source licenses), and then he could sell it without giving me either
>royalties or proper artistic credit (credit in the source files and the
>Readme file is worthless in a game). I don't think this would be fair, and
>therefore I will not release my work under a license that makes this 
>possible.

IANAL but I think the general reaction would be that the
graphics are part of the overall work and said game company
would then be obliged to also give away the graphics,
which you would then have access to.

This would limit their ability to achieve revenue.  The
most viable model that I can think of off-hande would be a
shareware model.  In fact I have never seen commentary on
it but I suspect that it indeed *would* be viable to market
GPLed software as shareware.  As long as you only got
reminders to pay but were not crippled, there is no problem
for them asking all they want for people to pay them money.
Sure, someone would post a version without the messsages.
But pirates do that all of the time anyways.

And no, you would not get royalties from that.  OTOH you
and their competitors would get to peek and borrow from the
code...

Still a small company might find that viable, if only for
the publicity of having done it.

>The type of license I am looking for is one that is basically like the GPL
>for non-commercial users, but that requires commercial users of my software
>to acquire a license from me (which implies that I will be paid and get
>artistic credit). Or else, a license that would force any graphics bundled
>with my code to become freely available, and that would ensure that I get
>proper artistic credit. So my questions are simple:
>
>Is there any open source certified license that meets these criteria? If
>not, is it possible to write one? Does anyone in the OSI have an interest 
>in
>addressing these specific problems faced by most open source *game* 
>developers?

I would recommend the strategy that Sleepycat follows with
Berkeley DB.  Dual-license.  Give the code away under a
license which commercial developers will generally not want
to follow, and also offer to sell commercial licenses.

>And a more philosophical question: If it is against the spirit of open
>source to require commercial users to buy a license, why is that? I think 
>it
>is perverse to require me to offer my work as a donation to Microsoft and
>other game publishers just so I can use SourceForge. Remember, the
>modifications a publisher might make to my code are worth nothing. The
>graphics is what is valuable.

As I just spent some time in another thread explaining,
the purpose of open source is to give protections to all
users of open source software.  The main thrust of these
protections is to avoid the possibility of being tied to
a vendor which can use legal tactics to discourage
competition in the free software market.

Not only are companies among "all users", as big potential
customers they are often key to making it possible for a
competitor to get started...

Cheers,
Ben
_
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: IPL as a burden

[Ben Tilly]

Manfred Schmid <[EMAIL PROTECTED]> wrote:
>
>clause O:
>
>"Activities other than copying, distribution and modification are not
>covered by this License; they are outside its scope."
>
> > The GPL does cover running the software.  In clause 0 I
> > see, "The act of running the Program is not restricted..."
> >
>
>As a lawyer I would argue that it should read "...by this license...".
>Clause 2 c) states "... you MUST cause it [...] to print or display
>announcement including an appropriate copyright  ". Looks to me like
>a (perfectly rational) restriction.

My understanding of the position of the FSF on this matter
is that you own your copy of the software.  Unlike a
typical shrinkwrape license where you have licensed the
use of it from the owner, that copy is really yours.
Given that you own it, running it is covered by fair use.
Therefore the act of running code that you own is not
restricted because it is not restricted in copyright law
and you have not agreed to anything which could limit that
right.

The second quote from part 2c is a restriction on what
modifications may be made.  When you modify the code you
must cause it to display your copyright information if it
normally displays any others.  This is not a restriction on
what you may do while running, nor is it even a requirement
to display copyright information.  It has nothing to do
section 7 of the OSD.

Now you are going to claim that this is a limitation on
item 3 of the OSD.  And you are absolutely correct.  (In
fact I noted in my first email that it was not clear that
you conflicted with section 3, but I thought that a fault
of the OSD, not a validation of what you seek to do in
your license.) It is a point in the OSD that IMHO could
use some clarification.

But the clarification that is likely to happen will not
be to your liking.

>If OSD #7 is not part of GPL, there might be a playground for lawfirms.
>All that is legal stuff and we are not judges, so lets leave the topic
>out. I do not want to challenge GPL.
>
The interpretation that I have seen Richard Stallman
state does indeed cover OSD #7.  As you say, challenges
to that are a matter for judges, not us.
>
> > The OSD is a commonly accepted definition of exactly
> > that.  Software which is delivered under an OSD
> > compatible license comes with a guarantee that there is
> > no legal barrier to having a free market for upgrades,
> > bug-fixes, training and support.  Whether or not there
> > will actually be a viable market in upgrades, bug-fixes,
> > training and support will depend on applicable free
> > market forces.  But no vendor has the ability to wave
> > around a legal document and run potential competition out
> > of town.
> >
> > *ANY* licensing move that you make to guarantee yourself
> > the ability to restrict such competition means that the
> > customer no longer can count on that freedom.  Therefore
> > any such move should make it impossible to certify you
> > as having a license that offers such protection.
> >
>
>We are not restricting competition. Opening the source will increase
>competition for us and it is a good and solid principle at the basis of
>capitalism :)

When you have two competitors selling a product, and all
sales to either company result in license fees going to
one of those competitors, they are not on an even playing
field.  The dramatic resulting effect may be seen from
some of the OEM policies that Microsoft managed to get
away with.

>Any company may provide upgrades, bug-fixes, training, support or
>wahtever they feel reasonable in the context of IPLed software. There is
>no such restriction in IPL. If you find one, we will take it out.

The original version required companies provided support
and services to pay you non-zero license fees (while the
end customers receieved free licenses).  Given that you
choose your competitor's cost here, no sane competitor
would go head to head against you in that market.

>If you would choose for example to develop upgrades for IPLed software
>and market it under whatever business model, you are free to do so. All
>that IPL requires is, that the company running the software sticks to
>IPL and has eventually had a look at our price list. You are able to
>introduce your upgrades at the heart of any IPLed software since you
>have the source and you are legally entitled to do it.

And what was the licence requirement that you had?

>If you are able to provide better upgrades etc. than we are, we have
>done a poor job. However it will help the guy running it and thats what
>competition is for.

Again, your license is founded upon the principle of finding
ways to make the source-code available but leaving you with
sufficient control to ensure that money will be paid to you.

That is a huge head start and realistically is a very high
barrier to competition.

>Still my understanding is, that open source does not mean free beer. Do
>you agree on this point?
>
We not only agree, but I have pointed out specific

Re: IPL as a burden

[Ben Tilly]

Manfred Schmid <[EMAIL PROTECTED]> wrote:
>
> > I'm sorry, I was thinking that you were talking about using an open
> > source license, and then claiming license fees on top of that.  Now I
> > understand that you were just continuing your claim that requiring
> > license fees was compatible with open source.  That's interesting; I
> > don't see a clear statement in the OSD that recipients of a program be
> > permitted to run it.
> >
> > Nevertheless, if the recipient of an open source program can not run
> > it without an additional license, where the license itself is the only
> > obstacle (that is, no other software is required, just the license
> > itself), I feel certain that that program is not actually open source.
> >
>
>It is indeed interesting that GPL does not address the matter ofrunning
>a GPLed program. From a legal standpoint it might be interesting, if the
>OSD is an inegral part of GPL or not. From a non-legal standpoint I
>would argue that OSD #7 covers that matter.

The GPL does cover running the software.  In clause 0 I
see, "The act of running the Program is not restricted..."

>Still I do not see IPL being incompliant with the OSDs. we explicitely
>address the matter of running an IPLed program and state that license
>fees may apply.

I see it as being completely not compliant with both the
letter of the OSD and the intent.  You have been told in
no undertain terms (including by some of the people who
would actually make an official certification decision
- and no, I am not in that list) that any kind of
licensing fee or requirement for another license will
not fly.

>We do not feel that the license is an obstacle. Free Software mens free
>speach, not free beer (adopted from gnu.org)
>All you will have to do is pay the price asked for, if applicable.

The people you need to convince have told you that it is
an obstacle and they will not budge.  Indeed similar
issues have come up and their position is clear.  I have
given you fairly detailed explanations of where you are
going wrong.

> > If I want to run your program on several different computers, then
> > removing the license information is clearly an improvement for me.
> > With open source programs, you don't get to define what an improvement
> > is.  I do.
> >
>
>You do have to stick to the license terms and the definition of an
>improvement is not totally up to you.

Indeed you have to stick to license terms.  If you did
not then there would be no value in having a clear
definition of what software comes under license terms
that gives the end user protection from being caught at
some point by a legally enforced monopoly.  It is
exactly because you have to stick to license terms that
there is value to consumers in that.

The OSD is a commonly accepted definition of exactly
that.  Software which is delivered under an OSD
compatible license comes with a guarantee that there is
no legal barrier to having a free market for upgrades,
bug-fixes, training and support.  Whether or not there
will actually be a viable market in upgrades, bug-fixes,
training and support will depend on applicable free
market forces.  But no vendor has the ability to wave
around a legal document and run potential competition out
of town.

*ANY* licensing move that you make to guarantee yourself
the ability to restrict such competition means that the
customer no longer can count on that freedom.  Therefore
any such move should make it impossible to certify you
as having a license that offers such protection.

THAT is why your license is not open source.  It may well
be perfectly legal.  It just isn't an open source license.

(As an aside to anyone still reading, if my description is
in any way incorrect, please correct me.)

[...]
> > That one step is taking you out of the realm of open source.
>
>I still do not understand why that should be the case.

Please read my description of what the OSD certification
is supposed to mean, compare to what your license says,
and get back to me if you don't understand how your
license tries to remove protections that are key to being
an open source license.

[...]
> > I want to stress that I am not saying that you should not use the
> > license.  I am saying that you should not call this license ``open
> > source.''
> >
>
>Besides being able to "officially" call it Open Source and get the
>license approved, we think it is a good step to open the source and make
>it publicly available. We have thought a lot about it and feel it is the
>best for all the parties involved.

That is your decision, and there are good arguments which
may be made for doing that, even under a license that is
not open source.  However I note that experiments by Sun
and others to try and get developers to accept halfway
open license have generally failed abysmally.

>Still we would like to get approval.

That will not happen while your license fails to offer the
protections that OSD certification is supposed to provide.

Regards,
Ben
___

Re: Misunderstanding of the basics?

[Ben Tilly]

Ralf Schwoebel <[EMAIL PROTECTED]> wrote:
>
>Hi Ben,
>
>thanks for the open :) reply...

I just want to make sure that there is no
misunderstanding on either part here.

>Ben Tilly wrote:
>
> > My first comment is that we don't need an additional
> > license.
>
>Mine would be: we finally need one that works (even in such
>small and unimportant countries like Germany)...

We have many open source licenses that work perfectly
well, even in Germany.

That they don't do what you want has more to do with
the fact that you don't want to be open source than
it has to do with any failings of the licenses in
question.

> > My second comment is that if this meets the open
> > source definition then that is a flaw in the
> > definition.
>
>Or intented to be like that? I see nowhere the sentence:
>"Do not charge money for software under the license XXXPL)

The entire point of an open source license is not to
restrict people's ability to make money, it is to
create significant and visible barriers to creating
a MONOPOLY.  Every clause that I dislike in your
license has to do with creating and giving you
monopoly control over software.

> > requirement conflicts with item 7 of the open
> > source definition.  (You may not require an
> > additional license.)
>
>I do not see a point there, there are a lot of companies
>out there, which mix GPL and MPL or like Lutris who
>mixes closed source with GPL parts. If you markup these
>parts, it's fine.

You may not give on the one hand and take on the
other hand.  If your license requires additional
licenses and those licenses are not open source,
then the whole is not very open.  Therefore the
possibility of creating a monopoly that way is
restricted.

> > My fourth comment is that 3.3 (that the code for
> > license keys cannot be deleted and must be
> > included in anything that copies from the software)
>
>=> if there is a license key check you are not allowed to
>  do that with GPL either... but GPL is so weak that it is
>  not even mentioned...

If there is a license key check in GPLed software
you can take it out.  This is not a weakness in
the GPL.  This is a protection against would be
fascist monopolists.

> > may or may not meet item 3 of the open source
> > definition (derived works) but to the extent it
> > does shows a flaw in the wording of that section.
>
>Definitly not, the license GARANTEES the openess of the source
>and covers more eventuality than the GPL in that part.
>Seriously: the IPL is capitalism for OpenSource with the
>whole philosophy and ideas behind the GPL.

When you claim that open source means one thing,
and people who are established in open source
disagrees with you, which is more reasonable, that
everyone else is wrong or that you are wrong?

Again the key point is to offer protection against
would-be monopolists.  You don't do that, and do
not even appear to understand why that matters.

>I just got the feeling that everybody is afraid of using that
>ugly word "money" in combination with the word "OpenSource".

Why are you confusing monopoly with money?

Are your products and services so bad that you
don't think that you can shove them down people's
throats without the support of lawyers and courts?

>If you use the IPL, and we will encourage everybody to, you
>can or you can't charge license fees for that. If you do, you are
>a "classical" software company that delivers the source with the
>application, if you do not, you are an real OpenSource company.

If you use the IPL then you are not open source.

If you use it and claim to be open source then
you will have a bad public relations problem.
Because you are not open source and lies to the
contrary will result in people advising others
to boycott you.

But considering how your company stands to get
a monopoly from others using your license, I
can see why you want to encourage everyone to
do so.  I cannot see why they would want to be
so foolish though.

> > My fifth comment is that section 5.2 (requiring
> > fees from anyone doing modification and support
> > for third parties) is particuarly awful, and IMO
> > violates sections 5 and 6 of the open source
> > definition.
>
>That is again not true, because the license fee could be
>ZERO and then it is like you want it... GPL comes from the
>other end and now has problems to reach the capitalism level.

It is NOT how I like it.

If I am trying to get something reinstalled at 2 AM I
don't want to have to worry about your PoS license
key.

If I build an internal application I don't want to
have to worry that in 5 years I may be SOL because
you have gone out of business and I don't have any
way to get a license key for my 

Re: IPL as a burden

[Ben Tilly]

Ralf Schwoebel <[EMAIL PROTECTED]> wrote:
>
>Frank LaMonica wrote:
>
> > but differ from the GPL or LGPL.   Each such license places additional 
>burdens on
> > the entire open source community.  Those burdens devolve from the 
>inevitable
>
>Dear Frank,
>
>thanks for the input, but I have to disagree. The lack of the word
>money is the burden of the OpenSource community and even companies
>like VA or RedHat have to feel that these days. And the GPL comes
>from a time when students changed the world and coolness was a skill.

It is clear that you don't understand open source.

>Now we have 2001 and the idea of Open Source needs a kick, because
>we need applications now and everybody thinks its cooler to work
>on an operating system, not an application.
>We see no other possibility than enabling people to charge money for
>sources without violating the basics of OpenSource:

You are not producing open source.  You are producing
something that violates every principle of open source
and then lying by calling it open source.  If you wish
to produce proprietary software, go ahead.  But don't
try to lie and call it open source.

>Anyone is allowed to use the software, everybody has access to
>the sources, etc. pp.

They are only allowed if they have your license key.

I am not allowed to take my knowledge of your software
and freely start a consulting business if I think that
you have been doing a piss-poor job.

This is not open source.

>This money goes to the developers and they can pay their bills.
>
>And by the way:
>Our license is approved by a very good and accepted lawyer in
>Washington DC (some senators and HUGE software vendors agree to that)
>and is suitable for the Virginia law, since software licenses have to
>fit the state laws, not the federal law in the US.
>
UCITA is generally detested by all except
organizations whose attitudes towards intellectual
property are also generally detested.

Once again, your license is not open source.  Nor
will you find that people in the open source
community generally willing to accept it.

Regards,
Ben
_
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: Request for approval: IPL 1.0

[Ben Tilly]

Ralf Schwoebel <[EMAIL PROTECTED]> wrote:
>Hi Everybody,
>
>hereby we release our OpenSource license as announced in the last
>Open magazine. We are sure that we fullfill the basics from the
>http://www.opensource.org/osd.html
>page, but we already got some feedback like:
>
>"...there is no need for an additional license..."
>
>from the german jurisdiction point of view, we totally disagree.
>
>We kindly ask for serious comments.
>
My first comment is that we don't need an additional
license.

My second comment is that if this meets the open
source definition then that is a flaw in the
definition.

My third comment is that 2.2.a (that people with
this license can use the software appears to me
to be in serious conflict with 3.1 (that people
may need license keys from IPL to run this
software).  You may claim that is because the
section in 2.2.a is subject to other intellectual
property claims.  Be that as it may, but your
requirement conflicts with item 7 of the open
source definition.  (You may not require an
additional license.)

My fourth comment is that 3.3 (that the code for
license keys cannot be deleted and must be
included in anything that copies from the software)
may or may not meet item 3 of the open source
definition (derived works) but to the extent it
does shows a flaw in the wording of that section.

My fifth comment is that section 5.2 (requiring
fees from anyone doing modification and support
for third parties) is particuarly awful, and IMO
violates sections 5 and 6 of the open source
definition.

I could go on, but let me summarize.

I am not a lawyer.  But I do not believe that you
have met the open source definition.  If your
license is by some miracle accepted by the OSI as
being compliant, I will consider that a failure
of the process and not a recommendation for your
license.  I will refuse to use or recommend any
software produced under this license.  I suspect
from your license that you are unclear on what
this whole open-source thing is.

Regards,
Ben Tilly

>best regards,
>Ralf "puzzler" Schwoebel
>CEO, intraDAT international inc.
>11250 Roger Bacon Drive (#3)
>Reston, VA 20190
>Tel.: 703 796 
>
>** snip
>intraDAT Public License
>Version 1.0.0
>---
>
>Please read this Agreement carefully before using, copying, modifying or
>distributing the intraDAT Public License Code ("IPL Code"). It will only
>be
>licensed to you if you first accept the terms of this Agreement. By
>using,
>copying, modifying or distributing the IPL Code, you indicate your
>acceptance
>of this license and all its terms and conditions for the IPL Code or
>works based
>on it. Nothing other than this license grants you permission to use,
>copy,
>modify or distribute the IPL Code or its derivative works. If you do not
>agree
>to the terms of this Agreement, promptly notify the provider of the IPL
>Code
>and delete the IPL Code and all copies of the IPL Code immediately from
>any of
>your storage media. You are not allowed to separate or to modify this
>License
>from the IPL Code.
>
>Note: This license is not identical to any of the GNU Licenses published
>by
>the Free Software Foundation. Its terms are substantially different from
>those
>of the GNU Licenses.
>
>Copyright of this Text: intraDAT, Wilhelm-Leuschner-Straße 9-11, 60329
>Frankfurt am Main, Germany and Alexander Eichler, Graf von Westphalen
>Fritze &
>Modest, Marsstraße 33, 80335 München
>
>1. Definition
>
>1.1. "Distribution" means to copy the IPL Code in part or total for or
>to one
>or several third parties. This includes both the active copying (e.g. in
>form
>of a transmission) as well as to place the IPL Code in part or total at
>the
>disposal of third parties (e.g. ftp server or  CD-Rom).
>
>1.2. "Distributor" means somebody who distributes, different from
>intraDAT.
>
>1.3. "Documentation" means the documentation given in electronic or
>paper form
>for users and/or developers. Documentation will be provided in English
>language.
>There is no obligation for any other language, but parts of the
>Documentation
>might be given additionally in other languages.
>
>1.4. "IPL Code" (intraDAT Public License Code) means the Software as
>licensed
>by intraDAT under these clauses in form of source and/or object code.
>User will
>find the exact definition of "IPL Code" in form of program names and
>version
>numbers on www.intradat.com.
>
>1.5. "Source Code": The source code for a work means the preferred form
>of the
>work for making modifications to it. For an execu

Re: Free documentation licenses

[Ben Tilly]

Karsten Self wrote:
>
>on Tue, Nov 28, 2000 at 05:26:20PM -0500, John Cowan 
>([EMAIL PROTECTED]) wrote:
> > [EMAIL PROTECTED] wrote:
[...]
>The way I read 3(c), the GNU GPL refers to the program, but doesn't 
>preclude
>its inclusion into a larger, ***nonprogram*** work:
[...]

I think section 2 has a lot to say about this.  Its wording
makes no - and allows no - distinction between programs and
non-programs.  However you may aggregate works together.
So even though documentation and your program are distributed
together, since each can be used independently of the other
I would argue that that is just aggregation.

An interesting precedent that related things shipped together
need not be a single work under the GPL - the text of the GPL
(which is shipped with many GPLed products) has a copyright
that is in no way compatible with being part of a GPLed
whole!

Cheers,
Ben

PS IANAL etc.
_
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com

Re: Qt/Embedded

[Ben Tilly]

David Johnson wrote:
>
>On Friday 17 November 2000 01:20 am, [EMAIL PROTECTED] wrote:
>
> > The idea is that, if a program is a work, and if (as the courts have
> > held, in Mai v. Peak) a program in memory meets the fixed and tangible
> > requirements of copyright law, and is therefore a copy under copyright
> > law, then a program linked to a library at runtime is a derivative work.
>
>I've heard this before, but I've always dismissed it as hearsay. I will 
>have
>to look up Mai v Peak. The implications of this are mind-boggling! Does
>Stephen King have rights to my brain because I've read his books and 
>they're
>now in my memory?

Yes. :-)

And if your brain, influenced by Mr. King puts out a work
that looks like something he wrote, he can sue you for it!

Cheers,
Ben

PS IANAL and I partly wrote that just to tease you. :-)
_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

Re: Another pass at redrafting the Artistic License

[Ben Tilly]

David Johnson wrote:
>
>On Sat, 16 Sep 2000, Ben Tilly wrote:
>
> > >My view of "proper" OSS and FS licenses is that they grant additional
> > >permissions to the user beyond those offered by copyright, but take
> > >away none of the rights of the user that copyright allows. You can give
> > >but you can't take away.
> >
> > Then this clearly is not a "proper" FS license.  Basically it
> > says, "If you want to play in our sandbox, you have to follow
> > Larry's rules.  If you just want to play with our toys, go
> > ahead as long as you don't mess with our sandbox."
>
>Perhaps I didn't clarify myself. I find it perfectly acceptable for a
>permission to have conditions. IANAL though, and I could be
>completely off base here. Basically, one can say "you have permission to
>play in our sandbox so long as you follow our rules, but if you don't
>follow our rules then the law says that you can't play in other people's
>sandboxes anyway."

I have been told by lawyers that you can say it, but you cannot
necessarily enforce the rules.  For instance I was just told (and
find believable) that statements about, "You cannot represent this
as your own unless it is, and cannot the copyright holders and
contributer's names for endorsement without express written
permission" cannot be enforced as part of a copyright.  It can be
as part of a contract.

>A license along the lines of "you can do x, y and x provided
>that you also do 1, 2 and 3" may technically be a contract, but it
>doesn't require contract law for enforcement.

It may.  If you require stuff not covered in copyright law you
are SOL if someone doesn't do them.

Or at least so I have been told.

>One problem with contract/agreement "based" licenses is what happens
>if someone doesn't agree? If you are unable to protect the software
>with copyright, then you have no recourse if someone disagrees with the
>contract. I think the GPL got it right when it said "These actions are
>prohibited by law [copyright] if you do not accept this License".

Which makes the GPL a contract.  Enforcable under contract law,
in addition to copyright law.  As I understand it for roughly
the same reasons I am trying to do that.

> > There are two items that do not fall under copyright law in
> > there.  The first is that you really want something somewhere
> > saying that, "Yes, all developers really agreed to our
> > ground-rules."  Doesn't have to be here, I just think it is
> > a convenient place to put it and avoid paperwork.
>
>Okay, fair enough...

One note.  To quote Tom Christiansen: "I take it as an article of
faith that Larry Wall would never actually sue anyone."  So if you
do not like something in the draft, remember that that is the kind
of person on the other end. :-)

Cheers,
Ben
_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

Re: Another pass at redrafting the Artistic License

[Ben Tilly]

David Johnson wrote:
>
>On Fri, 15 Sep 2000, Ben Tilly wrote:
>
[...]
> > Does that answer why I might want to propose a major rewrite?
>
>Yes it does. If it's broke fix it, but it seems as if your trading in
>the broken hunk for a completely different model :-)

I am.  It is a model based on the stated feelings of core
Perl people about what they care about.  Basically it falls
under, "Don't screw us over and we'll share."

> > Now why the structure?  Well I am borrowing from the GPL the
> > idea of having a license which is also used as a contract
> > agreement.  (Read section 5.)  My understanding is that that
> > allows you to have provisions enforcable under contract law,
> > which allows you to enforce lots of things that copyright
> > law won't.
>
>Okay, this is my opinion, and as such I expect it to hit the bit bucket
>microseconds after delivery...

Noted.

>My view of "proper" OSS and FS licenses is that they grant additional
>permissions to the user beyond those offered by copyright, but take
>away none of the rights of the user that copyright allows. You can give
>but you can't take away.

Then this clearly is not a "proper" FS license.  Basically it
says, "If you want to play in our sandbox, you have to follow
Larry's rules.  If you just want to play with our toys, go
ahead as long as you don't mess with our sandbox."

Playing by Larry's rules means that Larry should be able to
say, "XYZ accidentally did foo.  I told them it wasn't going
to be a big deal. but their lawyers want to know if I can
really say that.  Can I?"  He shouldn't have to track down
every last copyright holder, get their attention, and say,
"Can I say this?"

You can't do that unless your contributers have all agreed in
advance that you can.  Most certainly copyright law by itself
won't cut it.

If a license follows this guideline, then
>there is nothing that cannot be enforced by copyright law.  IANAL, but
>it seems that if someone went against the terms of a copyright-based
>license, they would be in violation of copyright law regardless of the
>presence of any agreement or contract.

You have a circular definition of copyright-based, it is
copyright-based if it can be defended under copyright law. :-)

There are two items that do not fall under copyright law in
there.  The first is that you really want something somewhere
saying that, "Yes, all developers really agreed to our
ground-rules."  Doesn't have to be here, I just think it is
a convenient place to put it and avoid paperwork.  The other
is that you have to guarantee public source-code availability
for the Original Version and any Standard Version you create
from the Original Version.  I really don't think that you can
do that in copyright, and it is key to defending against all
sorts of neat attacks where the Original Version exists...but
is not publically available.

>Since I am of the persuasion that contracts without explicit agreement
>from both sides are onerous things, I would much prefer a list of
>permissions to a contract. Tell me what I can do, not what you will sue
>me over.

That has been tried.  The problem is that you are allowed to
do pretty much anything as long as you don't interfere with
Larry Wall's ability to define Perl how he likes, so a list
of what is allowed gets very long and you wind up missing
stuff anyways.  (One of the reasons that the AL is today in
bad shape.)

Basically the opposite of how you write a firewall.  In a
firewall you want to deny pretty much everything so you
arrange to say only what you allow.  Well in this license
you want to allow pretty much everything so you arrange to
say only what you deny.

>Okay, opinion over...
>
And noted. :-)

Cheers,
Ben
_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

Re: Another pass at redrafting the Artistic License

[Ben Tilly]

David Johnson wrote:
>
>On Fri, 15 Sep 2000, Ben Tilly wrote:
> > (To the folks on the license-discuss list.)  As you may know,
> > Perl is currently undergoing a rewrite.  As part of this
> > rewrite licensing is being reviewed, and we are attempting
> > to come up with an Artistic License that is (*ahem*) on
> > somewhat better grounds than the current one.  This is my
> > current attempt but IANAL and I desperately need some legal
> > types who are willing to comment on whether this will hold
> > water, whether it will meet the OSD, etc.
>
>This is a vastly different license than the old version. So I have to
>ask, why the *huge* change? Another question is why there is a separate
>agreement?

The polite description for why to consider a huge change is
that the current license is Swiss cheese.  Perl has basically
survived on the fact that everyone loves Larry Wall, Larry
would never sue anyone, no other core developer would either,
and Perl hackers don't mind ignoring lawyers.

Anyone who wishes to read the license carefully can figure
out for themselves that there are problems.  I got bored
after a while with counting ways to break, mutilate, and
generally abuse the license.  It gave TIMTOWTDI new and
unhappy meanings.  Grabbing copies of the Artistic License
out of different versions of Perl is another fun exercise.
It seems to sprout additions whenever someone wants to do
something Larry hadn't thought of allowing.  Certainly
anyone who says, *THE* Artistic License hasn't actually
looked carefully...

Given that Perl is undergoing a rewrite and this is going to
be the best chance for fixing the situation for, oh, at least
a decade, (the time between rewrites grows exponentially with
releases) a few people who buck the trend and care think it
might be a good idea to propose a solution to this...

Does that answer why I might want to propose a major rewrite?



Now why the structure?  Well I am borrowing from the GPL the
idea of having a license which is also used as a contract
agreement.  (Read section 5.)  My understanding is that that
allows you to have provisions enforcable under contract law,
which allows you to enforce lots of things that copyright
law won't.

It is somewhat behind, but take a look at

http://www.mail-archive.com/perl6-licenses%40perl.org/maillist.html

for some of the discussions leading up to this.  Scroll to the
bottom and start working your way up.  A few good stopping
places:

http://www.mail-archive.com/perl6-licenses%40perl.org/msg00019.html
http://www.mail-archive.com/perl6-licenses%40perl.org/msg00024.html
http://www.mail-archive.com/perl6-licenses%40perl.org/msg00032.html
http://www.mail-archive.com/perl6-licenses%40perl.org/msg00074.html
http://www.mail-archive.com/perl6-licenses%40perl.org/msg00079.html
  (Note the fact that the Artistic License may cease to be
  an open source license.  Oops.)
http://www.mail-archive.com/perl6-licenses%40perl.org/msg00084.html

Cheers,
Ben
_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

Another pass at redrafting the Artistic License

[Ben Tilly]

(To the folks on the license-discuss list.)  As you may know,
Perl is currently undergoing a rewrite.  As part of this
rewrite licensing is being reviewed, and we are attempting
to come up with an Artistic License that is (*ahem*) on
somewhat better grounds than the current one.  This is my
current attempt but IANAL and I desperately need some legal
types who are willing to comment on whether this will hold
water, whether it will meet the OSD, etc.

(To the folks on the perl6-licenses list.)  Hopefully after
this draft I will stop playing with the overall structure of
the document.  I don't seem to have succeeded in making it
shorter either, if it accomplishes some of my other goals, I
will live.  In particular while I cut some verbiage out, in
trying to cover the case where your package was derived from
*two* (or more) projects under the Artistic License some more
snuck in...

Please note in particular section 2.5.  This should give a
pretty good idea of how I want to make it possible for Larry
to resolve any licensing issues that *might* arise without
having to have everyone explicitly assign copyright to him.
Remember that I am looking for ways to give him flexibility
without paperwork...  Before I push that idea further I
really need feedback on whether this is going to fly, both
legally and in terms of what it requires from contributers.
Suggestions on what kind of defined policy would make sense
are also welcome. :-)

Cheers,
Ben

===

   THE ARTISTIC LICENSE
   VERSION 2,  SEPTEMBER 2000

Preamble

The intent of this License is to state terms under which the
developers of a free software project may allow use and borrowing
from the project while retaining a semblance of artistic control
over future development.  This license may be used on its own
but is intended to be used in a dual-licensing scheme and is
likely to be incompatible with other free software licenses when
outside of a dual-licensing arrangement.

 Terms and Conditions

1.1) This License applies to any work or derivative from a work
or collection of works containing a notice placed by the
copyright holder or holders licensing it in whole or in part
under the terms of this Artistic License.  The "Package" refers
to some package which thi license applies to.  A "Standard
Version" is any such work which is licensed in its entirety
under this Artistic License.  Each licensee is addressed as
"you".

1.2) To redistribute, modify, or derive from the Package you
must satisfy all copyright and license obligations on it.  The
proposed agreement contained in this license may be used to
satisfy any and all copyrights on the Package which have been
placed under this License.

1.3) The copyrights placed under this License in no way restrict
your use of the Package.  Similarly programs, library files,
files and the like used as input, output, or linked to the
programs and libraries of the Package do not automatically fall
under any copyrights placed under this License.  Unless
otherwise restricted, they belong to whoever produced them.

1.4) Intermediate states of the programs and libraries in this
Package during operation shall fall under the copyrights of this
License if that is possible after reviewing all applicable
licenses, agreements, and laws.  In particular binary images
produced using "undump", snapshoting internal byte code, or
other such methods of saving the operating state are likely to
be derivative works to which this License applies.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED.  IN NO EVENT UNLESS REQUIRED BY LAW OR AGREED TO IN
WRITING WILL ANY COPYRIGHT HOLDER OR CONTRIBUTOR BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA,
OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
OF SUCH DAMAGE.


 Offered Agreement
  for Distribution, Modification
   and  Derivative Works

 Preamble

This agreement is offered by the copyright holders for your
convenience should you wish to modify or distribute a Standard
Version or some derivative of a Standard Version.  You have no
obligation to accept it, however under Copyright law you will
need permission to undertake the activities covered.

  Terms and Conditions

2.1) The definitions in section 1.1) apply to this agreement. In
addition "Original Version"