All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ira McDonald <blueroofmusic@gmail.com>
To: Daniel Dressler <danieru.dressler@gmail.com>,
	Ira McDonald <blueroofmusic@gmail.com>
Cc: "printing-architecture@lists.linux-foundation.org"
	<printing-architecture@lists.linux-foundation.org>,
	Till Kamppeter <till.kamppeter@gmail.com>
Subject: Re: [Printing-architecture] ippusbd license
Date: Wed, 25 Jun 2014 16:51:21 -0400	[thread overview]
Message-ID: <CAN40gSuxUUg1xaf=M3achUk+B7kUwxkM1_71ZHVswBKEHzEP8w@mail.gmail.com> (raw)
In-Reply-To: <CAGC3nLB4HvB7Xnxm5_LiOrvjtFAcPYr+6TTUrGV+XnPgiYF_UA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 9538 bytes --]

Hi Daniel,

ALL of the work (design and code) of the Open Printing Job Ticket API
team used BSD/MIT (for reasons Mike Sweet has cited) - based on
actual legal opinions from a number of printer vendors.

Being "up-to-date" with GPL3 simply guarantees that no printer vendor
will ever allow their engineers to use (even in a test lab) "ippusbxd".

I'm very strongly opposed to licensing this work under any form of GPL3.

There are several other major OS vendors who have an absolute rule
that no GLP3 code is used in any product *or* product design (no I'm not
going to name them).

If your work on "ippusbxd" has a GPL3 poison pill included, then I also
can't encourage it's use in the IEEE-ISTO Printer Working Group, which
would be sad.

ALL - amateur discussion of license and patent terms is DANGEROUS.
Please use caution in your email assertions.

Cheers,
- Ira



Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434



On Wed, Jun 25, 2014 at 1:36 PM, Daniel Dressler <danieru.dressler@gmail.com
> wrote:

> Michael
>
> You're right that I do not intend to file any patents, and you're also
> right that I do not plan to hide ippusbxd from users with DRM. Granted
> if I did wanted to do those things I still could, since I own the
> copyright. The GPLv3 only applies downstream, where one needs a
> license to avoid copyright infringement.
>
> In general mainline distros distribute plenty of GPLv3 since the GNU
> project's software has been GPLv3 for a long time. Android and OSX are
> the only big OSes which include GPLv2 but avoid GPLv3.
>
> Now it is true many companies involved with printing want to avoid
> GPLv3 and so their engineers will not be able to contribute.
>
> The low-down is that I'm working at about one tenth the market rate.
> Thus I don't see myself as being an employee of GSoC but rather that
> GSoC is providing a stipend to keep me afloat while I work on this. In
> return I am asking that downstream users provide the same freedoms to
> their downstream as I'm providing to them and in some cases provide
> their own work under similar terms.
>
> So what I'm trying to say is what I want to get out of this summer is
> more power for users over their software, plus of course working IPP
> over USB printers. This may not be compatible with some business
> plans, which is okay since those business plans are not paying me
> market rates either. Now if those business plans were interested in
> making up the difference between the stipend and market rate I would
> love to negotiate a friendly license, for them. Until then the
> opportunity cost, the amount of money which would be in my bank
> account if I was not working on ippusbxd, is approaching one and a
> half Honda Civics at MSRP.
>
> Now the BSD people have a different goal, they would prefer their
> software get used even if it means users cannot edit it. For me if
> users cannot edit the software then it might as well be proprietary,
> and proprietary software licenses often include large bundles of cash.
> So my price sheet would look like: A: lots of power to the users, or
> B: lots of cash to me.
>
>
> Daniel
> PS: Michael, you might be thinking of how Apache 2 is not compatible
> with GPLv2 since it includes restrictions on patents. While the Apache
> foundation says that Apache 2.0 -> GPLv3 is compatible:
> https://www.apache.org/licenses/GPL-compatibility.html
> PPS: I understand where everyone is coming form, and I don't think any
> of you are wrong or evil. I don't want to hurt anyone with my words or
> actions. I hope this email layed out why I picked GPLv3
> PPPS: I do understand that someone from the BSD side of open source
> may think that I'm greedy, but please understand my preference is for
> user freedom over the cash.
>
> 2014-06-25 10:24 GMT-06:00 Michael Sweet <msweet@apple.com>:
> > Daniel,
> >
> > Unless you plan on filing patents for the work you've done for IPP USB,
> the patent protections of GPL3 simply do not apply.  (and the reason why
> corporations don't like the GPL3 patent provisions is because they are
> overly broad - use GPL3 software and you may be giving away your rights to
> assert your patents, even for defensive purposes...)
> >
> > Similarly, DRM is a non-issue - IPP USB involves no DRM and (I assume)
> you are not incorporating a blob or non-open code signing mechanism.  Any
> operating system mechanism falls under the "standard system
> library/service" clauses.
> >
> > What may be an issue is future contributions - GPL2+ is generally OK but
> GPL3 will assure that few corporations allow their devs to help out for
> fear of "contamination".  Apache is not GPL3-compatible.  2-clause BSD and
> MIT are GPL3 compatible but don't prevent people from taking your work and
> doing something non-free with it.
> >
> > So in my mind the best choices (the ones that will create the fewest
> problems long-term) are GPL2+ or BSD/MIT.
> >
> > But perhaps the best people to ask are the lawyers at the various Linux
> distros - they are the ones that need to distribute your work, and if you
> choose a license they are not comfortable with then it won't be included in
> the distros.
> >
> >
> > On Jun 25, 2014, at 12:05 PM, Daniel Dressler <
> danieru.dressler@gmail.com> wrote:
> >
> >> Hello everyone
> >>
> >> I just wanted to chime in and explain why I picked GPLv3.
> >>
> >> The two big reasons is that the GPLv2 does not handle DRM and patents.
> >> Which is understandable since version 2 was written before DRM was
> >> enforceable by law and before software patents were common.
> >>
> >> Now I'm not a lawyer but I have read the GPLv3 license. The license
> >> handles patents by requiring a patent license to cover the software.
> >> Which just means that if software A violates patent B and a developer
> >> for company C contributes to software A then patent B must be licensed
> >> to users of software A. With some extra details: that company C that
> >> patent B, and any new patents or new additions to the software do not
> >> create further obligations to license father patents.
> >>
> >> The purpose of the GPLv3's patent clauses is to prevent someone from
> >> distributing code and then placing further restrictions on the user.
> >> The GPLv3 is very similar to Apache 2 in regards to patents. With
> >> Apache 2 being Google's and Microsoft's preferred license as of late.
> >>
> >> DRM meanwhile is the bigger sticking point for corporations. This is
> >> also where there is controversy. My reading of the GPLv3 made me think
> >> it is okay to encrypt and check signatures of operating system images
> >> and updates provided the user can get their own images and updates
> >> installed. Which as a user an unlocked android this is a feature I
> >> like.
> >>
> >> In short I think GPLv3 does a better job of guaranteeing the user's
> freedoms.
> >>
> >> Now, any code in my presentation at the summit will be CC0, likewise
> >> any contributions to other projects as part of integrating ippusbxd
> >> will be under those project's existing licenses.
> >>
> >> Daniel
> >>
> >> PS: ippusbxd only links with libusb, a lgpl system library. I cannot
> >> think of something we could gain by switching to GPLv2. Apple already
> >> has their ippusbd and I doubt Microsoft is interested in using mine =)
> >> Even if one of them was interested I expect they would want to
> >> negotiate a more corporate friendly license than even GPLv2.
> >> PPS: The MIT and BSD licenses do not handle patents which I'd say
> >> makes them unreliable. The Apache 2 license is better if you want a
> >> non-copyleft license.
> >>
> >> 2014-06-25 8:26 GMT-06:00 Till Kamppeter <till.kamppeter@gmail.com>:
> >>> Should we do GPL2+ then or better something non-GPL (like MIT, BSD,
> ...)
> >>> to get maximum flexibility?
> >>>
> >>>   Till
> >>>
> >>> On 06/25/2014 01:09 PM, Michael Sweet wrote:
> >>>> GPL3 is a poison pill for most corporations, thanks to the draconian
> patent terms and generally unfriendly stance towards any other OSS license.
>  Apple has a blanket policy of not allowing any GPL3/LGPL3 use without
> special authorization, and an absolute prohibition of inclusion of
> GPL3/LGPL3 licensed software or documentation in any products.
> >>>
> >>>
> >>> _______________________________________________
> >>> Printing-architecture mailing list
> >>> Printing-architecture@lists.linux-foundation.org
> >>>
> https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture
> >> _______________________________________________
> >> Printing-architecture mailing list
> >> Printing-architecture@lists.linux-foundation.org
> >>
> https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture
> >
> > _________________________________________________________
> > Michael Sweet, Senior Printing System Engineer, PWG Chair
> >
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture
>

[-- Attachment #2: Type: text/html, Size: 12449 bytes --]

  reply	other threads:[~2014-06-25 20:51 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <m38up3ymxw.fsf@carbon.jhcloos.org>
2014-06-24 18:35 ` [Printing-architecture] ippusbd license Till Kamppeter
2014-06-24 19:06   ` Michael Sweet
2014-06-24 19:27     ` Ira McDonald
2014-06-24 19:56       ` Till Kamppeter
2014-06-24 19:59         ` James Cloos
2014-06-25 11:09         ` Michael Sweet
2014-06-25 14:26           ` Till Kamppeter
2014-06-25 16:05             ` Daniel Dressler
2014-06-25 16:24               ` Michael Sweet
2014-06-25 17:36                 ` Daniel Dressler
2014-06-25 20:51                   ` Ira McDonald [this message]
2014-06-25 21:14                     ` Daniel Dressler
2014-06-25 21:28                       ` Ira McDonald
2014-06-25 21:42                         ` Daniel Dressler
2014-06-25 21:49                         ` Till Kamppeter
2014-06-25 22:00                           ` Daniel Dressler
2014-06-26  1:59                       ` Michael Sweet
2014-06-26  7:59                         ` Daniel Dressler
2014-06-26  8:19                           ` Daniel Dressler
2014-06-25  7:56       ` Johannes Meixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAN40gSuxUUg1xaf=M3achUk+B7kUwxkM1_71ZHVswBKEHzEP8w@mail.gmail.com' \
    --to=blueroofmusic@gmail.com \
    --cc=danieru.dressler@gmail.com \
    --cc=printing-architecture@lists.linux-foundation.org \
    --cc=till.kamppeter@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.