Re: [License-discuss] [Non-DoD Source] Re: NOSA 2.0, Copyfraud and the US Government

[Chris Travers]

On Tue, Aug 29, 2017 at 2:59 PM, Karan, Cem F CIV USARMY RDECOM ARL
(US)  wrote:
>> -Original Message-
>> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
>> Behalf Of Thorsten Glaser
>> Sent: Monday, August 28, 2017 4:33 PM
>> To: Stephen Michael Kellat 
>> Cc: license-discuss@opensource.org
>> Subject: Re: [License-discuss] [Non-DoD Source] Re: NOSA 2.0, Copyfraud and 
>> the US Government
>>
>> Stephen Michael Kellat dixit:
>>
>> >them to fix this to be public domain globally is best done by amending
>>
>> There’s no such thing as voluntarily releasing a work into the Public Domain 
>> in several countries of the world, so this is futile at best,
>> worse hamful.
>>
>>
>> Karan, Cem F CIV USARMY RDECOM ARL (US) dixit:
>>
>> >> So, in the end, “we” need a copyright licence “period”.
>> >
>> >Not exactly.  This is where CC0 comes into play, at least here at the
>>
>> Yes, that’d be a way to express the same thing *if* CC0 were sublicenseable. 
>> It currently sorta works, but…
>>
>> >even if the work could have copyright attached in Germany, people there
>> >know that the work is under CC0. This covers the really hard question
>> >of a US Government work being exported to Germany, modified, and then
>> >re-exported back to the US. The goal (at least at ARL) is to
>>
>> … this could be tricky.
>>
>> If it were sublicenseable, the thing exported back to the USA could be fully 
>> under a proper copyright licence as the work of the person
>> who created the modified work (assuming it passes threshold of originality, 
>> of course).
>>
>> But I’m assuming it’d also work with just CC0, except CC themselves asked 
>> for it to not be certified as Open Source due to problems with
>> it (I don’t know which ones exactly).
>>
>> >make sure that everyone world-wide knows what the terms are, and that
>> >they are the same regardless of where you live, and where you are
>>
>> This is never true.
>>
>> Under the Berne Convention, a work from country A is, in country B, subject 
>> to the same protection as a work from country B. That means
>> for a work originating in the USA, in Germany, only(!) German copy‐ right 
>> law applies. In France, only French law, etc.
>>
>> I kinda like Richard Fontana’s approach to state a proper Open Source 
>> licence for where copyright law applies.
>
> I see your point, but CC0 is an attempt to even out the use cases as far 
> possible.  Basically, a person in Germany should not have to wonder if 
> they'll be sued for using a US Government work that is in the public domain 
> in the US.  CC0 answers that question as far as it is possible given the 
> various jurisdictions around the world.

What about jurisdictions where moral rights cannot be legally waived?
___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] some FLOSS license + commercial: Your thoughts?

[Chris Travers]

On Mon, Sep 23, 2013 at 11:12 PM, Alec Taylor alec.tayl...@gmail.comwrote:

 I am building a set of generalised libraries and frameworks.

 Would like to open-source it all; however in the cases where a client
 wants their custom stuff under a non open-source license; I should have
 provisions for such a case.


I usually just do two things:

1.  License the code to the client under their choice of GPL or BSD
licenses, and

2.  Privately agree (in a formal contract or otherwise) not to merge the
changes made in their current form back into the main software.

If they want to sell it they can, but under the BSD license, they can't
sublicense (unlike the MIT license) so they'd have to have someone make
some change they could license on their own or they can come to an
agreement with me for revenue.

Best Wishes,
Chris Travers
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] we need a new license for earning money

[Chris Travers]

 to our
work but it also creates an explicit path for people to write proprietary
addons to the software in whatever language they want.

What this means is that people can (and sometimes do) offer proprietary
addons for LedgerSMB.  We could too.  We have other ways of making it
happen though.  We are looking at a large launch of new services starting
in 1.4, but I don't want to talk specifics at this time.

My point in bringing this up is that it is possible to go with community
development, freemium, and open source (under the OSD together) if you look
at this as an engineering challenge rather than a licensing one.  This can
help cultivate community as well.

It sounds to me like part of what you are trying to do here is cultivate a
community of partners and resellers.  I think the question you need to ask
yourself is what role there is for commons between resellers or if you are
just claiming to control those commons.

Whether or not you agree with it you may also find this to be an
interesting read:

http://ledgersmbdev.blogspot.com/2013/04/a-distributist-view-on-software-freedom.html


 Your Rights
 ===
 IntarS Unternehmenssoftware GmbH grants you the right to
 use, redistribute, modify IntarS, create and/or distribute a derived work
 based on IntarS
 under these

 Conditions
 ==
 Redistributions of source code of IntarS or a derived work must retain the
 above copyright
 notice and this License.

 Redistributions in binary form of IntarS or a derived work must reproduce
 the above copyright
 notice and this License in a convenient manner.

 A derived work must provide the information, that it is based on IntarS
 and that the contained
 IntarS is licensed under this license.

 Usage of IntarS is free for private users, educational and non commercial
 organisations.

 For commercial organisations usage is free for the first 5 concurrent
 named users.
 Continued usage by exceeding concurrent named users needs to be licensed
 in a seperate, written
 license agreement with IntarS Unternehmenssoftware GmbH.
 This applies also to the IntarS contained in a derived work.
 Commercial organisations must immediately send a mail to i...@intars.deto buy 
 required licenses.


As a reseller, I would never modify your work under such terms because
there is no provision for me to require downstream licenses too.

If you fix that though then you make end users buy licenses from umpteen
different partners.  I think you are going to have a mess on your hands
trying to make that community-friendly.


 Termination
 ===
 Failing to conform to a condition will automatically terminate your rights
 under this License
 and constitute a claim for compensation.

 Clarification
 =
 You don't have to redistribute your derived work. If you do, you don't
 have to distribute source with your derived work.
 You are free how to license your derived work.


That conflicts with above.  You might want to say that you are free to add
licensing requirements to your derived work.


 For the IntarS contained in the derived work of certified IntarS Partners,
 IntarS Unternehmenssoftware GmbH takes
 only 30% of the regular license fee rate from the commercial end users.


Not sure what you mean by that.  Does that mean they take 30% of
collected?  Or 30% of what they charge directly?

Moreover if you write this into the license, it is very much out of your
hands.

If I may, if you really want to go with this approach my recommendation is
you treat it as proprietary and have transfer pricing agreements with
resellers which are individually negotiated and contractually based, and
offer your shareware source license on the source code itself.  I would
suggest changing it to say further that derivative works can be licensed
under the same terms, or transfer pricing agreements are available from you.

Hope this helps,
Chris Travers
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] we need a new license for earning money

[Chris Travers]

On Fri, Sep 20, 2013 at 3:04 PM, Pirmin Braun p...@intars.de wrote:

 Am Fri, 20 Sep 2013 15:22:41 -0400
 schrieb John Cowan co...@mercury.ccil.org :

  Pirmin Braun scripsit:
 
   So I'd like to share our thoughts: Maybe it is possible to add such
   an extension to the OSI Open Source Definition? Or create a new class
   of approved liceneses?
 
  Not gonna happen.  We believe very strongly in non-discrimination among
  licensees, and to disadvantage the millionaire is as unethical as to
  disadvantage the poor.

 we're in the business world: The millionaire companies feel better to pay
 for licences. It's not a disadvantage. They want to see, there is someone
 taking care of the software they're using who makes a living from this
 money. There are about 60 years of programming in IntarS (started at 1996)
 and it's easier to just say price than trying to explain how this
 development was financed. Because either there were non-paid just-for-fun
 programmers at work who may turn away at any time or the professional
 services have to pay the bills.
 Taking license fees just gives more credibility and trust.


