[Squeak-fr] Fwd: Debian rejects APSL?

[stéphane ducasse]

lisez a la fin


Begin forwarded message:

> From: Jim Gettys <Jim.Gettys at hp.com>
> Date: 13 juin 2005 16:46:09 GMT+02:00
> To: The general-purpose Squeak developers list <squeak- 
> dev at lists.squeakfoundation.org>
> Subject: Re: Debian rejects APSL?
> Reply-To: The general-purpose Squeak developers list <squeak- 
> dev at lists.squeakfoundation.org>
>
>
> On Sun, 2005-06-12 at 15:47 -0400, Lex Spoon wrote:
>
>> Jim Gettys <Jim.Gettys at hp.com> wrote:
>>
>>> Lex wrotes:
>>> Thus, I'm much more interested nowadays in what
>>>
>>>> the likes of Lawrence Lessig have to say than in what Debian,
>>>> OSI, or FSF have to say.  If these latter organizations want to  
>>>> stay
>>>> relevant in the area of open-source ideas, then they need to  
>>>> adjust to
>>>> the changing times.  Like it or not, real law hacking requires  
>>>> real law
>>>> hackers, not computer scientists who have taken a class or two  
>>>> on law.
>>>>
>>>
>>> Hmmm...  I will note that Lawrence Lessig is on the board of  
>>> directors
>>> of the FSF.  There is some serious legal talent on board.
>>>
>>
>> Glad to hear, and I hope this goes somewhere.  RMS is great at  
>> advocacy,
>> but Lessig knows law and has a great reputation in intellectual  
>> circles.
>>  It could be a great team if they find a way to work together.
>>
>> debian-legal is an entirely different story.  The "consensus"  
>> agreements
>> it comes up with are driven by amateurs.
>>
>>
>>> And at least in the case of the GFDL, I think Debian has made the  
>>> right
>>> call (I'm not very familiar with the other cases).  The  
>>> interaction of
>>> trademark law with the "invariant sections" part of the GFDL can  
>>> cause a
>>> document to become unusable in other contexts, presenting a raft of
>>> problems, either for reuse of code, or when forking a project, which
>>> sometimes becomes necessary.
>>>
>>
>> I agree on a strictly theoretical level, but these differences don't
>> have enough practical impact that Debian should toss all of that  
>> stuff
>> into its non-free section.   Most people just aren't going to load up
>> their documents with invariant sections, so Debian's policy means  
>> that a
>> great deal of free documentation is getting tossed into "non-free".
>> Similarly, while I agree that all the GNU licenses cause problems  
>> with
>> intermixing, that was an intentional feature that RMS added.
>>
>>
>>> From a wider perspective, notice that there is a vast difference  
>>> between
>>>
>> Microsoft-L and any vaguely free license you can name.  Despite this
>> vast difference, however, groups like FSF, Debian, and OSI are  
>> spending
>> tremendous efforts quibbling about border cases among different
>> open-source licenses.
>>
>>
>>
>>> One of the biggest issues right now is the fact that there are  
>>> too many
>>> licenses, many/most of which are not well thought through.  The
>>> combinatorial explosion when mixing code is becoming intractable,  
>>> and
>>> many people are working to reduce the number of open source  
>>> licenses in
>>> use.
>>>
>>
>>
>> This is truly  a problem.  On the other hand, it is not the end of  
>> the
>> world even in the extreme case that code from different projects  
>> cannot
>> be intermixed at all.  The individual projects can always continue to
>> move forward.  And usually, it is allowed for components to speak  
>> over
>> socket connections no matter what kind of licenses they have.  While
>> this is not a nice solution, it means that incompatible licenses  
>> are not
>> usually a complete show stopper.
>>
>
> It causes major waste of effort, and the license complexity actively
> inhibits progress in many circumstances.
>
>
>>
>> Thus, I would say a bigger problem is that the *legal systems* aren't
>> set up to handle open source software.  There is such a thing as  
>> public
>> domain in copyright law, but nothing AFAIK corresponding to open  
>> source,
>> where you have zillions of authors and the goods are given away for
>> free.  If I want to public-domain something, I can just say it;  
>> even if
>> I say it incorrectly, the courts can figure out what I meant, and  
>> I have
>> a good chance of causing the legal effect I was going for.  For  
>> the long
>> term, we ideally need the same thing for open-source software.
>>
>
> No one will touch code without a copyright declaration.  If you  
> want to
> give software away, choose the MIT license as the shortest and  
> sweetest
> declaration of that sentiment (the BSD license is a bit more verbose,
> and the old versions of the license have the infamous advertising
> clause, so I recommend the MIT license).  That's what we drafted it  
> for
> (I was somewhat involved in its drafting).
>
>
>
>>
>> So I think more open-source activists should be working on things  
>> like:
>> publicizing the issues to wide audiences, showing why the general  
>> public
>> should care, and ultimately getting legislators to look at it and  
>> move
>> towards a new international copyright treaty.  Digital copyright is a
>> hot topic right now around the world, so now is a good time to  
>> strike.
>>
>
> We are, every change we get.
>
>
>>
>> In the short term, I have started public-domaining my code and
>> documentation.   It makes no difference for me in practice to using a
>> specialized open-source license, and I avoid a lot of headaches and
>> possible future problems.  Even though open-source licenses have some
>> nice strings included that I might like to enforce, they make no
>> practical difference because:
>>
>>     1. There are loopholes, and I don't know where they are until  
>> these
>> licenses get vetted in court -- which isn't going to happen in the  
>> near
>> future.  Witness the ICS chess software, many branches of which are
>> closed source despite descending directly from GPL code.
>>
>>     2. It's all a bluff anyway, because I will never bother to sue.
>> Witness Interval's hacking of Squeak without releasing source
>> code--blatantly illegal (so I'm told) but no one cares enough to sue.
>>
>
> Yes, if there is no interested party, you have no one with standing to
> sue.
>
> In fact, in the GPL case, there have been many enforcement actions  by
> the FSF and others.  As the MIT/BSD license permits any additions you
> like, it doesn't end up in court; about the only thing that might come
> up is violation of people's use of their names and/or organization's
> name without permission.
>
> Only a few violations required going to court to get resolved.   
> Most are
> resolved amicably behind the scenes with no publicity.
>
> So far, the GPL/LGPL has stood up cleanly enough there has not been  
> any
> serious litigation; the licenses are in fact holding up much better  
> than
> many people expected.
>
> Personally, independent of license, I think a situation where there  
> are
> more than one copyright holder in a larger set of code is more  
> likely to
> end up with enforcement (since there are more people with standing to
> sue).
>
>
>>
>>
>> So, I think that hackers may as well avoid open-source licenses all
>> together for now, and that activists should spend a larger portion of
>> their time trying to adjust copyright law itself.  Obsessing about  
>> our
>> differences is causing more harm than good at this time.
>>
>>
>
> No, here I *strongly* disagree. Code without copyright no one will
> *touch*.
>
> Remember, copyright law is at the basis and serves as the  
> protection of
> open source and free software.
>
> Many people are actively trying to reform copyright law.  So far,
> Hollywood and the RIAA are winning (at least in lengthening copyright
> terms toward infinity).  The big issue is around orphan works: works
> that are not being marketed, and for which it can be impossible to  
> even
> identify the owner any more.  In most ways, copyright law is much less
> broken than patent law.
>
> As the consequences of interactions between licenses are *not* well
> understood particularly by most programmers, I do strongly urge anyone
> (depending on circumstance and inclinations), to choose one of the  
> big 3
> licenses: MIT or BSD rev 2, LGPL, GPL.  Note I leave the GFDL off that
> list.
>
> These licenses are well known, and interoperable. Some other open  
> source
> licenses have real problems.  The OSI is working on both reducing the
> number of recommended licenses, and resolving problems between  
> them, as
> best they can (sometimes licenses have terms that will prevent  
> mixing of
> code in various ways).
>
>
>                 Regards,
>                     - Jim Gettys
>
>
>
>
>