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

[Bruce Perens]

On 4/17/2013 10:12 AM, Karl Fogel wrote:

Bruce Perens  writes:

Karl, Robin means that the work is dedicated to FSF and placed under a
BSD or MIT license. These are compatible with the GPL and FSF is fine
with it.

Er, yes.  (Was there something I said that contradicted that?)
projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Just that Robin doesn't know as much about this, and it's really easy to 
confuse rather than enlighten :-)


Robin, FSF's main concern is that works meet their "Four Freedoms", 
which the permissive licenses would. They have a secondary goal of using 
reciprocal licensing as a strategy to increase the amount of good free 
software, but it is not my understanding that they would reject a work 
for being permissive.


Of course, with FSF holding the copyright they can, theoretically, 
determine the license. However, they are much less likely to do this as 
long as there is still an active developer running the project and the 
license used meets the four freedoms. Richard Stallman knows through 
long experience that pushing on developers about licensing can get them 
really annoyed, and the FSF's director is more empathic than Richard and 
thus unlikely to do that either.


A more modern way for a project to donate than to assign to FSF would be 
to become a member project of the Software Freedom Conservancy. This 
organization is very clearly on the side of Free Software but leaves the 
control of the project in the developer's hands.


Thanks

Bruce

___
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

[Bruce Perens]

Karl, Robin means that the work is dedicated to FSF and placed under a 
BSD or MIT license. These are compatible with the GPL and FSF is fine 
with it.


Thanks

Bruce

On 4/17/2013 10:04 AM, Karl Fogel wrote:

Robin Winning  writes:

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?

It's technically valid, in that the FSF (as a non-profit corporation)
can hold copyrightable assets under any licenses it wants.

But it's likely usually a mistake, in the sense that the FSF probably
has no idea these works are being "donated" to it under these non-GPL
licenses, and because there is usually no need to make the FSF the
copyright holder -- except in certain cases where the FSF is actually
involved in the development or maintenance of the software, in which
case they would have discussed this with the programmer and, in most
cases, the FSF would have insisted on one of the GPL family of licenses
(though there are some exceptions to that).

I'm not a lawyer and this is not legal advice.  There are plenty of
people who can give you real legal advice if you need; we may be able to
help you find those people.


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.

Nice researching (re ncurses)!


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.

It's not contradictory, but it's probably often a mistake by a
programmer who thinks that putting a license's terms on some software
implies that the software's copyright must now be held by whatever
entity wrote that license -- which, of course, is not the case and not
the norm.

-Karl
___
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?

[Bruce Perens]

We appreciate what we got. But my point is that maybe with a well written 
license Victoria Hall would have finished the case on her own in the lower 
court.

Lawrence Rosen  wrote:

>I note that the plaintiff in the Jacobsen v Katzer case won on appeal
>to the
>CAFC. So reading the judge's decision in the district court is kind of
>irrelevant at this point.
-- 
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

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

[Bruce Perens]

Ben,

Yes, my testimony was to establish the economic interest in attribution of Open 
Source software. However, it's going too far to say that the license terms were 
not a problem. The judge's finding starting at "Plaintiff's Claim Sounds in 
Contract, Not Copyright" is that the Artistic License 1.0 text is 
self-invalidating. It's not so clear that a better drafted license would have 
reduced us to basing the appeal on the economic value of attribution alone.

Thanks

Bruce

Ben Tilly  wrote:

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

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

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

[Bruce Perens]

It isn't the least bit difficult to diagnose when no lawyer was involved in 
drafting a license. At the start we had an excuse because no lawyer would help 
us. The only excuse those licenses have today is disinterest in fixing the 
problem.


Luis Villa  wrote:

>On Wed, Mar 6, 2013 at 10:15 PM, John Cowan 
>wrote:
>> Bruce Perens scripsit:
>>
>>> 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.
>>
>> Please itemize.
>
>I don't think we do anyone any favors by having extensive public
>discussions of the legal/drafting weaknesses of existing licenses, so
>please don't.
>
>The point stands that some licenses are poorly drafted, and that in a
>perfect world where we could easily identify and evaluate such
>licenses, we would probably no longer publicize/endorse them.
>
>That said, as Richard pointed out, this is an extremely difficult
>issue to evaluate. It is inherently subjective, and a matter requiring
>expertise. Given that, I see  no evidence that OSI (or anyone) could
>perform it in a reasonable, objective, efficient manner, so I'm not
>very interested in pursuing it.
>
>Luis
>___
>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

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

[Bruce Perens]

The license isn't really "standing up" when you have to file a writ of 
certiorari after a judge throws his hands up at the license text and pronounces 
it to be tantamount to a dedication to the public domain. That was no easy 
appeal to win, and the Open Source developer was seriously damaged by the cost 
and the 5-year process. It cost me a good deal of time and work too.

A license that stands up would, I hope, require much less time to dispute and 
would be parsed as intended by the court.

So, what the Artistic License 1.0 made much more difficult for the poor Open 
Source developer is exactly what I'd like to fix. And yet the Artistic 1.0 is 
not the one I thought of first upon seeing this discussion in progress. We have 
much worse.

Thanks

Bruce

John Cowan  wrote:

>Bruce Perens scripsit:
>
>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

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

[Bruce Perens]

The justification for de-listing presently accepted licenses is that:

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.


2. They don't comply with the OSD and were accepted in error.

3. They are both redundant /and /rarely used.

Those are the only justifications. You don't get to de-list something 
because you don't like its politics.


I think you need to have a committee review a proposal to de-list, with 
arguments from the submitter regarding the problems in the license, and 
with advice from an attorney on whether the suggested problems are 
really problems.


Thanks

Bruce

On 03/06/2013 08:23 PM, Luis Villa wrote:

On Wed, Mar 6, 2013 at 11:48 AM, Richard Fontana
 wrote:

The Frameworx license is one of those OSI-approved licenses that I
believe was approved "in haste". If OSI had such a procedure, I would
recommend that the Frameworx license be reviewed for de-listing.

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

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


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

Re: [License-discuss] List moderation and CoC enforcement [was Re: proposal for revising (and making relevant) the code of conduct]

[Bruce Perens]

> * *On-list*: discussing conduct on-list, either as part of another
message or as a standalone thread, is always acceptable.

Pretty often this sort of discussion has triggered an instant flame-fest.

And I have to agree with John. If there's a breach of civility, direct
confrontation is unlikely to solve it.

It's best if moderators actually moderate.

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

Re: [License-discuss] License which requires watermarking? (Attribution Provision)

[Bruce Perens]

Would that we all had infinite budgets for going to court :-) But short 
of having them, many businesses choose, quite sensibly, to err on the 
conservative side of this sort of issue and will honor the license 
whether or not a court would make them do so. This will also get them 
through an M&A intellectual property audit in better shape than otherwise.


I do know a company that spent money, including on me, to argue just 
this sort of issue recently. They spent more than most businesses would 
be able to endure.


Thanks

Bruce

On 01/01/2013 05:23 PM, Lawrence Rosen wrote:
Really? That's not wise. How would the choice of license affect the 
*legal* determination of whether the resulting work is or is not a 
derivative work for which source code must be disclosed?


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

Re: [License-discuss] License which requires watermarking? (Attribution Provision)

[Bruce Perens]

On 01/01/2013 02:08 PM, Ken Arromdee wrote:


Some people use ordinary GPL on libraries with the intent of crippling 
competing commercial reuse (since any competitors have to release 
their source and competitors wouldn't want to do that).  Is the GPL 
also considered unfree when applied to libraries?

No.

Be careful to avoid confusing the creation of derivative works with use, 
which are two separate rights under copyright law.


And although badgeware should in general be rejected, "crippling 
commercial reuse" is the wrong reason to reject badgeware.


The reason to reject it is that it complicates simple use. We'd really 
like it to be possible for people to use software without the need for 
some compliance process. That line is crossed when you create a 
derivative work. If you have to be sure to put badges on your web site 
for some set of software you use, possibly a very large set, then you 
have to keep track of the software and its license terms just to use it, 
and simple use is no longer simple. There is also no limit to the 
potential number of badges you might have to display.


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

[Bruce Perens]

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

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

[Bruce Perens]

On 09/10/2012 01:38 PM, Rick Moen wrote:

Quoting Karl Fogel (kfo...@red-bean.com):

It's better to question reasoning than motivations, on this list and probably 
most others.

Karl,

I question why you didn't call a halt when the discussion was obviously 
becoming a testosterone contest past the point of any useful content. 
OK, you'll never have the time to moderate. That's fine. What isn't fine 
is that you don't find someone else to do it.
<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
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?

[Bruce Perens]

On 09/07/2012 11:24 AM, Rick Moen wrote:

I don't think you are approaching this discussion with a serious attitude, 
attention to the subject, and/or a sense of perspective.

Is this really a serious discussion?

It sounds to me more like a contest of how many silly things some of us 
can get away with doing or advising our clients to do, in avoiding a 
requirement that is brain-dead simple and no sweat for anyone to fulfill.


Some lawyers and IP specialists enjoy sophomoric discussions of legal 
theory that has little value in real life. I guess they can blow off 
steam here, at least until it gets /too /annoying. I hope they don't 
waste their clients time on such things.
<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
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?

[Bruce Perens]

Larry wrote:

I think it would be FAR more useful to have a simple license
statement in the source tree of each program that points to the
OFFICIAL version of that license on the OSI website.

You are very optimistic regarding the longevity of OSI.

<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
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?

[Bruce Perens]

On 09/06/2012 03:07 PM, Luis Villa wrote:
Custom waivers (particularly for something trivial like this) are just 
another form of the same mess.
Posit that I am creating a version of the old Lyons Unix book, 
containing the Linux source code. How many copyright holders must grant 
me a waiver? Is the answer the same across all jurisdictions?


It is easier to print the GPL than it is to even /start /analyzing 
questions like rights in a compilation vs. rights in a collective work.


Thanks

Bruce
<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

[License-discuss] licenses and software in books

[Bruce Perens]

So, I have 24 titles in my old book series that have mostly dealt with 
this issue.


Conveying the license text in print form is not an odious requirement. 
There are 200 to 400 pages of tutorial material, to dedicate two to a 
small-print rendition of GPL is no hardship.


Nobody ever requested the source code on a CD. Where appropriate, it was 
available for download. If anyone tries to contest that download is not 
an appropriate medium under the terms GPL2, they are doing it to be 
difficult, not to get the source. We would have had the means to deal 
with such a person.


In general, all parties went to the project (for example, Samba) for the 
source code.


A book isn't a computer program. While we could fulfill the GPL terms 
easily enough, we could have also made a case that the program 
inclusions in the book were quotations in a critical work, and should 
have been handled as such.


We had no power to issue waivers, since we weren't the copyright holder 
of the software.


Thanks

Bruce

On 09/06/2012 02:55 PM, Rick Moen wrote:

Quoting John Cowan (co...@mercury.ccil.org):


The difficulty is that text often winds up in printed books, and then
you either have to distribute a CD with the book containing the editable
source, or be prepared to issue such CDs for no more than the cost of
distributing them.   Both are expensive and awkward activities, and
neither is well-supported by the printed-book sales channels that exist.

Emphasis added:

_Um, hello?  Waiver._

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


<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
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?

[Bruce Perens]

Arguing the merit of plain text vs. HTML is just Lilliput v. Blefuscu. 
Provide both, for different reasons.


Plain-text is a better source for cut-and-paste operations.
In general plain text divides the actual license text from any attached 
commentary, making it clear which is which.


There is no universally-accepted standard for indicating the character 
set of plain text in the data, rather than in an external indication 
such as the HTTP Content-Type header. There is an assumption, sometimes 
wrong, that plain-text is ASCII. ASCII isn't capable of representing 
non-Latin character sets. Web servers often misrepresent the character 
set of plain text, since the content-type indication is set in an 
external file rather than the content itself.


HTML provides some desirable features:

Web page producers are more conscious of the need to represent the page 
character set accurately. It is possible for a web site to enforce that 
all pages be UTF-8, and for most national characters to be represented 
accurately.


However, not all sites are this well-disciplined, and there are regional 
issues such as the Han unification in UTF-8 that can cause an 
undesirable rendering of a character for languages like Japanese. In 
logogramic languages, getting a character wrong in a legal document is 
much more likely to cause an unintended change of meaning. This is not 
to say that plain text could render these characters at all.


HTML provides internal anchors which can be referenced by external 
documents, providing a way to link to a particular paragraph (or finer, 
if provided) from an email or article.


HTML provides a wealth of methods for rendering commentary internal to 
the document. It can be called out by changes in font, color, or 
position. It can be hidden and revealed using javascript, CSS, or 
document structure, and selected by hover-over or click.
<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] relationship between opensource code and the copyrighted works it produces?