The question in my mind is that of ownership.  If you license the software
to someone, you control what they can do with it.  You own the software
they use (in the sense of having the right to control it).  If you cede
that ownership by degrees (GPL cedes some, BSD cedes more, etc) the
companies take on more of that ownership.  In essence, I see software
licenses as folks paying for the privilege of being told what they cannot
do with the software.

If they need to give you credibility and trust, charge them for a support
account, a warranty, or the like.


 Then have you ever thought about the allowed means of making money from
 Open Source? Like selling copies? Strictly speaking, this is also a
 discrimination: Someone having a slow internet connection or little
 knowledge of how to build a product from the sources and having no friends
 that can help is forced to pay money. Same with professional services:
 companies not having the IT stuff to do it inhouse are discriminated! They
 have to hire Open Source contractors to help them.


Selling copies have never been significant money makers for my business.

Also IME, the companies with IT staff tend to pay for more services
(because they know what they need!) than those who don't, and they often
have more complex needs.

Best Wishes,
Chris Travers



 --
 Pirmin Braun - IntarS Unternehmenssoftware GmbH - Am Hofbräuhaus 1 - 96450
 Coburg
 +49 2642 40526292 +49 174 9747584 - skype:pirminb www.intars.de
 p...@intars.de
 Geschäftsführer: Pirmin Braun, Ralf Engelhardt Registergericht:
 Amtsgericht Coburg HRB3136
 ___
 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] we need a new license for earning money

[Chris Travers]

On Tue, Sep 24, 2013 at 5:45 AM, Pirmin Braun p...@intars.de wrote:

 Am Tue, 24 Sep 2013 12:07:01 +0100
 schrieb Cinly Ooi c...@theiet.org :

 If it was only my situation, I wouldn't have asked. But I'm also an Open
 Source Evangelist and FSFE member and have detected this common pattern
 with Open Source projects becoming mature, usable, successful. They don't
 fit into the Open Source world any longer and start escaping into dual
 licensing, Open Core, closed source forks or only older versions remain
 free. Not only the projects are lost but there is also a brain drain of
 programmers. Another brain drain pattern: talented young programmers turn
 away after their first half finished Open Source project for a real job.
 Whether this was considered or not, I can imagine a better overall
 situation but it all boils down to breaking the money barrier.


This isn't a problem with open source.  It is a problem with corporate
control.  If you have a single-vendor solution controlled by a single
company, yes, this is a trend.  On the other hand if you have a
multi-vendor solution (PostgreSQL, Apache) the dynamic is very different.
Note these are under more permissive licenses that allow proprietary
forks.  I can talk more about PostgreSQL than the others.

PostgreSQL has always had proprietary forks which are a little ahead of the
standard version in some ways or another.  The thing is, they largely serve
as a means of pointing the direction for future development.  There used to
be Mammoth PostgreSQL which offered replication as standard.  Then
PostgreSQL got replication and the mammoth went extinct.  Then there was
Green Plum but they went their own way and we got Postgres-XC.   And so
forth.   PostgreSQL continues to develop quickly in part through
competition with the proprietary forks.  This is one of the things we tried
hard to replicate in LedgerSMB.

Best Wishes,
Chris Travers
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Is Web application including GPL libraries covered under GPL?

[Chris Travers]

Wrapped up in this discussion are basically two questions:

1.  Am I legally required to distribute the source of my application in
these cases?  This is a complex, fact-bound question and there is no
substitute for asking a lawyer what is required and what the potential
legal consequences enforced by judge and jury, are likely to be.  However
in addition to a lawyer, I think you should also ask the licensors of the
Java library what they expect, not because this carries significant legal
weight but because it affects the other questions below and it also
addresses the possibility of legal action regardless of how it turns out.

2.  Should I distribute the source if I distribute my application?  What
happens if I don't?  In general, I think you should distribute the source
if using GPL'd libraries one is linking to.  In addition to the possibility
of lawsuits regardless of their merits, you also have the possibility of
bad press and hostility from many would-be users of your application.
Regardless of the legal requirements, there is a general norm of releasing
source.  The GPL as a social contract expects this.  You will get good
things by releasing source and bad things by not.  The social contract
aspects are often at least as important as the legal aspects.

As for displaying text from libraries, I am pretty sure it depends on the
text, the expressiveness vs functional aspects, and the like.  I would not
think that error messages would be a problem.  an original poetry
collection certainly would be.  Again it's fact bound.  Talk with a lawyer.

Best Wishes,]Chris Travers
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

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

[Chris Travers]

I don't entirely disagree with you.

My reading of the LGPL however is that it offers a safe harbor from the
derivation requirements if the vehicle for that derivation is linking.  I
don't think linking is either necessary or sufficient for derivation.  I
don't even think it is usually that relevant.  However, there are at least
some cases where it might come into play.

Here's a hypothetical.

Suppose FossGames, LLC releases a video game music player engine under the
LGPL along with an embedded MIDI synthesizer which produces a distinctive,
and artistic sound.  Let's say further that it comes with a set of built-in
MIDI sequences.  Let's say further that EvilCorp Inc releases a closed
source video game which uses FossGames MIDI engine and even their built in
music, all by linking to FossGames' engine, which they publish on their web
site, as minimally required by the LGPL.  FossGames sues EvilCorp alleging
that EvilCorp's game is an audiovisual work which infringes on their right
to make derivative works of the music embedded in their MIDI engine.
EvilCorp responds saying that the LGPL offers a safe harbor where linking,
and invoking routines in linked libraries, is the means of that
derivation.  By my reading EvilCorp wins summary judgement (which they
would not win with the GPL) or am I missing something?

I can't think of any other case where it clearly makes a difference though.

Best Wishes,
Chris Travers
___
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?

[Chris Travers]

On Sat, Aug 18, 2012 at 9:41 AM, Lawrence Rosen lro...@rosenlaw.com wrote:
 Russ Nelson wrote:
 I hear a lot of whistling past the graveyard here. As people point out,
 it's never happened yet, and so it never will happen. Not a cause for
 concern; move along, nothing to see here.

 Russ, among the things I worry about in FOSS, moral rights are among the
 least worrisome. I'd almost welcome litigation about this issue so that we
 can expunge morality from software.

 If you want to worry about copyright law, consider 17 USC 203. [1] Tell me
 what you experience as you drive over that bridge

Fascinating law.  I will admit not to worrying about moral rights, or
this specific law.  For one I don't know that there is a lot of code
that wouldn't be turned over in the course of 35 years.  However it
does make you wonder once Linus passes on if his kids might decide to
pull this sort of thing and if so what the effect would be.

Best Wishes,
Chris Travers
___
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?

[Chris Travers]

On Fri, Aug 17, 2012 at 10:05 AM, Lawrence Rosen lro...@rosenlaw.comwrote:

 [This email best viewed in HTML format]

 ** **

 Hi Ben,

 ** **

 It would be difficult for Linus Torvalds to complain about porn when he
 intentionally released an operating system that is so ideally suited for
 the delivery of porn. It would be like Michelangelo complaining because
 derivatives of his statue of David revealed some private parts.



