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 <lro...@rosenlaw.com> 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 <lro...@rosenlaw.com>; 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 <lro...@rosenlaw.com>
> 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 <license-discuss@opensource.org>
> *Subject:* Re: [License-discuss] patent rights and the OSD
>
>
>
>
>
>
> On Mar 07, 2017, at 04:45 PM, Ben Tilly <bti...@gmail.com> 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. <nigel.tz...@jhuapl.edu>
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 <license-discuss-boun...@opensource.org> on behalf
> of Ben Tilly <bti...@gmail.com>
> Reply-To: License Discuss <license-discuss@opensource.org>
> Date: Tuesday, December 6, 2016 at 6:04 PM
> To: License Discuss <license-discuss@opensource.org>
> Cc: "henrik.i...@avoinelama.fi" <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. <nigel.tz...@jhuapl.edu>
> wrote:
>
>> On 12/6/16, 3:33 PM, "henrik.i...@gmail.com on behalf of Henrik Ingo"
>> <henrik.i...@gmail.com on behalf of henrik.i...@avoinelama.fi> 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&quot</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=1480369990&
> sr=8-1=open+source+for+business+meeker
>
>
>
> *From:* License-discuss [mailto:license-discuss-boun...@opensource.org
> <license-discuss-boun...@opensource.org>] *On Behalf Of *Ben Tilly
> *Sent:* Monday, November 28, 2016 11:44 AM
> *To:* License Discuss
&g

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 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 

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 lro...@rosenlaw.com 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 lro...@rosenlaw.com
 Reply-To: memb...@apache.org memb...@apache.org, lro...@rosenlaw.com
 lro...@rosenlaw.com, License Discuss license-discuss@opensource.org
 Date: Tuesday, May 26, 2015 at 10:16 PM
 To: License Discuss license-discuss@opensource.org
 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 lro...@rosenlaw.com 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 lro...@rosenlaw.com 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

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 lro...@rosenlaw.com 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 ftf-le...@fsfeurope.org.  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
 snip


 ___
 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 lro...@rosenlaw.com 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,  co...@ccil.org 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]

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 lro...@rosenlaw.com 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] 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 xcvi...@me.com 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 bti...@gmail.com 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 lro...@rosenlaw.com 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

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 k.rein...@telekom.de 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 dynamic linking”. Unfortunately this 
 is not 

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

[Ben Tilly]

 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 
 from the first principles. Of course, it is a hassle, to read all this single 
 steps. But it is good, to have such a step by step analysis.”

 And in this case, I would have answered very briefly:

 Oh yes, I fully agree with you. A hassle. Even sometimes, when I was writing 
 it. But the meaning of a proof is, that it does the job once for all. Now, 
 one can hint to a work instead of writing all these hassling lines by 
 oneself. And yes

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
claus-peter.wiedem...@bearingpoint.com 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, retention, or any action taken or omitted 
 to be taken in reliance on it is prohibited and may be unlawful. If you are 
 not the intended recipient, please reply to or forward a copy of this message 
 to the sender and delete the message, any attachments, and any copies thereof 
 from your system.
___
License-discuss mailing list
License

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 k.rein...@telekom.de 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 hoping to having
 contributed something which 

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 mas...@opensource.org
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
for...@david-woolley.me.uk 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]

On Mon, Apr 28, 2014 at 9:55 AM, Lawrence Rosen lro...@rosenlaw.com 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] 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
font...@sharpeleven.org wrote:
 On Mon, 28 Apr 2014 13:31:06 -0700
 Ben Tilly bti...@gmail.com 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] 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 buck.2...@gmail.com 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 andrew.wil...@intel.com 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 avile...@gmail.com 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,  zgil...@culturestrings.org 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 nico.diekh...@gmail.com 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 co...@mercury.ccil.org 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 co...@ccil.org
 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 engel.n...@gmail.com 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-discusshttp://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 r...@linuxmafia.com 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 11:14 PM, Rick Moen r...@linuxmafia.com 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 4:46 PM, Rick Moen r...@linuxmafia.com 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] License compatibility - reg

[Ben Tilly]

On Wed, Jun 26, 2013 at 9:35 PM, Rick Moen r...@linuxmafia.com 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 possible precedent being established which
would affect their license, there is a good chance that said drafter
is likely to attempt to sway the court to what the drafter believes is
right by presenting their best arguments in an amicus brief.  There is
no particular reason to believe

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
jilayne.love...@openlogic.com 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] Copyright Free Software Foundation, but license not GPL

[Ben Tilly]

On Fri, Apr 5, 2013 at 3:14 PM, Robin Winning robin.winn...@cyaninc.com 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]

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 br...@perens.com 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 co...@mercury.ccil.org 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] 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 br...@perens.com 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 bti...@gmail.com 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 br...@perens.com 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 co...@mercury.ccil.org 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


 --
 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 br...@perens.com 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
randomrhy...@rhythmengineering.com 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 4:04 PM, Rick Moen r...@linuxmafia.com 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] License Stewards

[Ben Tilly]

On Thu, Oct 4, 2012 at 5:35 PM, Rick Moen r...@linuxmafia.com 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] plain text license versions?

[Ben Tilly]

On Fri, Sep 7, 2012 at 10:37 AM, Ben Reser b...@reser.org wrote:
 On Thu, Sep 6, 2012 at 11:12 PM, Rick Moen r...@linuxmafia.com 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 lro...@rosenlaw.com 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

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 r...@linuxmafia.com 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 to select a license that does not protect
them from situations that they would prefer not to see happen.  Even
though you may think it a tragedy that things keep on happening

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: 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: 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: 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 today, proper sanitation
does more to extend the average lifespan of the population
than the 

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: 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:

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: 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
_
Get your FREE 

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: 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: 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: 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 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 code. However, the source code
distributed need
not include anything that is normally distributed (in either source or
binary
form) with the major components 

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: 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 legacy application.

If I am a developer I don't want to learn a
technology which I cannot start offering support
for without paying license fees to a direct
competitor.

If I am a customer I want to have the guarantee
that as long as there is sufficient demand, I will
have the ability to find someone who can offer me
decent support.

Being only mildly paranoid I do

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.

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" 

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.