[Bruce Perens]

On 09/05/2012 08:19 AM, Karl Fogel wrote:
My understanding (I am not a lawyer) is that copyright only applies to 
creative works -- specifically, to works resulting from human 
creativity, or to the portion of a work that results from human 
creativity. This is why, for example, the information in a phone book 
cannot be copyrighted, but a song reciting those numbers could be.
Or indeed, a work containing a creative form of organizing or presenting 
the phone numbers could be copyrighted, while the data could be 
/extracted from it/ and would not be covered by copyright.


There is one thing to watch out for: do your tools embed the copyrighted 
work of others in your work? It used to be that Inkscape /did, /and the 
same has been true for other tools.//In the case of Inkscape, it placed 
a raster texture called "Sand" in SVG works, and that texture was under 
Creative Commons Attribution 2.5 . Wikipedians were uploading SVG images 
to Wikipedia and dedicating them to the public domain, but they had this 
embedded texture that was /not /public domain.


I think that Inkscape has since been cleaned up. You can see the 
Wikimedia Commons discussion at

http://wikimedia.7.n6.nabble.com/Licensing-for-textures-within-SVG-files-td1473913.html

Thanks

Bruce


<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] OSI approved license without original license and reproduction of notices required in redistributions?

[Bruce Perens]

There are two different fundamental forms of copyright regime. One is 
based upon the right to copy, and the other is based upon the moral 
rights of authors. A number of European nations, for example, are moral 
rights regimes, while the U.S. is based upon the right to copy.


However, even in the United States, there is moral rights law, but it is 
often in state law. For example, the California Art Preservation Act. 



Thanks

Bruce

On 07/16/2012 07:16 AM, Johnny Solbu wrote:
The reasoning behind it is to give credit to the authors. To ensure 
that happens, the law make it as a statutory requirement. The author 
cannot waive this right.


<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Is it possible to use code or knowledge from Manuals/Wiki/Blog/Resonal pages?

[Bruce Perens]

For my legal protection, don't treat this information as if it came from 
an attorney 'cause I'm not one. There are various free attorneys who 
help Open Source projects, you can ask them if necessary.


On 07/10/2012 06:30 AM, Oleksandr Gavenko wrote:


Is it possible use knowledge I get form these sources? In case of patent I 
think no...
Copyright would allow you to do so. The generally-used strategy 
regarding patents for an Open Source project is to proceed on the 
assumption that there isn't one until you are informed otherwise, and 
then ask legal counsel for advice. If you are some deep-pockets company, 
the strategy is different but you would also have your own attorneys to 
advise you.


And it also depends upon the purpose. Publishing information about a 
patented process doesn't infringe, using the process potentially does.


I don't understand this. For example I use copyleft licence for my program and
Wikipedia use copyleft (share alike) license for its content. I got conflict?
Which copyleft license? There can be copyleft licenses that are not 
compatible with each other in the specific terms of the license. Even 
GPL2 vs. GPL3. Are all of the pieces clearly under the same license or 
compatible licenses? Sometimes it is a lot of work to figure that out. 
And be sure to attribute the pieces correctly, and provide information 
about their licensing.


Wikipedia free for knowledge but non-free for use it in free software with 
different statements for freedom?
Generally what you find in Wikipedia is an explanation of an algorithm. 
This algorithm isn't copyrightable, but the specific way it is written 
can have copyrightable parts. So, the easy way to deal with this is to 
look at how it works and write your own version. The more complicated 
way would be to develop an understanding of the functional vs. 
expressive dichotomy in copyright law, in which case you would start by 
reading the decision in CAI vs. Altai.




Interesting also case of non-free references and standards. They define a
coupe of constants, without which you can't develop certain types of protocol.
You need to copy a large part of constants and adapt many symbolic names for
these constants...

Is that valid?
We just had a re-iteration of the functional vs. expressive debate in 
the Oracle v. Google case regarding Java. It made it even more clear 
that the functional part of the Java specification was not 
copyrightable. You get to use the constants, function names, etc. The 
problem would not be copyright, but patents.


Thanks

Bruce
<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] GPL linking exceptions

[Bruce Perens]

On 07/05/2012 06:30 PM, Chris Travers wrote:
Generally RMS seems to think this is not permissible, and most other 
people outside the FSF don't listen.
It is not permissible to modify the GPL text directly. That restriction 
has teeth. However, I can't think of a legal mechanism that could be 
applied to prevent exceptions to the GPL that are in separate text.


It would be different if there were contractual restrictions connected 
with the use of the GPL text. But there are none.
<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] GPL linking exceptions

[Bruce Perens]

There are really two sides to this problem. Is your license still OSI 
certified, and can you do this legally.


Regarding the OSI certification, the question is whether all of the 
rights granted by the certified license still apply. If this is the 
case, you can still say that the work is under the certified license.


None of the requirements of the Open Source Definition require that the 
license make restrictions, so removing a restriction would not in 
general cause a license to no longer be Open Source.


Then, the legal side. Of course, discuss this with your lawyer:

1. Make very sure you own the entire thing, or at least rights to 
relicense all of the covered code.
2. Given #1, you have the right to apply any number of licenses, 
including removal of restrictions.
3. Make sure that all changes you accept are either under the license 
exception as you specify it, or have the copyright or the right to 
relicense transferred to you.


Make sure that the way you communicate your removal of a restriction 
makes clear that the restriction is removed only regarding your own 
property. The GNAT modified GPL does this with the statement: /This 
exception does not however invalidate any other reasons why the 
executable file might be covered by the GNU Public License.


/Thanks

Bruce/
/
 On 07/02/2012 09:48 AM, Felix Krause wrote:

Hi everyone,

does a linking exception to the GPL require approval, or may a software be 
called open source whenever it is licensed under the GPL, even when the 
publisher grants the user additional rights?

There are some licenses around that add a linking exception to the GPL. The one 
I use is the GNAT Modified GPL [1]; but there are also others like the 
exception in the license of the GNU Classpath project [2]. Both licenses are 
not mentioned on the OSI site.

I think the core question is, does adding a linking exception to the GPL create 
a completely new license (which would need approval as open source license), or 
does it still count as licensed under the GPL and thus open source?

I think it would be a good thing if this question was answered by the FAQ.

Cheers,
Felix



[1]: http://en.wikipedia.org/wiki/GNAT_Modified_General_Public_License
[2]: http://www.gnu.org/software/classpath/license.html
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss



<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Bruce Perens]

On 06/11/2012 12:52 AM, Rick Moen wrote:
{scratches head} I think you must somehow be massively misreading what 
I said. Perhaps you thought I'd expressed a view about using an API 
(somehow) creating a derivative work? I didn't say anything of the sort.

It's regarding your statement:

   it doesn't seem likely to cast light on other areas of copyright
   law.  In particular, it cases none on what suffices to create a new
   work and what is a derivative work.

The point is that there's not /anything else/ in that body of law that 
would make the proposed work derivative.
<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Bruce Perens]

What legal theory would make a user of an API a derivative work if the 
API is not itself copyrightable?


On 06/11/2012 12:37 AM, Rick Moen wrote:

I belive I heard that his holding is that
Google wrote or commissioned independent code implementations of all
37, leaving only the question of whether the designs and names of the
functions in the reference API packages are covered by copyright.
He said they weren't -- which does not strike me as very surprising,
given the uncopyrightabilty of names and the idea/expression dichotomy
(patent/copyright division).   Other than giving clarification that
claiming an API is inherently copyrightable isn't going to fly, it
doesn't seem likely to cast light on other areas of copyright law.
In particular, it cases none on what suffices to create a new work and
what is a derivative work.


<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Bruce Perens]

On 06/11/2012 12:18 AM, Henrik Ingo wrote:
To be clear, NuSphere did not embed MySQL in their product, rather 
they embedded closed source components into MySQL
Per Eben's testimony, the Gemini storage engine, using the MySQL API for 
storage engines.
Which would be a funny relevation after a couple decades of successful 
GPL enforcements and several companies building a successful business 
on a more strict interpretation of GPL / the law.
I'm not going to advise people that they can mix GPL and proprietary 
software with impunity. And I will continue my own dual-licensing 
business. But I'm not going to be certain of my ability to prevail in court.
<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Bruce Perens]

On 06/10/2012 10:49 PM, Rick Moen wrote:
I believe this is entirely consistent with what I said, Bruce. You 
even said 'Read caselaw.'


I think we need to come to grips to the fact that it may be possible for 
GPL software to be embedded within a proprietary software product a la 
NuSphere without the result being infringement. At least as long as they 
provide source and a license statement for the GPL part.


If you go back to Progress Software (NuSphere) v. MySQL, the MySQL guys 
signed a contract with Progress without ever having it vetted by a 
lawyer. NuSphere had a reasonable assumption that they had a right to 
embed the program in their product. The MySQL guys messed up in a big 
way and were lucky to not have had to pay for it.