IANAL, but the intent of moral rights is to provide for the author's
reputation for his or her work and to ensure that the author maintains some
control over how the image of the work is maintained.  For a practical tool
this strikes me as somewhat of a mismatch just like protecting software as
expression is a bit of a mismatch.

For example, I don't know how Linus's moral rights would be interfered with
if nobody knew that a specific porn site was being hosted on a service
using the Linux kernel, although he'd seem to have a right to ask them to
display a powered by Linux logo or refuse to let them use such a logo.

Best Wishes,
Chris Travers
___
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?

[Chris Travers]

On Tue, Aug 14, 2012 at 8:52 AM, Tom Callaway tcall...@redhat.com wrote:
 On 08/14/2012 11:24 AM, Ben Tilly wrote:
 Based on http://www.linuxjournal.com/article/6225 and similar
 articles, I'd long believed that a declaration that you were
 abandoning copyright was a meaningless farce.

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

 Is D. J. Bernstein out of his depth here, or does he have a valid point?

 This question is hotly debated, and the answer boils down to the worst
 sort of maybe, sortof, kindof. Ask 10 different lawyers, and you'll
 probably get 10 different answers. (Not to mention that the answer
 almost certainly changes based on the jurisdiction.)


It really depends.  I would assume that if you release anonymously and
explicitly disclaim copyright, that the code can be effectively public
domain.  I am not aware of any jurisdiction that forbids anonymous
publication, especially when the author seeks to remain anonymous.

I don't see how copyright can be enforced when it is both explicitly
disclaimed and the link with the author is severed.  There would be no
way to enforce it, nobody to go after for implicit warranties, etc.
After all it would be like asking whether an anonymous pamphlet left
at a college cafeteria was copyrighted.  IANAL though, but IIRC, the
Bern convention makes it sufficient that the author's name is
associated with the work for copyright to exist and this doesn't reach
that level.

Are there any cases where copyright could be enforced or required,
where code was anonymously published through a means not directly
traceable to the initial publication?  I mean if I put my code up on
privatepaste, and then link to in anonymous Slashdot comments, is it
still protected by copyright if it is not traceable to me?

Best Wishes,
Chris Travers
___
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

[Chris Travers]

On Mon, Jun 11, 2012 at 12:43 AM, Bruce Perens br...@perens.com wrote:
 What legal theory would make a user of an API a derivative work if the API
 is not itself copyrightable?


If there was a case like MySQL v. Nusphere without the contract, this
is what I'd argue.  Note I'd avoid saying derivative like the
plague.  I'd point out (assuming the following is true for sake of
argument):

There's ample documentation that the licensor intended this license
not to reach compiled or collected works linking this software to
proprietary components, and that extra licenses were required at that
point.  There's ample evidence the licensee was aware of all this.

I'd then argue that whether or not it's a derivative work is not at
issue.  What is at issue is whether the licensor intended the license
to allow the behavior in question and whether the licensee knew or
should have known this.  By distributing the code, they need copyright
permission.  That's not in dispute.  Therefore, the behavior is
outside the GPL and at least contract violation if not copyright
violation.  This may not be a derivative work but it's not really
permitted by the GPL.  Compiled/collected works require permission to
and some of these are based on in the view of the GPL even if they
are not based on in the way that term is used in copyright statutes.

I don't know if that's a winning argument (assuming the ample
documentation is there).  But if I wanted to argue it, that's the case
I'd make.

Best Wishes,
Chris Travers
___
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

[Chris Travers]

On Mon, Jun 11, 2012 at 7:57 AM, Chad Perrin per...@apotheon.com wrote:

 These are generally exceptional cases that require either copyright
 assignment or carefully controlled maintenance of contribution records
 and continued contact with contributors.  In cases where contributions to
 the downstream copyleft project are accepted from all comers (within
 reason) without a lot of bookkeeping -- as is the case with many open
 source projects -- the ability to contribute substantial code from the
 downstream copyleft project to the upstream copyfree project starts
 evaporating, not only because it may be difficult to get people to
 consent to their code being contributed to a copyfree licensed project
 when they intended it for a copyleft project, but also because the
 project maintainers may not have any easy way to identify and contact all
 the contributors with affected contributions in the first place.

 In many cases, it may even be difficult to track contributions
 themselves, regardless of the contributors.

 Meanwhile, in proprietary downstream projects, there is a single
 copyright holder, almost by definition.  This entire problem of trying to
 figure out whether you have the legal right to contribute to upstream
 pretty much doesn't exist.

I think this is an important point.  When we look at a project like
PostgreSQL for example, you have proprietary vendors like Green Plum
and EnterpriseDB who contribute a *lot* of code back to the common
project.  This is pretty typical with BSD-licensed projects as a
whole.  Once you start having a GPL'd off-shoot then you have problems
getting the same level of contribution back to the BSD-licensed
original.  This is an important concern and it's something a lot of
people just kind of glide over but as someone who has worked with
projects under both licenses I will say clearly that it's easier to
get a proprietary project to make contributions back to a BSD-licensed
project than it is to get a GPL'd project to do the same.

True there are always cases where a vendor starts with a BSD codebase
and runs their own direction with it without contirbuting back.  In
the PostgreSQL world, I guess the primary examples that come to mind
are Informix and Vertica.  However these are usually only successful
when either the approach is so different that code sharing is not
helpful or the project is sufficiently immature to make it helpful to
just run one's own direction.   In general though the cost to the
developer is that they bear the fll cost of integrating new features
from the BSD version, and almost always this creates a heavy incentive
to contribute back.

 Best Wishes,
Chris Travers



 Permissive licensing implies right to create derivatives under licences
 you don't like and reuse in ways you don't approve of, because that's
 somebody else's property (derivative of yours, but needing to satisfy
 only your minimal conditions), and some guy actually read your licence,
 correctly understood its permissive nature, and acted accordingly.

 Ben Tilly appeared to be addressing more than this simple legal status of
 copyfree licenses and other permissive licenses.

 --
 Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
 ___
 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 to revise and slightly reorganize the OSI licensing pages

[Chris Travers]

On Mon, Jun 11, 2012 at 12:39 PM, Rick Moen r...@linuxmafia.com wrote:

 Anyway, as I just got through saying 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.

Sure.  But these are not always clear.

For example, suppose I start selling a binary-only table engine for
MySQL which offers real benefits over Innodb.  Let's say less bloat,
less maintenance, faster performance, and no issues with thread
deadlocks when multi-row inserts are done.  Suppose this is
dynamically linked and I ship with an installer that detects installed
MySQL versions and installs against this.  The installer asks for a
license key which is used to determine how many client access licenses
you have purchased.  I sell CAL's for $50/client.

Suppose furthermore that I only ship this in to customers in the US so
we can limit this discussion to US copyright law.

Do I even need Oracle's permission to release my project?  My money
would be on no and so the GPL really would have no implication.
After all, *all* have done is use an API owned by Oracle (my money
would also be that they'd sue me to try to win anyway, see Google v.
Oracle).

Allowed?  Not allowed?  Only talking about what the *law* requires in
this case.  There may be other ways of pressuring certain behaviors
other than court.  But only talking about US law here.  European law
may be different.  But I think that the current case law and statute
strongly suggests that this would be allowed without any copyright
license from Oracle at least in the US.

I think that Oracle would lose as a matter of law and that you can't
use copyright to restrict linking as a technical matter.  Static
linking would be arguably different *only* because one is distributing
a compiled work containing a component of someone else's and therefore
a copyright license would be required (providing a module which is
statically linked only during install would not pose this problem
though).  But if Lexmark v. Static Control settled anything it's that
you can't use copyright to control secondary markets for practical
goods.

Best Wishes,
Chris Travers
___
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

[Chris Travers]

On Fri, Jun 8, 2012 at 11:01 PM, Rick Moen r...@linuxmafia.com wrote:
 Quoting Chris Travers (ch...@metatrontech.com):

 Nowhere in these do I see any indication that mere inclusion of one
 work in another creates derivation.

 You will not find a simple acid test there or anywhere else.  And yet,
 in my experience, if you read those cases, you will get the pattern of
 the way judges rule.  It's a matter of whether copyrighted expressive
 elements were incorporated into a new work without permission.

Not exclusively.  I cited cases (Lexmark, Sony, etc) where expressive
elements were included without permission but this was held to be de
minimis (Lexmark) or fair use (Sony, Galoob), or allowed on other
grounds.  Those cases are interesting because it is undisputed that
literal copying occurred.  Hence my initial point of copyright only
applying to the extent that the function and expressive elements are
separable (in these cases, I would argue, they were not.  You couldn't
achieve the functions without copying the expressions, so it was
allowed).  These courts went about things in different ways but the
pattern appears to be that copyright is not a legitimate tool for
restricting interoperability of software.

 You are not going to find sharp lines about what constitutes creation of
 a new work, versus what is a collection.  However, as I said, you will
 get the pattern and be able to predict fairly well how other cases are
 likely to turn out.

Evidently we read the tea leaves differently.   I suppose it is true
that two observers will always connect the dots differently.

I see the following patterns regarding proprietary software:

1)  Where one party is copying another party's copyrighted works to
their direct financial detriment the court is far more likely to side
against the one doing the copying.

2)  Where the copying party however, is doing so for interoperability
purposes, or functional purposes of interoperability that do not
create new audiovisual works, and do not directly implicate the other
party's sales, these are far more likely to be allowed either via fair
use (Sony v. Connectix) or de minimis exceptions (Lexmark).  This, as
in Lexmark, is a straightforward application of 17 USC 102(b) which
states that copyright cannot be used to own an idea, method, practical
process, etc. (The exact words are (b) In no case does copyright
protection for an original work of authorship extend to any idea,
procedure, process, system, method of operation, concept, principle,
or discovery, regardless of the form in which it is described,
explained, illustrated, or embodied in such work. )

From that I would suggest that the chance of a court holding that the
necessity of linking to system libraries gives an OS vendor copyright
control over all software running on that platform is very low, and
the chance of that being upheld on appeal is effectively zero.  Indeed
I would argue that 17 USC 102(b) effectively prevents using copyright
alone as a barrier to functional software interoperability.  This
seems to me a straight-forward application of Sony and Lexmark as
well.  Moreover I think this is what concerned the court in Oracle v.
Google.

So if you see the Gemini Engine as a piece of software interoperating
with MySQL through a defined API, then static linking seems to my mind
to be creating a compiled work, not a derivative one.  If, however, we
argue that the only functional unit that makes sense is the server
binary as a while, then maybe it is derivative (however in that case,
surely dynamic linking would cure that).  I just don't think it is
settled or clear cut.



 No.

 NuSphere's product was obviously derivative of MySQL because of the
 incorporation of copyrighted expressive elements into a new work without
 permission.  The technological details are trivia.

I don't think that works. If it did, every compiled work would be
legally a derivative of all components, and I don't think you accept
that either.  If it was, then the work as a whole provision would
mandate that Fedora Linux is violating RMS's copyrights by including
OpenSSL on the same CD as the Readline library, which doesn't work.
If it did the mere aggregation clause of the GPL v2 and equivalents in
the GPL v3 would be meaningless.

Best Wishes,
Chris Travers
___
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

[Chris Travers]

Just one point in support of Rick's assertion here.

My points as I stated I think clearly, are under the assumption that a
court would look at the GPL v2 and try to map it directly to
compiled/collected works (license allows without regard to license of
other components) and derivative works (requires to be under the same
license).  Beyond the uncertainties I have suggested there's a second
way I could see a court looking at it (again IANAL but I have listened
to a lot of oral argument and read a lot of case law).

I could see a court saying the near-unanimous view of the GPL v2 as
expressed by the licensor here is that a work that links to this work
is based on it for purposes of this license.  Therefore it doesn't
matter whether or not it meets the definition of derivative work or
not.  The licensee knew this was the intention of the license and
therefore we intend to enforce it as such.

So I think you have questions as to how the GPL v2 would/should be
interpreted and, depending on that, questions of where the line is
between a compiled and a derivative work.  I don't think either of
these are as clear as the you need a license if you link crowd would
like to think though.

Best Wishes,
Chris Travers
___
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

[Chris Travers]

 into
the executable?  I really think that's in uncharted territory, but if
they could be distributed separately and linked by the end user, it
seems to me to be more of a case of a compiled work than a derivative
one.

So I don't think the case that this is as clear cut as it appears on
the surface.  One might be able to argue that the binary distributed
is transformative of MySQL's work and therefore derivative.  But I
don't think it's as simple as just what's included.  That gets you to
it's protected by copyright but not to it's a derivative, rather
than a compiled, work.

Best Wishes,
Chris Travers
___
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

[Chris Travers]

On Thu, Jun 7, 2012 at 8:18 PM, John Cowan co...@mercury.ccil.org wrote:
 Rick Moen scripsit:

 I keep hearing a limited group of people speaking of this alleged tort
 ('purporting to sublicense'), but fail to find it in copyright law.

 Is there actually such a thing as copyright sublicensing?  I suspect not.
 In which case purporting to sublicense an unchanged copy of a work
 is usurping the copyright owner's right to control the license, and
 likewise for a copy whose changes are de minimis.  You can license your
 derivative work however you like, consistently with the original license,
 but that's not a sublicense: it is the license of the new work.

Maybe I misunderstood what Larry Rosen was saying about the
differences in the BSD and MIT licenses in his book then ;-).  I
thought his discussion was pretty clear though.  Also see Gardner v.
Nike, 9th Circuit 2002 (IANAL  btw as I will repeatedly state below).
I am not 100% sure but I think after the changes in 2010, exclusive
licensees are now assumed to have sublicense rights as well.  For
non-exclusive licensees (all open source licenses), that's a different
issue.  Maybe a lawyer could correct me if I am wrong about the 2010
changes.

The thing that makes these issues hard is that protecting software
with copyright is a bit like pounding nails with an adjustable wrench.
 The tool isn't really designed for that (copyright, at least in the
US, is designed to protect literature, not recipes in cookbooks) and
so it seems to me there are all sorts of gotchas.

If I give a book publisher the right to sublicense my book, I would
assume at a minimum they could tell a magazine they could serialize
it, for example, and on what terms.  Presumably they could license an
excerpt to be published in an anthology and set terms (within certain
limits dependent on the contract with the publisher) for that
publication.  Maybe they could even negotiate movie rights.  My
understanding is that US law assumes that sublicensing is not allowed
unless specifically stated even in the case of an exclusive copyright
license.  IANAL though.