Thanks

Bruce
<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Bruce Perens]

On 06/09/2012 01:53 AM, Rick Moen wrote:

Read caselaw. I'm done.
I'm glad Rick's done. There is a good chance that you, not Rick, are 
right. Recent case law is that APIs are bright lines between separate 
works and that connections across APIs do not create derivative works. 
And this is regardless of the way software is linked. Go read the recent 
finding in Oracle v. Google, it only reinforces that point.
<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Bruce Perens]

On 06/08/2012 08:55 AM, Tzeng, Nigel H. wrote:

It amazes me that after all these years GPL proponents [...]

Not a positive contribution.

There are simple economic justifications for using a sharing-with-rules 
license or a gift-style license. One determines the desired result, and 
then one or the other is obviously appropriate.


Thanks

Bruce


<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Bruce Perens]

Rick,

I suggested that metric to tease Larry. He's been vociferous about the 
GPL and its enforcement previously.


You bring up the issue of court tests, though. It's not really the 
licenses that need testing, but some of the assumptions upon which they 
are built. So, Jacobsen v. Katzer was useful because it establishes that 
the Free Software developer has an economic interest and can use the 
full gamut of enforcement tools to protect that interest. Not because it 
included a court test of the Artistic License Version 1, a license that 
we are happily mostly rid of.


Oracle v. Google, if it stands (we have about 2 months to see if Oracle 
will really file cert), does two things, I think. It makes it even 
clearer that we can re-implement proprietary APIs in Free Software with 
impunity, and it makes it even less likely that we can successfully 
enforce that run-time combination of works at an "API" boundary creates 
a derivative work. We'll take that, we're more interested in freedom 
than enforcement.


I completely agree with you that it's silly to litigate with a Free 
Software developer. I'll take it farther, though. It's even silly to 
litigate with a Free Software developer /when they're wrong./ SFLC has 
previously insisted that dynamic-loaded Linux kernel drivers be provided 
in source form and under a Free Software license as a step in 
compliance. IMO they're on shaky ground with that; but it's easier to 
comply, in almost all cases, than to fight. So, I will continue to 
advise against proprietary run-time-loadable drivers despite Judge 
Alsop's finding on APIs.


Thanks

Bruce
<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Bruce Perens]

On 06/05/2012 09:22 AM, Lawrence Rosen wrote:


[I’ll add something now about MPL 2.0: It was submitted for approval 
in early December of last year and approved within a few months, as it 
should have been; it is a good license. Yet it appears already on the 
list of OSI-approved licenses” as “popular, widely used, or have 
strong communities.” Is it because there are defenders of the MPL 2.0 
on the OSI board?  Is that honest, fair, unbiased and legitimate?]


If MPL 2.0 was applied to Mozilla foundation software, it would 
immediately qualify as "popular, widely used, or have strong communities".


There are some absolutely horrid licenses that have strong communities. 
A certain font license comes to mind.
<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Bruce Perens]

On 06/04/2012 09:36 AM, Lawrence Rosen wrote:
Get rid of any indication that "popularity" [1] has anything to do 
with legal viability.
Yes. Let's instead rank the legal viability of licenses according to 
which ones have been enforced successfully the most times. You have no 
problem with that, do you Larry :-)
<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] license for code used for scientific results?

[Bruce Perens]

Kevin,

If you want to make everything fit in the framework of Free Software, 
you can get a lawyer for free through the Software Freedom Conservancy, 
and there is a well-established history of them going to court for their 
clients. But you have to fit in their parameters of Free Software.


It's worth discussing with Brad Kuhn. Maybe he'll see a way.

Thanks

Bruce
<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] license for code used for scientific results?

[Bruce Perens]

On 04/30/2012 10:13 AM, John Cowan wrote:
Conditional copyright licenses are most closely analogous to 
conditional licenses to enter land

:-)

Well, this is more than a bit of a stretch, but I can argue it this way 
if you like.

Of course, in civil law land, licenses are contracts, period.

The difference is in how they are enforced.

To enforce a license to enter land, the plaintiff can ask for criminal 
action on basis of tresspass, tresspass being a greater offense than 
breach of contract. The defendant claims there was a license and the 
plaintiff shows why one did not exist in those particular circumstances.


Similarly, the plaintiff sues for copyright infringement rather than 
breach of contract, and doesn't set out to prove consent and otherwise 
build a contract case.


The only value in licenses is that they can be enforced. If you don't 
care about enforcement, publish what you want as a guideline, and live 
with the fact that not everyone will follow it.


Thanks

Bruce

<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] license for code used for scientific results?

[Bruce Perens]

On 04/30/2012 08:36 AM, Kevin Hunter wrote:
I'm not looking for responses along the lines of "you can't enforce it 
so ignore it."  I'm very specifically focused on the licensing aspect.

Hi Kevin,

People who understand what they're doing won't generally write a license 
that can't be enforced because it makes them look stupid.


What you need is a contract, not a license. In general the Open Source 
licenses only deal with copyright, and you can't compel some action 
unrelated to copyright, like publication of research results, with a 
simple license.


Thanks

Bruce

<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Is the old style MIT license a Free Software license

[Bruce Perens]

On 03/13/2012 12:31 PM, Karl Fogel wrote:
I believe the "without fee" here refers to payment to the original 
licensor
Yes. The statement is "permission [to exercise a number of rights] is 
hereby granted without fee."
If it were "permission [to exercise a number of rights] without fee is 
hereby granted", the answer would be different.


Thanks

Bruce
<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] [License-review] CC0 incompliant with OSD on patents, [was: MXM compared to CC0 ]

[Bruce Perens]

On 03/09/2012 11:41 AM, Rick Moen wrote:
As an afterthought, OSI _might_ decide to adopt a policy that all new 
licences should at least not disclaim/waive any implicit patent waiver 
that might be created against patents held by licensor (estoppel 
defence) -- or establish some other minimum requirement on that subject.

...
If OSI elects to impose such a minimum requirement, it wouldn't 
necessarily need to amend OSD, but rather could find that OSD#2 
implies it.

In other words, do what has previously been done, but consistently.

Thanks

Bruce
<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] license committee

[Bruce Perens]

On 03/09/2012 09:49 AM, John Cowan wrote:

Fonts are not documents.  What's meant is that the license doesn't apply
to a document created using the font.
Obviously that is what is meant. But what it says is arguably different 
from what is meant. A professional would never have made such a silly 
mistake. And the point is that OSI can't even bring itself to 
dis-approve the "crayon" licenses.
<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] license committee

[Bruce Perens]

On 03/09/2012 09:13 AM, John Cowan wrote:

And the results would be different this time, why?
They would only be different if the organization became politically 
capable to dis-recommend licenses.


I think my favorite is probably still the SIL font license, where it 
says "The requirement for fonts to remain under this license does not 
apply to any document created using the Font Software." As far as I can 
tell, that allows you to convert a font to any license or no license, 
and then extract it again, and the SIL license doesn't magically come back.


Obviously there's a pretty strong potential to let down developers if 
that's the case. They end up with no control at all.


Thanks

Bruce
<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

[License-discuss] license committee

[Bruce Perens]

If I'm not mistaken, this committee met in 2004? "Time to do it right" 
would be about doing it /over./ Did I miss some announcement?


On 03/09/2012 08:55 AM, John Cowan wrote:

Karl Fogel scripsit:


If you want an organization that recommends licenses, the FSF is happy
to help. I agree that OSI should have a short-list of recommended
licenses, but the politics of dis-recommending some organization's
license are too much for them.

This isn't actually the case, by the way.  It's not the politics; it's
more the time it takes to do it right.

I sat on the committee that came up with OSI's current classifications.
Its original remit was to evaluate licenses into best/okay/bad, but no
one except me was willing to actually say that a license was bad or that
people shouldn't use it, so we wound up with the existing, basically
fact-based classification scheme.  And we took plenty of time just to
get to that, so it wasn't a matter of time.

I believe I was the only non-lawyer on that committee, except for ESR
who wasn't able to attend most of the meetings.



<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] [License-review] CC0 incompliant with OSD on patents, [was: MXM compared to CC0 ]

[Bruce Perens]

On 03/08/2012 12:51 PM, Rick Moen wrote:
the notion that anyone who thinks new licences ought to address patent 
issues in some way is logically obliged to try to revoke BSD licence's 
OSI Certified status (or formally deprecate the licence) is absurd, 
and we could have done without those and similar time-wasting polemics.

And they should stop now, please.
(3) Irrespective of CC0's merits as a fallback permissive licence, the 
document's fundamental reason for existing is foolhardy: the 
delusional belief that creative works can be safely magicked into the 
public domain despite a worldwide copyright regime, and the equally 
delusional belief that it's even desirable to try (and thereby, among 
other problems, have no protection against warranty claims).
Which makes it not tremendously worthy of the continuing effort to get 
it approved, IMO.
most of us agree that it's useful for newly crafted licences to permit 
at least implicit patent defences if not explicit patent rights, and 
that modern licences that address such matters are, all other things 
being equal, a better idea than ones that don't
DiBona called for it to be explicit in licenses going forward, I agree. 
Let's not ignore how the times have changed and what we have learned 
since starting with Open Source.
-- but that saying that is miles away from saying BSD should be 
formally deprecated. 
To be put in whatever hole is reserved for all "if you do this, you must 
also shoot yourself in the foot" arguments.


Thanks

Bruce
<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] combining GPL and proprietary software - was: CC withdrawl of CC0 from OSI process

[Bruce Perens]

On 03/02/2012 11:34 AM, Chad Perrin wrote:
Something tells me it is not reasonable to just always expect that 
writing open source code guarantees the EFF's help.
Sure. But folks who have asked me for help got me free, and I've 
sometimes found them an attorney too. This is something I would 
otherwise charge $7.50 per minute for.


<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Linking question

[Bruce Perens]

Larry Rosen wrote:

Is anything else required under the GPL or by the Busybox copyright owners? 
Specifically, is any of my client's proprietary software subject to disclosure? 
Must my client help anyone -- through product documentation or the disclosure 
of his proprietary code that he has purposely linked statically to Busybox -- 
to replace or upgrade Busybox itself in those millions of distributed 
proprietary wireless devices?


I am aware of a number of negotiations with Bradley Kuhn regarding 
Busybox and uClibc enforcement. Bradley was not representing my 
interest. When I was involved, I was working for the manufacturer's 
attorney and had waived my own copyright interest with regard to that 
customer. Some of the cases I know of played out before my involvement 
with that customer, and some with my direct involvement.


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.


In order to get this forgiveness, all parties that I know of have been 
required to provide complete and corresponding source code for /all 
/software with a Free Software license in the system, regardless of its 
connection with Busybox or whether SFC or SFLC was representing the 
interest of the developers of that software.