The Nusphere case is more interesting when we stop thinking about
software and look at copyright as protecting what might be thought of
as software as literature or software as expression.  The GPL
allows mere aggregation without license contagion but requires that
works based on the original work carry the same license.  If we
assume that these tie directly to categories of US copyright works,
then based on means derivative work (in the sense that a movie might
be based on a book), while aggregation would appear to mean compiled
or collected works (anthologies).  A program linking to another
program is not based on that other program in that sense regardless
of the mechanism of linking any more than an anthology is based on the
pieces published therein.  Whether the Geminii table engine would be a
derivative work of MySQL is a question that I don't think the
jurisprudence is clear on (IANAL again).  In the most simplistic of
approaches, Nusphere would be safe.  (It gets complicated because I
don't think API's and can be effectively copyrighted, and header files
are too heavily tied to APIs to get much protection in that way--- see
endless discusson on Groklaw during the SCO case on this issue, but at
the same time, if you can show continuity of expression that goes
beyond functional requirements, then you might have a case.)

But the point here is that both of these are cases where reasonable
minds can disagree.  Rick looks at the BSD license and says well, it
seems to allow me to license this to others under more restrictive
terms if I keep the old copyright notices and license text in tact.
Someone else might say sublicensing is not mentioned.  Therefore it's
not allowed.  Again with MySQL v. Nusphere, there are questions where
reasonable people can disagree about the intersection of copyright law
and software regardless of how severe Nusphere's violations of social
norms are.  These are the cases I see getting litigated.  I just don't
see how any statistics there tell us anything useful about the
licenses.

Best Wishes,
Chris Travers
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Linking question

[Chris Travers]

On Fri, Mar 2, 2012 at 12:35 PM, Lawrence Rosen lro...@rosenlaw.com wrote:
 Bruce Perens wrote:

 The parties didn't wish to contest whether they were in compliance or not.
 They instead took the route of requesting forgiveness for infringement as a
 settlement or before a suit was filed, since the terms to get that
 forgiveness end up being far less expensive than fighting the case.

 I can't argue against a quick settlement on terms cheaper than prolonged
 litigation. I've recommended that many times to clients, and if my client in
 this example was anything other than hypothetical, I'd seriously consider
 your advice. That's much safer than a hypothetical battle in court with
 Bradley Kuhn over Busybox enforcement; I know Bradley! But I also know
 companies that would fight Bradley all the way to the Supreme Court before
 they disclosed their crown jewel proprietary software to him.



 That sort of litigation blackmail was prevalent in personal injury tort
 cases also until the insurance companies realized that most juries were on
 their side and they started fighting back in edge cases. It is much harder
 to get a valuable settlement in those cases nowadays. GPL litigation might
 be next! :-)

I would second that.  I would add that there is a huge difference
between, say, the FSF suing Apple over an Objective C plugin to the
GCC and large for-profit software and service houses suing eachother
over the license.  Imagine if Oracle and IBM were fighting it out in
court over these things.  The calculus regarding settlements would be
very different.

Best Wishes,
Chris Travers
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] [License-review] CC withdrawl of CC0 from OSI process

[Chris Travers]

Rick;

I think you are missing one key point in your reply to me.  In short:
Part of the point is to realize that the engineer's question is What
do I have to do to stay safe?  How do I know if this license applies?
 Any answer you can give to the engineer's question will be both
heavily overinclusive and underinclusive because the frameworks do not
match.

The point of a software license is not to give lawyers an opportunity
to have long discussions with the engineers.  The point is to give
engineers an idea of what they can do with the software or not.  That
derivative works law is relatively developed as a framework does not
mean that it is  something where an engineer can know in advance what
behaviors are likely to raise problems, or even that a lawyer will be
able to say with certainty how a court will resolve many of those
problems.

On to the longer version.

Here's the fundamental problem as I understand it:

Copyright law is about protecting creative expression.  Software
authoring and engineering is about creating functional tools.
Functional elements are not subject to copyright, nor are creative
elements closely tied to those at least in the US (this is as I
understand it very much settled law).  This of course leads to the AFC
tests etc.  This is why I don't think that linking ever creates
derivative works by itself.  At most you are copying some header files
or the like and merely depending on external sources is not the same
thing as being derivative of them.  This being said using two products
together can create derivative works.  If I distribute third party CSS
files for your web application (let's be extreme here and say it's an
HTML5 game), then the result that is generated by the user's web
browser may in fact be a derivative work, and so may my module (I can
look up the case that lead me to this conclusion if you'd like).  Thus
I might be subject to the requirements of the GPL here.

This was the big issue when we contacted the translation authors for
SQL-Ledger who licensed their work under the GPL and SQL-Ledger
changed the license (back at 2.8.0).  It's not enough that there is
functional connection, but the fact that there is *expressive*
derivation in the output suggested to us that this pressure could
legitimately be brought to bear.  Now, maybe the strings don't have
very many ways of being translated, and so they are purely functional
and de minimis requirements are not met.  Maybe not There
isn't a clear way for us to tell.

The reason why we draw the line where we do is this:

We are not claiming that every use of inheritance leads to derivation.
 That of course is fact sensitive and requires lawyers and probably
judges to resolve.  However, we can say with reasonable certainty that
the mere use of our API's is not protected by copyright.  However,
once you get into inheritance, I think the situation changes in ways
which are meaningful for the AFC type test.  In particular the
expressive elements in the inheriting class are more closely tied to
those in the inherited class (the API's functionally merge, and so
forth--- it's not a matter of mere exposure of the API, but rather the
way it is exposed, namely as part of the other copyrighted module,
which makes a difference in our view).

So we get back to the problem that Bruce was trying to answer, which
is how we explain what a license allows to non-lawyers.  And more to
the point, letting an engineer be able to answer, the question of
what exactly do you have to take out to make that application clearly
non-infringing?  Inheritance is a nice line to draw there.

Best Wishes,
Chris Travers
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] [License-review] CC withdrawl of CC0 from OSI process

[Chris Travers]

On Thu, Mar 1, 2012 at 8:06 PM, Bruce Perens br...@perens.com wrote:
 On 03/01/2012 08:02 PM, Chris Travers wrote:

 How do I know if this license applies?


 Just assume it does, because you don't really have to decide this question
 to be safe.

I am not at all sure that line works once you get into trying to
bridge GPL'd and proprietary apps, which is an important thing to the
adoption of free/open source software generally, particularly for
larger business systems.

For example, support I have a customer that needs to move data back
and forth between LedgerSMB and, say, Quickbooks or Sage 500.  Does it
matter how I do this?   Is it possible to accidently create a
derivative work in the process?  What do I have to avoid on a
technical level (because I am thinking technically when programming,
not legally) to be sure I am safe?

If I assume the license always applies, and I interpret it as
expansively as possible, such connectors become problematic.

Best Wishes,
Chris Travers
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] [License-review] CC withdrawl of CC0 from OSI process

[Chris Travers]

On Thu, Mar 1, 2012 at 8:40 PM, Bruce Perens br...@perens.com wrote:
 On 03/01/2012 08:32 PM, Chris Travers wrote:

 I am not at all sure that line works once you get into trying to bridge
 GPL'd and proprietary apps

 Read
 http://www.datamation.com/osrc/article.php/3801396/Bruce-Perens-Combining-GPL-and-Proprietary-Software.htm

 Does it matter how I do this?

 Very definitely.

 Is it possible to accidently create a derivative work in the process?

 If you don't know what to do, you probably will, because the easiest ways do
 create them are the ones that are more legally risky. However, it's not
 terribly hard to build stuff in the more safe ways.

 What do I have to avoid on a technical level (because I am thinking
 technically when programming, not legally) to be sure I am safe?

 It's in the article, at least for a number of general cases.