When there was static linking to uClibc, it had to become dynamic.

Parties had to provide source code for run-time loaded kernel drivers.

Once a set of Complete and Corresponding Source Code for a release was 
constructed, that release was made available to customers as an update, 
and I suspect was automatically updated in some devices. I have not 
heard that anyone was required to cause every customer to update.


In all cases, Bradley was reasonable and a pleasure to work with. When 
he became overloaded and was unable to respond to companies in time, he 
did not enforce upon those companies obligations that he otherwise could 
have.


Of course, Larry, I understand that this is not what you think should 
happen. However, it appears to be how a lawsuit or something that could 
have become a lawsuit has been resolved, in every case that I know of.


Thanks

Bruce

On 03/02/2012 11:13 AM, Lawrence Rosen wrote:
Is anything else required under the GPL or by the Busybox copyright 
owners? Specifically, is any of my client's proprietary software 
subject to disclosure? Must my client help anyone -- through product 
documentation or the disclosure of his proprietary code that he has 
purposely linked statically to Busybox -- to replace or upgrade 
Busybox itself in those millions of distributed proprietary wireless 
devices?


<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] combining GPL and proprietary software - was: CC withdrawl of CC0 from OSI process

[Bruce Perens]

On 03/02/2012 10:38 AM, Chad Perrin wrote:
On the other hand, "a fully-written pleading for a Rule 11 sanction" 
is beyond the means of someone who cannot afford a competent attorney.
Since Olson was a Free Software developer, EFF provided his attorney 
pro-bono.


Thanks

Bruce
<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

[License-discuss] due diligence - was: CC withdrawl of CC0 from OSI process

[Bruce Perens]

It is indeed the case that the failures I see are in companies rather 
than among charity developers. However, it's a stretch to state that 
they already pay for lawyers! I sometimes get paid to read their 
depositions and explain them to the judge. Invariably, the failure is by 
an engineer or manager who interprets a license without proper use of 
legal counsel.


Software engineers in companies have the daily task of combining 
copyrighted property of multiple parties. They still graduate college 
today without the capability of recognizing the issues or using counsel 
to resolve them appropriately.
<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Bruce Perens]

On 03/02/2012 09:45 AM, Chad Perrin wrote:
This could turn out to be a huge problem for any independent open 
source software developer who is not wealthy. The only really safe 
approach to open source software development, given the above, would 
be "Don't." 
If you're a non-profit, pro-bono (free, for the public's benefit) legal 
counsel is available to you. If you are a for-profit, use of appropriate 
counsel is part of your development investment.


<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Linking question

[Bruce Perens]

Larry,

I know of multiple parties who have settled by
Ceasing to manufacture the product
or
Releasing a new version of their binary software along with complete and 
corresponding source code.


Some of these cases involved replacing binaries that were static linked 
to LGPL software with binaries that were dynamic linked, to satisfy the 
requirement that the two pieces be seperable so that the LGPL piece 
could be modified by the end-user.


In all of the cases that I know of, the parties had available to them 
the strategy of asserting that their work was not derivative, and 
providing the GPL source only without reference to the proprietary 
components of their products. Surely, many of them have read your book. 
However, none of these parties chose to do so.


You may well be right. Nobody, however, has found it economical to 
invest the resources to prove that in court.


Thanks

Bruce

 On 03/02/2012 09:16 AM, Lawrence Rosen wrote:

NOBODY has ever settled such a case such that their code must be released.


<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

[License-discuss] combining GPL and proprietary software - was: CC withdrawl of CC0 from OSI process

[Bruce Perens]

On 03/01/2012 11:57 PM, Chris Travers wrote:
Ok, so part of avoiding lawsuits is to avoid areas where folks think 
they can sue about.
Not quite, because neophytes think they can sue about anything. 
Sometimes lawyers cooperate in this, because they think the victim will 
settle or otherwise change their behavior without ever getting near a 
court. So, it has to be an area where there is not such a bright line 
that litigation would immediately fail and that any competent attorney 
would know that.


As an example, the abortive attempt of Astrolabe to sue Olsen over the 
timezone database had the obvious flaw that it attempted to assert 
copyright law over facts like legislative changes to daylight savings 
time. When the defendant showed them a fully-written pleading for a Rule 
11 sanction, Astrolabe withdrew. No gray area there.



So the FSF's statements are important here
Only because they have good counsel and have successfully enforced the 
license many times.


In contrast, Linus Torvalds' various confusing and conflicting mailing 
list statements about what is OK and not OK under the GPL were not 
something you could rely on. I think he now knows not to make them.
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. 
The fact that there are courts is evidence that lawyers frequently 
disagree. However, you should resist the temptation to waste your time 
on the areas of contention. They are known and can be engineered around.
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.
We have cases about just this that you can read. They are Goloob v. 
Nintendo, and Micro Star v. Formgen. But you are really far now from 
combining GPL and proprietary software, which doesn't present the 
problems of transforming visual output which is itself a creative work.
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


Yes, but if Dieter wished to enforce his license in a way contrary to 
your sentiment, your statements would have little meaning because his 
contribution is independent of you and your policies and precedes your 
involvement. Even in the case of other developers who are concurrent 
with you, they are either independent copyright holders or share-holders 
in a collective work, and haven't ceded you the right to represent their 
legal interest. If they gave me, as an expert witness, the task of 
showing your statements to be naive and unreliable, it wouldn't be much 
of a problem.


Thanks

Bruce
<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Bruce Perens]

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.


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.


So, what do you do? You stay away from that issue and arrive at an 
engineering solution that avoids it.
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.
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.


Thanks

Bruce
<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Bruce Perens]

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.

Thanks

Bruce
<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Bruce Perens]

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.


<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Bruce Perens]

The fact that we have not resolved some questions doesn't mean that we 
don't have /any/ bright lines. I have previously published guidelines 
that would keep you far from any fuzzy issues, while allowing you to 
build whatever you wish.


On 03/01/2012 07:42 PM, John Cowan wrote:
Which is as much to say, the wise person will use proprietary software 
to the full extent he can afford it, because there is no issue of 
copyright licensure, there is indemnity de facto or ex contractu from 
patent lawsuits, etc. etc. This leads to a vast amount of 
wheel-reinvention, but overall that is cheaper than defending lawsuits. 


<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Bruce Perens]

On 02/27/2012 12:57 AM, David Woolley wrote:
The software analogy is flawed in that software has to be understood 
by a machine and is written in a language with very precisely defined 
semantics.  Legal documents are written to be interpreted by a human 
and, unfortunately, legal language is not a simple formal language
The structure of laws, courts, and contracts is indeed a machine that 
executes statements of rules. That it does so /fuzzily/ and through 
human rather than machine elements is not necessarily a /flaw /of the 
system, in that it is invariably asked to handle unforseen problems, and 
extends itself by doing so.


A machine-executed language for legal rule sets is a frequently 
expressed, unachieved dream. But any program in such a language would 
necessarily be closed in its capabilities, and would need to fall back 
on humans for those unforseen problems. So, you wouldn't lose the courts 
or the arguing over what something "really means".


Thanks

Bruce

<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Bruce Perens]

On 02/26/2012 09:00 PM, Chad Perrin wrote:
I suspect a better approach to understandable, legally well-formed 
license production might be to get someone who wants a very simple 
license to write it, and only *then* get the lawyers involved. While 
you're at it, be prepared to make the lawyers explain everything they 
want to change, and to tell them "no" a lot. 
The problem with your software, Chad, is that it's much too complicated 
for /no reason./ There's no reason for half of that "crapton" to be in 
there. We could cut it down to 10% of its present complexity if we had a 
/user /who wanted a really simple program write it first, and then we 
could have a programmer make it work correctly. While the programmer did 
that, we would make him explain /everything /that he was doing, and we 
would tell him "no" a lot to curb his natural tendency to add 
unnecessary complexity.


:-)

The pieces you don't like aren't there because anyone likes to put them 
there or because the people who wrote the license are idiots.


There have been a lot of court cases in history. From those cases, we 
know a number of things that go wrong in courts. We want you not to get 
trapped by the same stuff.


I had to help Bob Jacobsen, an Open Source developer who chose one of 
those over-simple licenses, the Artistic License 1.0, written by Larry 
Wall the Programmer. Bob had someone who both used his program in a 
product without even attributing it to him, and /also /asked Bob for 
lots of money for infringing his patent and tried to get Bob fired from 
his job by filing an FOIA with his employer. This was all over /model 
train software./


When Bob turned to Larry's Artistic License to help him get the guy off 
of his back, the Artistic License failed in court. We put a good team 
together and turned that around on appeal, but it was a close thing. By 
the time we were done, Bob had spent 5 years on the case, was out a good 
deal of money, and his relationship with his employer was damaged.


We might not be able to help the next Bob who comes along and uses one 
of those licenses written in crayon. You can protect your friends by not 
encouraging them to do that.


Thanks

Bruce

<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] What would be necessary to consider the unlicense?

[Bruce Perens]

On 02/26/2012 05:50 PM, Clark C. Evans wrote:
So, what makes unlicense and these public domain statements alluring 
is that they serve as vehicles for their authors make a statement 
about public policy.
Yes, but the sentiment is so poorly directed that it's the one from 
/Henry VI.


/For all of the talk, there is no credible political organization 
working against software patenting today. In the past I've tried to get 
support for one, to no avail.


Thanks

Bruce
<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] What would be necessary to consider the unlicense?

[Bruce Perens]

On 02/26/2012 04:05 PM, Clark C. Evans wrote:
If it is a broken license, perhaps those with legal expertise might 
provide suggestions to fix it?
I am having trouble finding a benefit that would come from fixing it, 
that we don't already have from short-and-sweet licenses like BSD.
What you would to be "as good as" BSD would be a public domain 
declaration coupled with a covenant not-to-sue that extends to the 
patent claims of the dedicator that are necessary to utilize the work as 
it was dedicated. And a warranty disclaimer to protect the donor.


It ends up not being shorter nor simpler.

Thanks

Bruce
<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Bruce Perens]

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.


Thanks

Bruce
<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Bruce Perens]

On 02/26/2012 02:03 PM, Chad Perrin wrote:
Explain to me how wanting to enforce a crapton of additional terms is 
"realism" instead of "a more-restrictive license".
When the terms are grants, or specifications of what must be granted in 
derivative works.


<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Bruce Perens]

Larry,

You might even be right, but at the moment there are many attorneys less 
sanguine than you on this issue, and /much/ less emotional.


The prudent consultant advises his customers on how to stay /far/ away 
from these issues, since there is no technical reason they can't do so. 
The prudent consultant's goal is not to cast "naah-naah's" at the GPL, 
nor to be an inch over the line on the right side of the law, but so 
clearly in compliance that the prospect of litigation over a GPL 
violation is remote. Again, no technical reason prevents this.


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

Re: [License-discuss] Reply to various recent postings on the crayon license issue

[Bruce Perens]

On 12/20/2011 11:41 AM, Richard Fontana wrote:



Can you tell me how many licenses are in Fedora? If it's 300, it's
something of a self-created problem, but then you'd be in lots of
company.
 

The numerosity itself is not a problem

This is how an attorney confirms an unpleasant truth. 300 licenses in there.

If you need to hear argument about the numerosity being a problem, I can 
refer you to a list of other attorneys and embedded system producers.

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

Re: [License-discuss] Reply to various recent postings on the crayon license issue

[Bruce Perens]

On 12/19/2011 09:54 AM, Tom Callaway wrote:
nor are we the author of any of the licenses we track(1)), so we're 
not the appropriate entity to submit what we find to the OSI for approval.
Can you tell me how many licenses are in Fedora? If it's 300, it's 
something of a self-created problem, but then you'd be in lots of company.


Robin Miller, whom I had no idea was still around our community, wrote:
> Do we really need that many open source licenses?

Of course not.

My customers are advised to choose three for their own use. These three 
would include a gift-style license (think BSD), a sharing-with-rules 
license (think GPL) and something in-between. All three must be 
compatible with each other so that the customer is not in the situation 
of producing code that is incompatible with other of their works for no 
good reason. There are legitimate business (or personal) purposes for 
each style of license. For example, if you are making a standard, BSD is 
great because everybody loves to get a gift and everyone will be happy 
to use your standard code and do things your way. If you don't want your 
competitor to run away with your project without returning value to you, 
GPL imposes rules that bring competitors together well enough to make 
good software. And if you want to enhance the world of Free Software 
without being UNICEF to the world's richest corporations, GPL's nice for 
that, too. Or maybe Affero GPL if you are particularly concerned about 
Google and its ilk.


But way back when this was a new endeavor, we were tickled pink to get a 
new license from Mozilla or IBM, it meant that they took the Open Soure 
movement seriously! :-)


The one thing I didn't plan for was an embarrassment of riches. I hope 
you are all at some time blessed with perfect foresight. I have never 
been so blessed and am happy to have done as well as I did when we had 
to make up what we were doing as we went along and had limited 
information about fields like intellectual property and no professional 
help.


OSI took a stab at license unification some years ago but,, as far as I 
can tell, didn't want to tip as many oxcarts as deprecating accepted 
licenses would do. And thus nothing was done. At least this is my 
surmise, I have been kept at a distance from OSI activities these last 
10 years.


Richard Fontana:
> While there is very little in life that is certain, we can be 
reasonably certain that Red Hat will never submit that particular 
[Freedom Font] license for OSI review.


Font licenses seem to be a cesspool for some reason. The SIL Open Font 
license remains my prototype for "crayon" licenses, there is one line 
that says the license "is null and void" in regard to an embedded 
version of the covered font, which either places that version of the 
font in the public domain or makes it all-rights-reserved, depending on 
your preferred interpretation. The license is expected to magically come 
back into force if you ever remove the font from its embedded context. 
The OSI of that time certified this work of crayon and we're stuck with it.


Jeremy Reed:

Some copyright owners are stubborn and may respond negatively even on a
polite request.


Would that it were so easy. A good many of them are dead people or 
bankrupt business entities, and their assigns know nothing of Open 
Source or even that they own the property. Some (like an early but still 
relevant SSL developer) are contractually bound to never touch that 
software again.


Rod Dixon:
> Wow! I must add that I do not think I would have seen a comment like 
this posted by Bruce Perens 10 years ago.


RMS is lucky to have had the help of Eben Moglen back then, but we had 
no help at all from legal professionals for a long time. Lawyers were 
not willing to be seen to be involved with us, it would have offended 
their normal intellectual property customers. Very much has changed, and 
it is hard for some folks to imagine the way things used to be.


Over the past 10 years I have spent a lot of time with lawyers and 
courts, indeed it is half my income of late. So, now I understand things 
that we had no clue about then.


Thanks

Bruce



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

Re: [License-discuss] a Free Island Public License?

[Bruce Perens]

Sorry, I missed that it wasn't intended for submission.

The author should back up and state a /list of goals, /rather than 
present the argument as pseudo-legal drafting.


Thanks

Bruce

On 12/16/2011 10:23 PM, Karl Fogel wrote:
> It was never submitted -- I don't think Clark intended to, in fact.

<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] a Free Island Public License?

[Bruce Perens]

OSI should deny certification of this license for the reasons already 
discussed, and because:


It is not the product of a legal professional.

I've been calling these "crayon licenses", taking a line from an old 
Monty Python sketch about a dog license with the word "dog" crossed out 
and "cat" written in, in crayon.


Crayon, in this case, is a metaphor for the poor legal qualification of 
the authors. Crayon licenses show a lack of understanding of copyright 
law, license structure, and most important: what would happen if the 
license were to be interpreted in court. We had an excuse for writing 
such things in the early days of Open Source when no lawyer would help 
us. /We no longer have that excuse./


Crayon licenses harm Open Source developers because they don't do what 
the developer expects. My most poignant experience with one was working 
on the appeal of /Jacobsen v. Katzer. /Bob Jacobsen, an innocent Open 
Source developer, essentially lost his case in the lower court due to 
the poor drafting of the Artistic License 1.0, one of the initial Open 
Source licenses, when the judge found it to be tantamount to the public 
domain. This loss would also have been very damaging to Open Source in 
general, had it been allowed to stand. Bob suffered /very/ significant 
damage from this case. We are very fortunate that he persevered, and 
that we were able to overturn the decision on appeal.


OSI should no longer approve crayon licenses, due to the potential they 
have to damage our own community.


Thanks

Bruce Perens
<>

smime.p7s
Description: S/MIME Cryptographic Signature
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: a proposed change to the OSD

[Bruce Perens]

From: Russell Nelson <[EMAIL PROTECTED]>
> No, it doesn't.  The GPL only has a few minor terms covering use.  The 
> GPL relies on the act of distribution for enforcing its conditions.

And those conditions mostly hinge on the right to create derived works
rather than the right to use.

Bruce

--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: a proposed change to the OSD

[Bruce Perens]

From: "Dr. David Alan Gilbert" <[EMAIL PROTECTED]>
> but also would need to give them rights to grant use licenses on the
> derivative?

You directly license all users of your portion of the derivative work.
The creator of the derivative work does the same. The alternative is to
propogate a right to sublicense, which is more complicated so it's
generally not handled that way.

Thanks

Bruce
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: a proposed change to the OSD

[Bruce Perens]

From: "Dr. David Alan Gilbert" <[EMAIL PROTECTED]>
> Can you explain to me (and the list) what the definition of a
> 'use restriction' is?

IANAL, of course.

For software, "use" is execution of the software.

Copyright law doesn't speak much of software at all, so we can't rely
on that for a definition and must look at court cases for precedents.

Creation of derived works is a separate right from use under
copyright law. It can be restricted separately from use, and vice
versa. The act of modifying software creates a derived work
that is partially your copyright, and partially that of the original
contributor.

Public performance is a separate right as well, but in the U.S. it is
defined to apply to plays and audiovisual media, and _not_ to software.

There is some contention regarding whether linking creates a derived
work, and exactly one court case on the topic that isn't definitive.
Dynamic linking, server-izing, and cross-process procedure call schemes
like CORBA make this more complicated. With CORBA, you can "use" a
library without ever linking to it, and it would be difficult to proves
in court that a derived work would be created. In many of these schemes,
the derived work, if one exists, is created on the user's system at
run-time and it's going to be difficult to prove in court that it's
_distributed_ as a derived work. All of this makes it questionable that
the GPL's linking provisions with regard to source-code disclosure would
be enforced in court.

In an effort to create a more clearly enforcible GPL-like license, Larry
has relied on _use_ restriction rather than restriction of the creation of
derived works in his new license.

Thanks

Bruce
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: a proposed change to the OSD

[Bruce Perens]

From: "Ralph Mellor" <[EMAIL PROTECTED]>
> Does OSI certify open documentation licenses?
> If so, I recall there being optional clauses that limit
> the number of printed copies, or something like that.

I don't think anyone is contending that licenses that impose such limits
are Open Source licenses.

Thanks

Bruce
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: a proposed change to the OSD

[Bruce Perens]

From: "Dr. David Alan Gilbert" <[EMAIL PROTECTED]>
> Well I was thinking about GPL on libraries since that restricts what you
> are allowed to link the library against; (No I'm not trying to get into
> an argument about the merits or not of this).

Copyright law spells out a number of rights, including use and creation
of derived works. GPL attempts to restrict the creation of derived works
and contends that linking creates a derived work. This position is not a
use restriction, but may not be enforcible in court - we need more cases
to know for sure. Other licenses, like Larry's latest effort, do this
with something that is more clearly enforcible but rely on a use
restriction.

Thanks

Bruce
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: a proposed change to the OSD

[Bruce Perens]

My only concern is how this would interact with Larry's new license.

Thanks

Bruce
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: Legal soundness comes to open source distribution

[Bruce Perens]

From: "Rod Dixon" <[EMAIL PROTECTED]>
> it makes sense to say that clickwrap should not be a mandatory
> requirement of the OSD, but could be approved as appropriate for an open
> source licensor.

I'd better clear this up. There was no proposal for click-wrap to be a
a mandiatory requirement of the _OSD_. The question was whether or not
the OSD should allow a license that requires click-wrap. I mantain that
it's not appropriate for the OSD to allow it.

Thanks

Bruce

--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: Legal soundness comes to open source distribution

[Bruce Perens]

Bruce Perens:
> 1. Is a simple warranty disclaimer that does not require agreement
>adequate?

From: "Rod Dixon" <[EMAIL PROTECTED]>
> I do think the correct answer to the first question is going to
> be yes. In response to question #1, I would ask another question:
> aside from ease on the license drafter, why would you want to impose
> terms (a disclaimer is still a license term, albiet a negation) under
> conditions that make it unclear to both parties whether the terms have
> been agreed to?

This is mostly an issue of practicality - and practicality is what
drives many OSD questions.

Debian, for example, has some 8000 packages, and a typical system
will have 1000 to 3000 of them, some people install the whole kitchen
sink which is probably around 6000 packages once package conflicts
are resolved.

The packages are produced by some 800 different package maintainers
who are not employees of Debian and are not under the orders of any
corporation. Of course there are many different owners for the software
that is packaged.  It's not clear that Debian is the warrantor, rather
than the package maintainers and the copyright holders. There are at
least 100 variations on the licenses, both different license versions and
different entities offering the same licenses. If even one one-hundredth
of the packages required click-wrap, it would not be practical to present
them all.

Imagine clicking through 30 licenses during an install. There would be no
reasonable expectation that the installer had actually read the text of all
of those licenses, which defeats the purpose of click-wrap. The same issue
comes up in other venues, such as download sites, and applies to all other
distributions, Red Hat, and so on, although most distributions are
smaller than Debian and may have employees doing the packaging.

The practical alternative is to present _once_ that there are licenses,
that they in general disclaim warranties and that thus you should have
no expectation of warranty, where you can find them, and the fact that
since you have source you can perform your own due diligence.

> This seems to run counter to the purpose of drafting terms.

Only if you are taking a vendor-centric view. Vendor-centric licenses
are drawn with maximum possible terms to protect the vendor. Open Source
licenses are drawn to protect the vendor as much as possible while still
being practical and fair to redistribute and deploy throughout a broad
community of users and derivative developers who are not motivated to
accept an odious license. That means that we deliberately make some things
easy - for example the act of copying and redistributing a software
distribution, and installing and using that distribution. We may reduce the
software producer's capability to defend themselves, by a reasonable amount,
in order to achieve those goals.

Thanks

Bruce
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: Legal soundness comes to open source distribution

['Bruce Perens']

On Sat, Aug 03, 2002 at 12:17:10PM -0700, Lawrence E. Rosen wrote:
> Bruce, are you going to respond to any of my other comments besides my
> expression of bafflement?

Sure, no problem.

> Or are you going to simply blame me for the confusion and lack of legal
> understanding on the part of *some* of the leaders of the open source
> community about whether licenses are contracts?

That is Brian Behlendorf of Collab.net you are talking about. His
company offers training on Open Source licensing. HP buys it. If
you are not getting through to Brian, backing up and starting again
would be advised, because you are surely losing the rest of the
audience.

> I invite you to address directly my argument that the MPL
> (and similar licenses) is clearly, obviously, without question or doubt,
> a contract and not merely a copyright license.  

Oh, I considered this so obvious that it wasn't necessary for me to
comment upon it, and certainly I would not have disputed it. But it is
peripheral to the issue of a warranty _disclaimer_, which like a copyright
permission, does _not_ necessarily have to be in the form of a contract.

> The decision addresses a preliminary matter, specifically whether a license
> that contains an arbitration clause can be enforced against licensees.

There are many license terms that I believe would require a contract.
_Indemnification_ is one that is germane to this argument. Choice of
venue and arbitration probably require a contract too. But I'm not
convinced that a simple disclaimer of warranty requires a contract.

> Many of my clients (licensors and licensees alike)
> demand an arbitration clause in their licenses for the simple reasons of
> cost avoidance and risk reduction.  

Were I writing a proprietary software license, I would certainly ask for
indemnification, choice of venue, an arbitration clause, and anything else
that would be likely to hurt the other guy, and I would ask for them to
be expressed in the most forceful possible way - I might even require
internet registration so that I had confirmation that the licensee had
agreed. After all, that sort of license is entirely one-sided - it's written
for the copyright holder and nobody else.

If I am able to express those terms at all when pursuing Open Source, I may
not be able to express them with the greatest possible force, because they
place an undue burden on the other participants, and are not likely to be
accepted. This is simply the difference between a vendor-customer relationship
and a partnership with a community.
 
Thanks

Bruce
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: Legal soundness comes to open source distribution

[Bruce Perens]

> Is there a reference of some sort for this?

It's the case at
http://www.nysd.uscourts.gov/courtweb/pdf/D02NYSC/01-07482.PDF .
IMO it's not all that germane to warranty disclaimer, and I'm not buying the
chain of extrapolation that leads from this case to the conclusion that
click-wrap might be necessary.

> It's about the only solid reason I see to need to go beyond copyright law.

It's not about copyright law at all. The warranty obligation does not follow
the copyright. It's about:

1. Is a simple warranty disclaimer that does not require agreement
   adequate? 

2. How do you need to present the warranty disclaimer?

3. Do you really need a contract that other parties actually agree to in
   some way, for example by clicking "yes"? It's reasonably clear that you
   need one if you want someone else to indemnify you. It's not nearly so
   clear that you need one if you simply want to disclaim warranties.

> Agreed.  That's why I think we need to amend the OSD so that it 
> clearly states that a license must not restrict use, 
> modification, or redistribution of the software.

I agree that there should be no restrictions on use, modification, or
distribution _other_than_those_ necessary to implement the goals of Open
Source, such as disclaiming the warranty, preserving the copyright
statement, mandating source distribution when the licensor chooses that
option, and mandating transmission of the license to all parties. A simple
"no restrictions" equates to public domain.

Larry Rosen:
> I am baffled by everyone's confusion and philosophical rantings.
 
That's distressing. This is your own community, or should be, since you
claim to represent them. If they are confused, shouldn't you blame your
presentation of the issue? If they are philosophical, and you didn't expect
that, could it be that you've lost touch with them?

So far, I see some significantly better alternatives than click-through.
The very first should be a set of guidelines for distributions and other
environments where free software is installed that would cause them to
inform the user that:

1) There are licenses.
2) They disclaim warranties.
3) This is how you view the licenses.
4) This is how you look at the source code to perform your own
   due diligence.

In the case of a distribution, most of them already do this at
distribution install time. Debian does display a click-through warranty
disclaimer when you install it. It also has a login message disclaiming
warranties, but only on the text login. Obviously, this needs to be
beefed up.

In the case of package installers on something other than a Linux
distribution, where we have less control of the enivronment, perhaps
click-through is appropriate, but I still would oppose allowing it to
be a license requirement. A license that requires it is going to cause
us no end of trouble with the environments where we can deal with the
problem more easily.

Thanks

Bruce
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Open Standards: Principles and Practice

[Bruce Perens]

Please see http://perens.com/OpenStandards/ for a proposed policy on
Open Standards. I will be submitting this to a number of Free Software
organizations once it's done.

The issue of patents in standards has come to a head, and I took some time
to get this started. I am still working on the OSD change that we've been
discussing, don't fear.

There are a lot of standards organizations, and every one of them
has a different definition of an Open Standard. Almost all standards
organizations allow the incorporation of software patents, discriminatory
licensing, or other features that seriously damage the "open-ness"
of the standard.

With the Debian Free Software Guidelines, later known as the Open Source
Definition, we were successful in defining the terms of discourse for
an entire industry. We're at that sort of cusp once more, but this time
concerning Open Standards rather than Open Source. Of late, we have
evidence of a number of companies attempting to use patents coupled with
standards to erect "toll booths on the Internet" in a way that would,
intentionally or coincidentally, exclude Free Software. As with the DFSG,
it's time to draw a line in the stand and defend it. Thus, I am presenting
to you the first draft of "Open Standards: Principles and Practice".

My intent is to refine this draft with community input, much as we refined
the DFSG as Debian policy in a month-long discussion on Debian's private
developer list. I made some mistakes with the DFSG text and the Open
Source organization that I don't want to repeat - I'll be watching out
for them, you do too.

Please go to http://perens.com/OpenStandards/ . There is a link for the
current draft, and a link for the disucssion list.

Thanks

Bruce Perens
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: OSD modification regarding what license can require of

[Bruce Perens]

Thanks, Joyce. What I have suggested to FSF is that the definition of
"deploy", for their use, must be tightened up to only apply to the
situations in which one would otherwise be pushing that "source code"
button, and only for derived works.

Thanks

Bruce

From: Joyce Chow <[EMAIL PROTECTED]>
> Sorry, I've only been following this thread for a bit and this is really not
> central to the discussion, but a clarification is needed:
> 
> APSL Section 2.2(d) applies to any deployment of "Covered Code" (not just
> Deployed Modifications).  The intent is that if you distribute APSL'ed code
> in only binary form, you need to tell the recipient that the corresponding
> source for it is available under the APSL and how to get it.  I believe it's
> a fairly common concept that a number of open source licenses have.  The
> actual language reads:
> 
> "(d) if You Deploy Covered Code in object code, executable form only,
> You must include a prominent notice, in the code itself as well as in
> related documentation, stating that Source Code of the Covered Code is
> available under the terms of this License with information on how and where
> to obtain such Source Code. "
> 
> - Joyce
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

"source code" button

[Bruce Perens]

Richard and Eben,

I feel that the draft GPL change for the ASP issue chooses the wrong
balance point between the right to privacy and the right to modify.

In my opinion, the correct solution would be to require publication
of derived works, with one-time notification to FSF of the publication
URL, when those works are deployed in the form of a service to others.
I think you can make the language about this limited enough that
there would be no more privacy issues than those that would be created
by the "source button".

I am the creator of a GPL-ed embedded system: Busybox. I would not be
able to use the "source button" on busybox because of the system size
constraints. Embedded systems are subject to the ASP problem - Busybox
is used for routers and appliance servers.

But I really wouldn't want to use the source button on any of my software,
because I feel it breaks the efficiency of the software to drag its source
code around with each and every runnable copy. It feels awkward and kludgy.
Source should live on a well-known internet server where it can be easily
retrieved and archived. It doesn't need to be a ball and chain.

I understand that you have criticized the APSL implementation of a
publication requirement upon "deployment". But your implementation
can restrict "deployment" to just those situations where a user might
push that button, and no others.

The source button also seems to be too interface-specific to me. I can
think of any number of services where there is not a direct user-interface
in the form of an HTML form, etc., but just a set of RPC calls. It
might be difficult to find a "source button" in that setting, even if
one exists.

I've gotten both HP and Prentice Hall to use your licenses, and I'm sure
I've influenced many others to do so. My preference for GPL-like licensing
is well-known. If _I_ don't want to use this license, I don't think you'd
be very successful in finding other takers. Please go back to drafting.

Thanks

Bruce Perens
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: OSD modification regarding what license can require of

[Bruce Perens]

From: David Johnson <[EMAIL PROTECTED]>
> You don't have the APSL quite right. Clause 2.2d only applies to "Your 
> Deployed Modifications."
> 
> Clause 2.2d merely requires a prominent notice of the license for binary only 
> deployments. It can only be triggered by the creation of a derivative work, 
> since compilation is considered derivation.

I prefer this to the proposed GPL change. A whole lot. Is there anything
I should know before I write Eben and Richard to tell them that?

Thanks

Bruce
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: OSD modification regarding what license can require of user

[Bruce Perens]

Mitchell,

A possibly naive question: The text you submitted is a _broad_ definition
that is in common use. Is there a similar _narrow_ definition as well?

I don't see that this text would be the right way for a quid-pro-quo
license to define the legal entity in which distribution doesn't happen,
because that entity would include beta-testers under contract, would it
not? Maybe even _users_ under contract or NDA?

On the other hand, there are applications in a quid-pro-quo license
_would_ use this definition, "Your Licensed Patents" comes to mind.

Thanks

Bruce

--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: OSD modification regarding what license can require of

[Bruce Perens]

On Thu, Mar 14, 2002 at 02:21:52AM -0500, Forrest J. Cavalier III wrote:
>   "The rights to use the program must not be conditional,
>except for conditions on uses performed in service
>to any non-licensed party."

Are you sure that this language works in context of OSD #7?

Also, you should probably state it as a series of permissions followed by
a negation of anything not explicitly permitted. A mistake of the
OSD is that it says what you can't do rather than what you can. This
allows for too many loopholes.

Thanks

Bruce
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: OSD modification regarding what license can require of

[Bruce Perens]

On Thu, Mar 14, 2002 at 01:40:08AM -0500, Forrest J. Cavalier III wrote:
> The OSI approved the APSL, with clauses 2.2c-d, which require
> publication of sources upon "deployment."
 
Great. I'd like to hear comments upon the probability that this can be
enforced, and the way the license must be presented to the user.

> So Bruce, (correct me if I am wrong), your goal is OSD changes
> which better ensure user freedom, but still allow approval
> of the APSL (and as-yet-unwritten licenses with clauses like
> you mentioned.)  

Yes about maximizing user freedom, and I can state the other half
of that in a more positive manner:

The quid-pro-quo between the original contributor and subsequent
creators of derived works, as exemplified in the GPL but not limited
to the GPL, is a critical component of Open Source. Open Source might
well fail if it ever becomes impossible to enforce such a quid-pro-quo.
It should _not_ be mandiatory that _every_ OSI-approved license stipulate
a quid-pro-quo, only that it be possible to implement one within an
OSI-approved license.

Thanks

Bruce
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: OSD modification regarding what license can require of user

[Bruce Perens]

Bruce wrote (in part)
> So, what if it turns out that the present GPL doens't hold up with regard
> to dynamic linking? Some future version of the GPL might have to place a
> constraint on the user regarding combination of works on the user's system
> that would, if it were distributed in that form, be considered a derived work.
> I think that should be allowed by the OSD.

On Thu, Mar 14, 2002 at 01:05:34AM -0500, Forrest J. Cavalier III wrote:
> Did you somehow mean "constraint on the publisher regarding 
> combination of works on the user's system"?

If we really _can_ implement this as a constraint on the distributor,
rather than the user, that would leave us in _much_ better shape.
Would you like to float some sample legal language to implement that?
I have access to a legal staff to review it. If we can assure ourselves
that it's possible, that leaves indemnification and the ASP problem.
Indemnification is a must, IMO. The ASP problem, in contrast, is a
wish-list item we could lose.

> "freedom" and "requirement" are direct opposites.

Of course. I hope you accept that we _don't_ live in the libertarian
utopia. Thus, some turning of the dominant legal structure upon its
head is necessary. Our only avenue for doing that is the creative
use of legal restriction.

Thanks

Bruce
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: OSD modification regarding what license can require of

[Bruce Perens]

Bruce wrote (in part)
> Is this fair to them? I contend that this sort of activity should
> be placed outside of the covenant represented by the GPL. Richard and
> Eben don't necessarily agree with me - yet.

On Thu, Mar 14, 2002 at 12:37:06AM -0500, Forrest J. Cavalier III wrote:
> Is the goal here guaranteeing freedom of use, or is it trying
> to increase the amount of source which must be published?

I'm not sure the FSF folks would make a distinction between the two.

My concern here is that, as a result of those court tests of the
GPL that have not yet happened, we may run up against a situation in
which _copyright_law_is_inadequate_ to implement the GPL's agenda. And
they may have to fall back upon contract law, including some form of
tear-open license, and even one which applies to the user. Some say that
they already have a tear-open license, due to the presence of the words
"you agree" in the GPL.

FSF would not make such a change lightly, and not soon. Richard is the
most self-consistent person I know, and it would offend him to do this.
But if it becomes necessary for them to go down that path, and the result
ends up being non-OSD-compliant, this becomes another wedge between FSF
and OSI. I've created enough schism around here, I don't want to make
more. And I don't feel I can bet on OSI being agile enough to accomodate
FSF when the need for change happens, so I want to leave the room now. At
the same time, I don't want there to be a possibility of it being abused.

But you could drop the entire GPL argument, and just consider
indemnification of the developer and distributor by the user. No way are
any of us going to accept liability for free software, we can't afford
to do so. Yet there are various laws existing or in process that threaten
us with just that. If it takes a tear-open license to protect ourselves from
liability, I don't want to be left in the position of being constrained from
using one.

> Bruce, I know you are at the "collecting ideas" stage,
> and discussing details and mechanisms under development
> may just be inflammatory at this point. But can you
> share some more of your thoughts?  
 
There isn't much more than what I have posted. If any of you would be
more comfortable discussing this on the phone, you are welcome to call
the number on my web site during 10 AM to 7 PM US-Pacific time.

> Going in the other direction (to allow OSI approval of licenses
> which are binding only under contract law, and not copyright law)
> is going to require sacrificing OSD #1, right?

No, I don't yet see that. I think that most of the rights that you are
concerned about are explicit in the OSD anyway, and in the licenses
approved under the OSD, and don't really depend on whether or not the
user owns their copy.

> It was my understanding that it can be hard to convince a court
> that a gratis download binds the recipient to a contract/license.
> (Because there is no consideration.)  
 
We're in good shape as far as liability is concerned if that works both
ways.

> If these changes are made, the OSD will have to be expanded in
> order to explicitly require each license include the fair use
> and other permissions already in 17 USC, as well as explicitly
> prohibit other usage restrictions.

Well, I am a little concerned that 17 USC is part of the _US_ code.
In Europe they have this "moral right of authorship" which is not
parallel to the way we do things here. Thus, I think we need some
explicit language regarding the use permission in the license, for
no other reason that it should apply across national boundaries.

> Is that kind of complex rewrite what you are considering?

No, I want this to fit in one paragraph. This is something more than
"The license must not place any restrictions on use", but not much
more. Something in the form of "The only permissible use restrictions
are X, Y, and Z. Goals that I can't fit in such a simple form will
probably not be achieved.

Thanks

Bruce
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: OSD modification regarding what license can require of user

[Bruce Perens]

From: Brian Behlendorf <[EMAIL PROTECTED]>
> Yep, like making it available through VNC, for example.  A very clear
> violation of the spirit of the GPL;

I'm glad you agree.

> but the grey area between this and the examples in the earlier messages
> seems very hard to divide between clear and non.

It seems that the role of the user is key. Is the user running the
program?

Thanks

Bruce
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: OSD modification regarding what license can require of user

[Bruce Perens]

From: John Cowan <[EMAIL PROTECTED]>
> To be concrete, suppose I provide a "fast grepping" service.

Grep is an over-simple case, which might lead you to trivialize the problem.

Consider Evolution, OpenOffice, or GNU Emacs. Postulate that someone makes
a way for somebody to use one of those programs as if it were running
natively on their computer, without ever activating the "distribution"
terms of the GPL. And that same someone makes significant enhancements
which he does not disclose in either source or binary form.

Consider this from the perspective of the creator of Evolution,
OpenOffice, or GNU Emacs. This person has put an immense amount of work
out in the public with the expectation that improvements that are widely
used would be distributed, and thus would be returned to them. And they
aren't. Is this fair to them? I contend that this sort of activity should
be placed outside of the covenant represented by the GPL. Richard and
Eben don't necessarily agree with me - yet.

One thing that we learned in deploying the OSD is that the world would
surprise us, and that the language would end up being more important than
we thought. I don't want to be surprised as much the next time around.

Thanks

Bruce
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

CORRECTION: Re: OSD modification regarding what license can require of user

[Bruce Perens]

Darn. I garbled. Delete the "don't". The terms of the GPL require you to give
source code to the person to whom you distribute the binary. And nobody
else. The copyright holder can sue for infringement but can't compel the
infringer to give the copyright holder a copy of the source code. He can
compel the infringer to give the source code to the person to whom he
gave the binary.

Hopefully this parses better.

Thanks

Bruce
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: OSD modification regarding what license can require of user

[Bruce Perens]

On Wed, Mar 13, 2002 at 10:24:02PM +, Thorsten Glaser wrote:
> Or A, to look from a different side on this?

No.

The terms of the GPL don't require you to give source code to the
person to whom you distribute the binary. If you fail to do so, the
copyright holder can sue you for infringement, but unless you manage to
give the copyright holder a binary, they can't compel you to give the
source code to them.

Bruce
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: OSD modification regarding what license can require of user

[Bruce Perens]

From: John Cowan <[EMAIL PROTECTED]>
> I don't see how that could happen, unless bandwidth (including the last
> mile) becomes "too cheap to meter".

Think about think clients and "internet appliances". If a lot of people go
to thin clients because they want to oursource their system administration,
then the paradigm changes.

> It's not at all clear to me that when I send you bits, you massage them
> on your own computer, and you send me different bits back, that this
> constitutes a public performance of anything.

You would not doubt that it was a public performance if those bits were
a television broadcast.

> Suppose A publishes a GPLed book describing some arcane subject, and B
> obtains a copy of it. C now mails questions to B along with payment, and
> B answers the questions out of the book and mails back the replies. In
> principle, C could read the book himself, but may not have the time or
> desire.)  Surely A's rights are not impinged on here?

If B cut and pasted the answers _directly_ from the book, and did so to
an extent greater than the simple occassional quoting within a larger
work allowed as fair use, B would indeed be conveying a copyrighted work
to C, and the license would apply. If B, on the other hand, conveyed the
_knowledge_ rather than its representation as created by A, there would not
be any conveyance of A's copyrighted work.

But that's not really what we're talking about here. B is not answering
C based on mere knowledge of the output of A's program. B is providing C
with a means of accessing A's program as if C was the party to whom the
work had been licensed. Although C can't see the source or binary code of
the copyrighted work, it is executed upon his behalf, at his command, and
he gains the benefit of its execution.

> Are things different if B adds his own marginal notes to the book?

There is a boundary to fair use, I don't think marginalia would fit one
within it.

> Is B really required by (the spirit of) the GPL to make those notes
> available to C?

I submit that this is the case. But the implementation of copyright law and
the current text of the GPL both leave a lot to be desired when this sort of
question comes up.

Thanks

Bruce
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: OSD modification regarding what license can require of user

[Bruce Perens]

John Cowan: 
> I don't understand how this breaches the spirit of the GPL any more than
> providing ASP-style access to the unmodified work does (i.e. not at all).
> If you are free to make private mods to GPLed programs for your own
> use, why not for others' use?  This is just timesharing under a new name.

Well, I could answer that in two, conflicting ways. If distribution becomes
irrelevant, the spirit of the GPL in that respect is obsolete, isn't it?

On the other hand, Richard treats this as a privacy issue. I contend that a
publicly performed GPL work with a private implementation does indeed contradict
the spirit of the GPL.

Then, you get into the question of "what is the entity in which privacy applies?"
In the GPL, it is the entity within which there is no need to distribute.
This has always been sort of vague to me, because it's not clear if a corporation
and all of its employees are a single entity, or if distribution takes place
between employees, or between employees and the corporation. Then, bring in
complications like consultants and companies working under contract but not part
of the same legal entity as the corporation.

Bruce


--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: Discuss: BSD Protection License

[Bruce Perens]

> To save time, can we just agree that I have absolutely
> horrible motives, that I'm a Microsoft plant, and that I'm
> reporting to the Illuminati, and get back to discussing the
> license?

Well, if you had submitted the license without the manifesto attached,
people would have considered the license rather than the manifesto. It
seems to be your own fault.

It looks to me as if 4(c) of the license fails OSD #7 because an
open-to-closed transition is _required_ by the license, rather than
by the license of the derivative work. If such a transition were
to be optional, it might pass, depending on the language you use, but
you would be effectively back to the BSD license.

Thanks

Bruce




--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

OSD modification regarding what license can require of user

[Bruce Perens]

trained from
distributing software under OSD-compliant licenses. Thus, I'm interested in
defenses against software patents, even if the only workable ones turn out to
be "poison the well" defenses.

Thus, there seem to be a few sorts of requirement on the user that I think
_should_ be permitted by the OSD. All of them are intended to further the
goals of Open Source or Free Software.

Can you think of more that should be added to this list?

    Thanks

Bruce

On Sun, Feb 10, 2002 at 11:35:15PM -0500, Russell Nelson wrote:
> Steve Mallett writes:
>  > On February 9, 2002 04:50 pm, Bruce Perens wrote:
>  > > I'd be happy to write the first draft and coordinate comments and changes
>  > > to it. Of course it would be a group project as I'd need to consult lots of
>  > > people - attorneys, community leaders, a discussion list, etc.
> 
> Cool.
> 
>  > > I suspect that some of the things I am worried about fail the current OSD
>  > > under "use" restrictions, but not as explicitly as I'd like.
> 
> There is much in the OSD which is insufficiently explicit.  For
> example, we have maintained that there are no possible restrictions
> a license could put on users, because there is no possible mechanism
> one could use to constraint them, because no approved license can
> require that the user execute a license (OSD#7).
> 
>  > It frightens me that no one has (on the list) bothered to ask what the 
>  > additions might address.  Bruce?
> 
> Bruce isn't an idiot.  He wouldn't propose additions we wouldn't be
> likely to accept.
> 
> -- 
> -russ nelson  http://russnelson.com | Crypto without a threat
> Crynwr sells support for free software  | PGPok | model is like cookies
> 521 Pleasant Valley Rd. | +1 315 268 1925 voice | without milk.
> Potsdam, NY 13676-3213  | +1 315 268 9201 FAX   | 
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: Advertising Clauses in Licenses

[Bruce Perens]

> Unfortunately, the OSD is not very well written. 

Of course we had no idea, at the time, that the scope of application of this
portion of the Debian Social Contract would grow so large.

I think that we'd better fix this particular problem regarding use before we
get to the more pervasive issues of the OSD. I am willing to attack those, and
can get some money and attorney resources to do so, but it would be a longer
haul.
Thanks

Bruce
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: Advertising Clauses in Licenses

[Bruce Perens]

From: Steve Mallett <[EMAIL PROTECTED]>
On February 9, 2002 04:50 pm, Bruce Perens wrote:
> It frightens me that no one has (on the list) bothered to ask what the 
> additions might address.  Bruce?

Badgeware, snoopware, etc., where the requirement is attached to _use_.
IMO these already fail the OSD, but not explicitly enough.

Thanks

Bruce
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: Advertising Clauses in Licenses

[Bruce Perens]

Someone please tell Russ his qmail is rejecting me.

Bruce
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: Advertising Clauses in Licenses

[Bruce Perens]

From: Russell Nelson <[EMAIL PROTECTED]>
Bruce Perens writes:
 > I think there needs to be language added to the OSD, protecting
 > the user and developer from odd burdens that the licensor wishes to impose
 > upon them.

Russ Nelson:
> Are you volunteering to write this language yourself, or volunteering
> someone else?

I'd be happy to write the first draft and coordinate comments and changes
to it. Of course it would be a group project as I'd need to consult lots of
people - attorneys, community leaders, a discussion list, etc.

I suspect that some of the things I am worried about fail the current OSD 
under "use" restrictions, but not as explicitly as I'd like.

Thanks

Bruce
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: Advertising Clauses in Licenses

[Bruce Perens]

Are you assuming that they will not admit new ones?

After my conversation with Larry today, and getting a better idea of the
way he wants the license approval process to work, I'm going to change my
stance. I think there needs to be language added to the OSD, protecting
the user and developer from odd burdens that the licensor wishes to impose
upon them. These burdens are mostly not directly connected with software
development. For example: usage-reporting, or taking attribution to a
greater level than simply putting developer's names with the software
license on a disk where the end-user or creator of a derived work can
read them. Such language needs to be general enough to admit whatever new
burdens people decide to invent. You should not be asked to bind the
developer's name as a sign on thy hand and as frontlets between thy eyes.

Thanks

Bruce

On Mon, Jan 21, 2002 at 10:39:42PM -0700, Richard Stallman wrote:
>   So where
> in the OSD, or in the GPL, do we make it clear that potentially
> burdensome license requirements (however those are defined) are not
> allowed?
> 
> I recommend you allow them but deprecate them.  That is what we do.
> We always did recognize the old BSD license as a free software
> license, but we said people should avoid it because of its annoying
> practical consequences.
> 
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: Advertising Clauses in Licenses

[Bruce Perens]

On Mon, Jan 21, 2002 at 09:34:10AM -0800, Lawrence E. Rosen wrote:
> But I still have a concern.  I have always argued that we should review
> and approve licenses according to a published standard.  This prevents
> us from being (or appearing to be) arbitrary and capricious.  So where
> in the OSD, or in the GPL, do we make it clear that potentially
> burdensome license requirements (however those are defined) are not
> allowed?

Larry,

I'm not sure we can create a definition of "burdensome", even in statutory
language, that would be sufficient for inclusion in the OSD. However, you can
make it part of the published role of the OSI board to review proposed
licenses for undue burden on the developer and user, and you can give some
examples - the combinatorial problem, user burdens such as badgeware,
etc. This is an activity that the OSI has previously carried out
well, and I most strongly urge that they should continue to do so. To
fail to do that will inevitably lead to all sorts of perversions of Open
Source as people figure out creative loopholes.

I do not believe, and never have, that any version of the OSD should be
applied as an automated process. Do courts never consider the spirit of the
law? I think you are coming at this from an urge to eliminate any
possible litigation situations in which an OSI decision is challenged.
There has to be some risk, but you can still make this a fruitless game
for the challenger without decerebrating the license approval process.

Thanks

Bruce
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: Advertising Clauses in Licenses

[Bruce Perens]

On Sun, Jan 20, 2002 at 12:07:53PM -0800, Lawrence E. Rosen wrote:
> I am unmoved by this perceived threat to free or open source software.

Perhaps you've never had to put together a Linux distribution, or an embedded
Linux product. Consider the overhead this places on Debian, which has
up to 5000 packages in a distribution. Some volunteer has to go through
and check each of those 5000 packages for an acknowledgement requirement
with every release, and make sure that the end-user documentation stays
in sync, which is one less person making free software for a pretty long
time.

> The individuals and communities who create free and open source software
> deserve to receive credit for their contributions.  Is it asking too
> much to require the authors of derivative works to acknowledge the
> contributions through simple notices?

Every package generally gets to publish its credits in the place in the
user software, where the online copyright statement is kept. This can be
managed automaticaly, so it's not a hassle. But to put it in the user manuals
and advertising can become quite a burden.

One of the goals of the OSD was to have software that the user could run
without having to read the license or take any special action. Note that
this is the user, not the creator of a derived work. But if the software
licenses ask the user to put badges on their home page, that really
blows the premise that the user can run it without having to investigate
anything.

> Suppose the list of contributions grows long.  Is it expecting too much
> for the authors of derivative works to include a text file listing those
> contributions along with the software?
 
No, not as long as it can be handled automaticaly, as with the files in
(on Debian) /usr/share/doc/ .

Thanks

Bruce
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: NCSA Open Source License

['Bruce Perens']

On Thu, Jan 17, 2002 at 02:38:20PM -0800, Lawrence E. Rosen wrote:
> Bruce, the so-called "advertising" clause in the Apache license is
> extremely important.  As I stated in one of my columns in Linux Journal,
> trademark protection is, in some respects, even more important to open
> source companies than copyright protection.

Hi Larry,

You saw "advertising", and read "trademark". But these are separable
issues.

I agree with you regarding the importance of trademark protection.
That's why I wrote the "integrity" provision in the OSD. The "obnoxious"
advertising clauses concern me, such as the _original_ BSD/Apache
advertising clause, which really is deprecated by both U.C. Berkeley and
the Apache project. Badgeware is even worse, because of its potential
combinatorial effect - 1000 badges on my homepage. OSI has (wisely)
resisted badgeware so far.

In accepting trademark-protecting licenses, the names of protected
trademarks should be in template form. Otherwise, you could easily
have to review and accept 500 versions of the Vovida license, with
only names varying between each version.

Thanks

Bruce
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: NCSA Open Source License

[Bruce Perens]

From: Russell Nelson <[EMAIL PROTECTED]>
> Approve it.  We judge licenses by one set of criteria: the OSD.  We
> do, it is admitted, sometimes attempt to convince people to use an
> existing license.  Feel free to try this with NCSA.

Yes, I'm trying. I will probably bring you folks in to help at some point.

Thanks

Bruce
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: NCSA Open Source License

[Bruce Perens]

Yes, I saw the present advertising clause. It's close to being a no-op, but
if you want it there, I guess I can't make much headway in this. Well, what
do you folks plan to do when faced with yet another BSD/MIT license?

Thanks

Bruce
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: NCSA Open Source License

[Bruce Perens]

> That would be three licenses, I think.

OK - one might consider that it's one license _text_ rather than 4, but yes
it's three licenses. Is it possible to sucessfully lobby Apache to get rid of
the advertising clause? They probably have enough experience now to see it's
had no positive effect. Then we are down to two, with the sole optional portion
being choice-of-venue. Venue is problematical - OSI has accepted a license
specifying California. If an applier of the X.com license changes that to their
own home state other than Calfifornia, it's no longer an OSI-accepted license.
But I don't think OSI really has preferences for one state over another.
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3