Bruce;

The questions above were rhetorical.  Now that we agree that the above
questions I asked are valid questions.

I notice you say Don't assume that you can put proprietary kernel
drivers in a run-time loadable kernel module. The legality of such a
practice is dubious, and there have not been sufficient cases to say
reliably what would happen if you were to get sued, which comes back
down to the linking question.  You seem to say do not link and thus
repeat more or less what the FSF says (and what Rosen spends a good
time arguing against in his book, and he is by no means alone--- at
least in any law review articles I have been able to find and read the
overall trend is overwhelmingly against seeing linking as having much
to do with derivation).

So this gets to the problem that I think we are both trying to solve,
which seems to be a fools errand:  giving an engineering answer to a
legal question.  My sense (as a non-lawyer) is that communications
from a project are very much likely to affect the scope of the
license, and that downstream developers are likely to be able to
reasonably rely on communications from a project that some practices
are safe in their eyes.  So this is where the discussions help.

Best Wishes,
Chris Travers
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] [License-review] CC withdrawl of CC0 from OSI process

[Chris Travers]

On Thu, Mar 1, 2012 at 9:44 PM, Bruce Perens br...@perens.com wrote:
 On 03/01/2012 09:09 PM, Chris Travers wrote:

 You seem to say do not link and thus repeat more or less what the FSF
 says (and what Rosen spends a good time arguing against in his book, and he
 is by no means alone--- at least in any law review articles I have been able
 to find and read the overall trend is overwhelmingly against seeing linking
 as having much to do with derivation).

 My goal isn't to help my customers win after they're sued, it's to prevent
 them from ever being in a lawsuit at all. And you do that by staying away
 from some issues.

Ok, so part of avoiding lawsuits is to avoid areas where folks think
they can sue about.  So the FSF's statements are important here.

 Despite the fact that Larry and those law review folks are sure about the
 linking question, every party who would benefit from a case going according
 to Larry's interpretation has settled their case with the GPL licensor
 rather than invest what is necessary for a court to make a determination.

That's why discussion of the murkey middle ground is important.

 So, what do you do? You stay away from that issue and arrive at an
 engineering solution that avoids it.

It also depends on what your relationship is to your audience, and
this is the big issue with explanations that exist apart from the
license.  The FSF can interpret the GPL one way and Linus and the
Linux community in a different way, and if they are public about their
views, the license grant may actually be different.  I don't see
what's so hard to understand about that.  I think for practical
reasons we like to pretend that there is one true interpretation of
the GPL v2 but in fact I don't think that necessarily is the case.
 The GPL v3 tries to make progress there, but I can tell you that if I
ask two different lawyers with different ideological views regarding
free software what the implications of mixing BSD and GPL3 files in
the same project, I get two different answers.


 which seems to be a fools errand: giving an engineering answer to a legal
 question.

 Only a fool's errand if the engineer doesn't have good legal support, or if
 the lawyer isn't able to work with engineers. I address that a little
 differently, by acting as a consulting engineer who works for the attorney
 and has experience in this particular sort of case.

A fool's errand because the models simply don't match.  There are
cases where no amount of isolation will protect you from having
created a derivative work.  For example, suppose I write a graphics
driver which recognizes Doom's OpenGL calls, and transforms them in
some interesting way.  Maybe if I detect Doom is the one running, I
make walls transparent, or something.

The two programs may be running on different processors, may share no
code or expressive structures, but because the output is pretty
clearly a derivative work may in some cases be derivative itself.

There is no line where you can draw technically where everything on
one side is safe, and if you draw one where everything is not safe,
there's a good chance a lot of stuff on the other side is not safe.

 My sense (as a non-lawyer) is that communications from a project are very
 much likely to affect the scope of the license, and that downstream
 developers are likely to be able to reasonably rely on communications from a
 project that some practices are safe in their eyes.

 About the worst thing engineers can do is attempt to make legal
 determinations without proper counsel and the necessary training. They
 invariably get it wrong and they can be made to look really stupid in court
 by a competent expert witness. Relying on what they say about legal issues
 of their own projects would be ill-advised. Instead, learn how to engineer
 around the gray areas.

So here's the thing

What I am saying is there's a difference between you saying Linking
is legally dubipus under the GPL and me saying As far as LedgerSMB
is concerned, we interpret the GPL not to restrict linking and mere
use of API's, but believe that inheritance may be run into trouble.
At least given that I am more or less the de facto leader of the
LedgerSMB project.

The first is an attempt to describe the license in the abstract.  The
second is a representation on behalf of a project as to what license
rights we believe we are granting.   As I understand it, these are
very different statements..

Best Wishes,
Chris Travers
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] [License-review] CC withdrawl of CC0 from OSI process

[Chris Travers]

On Tue, Feb 28, 2012 at 10:44 AM, Rick Moen r...@linuxmafia.com wrote:
 Quoting Chris Travers (ch...@metatrontech.com):

 Any layman who wants to understand why this doesn't work needs only to
 pick up any of Derrida's books at the corner used book store.

 Anyone who cannot distinguish between the accessibility of Larry Rosen's
 extremely lucid work and Jacques Derrida's ridiculously obscure text has
 much bigger problems.

Derrida's theories on text and meaning are entirely applicable to
legal agreements even if we pretend they aren't.


Rosen's work is very lucid, insightful, and interesting.  It certainly
is one of the works I would refer people to.  However, there are a
couple points I would make:

1)  There isn't a lot of case law on what constitutes derivative works
in software as a whole, and it isn't clear to what extent this may be
an evolving field.  And it may not be clear how it will evolve until
one gets into court.

2)  Therefore a book which doesn't include in fairly clear detail the
various possibilities as to what courts *might* do is fundamentally
incomplete.  There is often a world of difference (that the FSF
exploits as much as they can, btw) between what you can be sure of as
a licensor and what you can be sure of as a licensee.

 However, as a reminder, it is _not_ necessary to read a comprehensive
 book on open source licensing to have a reasonable knowledge of how a
 major open source licence, particularly a simple permissive one, is
 constructed and why.

But this gets back I think to the problem with the idea that separate
explanations are sufficient, or even the question of how much abuse a
license needs to prevent.  You have essentially two separate aspects
of a software license and these need not overlap exactly:

1)  You have the legal contract which needs to be specific enough to
protect against the worst of the abuses.

2)  You have a social contract which rewards those who fill social expectations.

Consequently if I go out and, say, distribute psql linked to readline
(GNU GPL) and openSSL (incompatible with the GPL) as most Linux
distributors do, I am *probably* safe from legal retaliation by the
FSF for two reasons:

1)  This is probably within the bounds of the GPL for the reasons
Larry Rosen articulates, though the FSF claims not and who knows what
a court would rule given the additional explanations and so forth, but
it's a serious risk that the FSF might be ruled against.

2)  This is clearly within the overall accepted social contract of the
GPL culture.  If the FSF starts going after BSD projects because of
which other open source libraries they are linking to, this has social
costs as well.



 All human communication is subject to areas of ambiguity and
 irreducible complexity.  The more you try to specify, the more you
 will run into conflicts and omissions.

 Thank you, Captain Edge Case.

Edge cases include all kinds of things that have been discussed to
death on this list including:
1)  Linking GPL libraries to proprietary software
2)  Linking proprietary libraries to GPL software

(The above while very likely inside the scope of what is permitted by
the GPL is certainly outside the GPL social contract.)

3)  Taking BSD software and distributing it under the GPL without
changing the code.  Does the GPL v3 require allowing this?  If so, is
the BSD license incompatible?

(Even if, as the FSF claims, not inside the scope of what is
permitted, still within the GPL social contract)


 And as much as folks like to pretend that legalese is a programming
 language, it's not.

 I hope you're addressing this bit of packaged Polonius-grade wisdom to
 someone else, as I certainly have had no such illusion.  How many times
 have I said on this mailing list that the law (and judges) are not
 Turing machines?  Let's find out.

Not directed at you.  However the point is that with any contract you
have three categories of behaviors:

1)  Behaviors where the first party can be sure of a ruling in his favor
2)  Behaviors where the second party can be sure of a ruling in his favor
3)  Behaviors everyone avoids because there is at least some
uncertainty as to whether that would go to court and .

The problem with a lot of these discussions is that they ignore that
third category.   Being aware of where the uncertainty is on both
sides is very helpful.  I keep coming back to the question of How do
I, exactly, determine whether my software counts as a derivative work?
 How certain am I that this is what a court would hold?  Like it or
not, I agree that linking is irrelevant to the GPL, but I recognize
that what the FSF has done has been to draw a bright line around
something that is a very murky issue.

In LedgerSMB, we have publically said that linking is fine, but OO
inheritance implies a level of expressive intimacy that implies
derivation, as does using our code as a basis for your code.  In other
words, you can use our API, but you cannot create your own API based

Re: [License-discuss] [License-review] CC withdrawl of CC0 from OSI process

[Chris Travers]

On Sun, Feb 26, 2012 at 4:50 PM, Bruce Perens br...@perens.com wrote:
 On 02/26/2012 02:31 PM, David Woolley wrote:


 The reality is that the people who have to comply with licences are not
 professional lawyers.

 This is always in my thoughts when considering any Open Source license.

 We can fail these people in two ways:
    1. Provide them with a license that they might not understand.
    2. Provide them with a license that won't hold up in court.

 The second damages them more. The first can be solved with explanation
 separate from the license.

If the first can be solved with an explanation separate from the
license, why not use that instead?

Of course we don't use that instead because the explanation is not the
same as the license.   I also wonder whether in court a defendant
could successfully argue that the explanation is itself a license as
well and therefore when they disagree, the most permissive
interpretation of either wins?

I think it's important to keep licenses short, understandable in plain
English (outside of formulaic warranty disclaimers), and to the point.
 Sure there will be some abuse in some corners, but the alternative is
to write increasingly long, complex, and unintelligible licenses whose
main virtue is giving lawyers something to argue about what exactly
they mean in court...

Best Wishes,
Chris Travers
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] [License-review] CC withdrawl of CC0 from OSI process

[Chris Travers]

On Mon, Feb 27, 2012 at 12:00 AM, Rick Moen r...@linuxmafia.com wrote:

 Oh, bushwah.  Any layman who wants to understand in even paranoid levels
 of detail the major licences and has two hours to spare can pull down
 the PDF of Larry Rosen's book free of charge, among other methods of
 arriving at that understanding.

 And any of them who cannot comprehend MIT/X after two hours even without
 Larry's book probably should rethink running a business.

Any layman who wants to understand why this doesn't work needs only to
pick up any of Derrida's books at the corner used book store.

All human communication is subject to areas of ambiguity and
irreducible complexity.  The more you try to specify, the more you
will run into conflicts and omissions.  And as much as folks like to
pretend that legalese is a programming language, it's not.

Best Wishes,
Chris Travers
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] TCPDF license: LGPLv3 + a special clause: is this still considered Open Source?

[Chris Travers]

Does the GPL v3 give you the permission to drop legitimate copyright
notices from software or accompanying documentation?  I know as a
software developer I would most certainly NOT drop such attributions
for both legal and other reasons.

I would add further that the requirement for attribution/copyright
notice seems entirely in line with the 7b attribution terms.  I don't
see why you have to see this as a new license.

Best Wishes,
Chris Travers
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] GPL and proprietary WebAPIs

[Chris Travers]

 contributing back.  The shim being
 an actual anti-contribution since it may confuse users
 what is free software and what isn't.

Every open source license I know of allows some sort of bridging to
proprietary technologies.

Best Wishes,
Chris Travers
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] GPL and proprietary WebAPIs

[Chris Travers]

On Thu, Dec 22, 2011 at 2:00 PM, Lawrence Rosen lro...@rosenlaw.com wrote:
 Rick Moen wrote:
 You know, Clark:  Speaking for myself, I have no interest in advising
 querents about how closely they can lawfully skirt the requirements of
 copyleft licences, or how they can creatively circumvent those
 requirements entirely, in order to use copylefted properties in
 proprietary works.

 You keep asking basically the same question, but are seeing scant
 interest in helping you.  Might be that my view is common.

 Might be, but it is not unanimous. Indeed, I'm glad to advise companies how
 to circumvent the *purported* and *frequently misunderstood* requirements of
 the GPL.

Good for you (I mean that).  As I say in the LedgerSMB project we hold
API's (however invoked) to be freely usable with the minor exception
that inheritance probably crosses the line into derivative works land
(because once inheritance is much more expressively intimate than mere
linking).

 My opinion of the GPL licenses is that they do not prohibit the use of
 so-called creative circumventions to avoid having to disclose
 non-derivative works, despite the desire of some to call it morally evil.
 Linking GPL software to proprietary software is legal as long as one doesn't
 create a derivative work. If GPL advocates insist upon distinguishing among
 types of functional linking, then talented software engineers will avoid
 disputes by building shims, APIs, or use dynamic linking to accomplish their
 functional goals. More power to them!

The only caution I would give here is what I clearly stated in my
first reply.  The GPL is not only a legal document but also to some
extent a social contract as well.  In general what is legal under the
license and what is beneficial in skirting that edge may be separate,
and taking on the wrath of the community is not so good however a
court might rule.  The social costs of violating accepted norms may be
significant even if the action is technically legal.  Similarly even
if technically infringing (i.e. some interpretations of the BSD
licenses are incompatible with some interpretations of the GPL v3),
staying within accepted norms will never give you trouble.

Thus in general I think one is generally better off talking with
upstream projects and trying to get them on board.

Best Wishes,
Chris Travers
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] GPL and proprietary WebAPIs

[Chris Travers]

On Wed, Dec 21, 2011 at 10:26 AM, John Cowan co...@mercury.ccil.org wrote:
 Chris Travers scripsit:

 Now, if linking implies derivation, then isn't the software (and by
 extension *all* Windows software) derivative of Windows?  If that's the
 case then doesn't every developer of Windows software need Microsoft's
 permission to distribute such software?  I don't think so.

 I do think so, but in fact such permission is forthcoming.  Microsoft
 grants explicit permission to use its SDKs to construct software that
 is intended to run on Windows.  If it happens to run on non-Windows
 systems such as ReactOS or Wine, that is not the developer's fault.
 In this case of NDISwrapper, the Windows drivers that it wraps are
 licensed to run on the hardware they are being used on, since almost
 every PC is licensed to run Windows whether it actually does so or not.


But wait..  We didn't say licensed to run Windows.  We are talking
about Microsoft's legal right to prevent distributions of derivative
works.  The fact that hte hardware may have Windows licenses is
irrelevant as to whether a derivative work of Windows can be
distributed in the first place, or am I missing something?

In fact, if we go that route, why couldn't Microsoft have just revoked
Netscape's license to distribute Windows software and killed the
competition that way?

Best Wishes,
Chris Travers
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Greetings, Earthlings! Need quotes for article

[Chris Travers]

On Wed, Dec 21, 2011 at 1:28 PM, John Cowan co...@mercury.ccil.org wrote:
 Karl Fogel scripsit:

   Adaptive Public License http://www.opensource.org/licenses/APL-1.0

 This license was pretty much beyond my comprehension when it was first
 brought up, and it still is.

A Recipient (COMMERCIAL RECIPIENT) may choose to offer, and to
charge a fee for, warranty, support, indemnity or liability
obligations (collectively, SERVICES) to one or more other Recipients
or Distributors. However, such Commercial Recipient may do so only on
that Commercial Recipient's own behalf, and not on behalf of any other
Distributor or Recipient, and Commercial Recipient must make it clear
than any such warranty, support, indemnity or liability obligation(s)
is/are offered by Commercial Recipient alone.

Am I reading this right?  Wouldn't this at least be arguably outside
portions of the OSD (1, 2, 5, and 6) at least as regards natural
persons who receive the software from their corporate employers for
the purpose of providing warranty support or other covered services to
customers?


   Frameworx License http://www.opensource.org/licenses/Frameworx-1.0

 The issue here seems to be clauses 1d and 3b:

    1. (d) Value-Added Services means any commercial or fee-based
    software-related service, including without limitation: system or
    application development or consulting; technical or end-user support
    or training; distribution maintenance, configuration or versioning;
    or outsourced, hosted or network-based application services.

    3. (b) Any Value-Added Services that you offer or provide,
    directly or indirectly, in relation to any Downstream Distribution
    shall be offered and provided on commercial terms that are
    reasonably commensurate to the fair market value of such Value-Added
    Services. In addition, the terms and conditions on which any such
    Value Added Services are so offered or provided shall be consistent
    with, and shall fully support, the intent and purpose of this
    License Agreement.

The intent and purpose language here is pretty troubling.  Could
someone at least argue that providing support for people porting their
applications *from* the covered software would violate the intent and
purpose of the license agreement (which is obviously to bring the
framework to more people)?

Best Wishes,
Chris Travers
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] GPL and proprietary WebAPIs

[Chris Travers]

On Tue, Dec 20, 2011 at 6:35 PM, Clark C. Evans c...@clarkevans.com wrote:
 On Tue, Dec 20, 2011, at 03:30 PM, Chris Travers wrote:
 In general, good will from the projects at issue is a factor that
 should not be underestimated and being a good citizen means ideally
 making sure they are ok with it.

 Absolutely.  If people consider you to be behaving fairly,
 they are more likely to support your cause.

Also bad feelings can come back to hurt you later, legal actions or not.

 I can tell you how the LedgerSMB core team approaches this.  We draw a
 hard line between using our code (requires adhering to the GPL) and
 using our API (does not).  In practice this means if you use our code
 as a basis for your code whether through object inheritance, literal
 copying, or paraphrasing, we expect you to adhere to the GPL v2.

 Let's suppose that I've working on a Ledger++ program
 which is a proprietary version of your Ledger SMB that
 adds awesome multi-state Payroll and Asset Depreciation
 features.  Only rather than including these features
 in your code-base, I include only stubs that package
 up the data each feature needs, calls a proprietary
 web service, and returns the data.

Ok.  So far so good.

 So, about 5% of my code is a bunch of hooks, while 95% of
 my Ledger+ code remains proprietary.  I release the stubs
 under the GPL license... but effectively, the features
 I've added are completely useless and non-operational
 unless you've paid for my web service subscription.

Well, technically you'd probably release under the LGPL or BSD
license, sort of like nVidia does with their stubs for their Linux
video drivers.  Again this isn't a new thing.  You see a surprising
amount of it in Linux (ndiswrapper, the nVidia drivers that RMS hates,
etc).

 This is intended on our part to keep the based on
 language in the GPL v2 to be close to the derivative
 works definition in copyright law and recognizing that
 nobody needs copyright licenses from Microsoft to write,
 say, Internet Explorer plugins.

 My reading of the GPLv3 is that it uses copyright law
 to determine when you've made a modification, but, the
 condition to distribute your modification goes far beyond
 this limitation, including the whole of the work, and all
 its parts, regardless of how they are packaged.

That's not my reading.  My reading is that the license tries to get
away from the derivative works definition (maybe it's not strict
enough for Stallman?) through refining definitions.  Of course the GPL
is not a EULA and it only requires acceptance when you distribute the
work or derivative works, but that only covers some cases.

Let's try a thought experiment.  Let's say LedgerSMB depended on
Windows and was essentially using Windows-only API's (and thus linking
with Windows base libraries).  Now, I recognize that the GPL
specifically exempts linking to system libraries, but I see no reason
why system libraries are different from a copyright perspective (i.e.
this distinction exists solely because RMS wrote it into the license).
 Now, if linking implies derivation, then isn't the software (and by
extension *all* Windows software) derivative of Windows?  If that's
the case then doesn't every developer of Windows software need
Microsoft's permission to distribute such software?  I don't think so.

So if it isn't a derivative work and you aren't distributing
LedgerSMB, I am hard pressed to see how legal action could be
successful in court, but IANAL.  OTOH, it could be very successful
both in terms of expenses involved and bad press to get you to do what
I want.  Really, this is what the FSF did to Apple over the Objective
C add-ons to the GCC.  Sooner or later though someone will fight
through and win and this will lose its effectiveness.

 In this view, there is no problem. There wouldn't even be a problem,
 in this view, if the libraries were linked provided that the code
 connections are not so intimate as to create a derivative work (for
 example, I would argue that class inheritance in fact does this).

 Would you have a problem with the scenario above, perhaps
 assuming I'm implementing a business feature that you consider
 to be core to the mission of Ledger SMB and you would have
 hoped would be contributed back to the project?

Would I personally have a problem with that?  Not as such, though I
might think you were doing something unwise.  You are obviously
building a market for us and helping define how payroll should work
and how we should enhance our asset depreciation features.  However,
as we develop these, you are faced with a problem in that refusal to
contribute back would increase your own maintenance efforts for
diminishing returns.  You can't just take our code and close it all
off because of the GPL, and then fork and go on your way as a
proprietary product, so you are kinda trapped.  So in other words this
technique doesn't work around copyleft so much as it limits the
applicability of copyleft to code as code

Re: [License-discuss] Looking for a license agreement.

[Chris Travers]

On Fri, Oct 7, 2011 at 8:09 AM, David Woolley
for...@david-woolley.me.uk wrote:
 Chad Perrin wrote:

 someone else.

 This may be a touch off-topic for this list, but . . . why would you want
 to grant someone the ability to prohibit others from using *facts* by the
 simple expedient of (for instance) alphabetizing a list of facts?  That's
 insane.  In a time when even the ability to maintain a monopoly over
 things that have been *created* is becoming controversial, someone
 asserting a monopoly over information that has been *found* seems quite
 regressive and, frankly, harmful.


 Database copyrights are not like patents.  As long as you obtain the fact
 independently, you can publish them.  Telephone directories and maps have
 bogus entries to help detect whether a competing compilation is truly
 independent.

Darn it!  I was still hoping to get my copy of Flags Up! by Lillian
Mountweazel.

Best Wishes,
Chris Travers
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss